Transport Tycoon Forums

Havent got time to get into the code yet, but I read OpenTTD still uses software rendering. What are the reasons for that? Why isnt OpenTTD using SDL or OpenGL? Sprite Rendering is not that hard of a deal. Is there something about the architecture which makes this harder than it should be, or has just no one deemed it worth it?
Also, what are thoughts of the development team implementing multi-threading? (Obviously much harder to do)

there's one main reason for this: it doesn't offer any benefits over the existing implementation. so it's not worth the effort to re-implement it, and the risks to re-implement it bad...

The multithreading question has been answered before: The reason OpenTTD is not multithreaded in its core simulation is because of the requirements of the multiplayer design. A game contains too many entities moving about and updating all the time for it to be feasible for a server to send a delta of the complete game state to all clients 33 times a second (on large games that could be tens or hundreds of megabytes of data per second). Instead the game works on a model of strictly deterministic simulation. Knowing the complete game state, and the list of commands to be executed in a game tick, lets you simulate the next game tick to reach an identical game state on all clients. This way, clients and server in a network game only need to exchange commands of the actions performed, which is generally on the order of at most a few kilobytes per second, regardless of the size of the game world.
If you introduce multithreading into the game simulation you can no longer guarantee any kind of deterministic simulation that's repeatable across clients and servers that can all be running on vastly different hardware and software configurations. Attempting to make it deterministic would be a Sisyphean task involving barriers and dependencies everywhere, which is not just practically impossible to program correctly (too many edge cases and difficult to trace dependencies between everything), it could very likely also result in so much performance loss to the synchronization that you'd have a net performance loss over running in a single thread like now.

jfs wrote: 27 Jan 2022 21:02 The multithreading question has been answered before: The reason OpenTTD is not multithreaded in its core simulation is because of the <snip>
performance loss to the synchronization that you'd have a net performance loss over running in a single thread like now.

This is incorrect.

RenX wrote: 27 Jan 2022 15:08 Havent got time to get into the code yet, but I read OpenTTD still uses software rendering. What are the reasons for that? Why isnt OpenTTD using SDL or OpenGL? Sprite Rendering is not that hard of a deal. Is there something about the architecture which makes this harder than it should be, or has just no one deemed it worth it?

SDL is just a library for managing rendering of pixels to a window. Doing OpenGL for the sake of OpenGL is just silly. Current implementation is fast and understood by the developers and fitting its purpose - whatever it is. No reason to change it.

Also, what are thoughts of the development team implementing multi-threading? (Obviously much harder to do)

Introducing multi threading into a mature existing code base is usually not worth it, at least on the wide spanning architectural level. Implicit dependencies between pieces of code tend to cause synchronization problems. Once you get it working it tends to be no faster than a previous approach. Localized usage of threads to solve specific tasks maybe introduced, but OTTD will never see a wide spread multicore support.

Besides - this game can run on a computer from 20 years ago. Not everybody makes 20kx20k map and fills it to the brim with stuff.

uzurpator wrote: 28 Jan 2022 21:29 This is incorrect.

Are you dismissing my entire argument, or just the "it might perhaps depending on circumstances not give any actual speed improvement" part?

jfs wrote: 28 Jan 2022 22:11 Are you dismissing my entire argument, or just the "it might perhaps depending on circumstances not give any actual speed improvement" part?

There is nothing in peer-to-peer networking that precludes, principally, from usage of threads. Supreme Commander uses the same model and had threads since inception.

There might be quirks in OTTD code that make such approach not feasible, sure, and as I said - there is no mcguffin to change it, but it does not mean that it can't be done.

uzurpator wrote: 29 Jan 2022 11:46had threads since inception.

and that is the key difference. if you design it multithreaded from the start, it can work. but trying to untangle an existing implementation into threads will either fail horribly, or not improve anything.

Eddi wrote: 29 Jan 2022 12:18 and that is the key difference. if you design it multithreaded from the start, it can work. but trying to untangle an existing implementation into threads will either fail horribly, or not improve anything.

Yes. That is what I already said.

then i don't know what we're discussing, because the original post was already written on the background that starting over with a new game is out of the question

OpenTTD heavily uses palette animation, implementing this in OpenGL will be a huge pain and will most probably be slower than the current software renderer.
In addition to this, development team will not change something that works good enough, they will rather implement new fancy features instead.

Sometimes what we think are the facts aren't the entire facts.

https://github.com/OpenTTD/OpenTTD/pull/7744

Actually, the OpenGL-based framebuffer output that is implemented now does do exactly that: Palette animation in fragment shaders. That's one of the major performance wins it can give over software output, in 32 bpp display modes.

This uses a special 40 bpp pixel format for five channels: Red, Green, Blue, Alpha, and Palette index. The RGBA values are used as-is, but if the palette index is not transparent, it instead gets transformed by the current palette, in the fragment shader. That lets the OpenGL video driver handle 32 bpp and 8 bpp graphics efficiently.

What the OpenGL video driver does not do is compose the frame from sprites, doing that would be a major rework of the entire graphics pipeline in the game, and probably mean that software rendering support would likely have to be dropped. Dropping software rendering definitely isn't happening until there's an extremely compatible alternative that works on basically anything.

This is just a driver backend, NOT a re-implementation of the whole blitter stack, i.e. OpenGL is not used to draw single sprites to the screen.

So it seems it still uses software renderer, and then copies video buffer to screen using OpenGL.

yes, that's pretty much what it does

I may have to eat my own words on the multithreading. It's still not much more than an idea, but I realized that by splitting the vehicle ticks processing into a "plan" and an "execute" stage, and requiring that vehicles must be able to fail their execution and restart from planning, it should be possible to run the planning in parallel, and hopefully the execution can be made so simple that it's not a major cost to run it serially. I've started work on doing this, but it's only a skeleton so far. (It may turn out that there actually won't be any performance gain from it. But it will definitely alter the way the simulation plays out.)

jfs wrote: 11 Feb 2022 11:06 I may have to eat my own words on the multithreading. It's still not much more than an idea, but I realized that by splitting the vehicle ticks processing into a "plan" and an "execute" stage, and requiring that vehicles must be able to fail their execution and restart from planning, it should be possible to run the planning in parallel, and hopefully the execution can be made so simple that it's not a major cost to run it serially. I've started work on doing this, but it's only a skeleton so far. (It may turn out that there actually won't be any performance gain from it. But it will definitely alter the way the simulation plays out.)

This was my thought. Deterministic multithreading in OpenTTD just requires being able to deterministically resolve any conflicts between ticks on different threads. The easiest way to do this that I can think of it to run all the planning first, find any conflicts, re-plan any conflicts, and then parallel execute the results.

The main conflict I can see is at junctions. You don't want which train gets to enter a signal block to be nondeterministic (or road vehicle at a road junction, etc). So - you'd just need an efficient way to detect when multiple vehicles are trying to enter the same junction and give priority to one in particular - whether it's the one that was there first, or the lowest ID, or whatever; as long as it's deterministic.

Note: With path signals you can end up with the case where two trains can both enter the same junction at once, but the exact paths they take depend on the order they are allowed to plan their path reservations.