Future graphics

[krtaylor]

Anyway, the point I'm making is that the TTD pallette is a LOT more complex than it appears, and any replacement to it will have to bear all these functions in mind.

[Vurlix]

Which is why i pointed out it would take a while

[krtaylor]

I'm wondering if it would be possible to do OpenTTD so that it supports two different, completely separate formats:

1. The GRF files, as with the original TTD graphics and the new graphics sets

2. This new, higher-resolution format, to which everything would change over time.

[Alltaken]

this is how things can be done. (suggestion)

there is a "colour" graphic set for each object, this would use magic colours for things that TTD would change.

then there is the Custom graphics sets (each designer can add as many of these as they want) they could be assigned to replace colour ones if wanted or the user could choose to use these. these have no magic colours.


the other methog of course which people may not have thought of. is basicly adding another colour channel,

the alpha channel is naturally gonan be alpha, depending on the number of magic coulrs we would honestly need i would propose these as options for being used.

r=255 b=255 g=0 (purple full saturation)

g=255 b=0 r=0 (green full saturation)

g=255 b=255 r=0 (aqua marine full saturation)


however my real idea was that graphics had animations built into the file. rather than blink on/off i would have proposed having a number of frames and having the config file sorting this kinda stuff out. e.g. timing of them and such. IMO although it makes for a slightly larger file size (matter of a few bytes or Kb) it allows more freedom. for example you could have a door opening animation for trains etc... lights could flash on/off or could flash 5 times red then once green etc...


this way you would only need one magic colour for one file and thats the gradient fill graphics set that TTD uses for its internal graphics. using a grey scale would be fine IMO (if not a grey scale an aqua marine scale, e.g. red is always set at zero, and this means you could have grey/black element in the design that didn't change, noboy will ever use any colour that the green=the blue and red is zero)

so i only see limited use for a pallet of magic colours, using seperate images is the current technology. but considering we have 16 million colours to play with we can surly choose one that people don't want to use LOL (or even an entire scale people don't want to use)


Alltaken

[Tyrell]

Just some personal feelings/suggestion about ... (think ware)

1) : all views are based on personal feelings, and not necessarily based on facts)
2) : I'm not a big or good writer, and need serious time to (read), think and write,
This is limiting my possibility to really discus items/ideas. no excuse, just practical fact)



Personal I see no real need to ditch the pallets graphics in favor for true-colors.
To effectively use the "implied" promise of better graphics would not really work (unless...).

Considering the small size of the sprites that are used in TT,
there is not really enough pixel space to use smooth color transitions,
so you would need to increase the sprite to make the use of true-color graphics really work.

Because the small sprite sizes, you need a minimum color(gamma) level difference to let
the details stand out. 256 pallets graphics are just fine for that.
Granted 256 is not a big number, and 512 would have probably worked better.
but 256 it is, and going for true color to bypass this limit is in my view a little overkill.
(actual pallet use is les than 256 colors)

Secondly, because the sprite are relatively small, the ingame graphics like the direct turning
of the trains do not feel really un-natural. But when you start to use bigger sprites, this will
also become a bigger problem. The more details are used, the more difficult it becomes to avoid
that strange feeling of inconsistence when looking/playing the game.

Personal experience with 'railroad tycoon', oww nice smooth curved tracks ... being used by trains
that are still limited by 8 direction ... bleeeeeeee(inconsistent use of graphics), made me ditch the game.



The way I would go about ... code.
1) fix and cleanup the initial code. (no adding or changing anything other than whats true to TT's)
(exception to this would be none game-play related things like using PNG(256colors!) instead of bmp for schreenshots, etc)
-> v1.xx (TTDLX-org)
2) adding TT-patch options + some things that where not possible by TT-patch, like bigger maps.
But I would try to maintain the general TTDLX feeling (gameplay and graphics)
-> v2.xx (TTDLX-extended)
(a personal fantasy would be to use a better base pallet for the game, kind a like the RCT pallet.
but, hehe, talking about a lot of work)

3) looking at posibility's/problems to use the core game-play ingine, but with bigger sprites at truecolor level.
I think that 3D in this case would be not be a bad alternitive, considering your going to need to redo
all of the sprites anyway, it would probebly amount to the same amout of work.
This would probebly also need a lot of rewriting of the core, so it would probebly be better to compleetly
seperate this as a seperate project. (o dear, a other one)

...

( currently best 3D-remake I have seen of a old clasic,
UFO: Alien Invasion, Technical Demo http://ufo.myexp.de/ )

[graphic are like the cover of a book, they might make it look good, but they don't make the game/story]

[Tyrell]

Mmmm, if that fish_pond is showing the future of simutrans graphics.
I might seriously reconsider my points of view. (grin)

[krtaylor]

1. As long as OpenTTD stays reverse compatible, I think it would be nice eventually to support also a new graphics standard which would include more colors. This could also support one level more of zooming in.

2. Including animations in the graphics is a good idea, but it's more complicated than it appears, there need to be some controls. For instance, it would be cool for steam locos to have animated side-rods, but you'd have to be able to control the speed of the animation based on the train's speed, or at least to stop it when the train is stopped.

[Bjarni]

1. As long as OpenTTD stays reverse compatible, I think it would be nice eventually to support also a new graphics standard which would include more colors. This could also support one level more of zooming in.

It have to be reverse compatible and compatible with graphic sets for TTDpatch. The DB set is really good and it looks like more really good ones are on the way. It would be a shame not to support that in OTTD.

2. Including animations in the graphics is a good idea, but it's more complicated than it appears, there need to be some controls. For instance, it would be cool for steam locos to have animated side-rods, but you'd have to be able to control the speed of the animation based on the train's speed, or at least to stop it when the train is stopped.

Haven't you heard of wheelslip
I think it is a good idea. It's not to much use right now, but with better graphics, it would be great. If the steam from the chimney could be matched as well, it would be outstanding.
Different colors on smoke would be nice too. If a steam freight train is fighting a hill, the fireman will give it A LOT of coal and the smoke would not be white. White smoke is pure steam, which is nearly only present when the fire has died (shame on that fireman)

[jixor]

IMHO

I like 24bit png for the graphics Lets keep rez reasonable and maybe not worry about features like rotating the view. Perhaps even mng support to enable animated anything, probably just buildings. The files could come packed in zips, tar, tgz or whatever with maybe an xml formatted config file that could allow for great flexibility and ease of specifying attributes. Perhaps even for buildings we could give them special attributes that effect their surroundings, such as increase traffic to airports in the city or such.

Then regarding reverse compatibility perhaps the game could on load scale up/convert old graphics formats in runtime or maybe some type of converter can be created. It would be a shame to hold back development of any impressive new features for backwards compatibility. Maybe in 5 years ottd will look as good as transport giant? Of course making the game look great is more about the artists than the programmers I would expect, unless you can do both



All this said you know at the end of the day the graphics dont particularly concern me, incorperating the features of ttdpatch and then some, such as larger mapps, higher bridges would be so much more awsome Then the new graphics concentration might go into drawing new transit types rather than redrawing new graphics. Oh sounds nice!



so thats 24bit png/mng (using alpha chan for transp) + easy config, thanks.

[Alltaken]

1. As long as OpenTTD stays reverse compatible, I think it would be nice eventually to support also a new graphics standard which would include more colors. This could also support one level more of zooming in.

2. Including animations in the graphics is a good idea, but it's more complicated than it appears, there need to be some controls. For instance, it would be cool for steam locos to have animated side-rods, but you'd have to be able to control the speed of the animation based on the train's speed, or at least to stop it when the train is stopped.

1. agreed 100%

2. as far as i have thought. the animation speed for a train in particular (your scenario) could be controled by the speed of the train which is known already within TTD. the graphics artist would just need to in the config file write in somthing along the lines of "animation 1= a1,a2,a3,a4.png, once per 20km/h" i am not a coder so it will be nothign like that, but basicly i would imagine the option of it.

i would imagine for a train in particualr you would have an animation for
Moviement (like you say)
Doors closing/opening (one is the reverse of the other)
maybe it flashes lights at crossings, or toots its horn at crossing (so another location of possible action)

basicly i imagine events trigger animation sequences, so the designer animates these sequences and codes them in the xml file.

for propellor planes/helicopters i would imagine similar, planes i think should have blinking lights on them too (i like graphics you see)

also i personally will design graphics for 16 directions (or perhaps 32) wetehr they are used in the gmae or not, i like to go overboard on things. i have often been criticised for my over the top effort. (i have much proof)


Alltaken

[Bjarni]

2. as far as i have thought. the animation speed for a train in particular (your scenario) could be controled by the speed of the train which is known already within TTD. the graphics artist would just need to in the config file write in somthing along the lines of "animation 1= a1,a2,a3,a4.png, once per 20km/h" i am not a coder so it will be nothign like that, but basicly i would imagine the option of it.

i would imagine for a train in particualr you would have an animation for
Moviement (like you say)
Doors closing/opening (one is the reverse of the other)
maybe it flashes lights at crossings, or toots its horn at crossing (so another location of possible action)

basicly i imagine events trigger animation sequences, so the designer animates these sequences and codes them in the xml file.

The way I see movements of the rods:
1. creation of sprites of every possible posision.
2. put them in order, so if they are looped, it looks like the wheels are turning
3. When the engine is moving, it goes to the next sprite each time the engine have moved any given length. This can be calculated from speed.
4. Each time the engine puts out smoke, it checks the sprite. If it is a sprite, where one of the cylindres are in the end (or high speed have made it skip it) it puts out a big puff, othervise a small puff. Exception is if the sprite haven't moved since last puff(standing still). This is how smoke looks/works on real steam engines. I can explain why, if anybody is interested.

About the crossings:
I already suggested the horn on the patch mailing list. Nobody answered I still like the idea.
Early crossings could be made without barriers and the trains would have to use the whisle. Later, barriers can be installed, no horn and higher speed.
Really old/cheap crossings might not have flashing lights. Then the trains would have to use the horn (we have a few of that kind left here, but they are private roads only)

[Alltaken]

yes thats exactly how i see the graphics working.

some sets of graphics would have fixed timings, others could be related to the speed etc...

Alltaken

[dJP]

Anyway, the point I'm making is that the TTD palette is a LOT more complex than it appears, and any replacement to it will have to bear all these functions in mind.

I agree. However, if the palette issue was resolved to support 16bit or higher colour systems then that might just kill two birds with the one stone - allowing for good anti-aliasing code to be introduced and the zoom function could support any arbitrary factor from 1% to 200%. Keeping the people on the large screens happy and keeping the game's memory usage down.

Has anyone ever tried to sit down and create thousands upon thousands of sprites at a high resolution? For free? Not to mention the landscapes as well. High res trains would look pretty silly on crusty pixelated landscapes.

I think the development of OpenTTD would suffer dramatically if it went down the path of high res sprites. Besides - it has been and in my opinion always should be about the game play.

[CobraA1]

We programmers will still be working on gameplay, don't worry about that. Whenever they finish deciding on how the graphics are going to be done, I'm sure it won't be too much trouble implementing it. Besides, we have plenty of time - making graphics like what alltaken is proposing is going to take a long, long time - if he doesn't lose interest first.

[Alltaken]

if he doesn't lose interest first.

LOL

true true.

but to be honest i enjoy making graphics more than playing the game

Alltaken

[BobXP]

Right, I have an idea about how to store the graphics in their files.

Extension for an individual sprite (not an object) is *.tgs

And the way of storage:

Code: Select all

First byte indicates palette to use. 00 = temperate, 01 = arctic, 02 = tropical, 03 = toyland. Note that the first 3 climates have the same palette - so we could make different ones if we wanted. Just make this the value of the climate to use.

Second byte indicates width, third indicates height. Fourth indicates X offset, fifth indicates Y offset.

Now comes the novel bit! We have 2 bytes for each pixel down the side of the sprite. So if the sprite is 32 px high, we have 64 bytes here. The first byte in each pair indicates the first non-transparent pixel on that row, so if we want the first 10 px to be transparent, we enter 0A. The second byte in each pair indicates the last non-transparent pixel in that row. So if we have an image that is 64 px wide and we want the last 10 px to be transparent, we enter 36 (hex).

Next comes the actual bit map, one byte per pixel. Note that it only stores pixels between the first and last non-transparent pixel in each row, specified above! E.g: if we want the first non-transparent pixel on row 1 to be palette index 255, we enter FF as the first byte.

Everyone understand that? No? Here's an example:

The raw file, 609 bytes:

Code: Select all

01 20 20 10 10 0F 11 0E 12 0D 13 0C 14 0B 15 0A 16 09 17 08 18 07 19 06 1A 05 1B 04 1C 03 1D 02 1E 01 1F 01 1F 02 1E 03 1D 04 1C 05 1B 06 1A 07 19 08 18 09 17 0A 16 0B 15 0C 14 0D 13 0E 12 0F 11 01 01 01 02 02 01 01 02 02 02 02 01 01 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 02 02 01 01 02 02 02 02 02 02 01 01 02 02 02 02 01 01 02 02 01 01 01

can be rearranged into:

Code: Select all

01 20 20 10 10

0F 11
0E 12
0D 13
0C 14
0B 15
0A 16
09 17
08 18
07 19
06 1A
05 1B
04 1C
03 1D
02 1E
01 1F
01 1F
02 1E
03 1D
04 1C
05 1B
06 1A
07 19
08 18
09 17
0A 16
0B 15
0C 14
0D 13
0E 12
0F 11

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 01 01
-- -- -- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- -- -- 01 02 02 01
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 01 01

in which we see the structure of the file (refer to first "Code" box for help on reading that). The -- are just to push the text along.

Let's compare the sizes here:

294 bytes for a 256 color PNG
609 bytes for my format
947 bytes for a GIF
2102 bytes for a 256 color BMP

Hm. Well PNG won that one. But my format is easier to read and edit. And the offset and palette values don't exist in other formats either.

[CobraA1]

a: I want to get out of 256 colors, and start using 32-bit color.
b: I want to be able to be able to use the GIMP or other similar program to edit my graphics.
c: I don't care about readibility, as long as the GIMP or other similar programs can read it.
d: With the size of today's harddrives, I'm not too worried about how big/small the graphics are.

[Saskia]

@Bob, that looks like a XPM image, not very good since without compression and large

[BobXP]

not large in relation to BMP...

Besides, since it's uncompressed, zip compression will compress it better than a PNG!

[Vurlix]

Besides, since it's uncompressed, zip compression will compress it better than a PNG!

Yeah, right.

All PNG files are in fact zip compressed.