October 17, 2017, 03:58:02 AMLatest Member: jbaustin2017

Author Topic: Features in the HUD.  (Read 3736 times)

0 Members and 1 Guest are viewing this topic.

HalfDecent

  • Registered member
  • *
  • Posts: 3
    • View Profile
Features in the HUD.
« on: October 10, 2012, 02:36:06 PM »
I've only played CorsixTH for a few hours, but already I've come across a bit of a problem. While the ability to play in higher resolution is great for general game play, it does make the HUD and buttons across the bottom a lot smaller than they used to be. This wouldn't be too much of a problem, except I found that I kept missing bulletins and announcements when they popped up, as they were too small to catch my attention.

I'm not a graphics designer, but I have made sprites for a few amateur games in the past, and I'd be happy to give recreating slightly bigger icons a go if someone could tell me what size and format they need to be in.


MarkL

  • Moderator
  • ***
  • Posts: 359
    • View Profile
Re: Features in the HUD.
« Reply #1 on: October 10, 2012, 06:33:11 PM »
I don't think it is bigger icons or buttons that are needed as anyone with a smaller display would lose to much of the screen to these.  What is needed is the ability for them to scale up or down in proportion to the display size. Take a look at Interface & font scaling which is here http://code.google.com/p/corsix-th/wiki/ProgrammingIdeas

If you feel up to the challenge that would be great.  if you have any questions then log into IRC chat - there is is link above - and ask them there. 

Lego3

  • Project Owner
  • *****
  • Posts: 398
    • View Profile
Re: Features in the HUD.
« Reply #2 on: October 11, 2012, 06:28:13 AM »
At the same time we will need new icons in the future. The problem is that we can't import new graphics into the game at the moment, and hence there is no decided format to adopt yet either.
For the end of the world spell, press Control, Alt, Delete.

MarkL

  • Moderator
  • ***
  • Posts: 359
    • View Profile
Re: Features in the HUD.
« Reply #3 on: October 11, 2012, 11:58:34 AM »
@ Edvin
Could a group be added - like the one for translations - so that anyone interested in this could come up with the formats needed?    At the same time perhaps there could be one for multiplayer/network play.

Lego3

  • Project Owner
  • *****
  • Posts: 398
    • View Profile
Re: Features in the HUD.
« Reply #4 on: October 11, 2012, 12:17:17 PM »
Hopefully we can soon get a more open wiki for it instead. :-)
For the end of the world spell, press Control, Alt, Delete.

Alberth

  • Registered member
  • *
  • Posts: 45
    • View Profile
Graphics format
« Reply #5 on: October 20, 2012, 09:11:05 PM »
In my opinion, the biggest drawback of the current format is that it is all one big blob of file-data. Very efficient for loading and distributing, but for new graphics, it means you have make all graphics before you can distribute any of it.

Instead, you want to distribute in smaller pieces. As a starting point for the discussion, let me show what I have done in my project.
I don't expect that you will want to copy the data+code as-is, but rather use some of the concepts of it, and adapt them to your needs.

In the FreeRCT project I have taken an opposite approach to the one big blob idea. Everything is a small piece, even the standard things. All stuff is free in the project, so I assemble the data files as part of the build process currently. It is however the idea to allow others to also make such data files as well somewhen in the future. A file starts with a file header (to recognize it is 'your' file), and then a sequence of blocks with varying content. Each block has a name, a version, and a length (for easy skipping to the next block, and for size checking). Blocks can refer to previous blocks (enabling sharing), first block gets number 1, second block number 2, etc. Block 0 is the 'nil' block for references to 'nothing'.


The description of the data file format is in http://code.google.com/p/freerct/source/browse/trunk/rcd/data_format.rst The file header is described near line 41. The remainder of the description is a long list of different blocks. For example near line 60 starts the description of how an image is stored (just look at what it contains, don't try to read all details. You may of course also read the details, but quite likely it will change anyway). Lines 68-70 is the a header of a block followed by a bunch of fields. A simple graphics block is at line 390, the BDIR block contains 4 arrows pointing in the direction of building. (Most other blocks that exist currently are just endless variations of tiles with one or more corners lifted up, not very useful as example.)
In FreeRCT, there are also blocks with complete game elements, eg like lines 326-370, in this case a little shop selling things to customers. It defines all elements that are part of a shop object in the game (that I needed so far, but it will expand probably).
Note that every block has the same header, with a unique name to distinguish blocks from each other.

Besides the documentation, there are of course also actual input files. I have not yet settled for the final input format. I tried native Python first, my current generation is an XML input format, in the end I expect to have some nice text format. The shop input-file that defines a single shop looks like http://code.google.com/p/freerct/source/browse/trunk/rcd/shops.xml Please ignore the horrible syntax, and instead just look at what type of data you have to enter. All XML horribleness around it can quite easily be changed, I just have not found the time to make it nicer yet.

Finally, there is also a meta-xml file, that defines what you can enter as input, ie a machine-readable version of the data format description. (XML turns out to be quite useful for this.) Useful for a project that is expanding without knowing upfront what is all needed at the end (like with FreeRCT), perhaps less useful for CTH.



If you want a modular file format, I think this is a feasible way of doing it. The blocks make it very flexible. The version number in each block makes it easy to change a block definition. Depending on what you want, you can either refuse, load and upgrade, or ignore old blocks when you encounter them.

The current block contents is likely completely useless to CTH.
You likely want to have a different pixel format, iirc CTH just uses W*H bytes images, much less complicated than the format I use currently. If you want a different type of graphics, that would also be possible, a block can carry anything that you can express in bytes of data :)
As for the other blocks, the sky is pretty much the limit. You can just define a block for replacing sprites (ie a reception desk in 4 orientations), have an 'object' with all its properties, or even define a 'room' with everything in it.
I have plans to use the format for save games, and scenarios as well.