Author Topic: OpenGL  (Read 342 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
OpenGL
« on: January 12, 2018, 01:33:27 AM »
I have managed to build and test in Simutrans-Extended the OpenGL backend for Simutrans that was discussed here and worked on by Markhos a few years ago. The reason that I looked into this is because players are reporting performance problems on the Bridgewater-Brunel server that are related to the very inefficient graphics code that Simutrans uses, in which everything is done in software.

In summary, the result of the tests are that OpenGL mostly works, is slightly faster than purely software rendering, but is buggy. Firstly, as to the performance, the records of my tests (conducted using the normal nightly build and then the OpenGL build that I was able to make, both with optimisations enabled, and both using a saved game from the Bridgewater-Brunel server) are as follows:

Quote
Software graphics
Load location, normal zoom: 23-30fps
Load location, minimum zoom: 9-11fps
Flecksington dock, maximum zoom: 23-24fps
Hill and farm only, maximum zoom: 30-32fps
Load location, zoomed out in 2 increments: 18-21fps

OpenGL
Load location, normal zoom: 30-31fps (dropping to 28fps during route search, then 23fps for a few seconds afterwards before recovering)
Load location, minimum zoom: 15-17fps
Flecksington dock, maximum zoom: 20-30fps
Hill and farm only, maximum zoom: 29-32fps (including during path explorer run)
Load location, zoomed out in 2 increments: 27-30fps

The performance increase is modest but not entirely negligible, especially at intermediate levels of zoom, albeit the improvement is not entirely consistent.

However, with the current OpenGL code, the ticker does not work and constantly flickers; progress bars do not function at all (which gives the impression that the game has crashed when it is actually loading/saving), and the edges of the map flicker annoyingly.

Thus, I do not think that the OpenGL backend is suitable in its present state to be included into Simutrans-Extended, and I do not have the expertise to fix the bugs. However, if the bugs were fixed, it might well offer a modest performance improvement that might be worthwhile. Unfortunately, I note that Markhos, who worked on this in circa 2012, last logged into the forum in December 2016.

Would anyone who has some idea about how the graphics system in Simutrans works and at least some idea about how OpenGL works be interested in trying to polish this enough for it to be included?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: OpenGL
« Reply #1 on: January 12, 2018, 05:02:40 AM »
The problem is that the reason it may be performing well is because it is buggy. Its the same reason some emulator graphic backends seemed faster, not because they were faster but rather because they were skipping emulating a lot of resource intensive features.

If you link a git branch I might be able to take a look at it. Not promising I will get anywhere with it however.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #2 on: January 12, 2018, 02:33:23 PM »
I do not think that the ticker, progress bars of map edges are what takes any significant amount of computational power for the graphics, are they? The transparency and animation appears to work correctly.

As to the code on Git, there is no separate branch; rather, it is just a matter of using different options for compiling the code on the master branch. I have set up on the master branch a build profile with Visual Studio for Open GL. You will also need to download and amend the paths to the SDL and GLEW libraries/headers (I am afraid that I used some absolute paths for my tests, so you may have to amend these in the project file). I have so far tested it using SDL1 (the Open GL API requires SDL in order to work); it might be worthwhile testing with SDL 2 instead to see whether it works any better with that, although it may be that it does not work at all.

I should like to use SDL sound for the Windows builds one day, as this would allow more than one sound to play at once, significantly improving the sound quality, but this is perhaps a project for another day.

Thank you for your interest in looking into this.

Edit: I have now managed to build the OpenGL version with SDL2 rather than the original SDL1, and this appears to fix the issues with the progress bars, ticker and map edges.

However, I do notice that, in spite of the reportedly higher framerates, scrolling the map is markedly less smooth with OpenGL than with the software renderer. This may well be because of the memory bandwidth overhead issues which I believe were the reason behind the original OpenGL project being abandoned in 2012.

Edit 2: On furhter testing, the issue with the scrolling smoothness is actually quite complicated. With the software renderer, scrolling small distances is very smooth, with a higher framerate than the OpenGL renderer; but scrolling for larger distances causes periodic freezes in the screen updating which can last a second or two. Even shorter distances of scrolling can have markedly inconsistent performances with the software renderer, with the scrolling being often smooth, but sometimes experiencing large periods of lag. With the OpenGL renderer, scrolling seems more consistent: the framerate for scrolling seems much lower than the reported FPS figure in the display window (and much lower than the movement of vehicles and pedestrians), but it seems to be less prone to the very long periods of lag evident with the software renderer.

As far as I can tell, the graphical quality is identical between OpenGL and software renderers.
« Last Edit: January 12, 2018, 09:13:49 PM by jamespetts »
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: OpenGL
« Reply #3 on: January 12, 2018, 10:22:00 PM »
The graphic quality cannot be the same because many graphic features were only added recently such as shadow transparency, and as far as I am aware these were not ported to the OpenGL branch.


Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #4 on: January 12, 2018, 10:29:57 PM »
The graphic quality cannot be the same because many graphic features were only added recently such as shadow transparency, and as far as I am aware these were not ported to the OpenGL branch.

The transparency works fine with the OpenGL backend - I specifically checked for that.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline TurfIt

Re: OpenGL
« Reply #5 on: January 12, 2018, 11:15:59 PM »
What are you calling the OpenGL version? simsys_opengl from trunk? or the actual OpenGL implementation in the simutrans3d branch?

simsys_opengl is completely deprecated by SDL2 (simsys_s2) which does essentially the exact same thing using OpenGL. (SDL2 can support DirectX too now that Dwachs fixed the bugs, but it's not enabled yet - still forces OpenGL). It's still software rendering to a memory surface with hardware assist on blitting to the GPU framebuffer (hardware when people actually have "proper" [MS default are not proper] opengl drivers installed - why so many complain about it 'crashing' [fixed by a silent fall back to pure software now])

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #6 on: January 12, 2018, 11:22:20 PM »
What are you calling the OpenGL version? simsys_opengl from trunk? or the actual OpenGL implementation in the simutrans3d branch?

simsys_opengl is completely deprecated by SDL2 (simsys_s2) which does essentially the exact same thing using OpenGL. (SDL2 can support DirectX too now that Dwachs fixed the bugs, but it's not enabled yet - still forces OpenGL). It's still software rendering to a memory surface with hardware assist on blitting to the GPU framebuffer (hardware when people actually have "proper" [MS default are not proper] opengl drivers installed - why so many complain about it 'crashing' [fixed by a silent fall back to pure software now])

That is very interesting - I was not aware of this distinction. I have been using the simsys_opengl.cc file from the trunk, which I had thought was the same as the 3d branch. I was not aware that there had been a separate branch. I will test again with SDL2 to see whether I get similar results.

As to the 3d branch, I imagine that this will be rather difficult to do anything with now in light of the code having moved on substantially since it was written?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline TurfIt

Re: OpenGL
« Reply #7 on: January 12, 2018, 11:43:58 PM »
IIRC the 3d branch only got as far as dealing with the landscape, and this predates the double heights functionality, so the code has indeed rather moved on...
IMO with the amount of objects Simutrans allows onscreen, any OpenGL implementation is doomed. There's a reason 'modern' games have such small restricted maps. Perhaps using Vulkan instead could alleviate the draw call overhead, but that'd be even more work for the poor hypothetical graphics programmer with such a low level API.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #8 on: January 13, 2018, 12:43:29 AM »
It turns out that I was compiling using SDL2 in any event - I seem to have done the correct thing in error. The SDL2 build does seem to have the slightly (but inconsistently) better performance. There is much to be said for using SDL2 for future builds, especially as the SDL2 sound is much better than the native Windows sound, and allows multiple sounds to be played at once.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: OpenGL
« Reply #9 on: January 13, 2018, 12:49:35 AM »
It is not the scale of Simutrans that is the problem, but more that the way the game was designed is. Draw related calls are coupled into game logic meaning they are spread all over the place. To minimize required fillrate the game only draws areas that change requiring complex logic to determine what to draw. Game logic also is coupled to frame rate, rather than the graphics being interpolated between game frames. Chances are it would be faster for a GPU to redraw an entire scene rather than only small parts of it as long as doing so would save on CPU time.

Much of the advantage Vulcan brings can be obtained with OpenGL if one uses command buffers. Vulcan only wins over it due to the API being inherently simpler to run.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #10 on: January 13, 2018, 12:57:18 AM »
SDL 2 does yield a small improvement in framerate, so this is a good start (although it may take me a while to set this up on the Linux nightly build server, as I will have to compile lots of cross-compile libraries; I am minded to do this at the same time as switching to 64-bit builds for Windows, which is necessary, as the server game is close enough to 4Gb for this to be an issue).

If anyone would like to code a full OpenGL and/or Vulk(c?)an backend for Simutrans graphics, even a minimal one that completely removes all the "does this bit of the screen need to be redrawn this step?" logic, I should happily include this in Simutrans-Extended if it works reliably and is faster than the current software renderer, but doing this from scratch is a long way beyond my current knowledge of programming, and it is likely to take me more time to learn about graphics programming in order to implement this than is feasible given the higher priority gameplay/balancing projects. Simply reducing the framerate on the server is a better solution for the time being.

Dr. Supergood, can I check - are you still getting lots of lag on the server from falling behind?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: OpenGL
« Reply #11 on: January 13, 2018, 02:09:20 AM »
Quote
Dr. Supergood, can I check - are you still getting lots of lag on the server from falling behind?
For now if I keep zoomed in mostly I am able to keep up.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16611
  • Total likes: 533
  • Helpful: 181
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: OpenGL
« Reply #12 on: January 13, 2018, 02:11:25 AM »
Splendid, thank you for confirming. Some of the optimisations from a few days ago might have helped a little here.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: OpenGL
« Reply #13 on: January 13, 2018, 02:14:42 AM »
That or maybe it is due to the server generating 1/50th of the passenger traffic it used to.