3d ottd

[Expresso]

Lets help one fantasy out of the world: if 3D is used, and you rotate the viewport a bit, it does not mean the entire map needs to be redrawn. However, redrawing the screen would take considerably longer then it would take now, and that would slow down the game even further... even on newer systems with better processors - yes, there is still a processor dependant part when you use hardware 3D.

However, the prospect of haveing complete viewing freedom sounds very attractive and would be very helpful - especially when the new map array arrives and we could have games with cliffs in them. Maybe a good reason to seperate the graphics rendering code and the rest of the program? How about makeing the renderer a plugin, so the player can decide if s/he wants to use the default renderer or the opengl one?

Would it be viable to OPTIONALLY put such a renderer on its own thread? Threading would reduce game lag, at a possible cost of processor time... however with multicore/-processor systems (which is the future atm) it is very attracitive)

But whatever happens, if this gets implemented try to keep the performance bottleneck at a minimum and don't kill playability by not giving camera control much thought. If camera control gets implemented correctly with something like this, you might even improve playability.

[remsys]

oh, please, please, yes, yes, yes. OTTD3d. Sounds great, doesnt it. Im looking out for centuries now. And there is nothing like Transport Tycoon jet. There must be dark forces at work.
Once, long long time ago, there was a game, like TT, called " Strasse und Schiene ", with real nice 3d trains+signals and trucks and tiny little 3d-cows , no planes and no ships , but it was only a playable demo and later forbidden by law anyway.
Even the dark forces again! They want us to buy their games and play on their servers!
I played TA Spring for a while, its open source too. Funy thing is, these two games, TT and TA, both oldscool and both set standards for future games and build up a large player community.
But i think spring is more powerfull with 3d, than ottd, well look at it. It is possible to build factorys and towers in spring, on a carthesian map, just like in all the other games, simcity for example, you know.
I cant do it my self, but it would bee so great, OTTD-3d via TA-Spring engine. Must be possible.
I know, this will never be, because of the gameming industrie(rhyme). So i will sit and wait another 20 years, maybe forever.
But if you have it,
it should have a construction view, with catchpoints at the end of the roads and rails for better viewability while constructing and another pritty rotatable view.

[Alberth]

If you had done your home work first and read a few threads on 3D OpenTTD suggestions instead of bumping an ancient thread, you'd have known it is quite impossible to get the current game in 3D (even if you don't mind the huge amount of art work that is needed).

Besides we already have a 3D version, namely Transport Empire.

[Eddi]

Once, long long time ago, there was a game, like TT, called " Strasse und Schiene ", with real nice 3d trains+signals and trucks and tiny little 3d-cows , no planes and no ships , but it was only a playable demo and later forbidden by law anyway.

that game is not fully dead yet. the long winding legal process ended a few month ago, and the future of the project is currently undecided. see http://3dtt.novatek.de/thread-208.html [german]

[remsys]

It is my special to reanimate dead threads.^^
The dark forces lost!
THX for the uplink..great news..where to play??^^

[XeryusTC]

where to play??^^

The playground would fit you the most

[thor82]

3D will probably screw up the gameplay. If you run a 512x512 map and connect all the industries your pc will start lagging in 2D, let alone 3D. So you wouldn't be able to work on big maps because it's simply not doable with these computers.

i don't think this is correct: actually i think (by guessing) that openttd loads and handle the whole map at the same time, and that's why it gets really heavy.

in every 3d game that has at least a "decent" programmer, there are systems that splits the environment letting the viewer load only the parts that he has visible.
that's not really difficult with system like octrees, bsp, and other things that i abandoned years ago

anyway.

i think that a 3dopenttd requires a BIG project ,and thus a BIG project manager, i don't think you can simply use a piece of openttd and render it in 3d.

[Rubidium]

in every 3d game that has at least a "decent" programmer, there are systems that splits the environment letting the viewer load only the parts that he has visible.

That becomes interesting in OpenTTD; trains not running when they are outside of the viewport, industries not producing when they are out of the viewport, ...

[Born Acorn]

It is my special to reanimate dead threads.^^

You're my new arch nemesis.

[audigex]

Now that this has been bumped (for great justice)

Could it not feasibly make the game marginally faster to run it in 3d? In 2d, much of the work is done by the CPU - in 3D, is it possible that by offloading the graphical work to the GPU it may be slightly quicker?

[thor82]

look : to put it simple:

take any 3d game from the last 10 years: they have bigger data than TTD.
what ttd/openttd lacks ( i guess ) is a system that splits the data load when objects are out of the viewport, so everything is loaded.

In EVERY 3d game there is a system that does so, so the speed is not a problem.

the problem is that ttd/openttd MUST be rewritten i think from scratches, so it's not a small thing to do.

[Rubidium]

what ttd/openttd lacks ( i guess ) is a system that splits the data load when objects are out of the viewport, so everything is loaded.

You think that OpenTTD draws the complete map and then only shows you a subsection of the map? If so: stop with making unfounded guesses and assumptions that aren't correct. OpenTTD ONLY draws the part that is visible for the player.

Also most 3D games I know calculate the state of the rest of the "map" too. This can be seen in most (if not all) first person shooters where you can get shot in the back or where other bots can kill eachother outside of the area that you are viewing. After all, those bots are outside of your viewport.

[thor82]

what ttd/openttd lacks ( i guess ) is a system that splits the data load when objects are out of the viewport, so everything is loaded.

You think that OpenTTD draws the complete map and then only shows you a subsection of the map? If so: stop with making unfounded guesses and assumptions that aren't correct. OpenTTD ONLY draws the part that is visible for the player.

Also most 3D games I know calculate the state of the rest of the "map" too. This can be seen in most (if not all) first person shooters where you can get shot in the back or where other bots can kill eachother outside of the area that you are viewing. After all, those bots are outside of your viewport.

ttd surely does something that shouldn't be done, i don't know what, since i do not know how it's developed (And do not want to know, i don't have free time )
i say so because it's "relatively" slow compared to other games that are much heavier than ttd.

i don't know the causes, but i say this based on 2 things:

i can play oblivion / fallout 3 at almost full <everything> , but the 2048^2 map of ttd slows down my pc.
i don't know the precise cause, multithreading? gpu/cpu balancing ? something has to be. you name it,i can't

small precisation: i love openttd and think that even as it is is perfectly playable, i only think that if in the far future this will be solved, it opens a new door on maps/game systems far bigger than 2048^2

(add-on):
i only let my imagination run before me, i know that maybe there are bigger issues, and priorities, but try imagine a sort of "mmo"ttd it could be a revolution of ttd online =P


p.s.
btw i said loaded, not drawn

[Rubidium]

How much 'state' do Oblivion/FallOut have? Lets assume it has 1000 things you can destroy/move and maybe 10 things that change state; opening a door, bullets that are flying through the air, etc.

Now, how much state does a 2048x2048 map have? A few hundred towns, a few thousand industries, millions of trees that spawn, grow and die, thousands of water tiles trying to flood neighbours, thousands of fields of industries.

And that's just an empty map. Then there are quickly thousands of vehicles (each wagon is counted as a vehicle) trying to navigate over the map, millions of pieces of cargo being routed over the map, thousands of houses and thousands of industries creating/accepting/producing cargo. Hundreds of trains reserving paths and then freeing the reservation.

So in short OpenTTD on a 2048x2048 map has millions of 'objects' of which the state changes, for lots of them EVERY tick (30 milliseconds). So OpenTTD has (if my assumption is correct) thousands (if not hundreds of thousands) of times more things to check/change the state of every tick.

Now most recent computers have a 'good' GPU. The GPU is designed to do one thing and do it fast: draw. This makes the GPU unuseable for the general purpose things like calculating the state. Also with those games you can 'cheat' and just don't draw a few frames; with 160 FPS and a screen capable of drawing 80 FPS it would be barely noticeable (if at all) that half of the drawing isn't done. With OpenTTD skipping the drawing is noticeable and because drawing isn't the biggest consumer of processor time it wouldn't help much. After all, all the state changes are the thing that takes the time.

[thor82]

i understand your point, and agree with your analysis.
i still have a "but" =P

But ...as you are describing it, it seems that nothing is possible,i sincerely cannot think that the problem of ttd is the quantity of stuff inside:
i could completely agree and definitely shut up if we were talking about calculating orbits or something similar, but in ttd the kind of elaborations shouldn't be THIS complex.
(wait before launching me something: i know that programming a game is NOT a thing that everybody can do,and i know that openttd has thousand of features that needs to be taken care of,so i'm not telling that creating ,mantaining and evolving ttd is an easy thing to do )

but i cannot believe that this is the limit of ttd.
a modern processor can do things that were unthinkable just only 5-7 years ago,and as far as i can imagine, we are not talking about parallel calculus, or heavy processor loads, we are talking (correct me if i'm wrong) of hundred of thousands small operations on the same quantity of entities so, for this motivation i cannot think that this cannot be an obstacle to ENORMOUS maps and further developments

[Alberth]

but i cannot believe that this is the limit of ttd.
a modern processor can do things that were unthinkable just only 5-7 years ago,and as far as i can imagine, we are not talking about parallel calculus, or heavy processor loads, we are talking (correct me if i'm wrong) of hundred of thousands small operations on the same quantity of entities so, for this motivation i cannot think that this cannot be an obstacle to ENORMOUS maps and further developments

Think again.

We do get reports about machines running into their CPU speed limit with larger games.

Note that a doubling in the length of a map means squaring the amount of space, and thus squaring the number of entities that may exist at a given map. The game expanded from 256x256 to 2048x2048 which means 64 times more work. Also, the game has become more complex. Each new feature adds a case that must be checked against before the machine knows what to do (and with some new features the cost may even be bigger).

Last but not least, processors did increase in speed, but to a large extent that is an increase in speed of internal CPU operations (ie adding, multiplying, dividing, etc). For lengthy calculations that gives a good speed-up compared to older processors. OpenTTD however does very little calculations (eg it does not do floating point calculations), it mainly does simple comparisons against data in the map. The map resides in main memory. Those compare operations thus use the memory-CPU data-bus very heavily, an area where processors made less progress (memory chips have not become that much faster).

[Rubidium]

The fastest (Intel) CPU in 1995 was about 200 MHz (Pentium Pro 200). Now the fastest CPU (Core i7-975 Extreme Edition) is roughly 13300 MHz (core clock (3.33 GHz) * number of cores (4)). This is an increase of 68. Okay, this is not very fair as the instruction count per clock might have increased, but OpenTTD only uses one core: lets assume the instruction count per clock doubled, then the fastest CPU is 34 times faster than in 1995.

Now lets see some algorithms:
- pathfinding: Imagine that on average the number of tiles to consider is 1.1 times the length of the route; with a complex route you easily get into a much bigger factor. Now maps are 64 times larger the time it needs is 64*1.1 = 70.4 time more.
- running of vehicles: in 1995 you could have 80 trains, 80 road vehicles, 40 aircraft, and 50 boats. Now you can have 5000 of each. So 20000/(80+80+40+50) = 800 times more vehicles.
- cargo generation: for each cargo generating 'entity' the closest station must be found. Increase the number of cargo generating entities and the number of stations with 64 and you quickly end us with 64 times more generators must find the closest in 64 times more stations, resulting in 4096 time more 'required' power. With maximum station spread the closest station tile could be about 64 tiles away from the station; just a tile in the north and south corner and the 'cargo generator' in the east of west corner of the station 'area'. This would mean that it has to search 128*128 (=16384) tiles, which makes searching the station list which is usually much much shorter (500 stations is really a lot).
- cargo handling: with 800 times more vehicles you also have 800 times more cargo and in 1995 there could be only one source and expiry date on the cargo of one wagon so the first/oldest value was kept when cargo from more than one source was added. Now this doesn't happen anymore. Even ignoring this, that amount of to-be-transported cargo has increased 800 times.
- the drawn area: this has increased quite significantly too; in 1995 640x480 was what you had with 2 levels of zoom-out. Now you've got 4 levels of zoom out and 1280x960 is close to the norm. 2 levels of zoom out mean (2*2)^2 = 16 times more can be seen. The screen increase also mean 4 times more can be seen, combining both means 64 times more can be seen and thus needs to be drawn.

All those numbers are (significantly) more than the increase in the speed of processors. Why isn't OpenTTD dieing under it's own weight? Because over the years we have improved quite a few algorithms that make it possible to keep the situation workable.


Now... the MAJOR 'obstacle' for OpenTTD to become multithreaded or have increadibly huge maps where we just don't calculate everything is: multiplayer.
It really is: either multiplayer or multithreading. You simply CANNOT combine both and expect miracles. A desyncing (in MP) and partly (self-)corrupting version that runs on all cores is fairly easily written, but when you want it to be NOT (self-)corrupting you quickly end up with a version that is only like 50% faster on two cores and maybe 75% faster on four cores just because it needs to do so much inter-core communication to make sure they do not corrupt eachother. We also wrote a version that didn't desync which was only 5-10% faster on two cores and 5-10% slower on a single core. That is really NOT worth the effort.

Ofcourse there are ways to make this kind of game in a manner that scale (fairly) well, but then you need such a different design that it simply isn't like TTD. Is it the intention of a clone of TTD to be not like TTD? Personally I would say no. However, you're free to make another game that scales well on multiple cores, just don't call it OpenTTD.