New Graphics Engine

[acidd_uk]

I have read through some of the posts regarding new grapics formats (increasing resolution or sprites / colour depth, new animations etc). I appreciate what I'm suggesting is a mammoth coding task, but I am trying to reconcile all the new graphics format suggestions which seem to basically boil down to 'my format is better than your format' in a lot of cases.) Also, if I've missed a development roadmap for a new graphics engine then please just point me at it and close/delete this thread. But I couldn't find a definitive one. Disclaimer over, on to the suggestions:


Wouldn't the most flexible solution be to have two separate graphics engines.

I appreciate this would (I'm assuming) take some major decoupling of the game engine and the graphics engine to the point that the game / screen area state is sent directly graphics engine and that decides exactly how to render it. E.g. A client / server model. So the game includes a graphics server with a defined interface and then a graphics client to actually display

The original / vanilla client would be the existing system (decoupled of course), supporting 8-bit colour and the original/existing graphics format. That way people on lower end machines are still ok.

The new engine would use a new graphics format for the input, and be generally lovely and extendible and nice. As such, the suggestions to use XML to tag the files is a good one, that way extra animations and other features etc may be easily catered for. The new graphics format could use sprites as big (resolution) as you want (though I'd tend to think that *4 current resolution would be plenty for most people).

Each object would be a tar file, containing a 'master' XML file describing what all the graphics in the archive are for, their size etc etc). The images could be further tar'ed within the object tar in order to keep them reasonably organised. The details could be handled by the xml file. The size of the object's tar file would be quite reasonable, since every graphic would be compacted in the png format and the size (memory) of graphics would be high compared to the uncompacted xml file. Therefore little efficiancy is lost by not compacting the xml.

The whole graphics set (collection of object tars) could be wrapped up in another .tar file. That solves the clutter problem.

Now onto the more technical suggestions:

The actual sprites:
32-bit (RGBA) PNG images seem to be the way to go as PNGs are both feature rich and compacted. Resolutions that are multiples (suggestions of 4* by default seem good) of the original graphic set are sensible. As has been said by many people, they can be scaled up or down as necessary for the game and anti-aliased as desired by the player.

The images needed per object:
1. A master image, which is a static picture of the object. A normal gray scale could be used for the parts that have to rendered in game with the player colour (see point 3).
2. Animation overlays - a set of images for each animation sequence that get sequentially overlayed on the main image - details such as animation speed / order etc can be specified by the XML file (or sub-file).
3. Player (or random for town buildings etc) colour overlays - PNG bitmask for every image in (1) and (2), specifying which bits should be coloured to the player colour. It may be possible to push this mask into each PNG image, I'm not up to speed on the full PNG spec and whether you can define in effect multiple layers. I think that it's important for the individual sprites to follow the PNG spec. But as long as it follows the PNG spec it should be fine either way.


Now when the graphics client gets game state information from the server, it can decide for itself how it should be rendered. The client should have the 'intelligence' to know (for example) that if a train is at a level crossing then the level crossing lights etc needs to be animated. I.e. the client should contain all the rules necessary for drawing the game based only on the current game state. Also, that way more animations can be added to an object and then the appropriate rules for using them can be embedded in either the client or the XML descriptor of the object. I'd tend to say the client should have the rules hardcoded for decent execution rate. Then it's up to the client to support as many animation 'events' as possible and up to the graphic artists to include whatever subset of those animations they wanted. If an animation is missing then it simply isn't displayed, for example, if the train engine has no spinning wheels animation then the client just moves the static sprite around the screen.

This is very much a brain dump of about half an hour and so I suspect it will be full of flaws. Please criticize gently

Edit: This is of course a very long term thing and I appreciate that.

[Lf3T-Hn4D]

Each object would be a tar file, containing a 'master' XML file describing what all the graphics in the archive are for, their size etc etc). The images could be further tar'ed within the object tar in order to keep them reasonably organised. The details could be handled by the xml file. The size of the object's tar file would be quite reasonable, since every graphic would be compacted in the png format and the size (memory) of graphics would be high compared to the uncompacted xml file. Therefore little efficiancy is lost by not compacting the xml.

Not a bad idea. XML is good at describing these stuff

I'm not up to speed on the full PNG spec and whether you can define in effect multiple layers.

Nope. you can't. PNG is only a single layer format. For multiple layers, you will need MNG. But too bad, no one was interested in it then, so it's dead. I belive one can make it such that there will be two images instead of one. One for the graphics that will not change, and another for the masking that will change according to the company colour. As for size optimization, the masking image can be a gray scale 256 colour image. I belive that's quite A LOT of colours for a company colour shade

[acidd_uk]

Sorry if I wasn't clear - I've just checked the png spec and you can indeed have a 1 bit palette png image. So thats ok for the company colour masks

Of course, the pixels that are masked for the company colour would be blended with the company colour - which would make interesting (but probably useless) possibilities of blending a colour with the company colour. Anyway, as long as the pixels that are going to be company colour masked are on a normal grayscale then you have a nice 256-level gradient.

[Lf3T-Hn4D]

not sure what you mean. you're saying that you can have an additional bit in a png image? Sounds weird. and at anyrate, what you are suggesting is the masking being made as monotonous image (black and white) being only haveing a bit for each pixel. yes filesize is small but I think it'll takeup quite A LOT of cpu power just to use that mask and translate an image colour into grayscale then to company color. imho.

[acidd_uk]

I mean each image png image has a corresponding 1-bit png mask image.

The process would be render the normal png, then render the 1-bit image over the top using a multiplicitive blend of the player colour. E.g. 0 = keep original colour, 1 = multiply by player colour. So a white square that got rendered to the player colour (say red) would be:

(R,G,B)

White ---- Red ------ Red
(1,1,1) * (1,0,0) = (1,0,0)

Gray ------------ Red ------ Dark Red
(0.5,0.5,0.5) * (1,0,0) = (0.5,0,0)

Etc. Shouldnt be much extra processing power and given we are talking about using this for todays PCs I don't think thats much of a processing hit.

[romek41]

Romanujan says:

I've got a proposal - I think that file format designed for storing vehicles should be able to store two types of sections:

1. Vehicle description
a) vehicle type (truck, clockwork locomotive, electric locomotive suitable only for passenger and mail transport, etc.)
b) vehicle name (like i.e. EU-07, JU-52 or TU-144)
c) manufacturer name (like i.e. Pafawag, Junkers or Tupolew, respectively)
d) engine power, max speed, capacity, etc.
e) list (nonempty) of elements storing the following data:
- country ID (0 for unspecified country, 1 for original TTD vehicle - then the list should contain exactly one entry)
- year when vehicle is available (different years for different countries are possible)
- nonempty list of graphics data ID's - there can be more than one painting scheme - each scheme should contail bit signalizing if there is no player colour on the painting scheme, or there is a lot of player colour (like original TTD models)

2. Vehicle graphics data
a) graphics data ID (unique only in the file)
b) palette type
c) vehicle graphics data (for most vehicle data) or file name and sprite numbers (for no-free vehicle data, like Michael Blunck's Tempset) - if there is additional set of carriages dedicated to specific locomotive, then it also should be placed here

Every file should contain at least one type 1 and at least one type 2 section.

Such file layout would have the following advantages:
- it's possible to use the same graphics for very similar models without storing the same graphics twice (like SH'30 and SH'40)
- it's easy to write code that allows player to choose only vehicles from specified region of the world
- it would be possible for player to choose different vehicle painting schemes or even repaint vehicles in the depot
- it would be possible to distribute vehicles alone or in sets (like DBSet XL)

And I opt for not using XML ( parsing XML is too complicated)

[MeusH]

why not to make zip or some packing stuff so one can put png and easy .cfg file (easy to read and edit in notepad) so it would work?

[iridium]

Some damn good suggestions here, especially seperating game code and graphics rendering.

What about aspects such as the actual rendering of the images?

OpenGL, for example? it could handle z-buffering, alpha blending etc etc, and hand off a lot of the graphics rendering work to the graphics card as opposed to the work being done on the CPU. How about SDL, or some other graphics library to make use of this?

This would (could, rather) also allow for smooth zooming in and out, which would be neat.

I think using XML is a good idea, even if it has to be a stripped down version of it to make the parsing simpler. I'd be willing to spend time writing the XML parsing code - (I've written XML parsers before..) I don't see why it would be too complex. Tars also good.

It's a bit OT, but how about providing a 'continuous' (ROYGBIV) colour bar rather than discrete colour selections such as red, green, dark green, etc?

I discussed the graphics engine with Darkvater recently but have forgotten most of the stuff we talked about.

You make good suggestions, acidd_uk.

I'd love to chip in with coding and anything else I can help out with,

irid.

[Alltaken]

well i have been doing some graphics for a hopefull new set.

how i would set it up is this.

4 images all lining up with each other having the exact same co-ordinates for sprite overlays (so the XML file needs only one set of co-ords

image 1.
Base sprites (background sprites, for object which have other things go infront of them)

image 2.
forground sprites, for things which protrude from the ground, and have things able to go behind it.

image 3.
company colours. this would be a "grayscale" image. white annotates colour, black annotates black. this would be changable via a HUE type filter, and will overlay over the other images (a 1 bit mask IMO is not so hot, because it doesn't take into account alpha and such.)

image 4. shadows.

many sprite sets won't need all images, or may need MORE images (if animated)


i will post my images for people to comment on later. as a designer i know what will work from MY POV, but coders have been talking to me (openttd chat) so its not just me imposing things onto others, i am listening and altering how i lay things out.

talking about it solves, nothing, the best thing is for me to have Mock-ups of what i plan, and then have people come up with "real world" sollutions to problems posed.

so wait for a example file, then discuss it as much as you want. theroretical stuff ain't helpfull. most design solutions come through doing it.

Alltaken

[oboka]

I had already posted this in other (wrong) thread. So I'll try here:

Talking about new graphics, I have a little suggestion for making the process of creating new graphics, a little easy. Looking how tedious is to make a new train for Locomotion where every train has hundreds of sprites in all posible positions, I wonder if it could be possible to combine, 2D graphics for the layout and 3D graphics for the mobile objects. Other games have done this and looks nice, take a look at this game:

http://www.gamespot.com/pc/rpg/sacred/screenindex.html

In addition, effects like smoke, explosions, fire, could look nice!

[MeusH]

How about vehicles as models? Then they could be seen from all directions! I can easily texture the UVW-maps, I just love it!

[Alltaken]

Looking how tedious is to make a new train for Locomotion where every train has hundreds of sprites in all posible positions

sorry not hard at all. i have made a quicktime VR image for my friend and it had 650 images of all angles of a 3d object.

it was very very easy to set up.
and once set up it can be used again and again and again.....

so the 3d model can be outputted in a matter of minutes to a set of images. for OpenTTD i would forsee about 40 sprites per vehicle "max" a set rotated in isometric. and a set of it going up/ down a hill. thats all.

it seems harder to put a 3d engine in than it might be worth. also IMO 3d models always look blocky even if UV mapped well.

Alltaken

[MeusH]

it is 8 images from right to left and 8 images from up to down for each image lrft-right. This is 512.
Another possiblity is 9x9x9=729 images. This is still really undetailed.

You should made at least 48627125 images. But it is easier to make one 3d model and let game pick right angle, isn't it?

[Alltaken]

MeusH

ummm a train will never go vertically, nor will it ever go above about 25 dgrees (in the game) so we can rule out all those angles.

the majority of a trains movements will happen at isometric/flat levels, which is about 16 images (if done smoothly)

then we have 2 angles which it can go up/downhill, I.E. 'NE'-to-'SW' and 'NW'-to-'SE' so if you imagine 3 angles of the train in this situation that is 12 more sprites.

a total of 28 sprites.

seriously this is EASY to do. you couldn't possibly use 512 sprites.

a full 360 degree x 360 degree situation is rediculous to say the least.

and you still make a 3d model, then you output it to images, you will get beautiful graphics this way.

Alltaken

[MeusH]

Yes, I know transport tycoon train uses only 8 directions, but how about smooth turning with new graphic?

Oh, thanks for remindering me about flat terrain Anyway 360x40x40 is big number

[Villem]

Locomotion has hundreds of angles for each trains, atleast 135 each. Is your method going to be considerably uglier in any turns or anything?

[oboka]

Another argument is the space needed to store all those bitmaps. This is a free game, and most people downloads it from internet, if each train model is 3Mb, the whole game will go about, maybe, 200-300 Mb.
That will make people afraid to download it and try it, and, anyone of us has the needed bandwidth to serve that amount of transfers?

[Killer 11]

if the bandwith is a problem then we can put it on edonkey

Hey i have downloaded a 250 mb size free game (babylon 5 i found her)
but i can say that the time that was spended was worth it

[jabberwalkee_]

America's Army is getting near a GB atm i believe and i know plenty of dial-upers who spent the couple of days it took to DL it.

Enemy Territory is around 600Mb as well i think

[acidd_uk]

From a size point of view, it might be smaller (not easier to include a version of POVray and then render the models during the install.