Transport Tycoon 3D

[Born Acorn]

If the cities were to be modelled like that (claustrophobic and crowded), I'd love it. Currently, TTD seems to be very evenly spaced.

[RMJ]

if you like building big networks, then you will see why most of us dont like it, already now there isnt a computer in this world that can run it if you build to many, and besides look at all the other transport games, there is A LOT, every single one of them failed. Mostly because of there fancy 3d and lack overview. The cartoonish 2d look is what makes openttd what is it.

[prissi]

I think a 90° rotation (with no rotation the things on the tile just the same house always) is possible with small alterations with the current code. Only assymetric buildings may look strange. For something just to "look" behind a hill, this is not too back. Maybe one must return to normal view before saving or city expansion. Or forbid rotation until all builings installe have the required views. And since the schedules only contain station index nummers, the routing tables should survive intact. Imho a patch is not entirely out of question.

[sforget]

I like the idea of 90 degree rotations.

You don't have to save rotation information, just always start in the default rotation.

Allow buildings to have 4-sides if the designer decides to create them, otherwise just show a single side when the building doesn't have them all.


While I've never looked at the code to OpenTTD, the biggest problem I can see involves drawing the rotated world to the user. Nothing internal should need to change - what does the code care what angle you are viewing the world at?

[exe]

Viewport rotation is nice, but please do not call Draw(x,y) to Draw(y,x) change "Transport Tycoon 3d".

The repository for 3d data is at:
http://sharpttd.top100.net.pl/wiki/inde ... stries.xml
It gets all imported to the game automatically with one click. On other pages of wiki there is also the rest of data files.

I'm going to upload dummy models for everything, and then they can be improved gradually. It's easy to start free Wings3d modeler, improve a model, and upload it back. Even easier for textures. There is also a custom .3ds viewer to see how models and industries completed from the parts look in the game.

I think the best looking things in 3d transport tycoon will be big height differences, tall buildings and inside the train view.

if you like building big networks, then you will see why most of us dont like it, already now there isnt a computer in this world that can run it if you build to many

No, 3d TT does not slow from big networks, but from zooming out too far. If normally 3d takes 10% of cpu leaving 90% for logic, and you zoom out much it will take 30% cpu and leave 70%. But if something is not on the screen it does not slow the game additionaly from 3d rendering. Besides, if everything about vehicle movement is in TrafficFlow object, it is much easier to almost double the train simulation speed by multithreading.

[gix]

Not true: A sprite is just a billboard with transparency. I've seen a few 2D games remain 2D and switch to hardware acceleration. It's entirely possible to port the game to DirectX and retain the original graphics.

I know, and I said that I am aiming for that. Seems like some people don't really read the posts here.

[DaleStan]

Besides, if everything about vehicle movement is in TrafficFlow object, it is much easier to almost double the train simulation speed by multithreading.

Except on single core machines.
Except that every TrafficFlow object must interact with every other object (TrafficFlow, StationCargo, AirportStatus or otherwise) in a precisely defined order.

[exe]

Except on single core machines.

And except on quad core machines.

Except that every TrafficFlow object must interact with every other object (TrafficFlow, StationCargo, AirportStatus or otherwise) in a precisely defined order.

I don't know much about it yet, and this is probably wrong, but:

Code: Select all

void GameLoop()
{
//...
traffic_flow.Tick();
//...
}

Only TrafficFlow can change vehicle positions and signal states, and only during Tick(), so external changes like starting a vehicle are enqueued for the Tick().
Just pathfinding is a read only operation, so the vehicle order does not matter and locks are not needed.

BTW There is also a .dll for networking based on http://wiki.openttd.org/index.php/Network_Protocol , that could be used to add multiplayer to any game that is open (all players see full state), and has explict commands.

Code: Select all

    public interface IGameWorld
    {
        void Tick();
        void DoCommand(ICommand command, int player_id);
        int GetStateHash();
        byte[] SaveState();
        void LoadState(byte[] savegame);
        string GameInfo { get; }
        //....
    }

Oh, and sorry if I sound rude saying that everyhing should be done from zero and differently than OpenTTD, while not showing much done. It's just some experimenting.

[DaleStan]

All vehicles must, among other things:
1) Enter (or queue to enter) signal blocks
2) Move to (or queue to move to) a new airport block
3) Turn (or queue to turn) onto a new road
4) Load (or queue to load) cargo
in the same order. In addition, the ordering of cargo loading at, cargo transferring at, cargo rating updating for, and delivery of cargo to, stations must also be strictly defined.

If any of those ever happens in an undefined order, then either you will have
1) one vehicle in two different locations on two different machines
2) one vehicle with two different cargo loads on two different machines
3) one station with two different cargo quantities on two different machines, or
4) one station with two different cargo ratings on two different machines

I think you're also falling into the one-writer many-readers fallacy. This is not a safe arrangement. At no time may you have any thread reading a given memory location if another thread may be writing to it, nor may you have any thread writing to a given memory location if another thread may be reading it. There are three safe arrangements for multithreading:
1) One single thread is doing both reading and writing
2) Any number of threads are reading, and zero threads are writing
3) Any number of threads are writing, and zero threads are reading (Note that the writing threads here cannot depend on the original value, since that would involve reading the original value.)

[exe]

Yes, in the general case vehicles must run in defined order, but I was thinking that most costly is the A* on track selection, and it can be done multithreadingly, even when vehicle still has a lot of time to the final decision.
1. Most often vehicle will just update its TileProgress and only when it is greater than X, it would get to single-thread list.
2. Each disconnected rail segment (mostly when owned by different companies) can be in its own thread, not including cargo loading.
3. Often it could be proven that for the next X ticks train can't in any way get in contact (signal contact) with any other train. Then it could be multithreaded too. But it would be hard.

Can the vehicle simulation fps can be reduced by 50% on heavily loaded maps, and interpolation be used instead in the viewport?

But the important thing now is to get some 3d models done.

[Rubidium]

Some small-scale tests have been done not so long ago and showed that implementing multithreading for stuff that can be easily multithreaded, like the sprite sorting and drawing yielded a negligable speedup for multicore computers and a 10-20% decrease in speed in single core computers.

Update tile progress -> update the hash table of where vehicles are -> needs to be done in same order or: DESYNC.
Cargo loading and unloading influence eachother -> needs to be done in same order or: DESYNC.
Arriving vehicles influence cargo loading/unloading -> needs to be done in same order or: DESYNC.
Arriving vehicles or company A can influence cargo loading/leaving of vehicles or company B -> needs to be done in the same order or: DESYNC.
That proving and making it done in the other thread is probably more expensive than actually not multithreading.

Getting in contact with "any" other train is not enough. It cannot come in contact with any other vehicle, like road vehicles.

[Zephyris]

So... I see youve set up that wiki page and started doing some basic 3D modelling and texturing, and I would love to help! I can provide very high quality bump-mapped full colour texures and low poly models. BUT I'm only willing to do this if there is some kind of 3D engine taking shape! What is the status of the 3D graphics code? If it is taking shape nicely then what is are the constraints on file formats, 3D model scale, number of polygons and texture resolutions?

[exe]

So... I see youve set up that wiki page and started doing some basic 3D modelling and texturing, and I would love to help! I can provide very high quality bump-mapped full colour texures and low poly models. BUT I'm only willing to do this if there is some kind of 3D engine taking shape! What is the status of the 3D graphics code? If it is taking shape nicely then what is are the constraints on file formats, 3D model scale, number of polygons and texture resolutions?

3D models created from TTD graphics is something so basic and obvious that it just can't get lost or be wasted.
And on MIT license they can be used for everything.

Models should be really low poly, so it is possible to view massive parts of map. And the texturing should look almost exactly like the original. One map square is one unit in modeller. 3ds files can be imported and exported anywhere including Wings3d, but they can lose some info.

However SharpTTD is not a 3d renderer for OpenTTD, but a totally different game. 3d rendering is just very small part of it. I wouldn't trust this game before I could play it - build some signalled rail routes between industries and earn money, save and load. (to done this year?)

So models are needed anyway right now, at least the dummy ones.

[CobraA1]

Some small-scale tests have been done not so long ago and showed that implementing multithreading for stuff that can be easily multithreaded, like the sprite sorting and drawing yielded a negligable speedup for multicore computers and a 10-20% decrease in speed in single core computers.

Yeah - in order for multithreading to be truly effective, major portions have to be separated out, not just a function here and there. On other words, the entire graphical system would have to be put into another thread rather than individual routines.

The ultimate goal is, of course, to have processing split evenly between CPUs, and to have the splits happen at the highest level possible to reduce context switches in single core machines.

For all practical purposes, the application has to be written from the ground up to support multiple cores. I seriously doubt the devs have the resources for a complete rewrite of OpenTTD.

[Rubidium]

Some small-scale tests have been done not so long ago and showed that implementing multithreading for stuff that can be easily multithreaded, like the sprite sorting and drawing yielded a negligable speedup for multicore computers and a 10-20% decrease in speed in single core computers.

Yeah - in order for multithreading to be truly effective, major portions have to be separated out, not just a function here and there. On other words, the entire graphical system would have to be put into another thread rather than individual routines.

FYI: the split has been made in the most logical place/the place where it could be done without a locking mayhem. This is just after the determination has been made what sprites to draw, as this can influence the game state it cannot be done seperately from all the other stuff that changes the gamestate. The actual sorting of the sprites, so they are in the right order to draw, and the drawing are done in a separate thread. But then again, the drawing only takes like 0.5% of the CPU power so any moving of memory to another core means you have undone the potential gain in time.

There is NO way to make OpenTTD multithreaded in a useful and effective manner. The only way means rewriting the WHOLE backend of the game, i.e. everything that has only the slightest thing to do with changing the game state including networking and determining what to draw. When you start doing that, it's better to just throw away *all* the code and begin from scratch, effectively making a new game. Which then means that OpenTTD still has not been made multithreaded in a useful and effective manner.

And yes, you can talk long about making it multithreaded in a useful and effective manner, but you simply cannot do that without completely rewriting, i.e. starting from scratch and ditching NewGRFs as they assume a lot about the order changes are done.

[magnato]

I think this is very interesting! And it must be important to support new initiatives - at least morally! For the future of the game, it is important to find new paths, and attract more people. A 3D version of the game is really a new dimmension to the game. Challenging - yes! - and with no guarantie of sucess, yet I belive it will boost new creativity and energy. New interest in the game is never bad - as well as atracting new people, developers and designers. Too me this is whats important. And a 3D version will never replace the 2D version, but will perhaps be a new game in itself - inspired by the original game.

[eraser]

Back in the day when i used to talk to chris sawyer he told me that the playstation version lost vast amounts of money because noone wanted to play a 3D version of TTD and no one wanted to play it on a console. He was planning at one stage back in micropose days to release it on the pc. 360 Camera views would be good sometimes tho.

Just my 2 cents.

-M

[RMJ]

It must be pretty awesome for someone like Chris Saywer to follow the progress that has been made on that old game, its really come such a long way compared to the old days

Also Transport Tycoon was really ahead of its time. when it was made, simply the most unique game ever, so simple, yet so fun an addictive

[planetmaker]

I think a 90° rotation (with no rotation the things on the tile just the same house always) is possible with small alterations with the current code. Only assymetric buildings may look strange. For something just to "look" behind a hill, this is not too back. Maybe one must return to normal view before saving or city expansion. Or forbid rotation until all builings installe have the required views. And since the schedules only contain station index nummers, the routing tables should survive intact. Imho a patch is not entirely out of question.

I'd like to support this view.

A possibility to rotate the play field in steps of 90° would help me to keep an overview and look for good places for new stations easier. In a first step none of the graphics would have to be changed. A 2nd step then could be to implement graphics for all four sides of the buildings and displaying one or the other depending on one of the four possible camera positions. Nothing what-so-ever had to be changed on the vehicles' graphics as all four views are already available.

Both steps (or at least the first) should in my crude understanding of algorithms be relatively simple to implement compared to a full 3D movable camera while bringing much of its benefits - but I might be way off.

Best regards,
planetmaker

[Rubidium]

How would you rotate the bank 90 degrees without changing the graphics and without making it look odd?