modular design + threads *WARNING: LONG POST*

[bobingabout]

awww... such a shame, would be a real performance booster...

[peter1138]

Yes, Doom 3 is well known for being faster than Doom 2, because it uses 3D acceleration...

[Bjarni]

Most often you need to use 3D graphics to gain a real performance boost from using 3D hardware acceleration

[DmitryKo]

there are no plans whatsoever of switching or adding an OGL driver to OpenTTD

Talking in the context of code modules, it's not about the intention of principal OpenTTD team to do a ceraint task or its lack thereof, but rather about providing some more abstraction levels to let other people extend the functionality, without having to rewrite the parts of the code which make too much assumptions about the legacy of Transport Tycoon...

And I want to make it clear that I'm not pursuing any kind of "total 3D conversion" in a foreseable future, at least not until full-featured OTTD 1.0, and even then its scope would probably be limited to 3D landscape and some effects, with most of the graphics still being done with goold old-fashioned sprites.

Yes, Doom 3 is well known for being faster than Doom 2, because it uses 3D acceleration...

Doom III is a completely different engine that's full ten years beyond the system requirements of Doom II. A proper comparison would be DOS-based Duke Nukem 3D vs. JFDuke3D/EDuke32 port vs. the latter with a Hi-resolution graphics pack.
The very same game engine and level data, still very different graphics options - sprite-based sector engine with software 8-bit rendering, true 3D world rendered with original sprite-based graphics and finally full-blown hi-res textures and all-3D models of monsters and weapons.

you need to use 3D graphics to gain a real performance boost from using 3D hardware acceleration

I believe there's a lot of sense in doing a true-color sprite-based 2D overlay on a 3D hardware, because it will 1) offload sprite data accesses to local video memory (for much more detailed graphics) 2) provide almost free hardware color fill with bilinear filtering (window gradients), alfa blending (smooth transparency transitions, night/day effects etc), linear MIP map filtering (smooth zoom levels) etc.

It wouldn't require extensive changes to current game code, because it's just another 2D renderer that operates in screen coordinates, and even a very basic 32 Mbyte 3D card is able to hold about six hundred 256x128 px paletted or DXT alpha-compressed textures with mipmaps (and open source DXT library is available at http://www.sjbrown.co.uk/?code=squish).

Yes, API calling overhead could be a problem, but I've read it that SDL library is already slow and inefficient - if true, hardware-accelerated OpenGL overlay could still be a better solution. Also, Windows Vista will no longer support hardware GDI acceleration (but will feature an Direct3D to OpenGL 1.4 wrapper for older cards with a DirectX driver but no OpenGL ICD). You have to run just to stay where you are, you know

[Syranide]

However you did give me one idea. Drawing on the screen is really slow, so if it were given it's own thread, we could make the core run at a fixed speed (like now) and then skip a frame if the previous frame is not done drawing. The result from this would be that if a computer got problems keeping up the speed, it would start frame skipping instead of slowing down the game. In large network games, some clients might get problems keeping the speed, but if they start frame skipping to ensure that the core keeps the same speed as the server, they would not desync, like a core slowdown will. It would also speed up on multiple CPU computers as all the core functions can run on one CPU and the drawing can run on another. It could also mean that the settings could alter the framerate to slow down on purpose, like you say that you only want 5 fps in fast forward while you like the current framerate when not fast forwarding. This would make fast forward a lot faster and slow computers would benefit from this. Also computers running on battery would benefit from this as less battery power is needed to fast forward say a year

I don't see why this wouldn't be possible without threads unless you have really done things (really really a few times) messy.

Having it skip frames if there is too much todo is basically just letting the engine work all the time as much as it needs, and if there is time over it will allow to redraw the screen... that is, between each engine update so to say there should be e.g. 50ms delay... and as long as there hasn't gone 50ms you update the screen, if it has been more than 50ms you update again and don't redraw (perhaps forcing updates at least a number of times per second is necessary), doing this will also make the engine quickly work its way back if it got slowed down.

Having threads wouldn't really solve the problem as I see it, the engine wouldn't be faster because of it, it would only mean more problems as of synchronization (or waiting for the engine), and still, drawing would use equally much CPU, or be limited in an equal way as described above.

[DmitryKo]

http://msdn.microsoft.com/directx/presentations/

GDC 2006: Coding for Multiple Cores (1.2 Mbytes)

Slide 5 - Good Multithreading
Start with main thread, look for major tasks
Split out into Game/Rendering
Add synch points… other than at those points, both threads can run independently
Look for additional parallelizable tasks… physics might be a good candidate
Synch points before and after
Break out other parallelizable tasks
Look for tasks that can run independently of main threads… service requests
Add communication but keep it to a minimum

Slide 13 - How Many Threads?
No more than one CPU intensive software thread per core
* 3-6 on Xbox 360
* 1-? on PC (1-4 for now, need to query)
Too many busy threads adds complexity, and lowers performance
* Context switches are not free
Can have many non-CPU intensive threads
* I/O threads that block, or intermittent tasks