Why doesnt OpenTTD run on OpenGL yet?
Moderator: OpenTTD Developers
Why doesnt OpenTTD run on OpenGL yet?
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)
Also, what are thoughts of the development team implementing multi-threading? (Obviously much harder to do)
Re: Why doesnt OpenTTD run on OpenGL yet?
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...
Re: Why doesnt OpenTTD run on OpenGL yet?
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.
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Why doesnt OpenTTD run on OpenGL yet?
This is incorrect.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Why doesnt OpenTTD run on OpenGL yet?
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.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?
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.Also, what are thoughts of the development team implementing multi-threading? (Obviously much harder to do)
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.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Why doesnt OpenTTD run on OpenGL yet?
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.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Re: Why doesnt OpenTTD run on OpenGL yet?
Yes. That is what I already said.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Re: Why doesnt OpenTTD run on OpenGL yet?
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
Re: Why doesnt OpenTTD run on OpenGL yet?
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.
In addition to this, development team will not change something that works good enough, they will rather implement new fancy features instead.
- andythenorth
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: Why doesnt OpenTTD run on OpenGL yet?
Sometimes what we think are the facts aren't the entire facts.
https://github.com/OpenTTD/OpenTTD/pull/7744
https://github.com/OpenTTD/OpenTTD/pull/7744
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Re: Why doesnt OpenTTD run on OpenGL yet?
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 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.
Re: Why doesnt OpenTTD run on OpenGL yet?
So it seems it still uses software renderer, and then copies video buffer to screen using OpenGL.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.
Re: Why doesnt OpenTTD run on OpenGL yet?
yes, that's pretty much what it does
Re: Why doesnt OpenTTD run on OpenGL yet?
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.)
Re: Why doesnt OpenTTD run on OpenGL yet?
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.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.)
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.
Melt with the Shadows,
Embrace your destiny...
Embrace your destiny...
Who is online
Users browsing this forum: Majestic-12 [Bot] and 19 guests