Future direction of OTTD graphics
Moderator: Graphics Moderators
Talking about mobiles or PDAs was only an example of the benefits of a new software design. We were proposing a client/server architecture, which might bring some new advantages. This is, the posibility of keeping old, and new graphics system working, a new multiplayer system, easy of porting to new platforms (as mobiles, pdas, or non windows/linux systems)...
Yes, and yet he seems to have missed the entire discussion. If you want to shout at someone, shout at MeusH for making another one of his "I know everything" statements.DaleStan wrote:What is the antecedent of "you" here? In case you hadn't noticed, Archonix, this thread was started by mdhowe.Archonix wrote:Did you actually read the thread, or just the last few posts?
Now, I'm sorry if I came across as offensivein my last post, it wasn't my intent.
well now that i am back from my trip of 4 days of solid biking over 320Km i can answer.
A) different graphics engine games will NOT be interchangeable. it would require an EXACT COPY of exisitng graphics, i.e. the kirby paul engine would need a counterpart in the 3d engine. it would therefore break all GRF support.
A1) unless we have a default engine or default building graphics etc.... that replaces EVERY not supported graphic with it. (same stats as the original, but a default graphic element) this would be ugly, but playable.
B) the track layout is being changed to a far more efficient, more userfriendly interface for track laying (all around more ergonomic for the user) at the same time. maintaining modern graphics for both sets would be possible but rather pointless.
B) Unless i create the current set of tracks in the new graphics without smooth corners. but this would also require a total set of new sprites for the OLD graphics engine. i.e. we would need 102 (or is it more) sprites per track type for the old system.
[warning ultra brutally honest text, cover your eyes if you don't like to be offended]
all in all, IF YOUR NOT DOING WORK ON IT, I DON'T CARE ABOUT YOUR OPINION. (to be brutally honest, and rather nasty LOL)
the amount of extra work required to make an interchangeable system is astronomical compared to creating a newer system.
[\warning ultra brutally honest text, cover your eyes if you don't like to be offended]
IMO the best option is this. OTTD branches while a new GFX system is implimented. you can maintain an older version of OTTD with all the features of 0.4 (or whatever the final version before the new GFX engine s done) and newer patches that people build. this means you can play all your extisting games.
however the new GFX engine OTTD will not be compatible with older games (as it offers far more and better gameplay options) so you can use it for any of your newer games, if you start a new game you can do so in the newer version, need to play an old game you can use the old version.
to be honest, a certain amount of debate on such topics is good, but in reality it would be much more productive just picking up a 3d app, and going for gold making new graphics
.
Alltaken
A) different graphics engine games will NOT be interchangeable. it would require an EXACT COPY of exisitng graphics, i.e. the kirby paul engine would need a counterpart in the 3d engine. it would therefore break all GRF support.
A1) unless we have a default engine or default building graphics etc.... that replaces EVERY not supported graphic with it. (same stats as the original, but a default graphic element) this would be ugly, but playable.
B) the track layout is being changed to a far more efficient, more userfriendly interface for track laying (all around more ergonomic for the user) at the same time. maintaining modern graphics for both sets would be possible but rather pointless.
B) Unless i create the current set of tracks in the new graphics without smooth corners. but this would also require a total set of new sprites for the OLD graphics engine. i.e. we would need 102 (or is it more) sprites per track type for the old system.
[warning ultra brutally honest text, cover your eyes if you don't like to be offended]
all in all, IF YOUR NOT DOING WORK ON IT, I DON'T CARE ABOUT YOUR OPINION. (to be brutally honest, and rather nasty LOL)
the amount of extra work required to make an interchangeable system is astronomical compared to creating a newer system.
[\warning ultra brutally honest text, cover your eyes if you don't like to be offended]
IMO the best option is this. OTTD branches while a new GFX system is implimented. you can maintain an older version of OTTD with all the features of 0.4 (or whatever the final version before the new GFX engine s done) and newer patches that people build. this means you can play all your extisting games.
however the new GFX engine OTTD will not be compatible with older games (as it offers far more and better gameplay options) so you can use it for any of your newer games, if you start a new game you can do so in the newer version, need to play an old game you can use the old version.
to be honest, a certain amount of debate on such topics is good, but in reality it would be much more productive just picking up a 3d app, and going for gold making new graphics

Alltaken
- Born Acorn
- Tycoon
- Posts: 7596
- Joined: 10 Dec 2002 20:36
- Skype: bornacorn
- Location: Wrexham, Wales
- Contact:
Butally honest? You want brutally honest?Alltaken wrote:[warning ultra brutally honest text, cover your eyes if you don't like to be offended]
all in all, IF YOU'RE NOT DOING WORK ON IT, I DON'T CARE ABOUT YOUR OPINION. (to be brutally honest, and rather nasty LOL)
[\warning ultra brutally honest text, cover your eyes if you don't like to be offended]
Here's brutally honest for you:
If you are not an OpenTTD developer, I don't care about your opinion.
Even if you are, I still don't care about your opinion.
I care about what Will Happen.
Absoutely correct, and "ugly but playable" not always a good idea. (Is it ever?)Alltaken wrote:<point A>
What are you counting there? *rummage*Alltaken wrote:i.e. we would need 102 (or is it more) sprites per track type for the old system.
TTD tracks have 6 independent tracks (trg1[r] #1005-10, for rail) and 26 ground-specific sprites (trg1[r] #1011-1036 for rail in temp). These 26 include all the possible combinations of track and slope. The three standard climates make a total of 116 (6+26*4); toyland would add another 32.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- Born Acorn
- Tycoon
- Posts: 7596
- Joined: 10 Dec 2002 20:36
- Skype: bornacorn
- Location: Wrexham, Wales
- Contact:
we all care what will happen, hence some people have jumped in the deep end and started to push what they want to happen. I.E. done some work towards their own goals. (a major thing about Open source projects)DaleStan wrote: I care about what Will Happen.
most people doing work towards developing thing, creating graphics.... have been tackelling these very questions ALL day. have been debating with other developers about the feesability of certain things and have already come to the conclusion of what this thread is about.
for example the idea of having two overlayed graphics engines that you can switch between has already been talked about, but it is rather hard to do. and would require about 2-3 times the work to achieve. hence we have concluded that its not feesable (we are donating our time)
this is why i react the way i do to this thread. i don't want people to get an impression that this thread will effect anything.
we are always open for new ideas, and i personally read all the threads around for new ideas. but compiling a list of demands, is not going to help.
we all care about what Will Happen.
the best way to get what you want is to create what you want.
Alltaken
oh BTW sorry if i sounded overly harsh earlier on.
i would like to encourage people to debate topics and issues. and more importantly encourage people to contribute towards what they feel the direction of OTTD should be.
this does however require work on the publics behalf.
some people are working towards implimenting OpenGL into OTTD for trains and such. some are working on 2d sprites..... which works or becomes popular is only determined by how many people from the public support these implimentations. and how much personal work is done towards a goal. debating and discussing ides of what can be done, will only go as far as hoped if someone takes it upon themselves to do so.
if we want to have two graphics engines overlayed on each other then people will need to do these.
A) seperate rendering from the game engine
B) create hundred of sprites per tracktype for the new track layout (in the old GFX engine), and about 20 per tracktype for the new GFX engine
C) recreate ALL existing engines (and newGRF added engines) ina new graphics format
D) create a new track laying tool for the old graphics layout. and emulate the old track laying style in a new track layout.
E) create a whole new set of ground sprites for the old map system to allow for more vertical levels and smaller hills....
its a lot of work. but anyone is welcome to contribute towards it, if they feel that a dual graphcis engine would be benificial and worth it.
i can provide all the source files for my graphics for those wishing to help with anything.
Alltaken
i would like to encourage people to debate topics and issues. and more importantly encourage people to contribute towards what they feel the direction of OTTD should be.
this does however require work on the publics behalf.
some people are working towards implimenting OpenGL into OTTD for trains and such. some are working on 2d sprites..... which works or becomes popular is only determined by how many people from the public support these implimentations. and how much personal work is done towards a goal. debating and discussing ides of what can be done, will only go as far as hoped if someone takes it upon themselves to do so.
if we want to have two graphics engines overlayed on each other then people will need to do these.
A) seperate rendering from the game engine
B) create hundred of sprites per tracktype for the new track layout (in the old GFX engine), and about 20 per tracktype for the new GFX engine
C) recreate ALL existing engines (and newGRF added engines) ina new graphics format
D) create a new track laying tool for the old graphics layout. and emulate the old track laying style in a new track layout.
E) create a whole new set of ground sprites for the old map system to allow for more vertical levels and smaller hills....
its a lot of work. but anyone is welcome to contribute towards it, if they feel that a dual graphcis engine would be benificial and worth it.
i can provide all the source files for my graphics for those wishing to help with anything.
Alltaken
am counting new track layout designed by oskar (once you use it you will be hooked foreverDaleStan wrote:What are you counting there? *rummage*Alltaken wrote:i.e. we would need 102 (or is it more) sprites per track type for the old system.
TTD tracks have 6 independent tracks (trg1[r] #1005-10, for rail) and 26 ground-specific sprites (trg1[r] #1011-1036 for rail in temp). These 26 include all the possible combinations of track and slope. The three standard climates make a total of 116 (6+26*4); toyland would add another 32.



http://doug.mudpuddle.co.nz/gallery/ottdwip/rounded3
http://doug.mudpuddle.co.nz/gallery/ottdwip/file_layout
its actually more efficient for pre rendered sprites than the existing track layout design.
hope that answers the question.
Alltaken
- Born Acorn
- Tycoon
- Posts: 7596
- Joined: 10 Dec 2002 20:36
- Skype: bornacorn
- Location: Wrexham, Wales
- Contact:
Alltaken wrote: C) recreate ALL existing engines (and newGRF added engines) ina new graphics format
Exactly. Instead of spending time making completely new engines and models, Making models for the already existing trains would be better as it could possibly point to a savegame converter or even compatibility with past savegames. Older models would do. Im sure there are people in the MSTS community with models usable.
yes this is fine to me.Born Acorn wrote:Alltaken wrote: C) recreate ALL existing engines (and newGRF added engines) ina new graphics format
Exactly. Instead of spending time making completely new engines and models, Making models for the already existing trains would be better as it could possibly point to a savegame converter or even compatibility with past savegames. Older models would do. Im sure there are people in the MSTS community with models usable.
i am more than happy (infact it would be nice) to have all the current trains brought into a new graphics format.
if anyone is willing to learn how to modell in 3d, i can help teach them blender/ point you to locations on how to use it. (free and open source)
even trains from locomotion would be good to have in OTTD, perhaps some of the people who have made mods for locomotion would be willing to give their models to us? (don't know if any of the trains are the same as in TTD)
Alltaken
- Born Acorn
- Tycoon
- Posts: 7596
- Joined: 10 Dec 2002 20:36
- Skype: bornacorn
- Location: Wrexham, Wales
- Contact:
what's your problem with starting a new game?Born Acorn wrote:Alltaken wrote: C) recreate ALL existing engines (and newGRF added engines) ina new graphics format
Exactly. Instead of spending time making completely new engines and models, Making models for the already existing trains would be better as it could possibly point to a savegame converter or even compatibility with past savegames. Older models would do. Im sure there are people in the MSTS community with models usable.
I think it's completely ridiculous to spend time on trying to maintain backwards compatibility just to save some people some time playing the game.
And once the newly proposed track system works, they'll never want to play with their old 90-degree-corner-networks again.
if you want to keep playing the old stuff, then go to the patch!
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
- Born Acorn
- Tycoon
- Posts: 7596
- Joined: 10 Dec 2002 20:36
- Skype: bornacorn
- Location: Wrexham, Wales
- Contact:
You imply that conclusions have been arrived at. What were they? I have been reading these forums since before the "NEW *" threads started, and ONLY thing I remember is someone (possibly DarkVater, but I'm really not sure) telling MeusH to code an OpenGL demo, if it thought OpenGL would be so great.Alltaken wrote:most people doing work towards developing thing, creating graphics.... have been tackelling these very questions ALL day. have been debating with other developers about the feesability of certain things and have already come to the conclusion of what this thread is about.
I have seen NOTHING sufficiently clear for my tastes. What follows are some examples of sufficiently clear statements:
"The double-size, 32-bit, graphics will be used."
"The TTD-sized, 8-bit graphics will be used."
"TTD-sized, 32-bit graphics will be used."
&c.
"The code will be the same as the curent NFO, with extentions as necessary."
"The code will have a better interface, but will have the same binary structure."
"The code will be completely different, both in interface and structure."
&c.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
DaleStan
from my unerstanding what has been decided so far is.
sprites will be 128x64 pixel, .PNG images at 32 bit (RGBA) per image. (ground sprite size)
some people want OpenGL 3d trains, yet another group wants 2d trains to the same specs as above, with about 40 directions of sprites for smoothness. this is still undecided and i guess we will see which wins.
track layout will be the corner, and mid tile system (but they are unsure how they will do it still) Oskars layout basicly. and its very very nice to use.
the landscape will have 2 levels of height where there is currently only 1 level.
i hope that is specific enough.
Alltaken
from my unerstanding what has been decided so far is.
sprites will be 128x64 pixel, .PNG images at 32 bit (RGBA) per image. (ground sprite size)
some people want OpenGL 3d trains, yet another group wants 2d trains to the same specs as above, with about 40 directions of sprites for smoothness. this is still undecided and i guess we will see which wins.
track layout will be the corner, and mid tile system (but they are unsure how they will do it still) Oskars layout basicly. and its very very nice to use.
the landscape will have 2 levels of height where there is currently only 1 level.
i hope that is specific enough.
Alltaken
Last edited by Alltaken on 05 Dec 2004 05:55, edited 3 times in total.
Yes, that is indeed what I wanted to see.
Thank you.
Does anyone know about the coding, though?
Or is that still an unknown?
I did some work (far from finished, though) on how to extend the NFO files to (1) define OTTD features, and (2) remain mostly compatible with TTDPatch. It appears that the second part won't be useful any more, but (*adds several missing </TABLE>s*) I've decided to put it up over here anyway. It keeps true to the NFO format; that is, all data is still written in hex.
There are probably whitespace errors, because I made the I-D-ten-T error of opening with a Macroshaft product. This particular one (Ivfhny Fghqvb.ARG (beautiful rotism there)) apparently thinks that </TT> REQUIRES trailing whitespace. Even if it wasn't there in the first place, and even if most decidedly don't want it. (If I wanted it, I would have put it in, no?)
Once you skim that, FE00 is (obviously) unfinished, and I have ideas for FE01 (which declares not real spirites, but patterns of [FF]02 cargoIDs), FE02 (if needed), FE03, and FE04. The other FE sprites may or may not exist (more likely not) though I am open to suggestions (post or PM).
Thank you.
Does anyone know about the coding, though?
Or is that still an unknown?
I did some work (far from finished, though) on how to extend the NFO files to (1) define OTTD features, and (2) remain mostly compatible with TTDPatch. It appears that the second part won't be useful any more, but (*adds several missing </TABLE>s*) I've decided to put it up over here anyway. It keeps true to the NFO format; that is, all data is still written in hex.
There are probably whitespace errors, because I made the I-D-ten-T error of opening with a Macroshaft product. This particular one (Ivfhny Fghqvb.ARG (beautiful rotism there)) apparently thinks that </TT> REQUIRES trailing whitespace. Even if it wasn't there in the first place, and even if most decidedly don't want it. (If I wanted it, I would have put it in, no?)
Once you skim that, FE00 is (obviously) unfinished, and I have ideas for FE01 (which declares not real spirites, but patterns of [FF]02 cargoIDs), FE02 (if needed), FE03, and FE04. The other FE sprites may or may not exist (more likely not) though I am open to suggestions (post or PM).
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: Amazon [Bot] and 20 guests