News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Performance - GDI vs SDL ( Windows XP vs OS X 10.8.2)

Started by meme, February 04, 2013, 06:44:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bjarni

Quote from: prissi on March 12, 2013, 04:00:51 PM
Does teh frame rate increase significantly when zooming in?
I have the same problem on 10.6 and I get 4 fps when using the whole screen as well, nomatter the zoom level. Trying SDL 1.2.12 didn't really affect anything either.
Didn't really try fullscreen as every second frame appears to be black, resulting in a flashing screen. I ended up feeling dizzy from just looking enough to find the quit button. I dismissed any further investigations of this issue die to my own health. For all I know it could have been other software running on my computer at the time, which tried to take screen control and as such not a simutrans problem.

Quote from: Ters on March 30, 2013, 10:01:08 PM
The OpenGL backend doesn't do 2D rendering. At least it didn't the last time I saw it.
Quote from: Ters on March 31, 2013, 08:04:29 AM
the internals of Simutrans and best use of OpenGL do in almost no way agree.
That depends on how you do it. One option is to make a few huge polygons (max size) and then add the screen as a skin to those. One guy once told me he did that to... *something* (oops, I forgot what software he ported :-[) and it performed with lightning speed. I can try to dig up what he wrote if people are interested, though he didn't put many details into it, just the concept.

OSX itself relies heavily on OpenGL. Any mac compiler has access to it even without adding libraries. Also the mac implementation of OpenGL is really good (unlike SDL which is horrible on mac).

Quote from: Ters on March 31, 2013, 08:04:29 AMWriting a native backend for Mac is probably the best solution. It might be that native backends are the best solution on all platforms in order to make use of touch devices and gestures. Platform independent libraries seems to neglect input the most. Unfortunately, I haven't seen any updates from the native Mac project in a while.
Something like that is done by Timothy here: http://forum.simutrans.com/index.php?topic=8783.0
It's much faster though I'm not sure performance will be as fast as the OpenGL solution as it looks like it lacks hardware acceleration.

Markohs

#36
we had one version of simutrans using OpenGL and just writing to a texture each frame, that might have better performance that the current SDL version in Mac, I can assemble the code for you to try if you want.


It uses a mixture of SDL and OpenGL, just replace simsys_opengl.cc for the simsys*.cc that you are using now when compiling, should be fine.


EDIT: Just read the posts above and you already talked about  this, sorry. ;)

Markohs

Quote from: Ters on March 31, 2013, 08:04:29 AM
I, and later Markohs, have been looking into making better use of this "car" when we first have it, but the internals of Simutrans and best use of OpenGL do in almost no way agree.

Yes indeed, but it will be possible to implement it in the future, if we are able to keep in vertex buffers the geometry of the objects synced with the world, plus some management of what's inside the viewport and not, so save memory and bandwidth.

That's why I'm implementing some features in the normal simutrans, to know it better so I can hopefully manage to design how to do this. I lack enough knowledge of the inner of simutrans atm.

ArthurDenture


There are naturally tradeoffs in using a native renderer: on the one hand, you usually can get good performance and better native look-and-feel. (Though, as Simutrans handles all its dialogs and text input itself, native look-and-feel is not applicable here.) On the other hand, it's yet another backend to maintain. I suppose it could be worthwhile to do a native Quartz version... I don't have any experience writing native Mac software, so I'd not be able to help much with that except by testing it out.

As for OpenGL: one way to sidestep the question will be to port to SDL 2. Their documentation claims that it will use OpenGL behind the scenes for hardware-accelerated 2D rendering whenever appropriate. That way you get the best of both worlds: fast rendering without having to clutter up the code with OpenGL calls that exist only to get a fast rendering context.


I actually spent some time trying this out, with some success :-). You can see the work-in-progress commit over at https://github.com/artdent/simutrans/tree/sdl2. It's still broken in various ways, but perhaps someone else wants to take a look and hack on it as well. It does get excellent performance, so it's probably well worthwhile to pursue this route and attempt to fix the rest of the bugs in my port.


Naturally, it wouldn't be possible to integrate this change until SDL 2 is actually out and has published binaries for the important platforms. And it'd be IMHO better to upgrade the SDL backend in-place rather than attempt to ship it as Yet Another Backend Option.

Ters

Quote from: Bjarni on March 31, 2013, 02:09:17 PM
That depends on how you do it. One option is to make a few huge polygons (max size) and then add the screen as a skin to those. One guy once told me he did that to... *something* (oops, I forgot what software he ported :-[ ) and it performed with lightning speed. I can try to dig up what he wrote if people are interested, though he didn't put many details into it, just the concept.

That's what I did, but defining geometry, setting up projection and transformation matrices, allocating texture buffer, configuring that texture buffer right (no mipmaps, correct filtering, etc), and so on, seems like serious overkill just to tell the system to copy x times y pixels from one place to another.

TurfIt

#40
Quote from: ArthurDenture on March 31, 2013, 06:47:35 PM
You can see the work-in-progress commit over at https://github.com/artdent/simutrans/tree/sdl2. It's still broken in various ways, but perhaps someone else wants to take a look and hack on it as well. It does get excellent performance, so it's probably well worthwhile to pursue this route and attempt to fix the rest of the bugs in my port.

I just tried this on Win7. Unfortunately performance vs SDL1 is rather lacking.











SDL213.6 ms/frame
OpenGL, PBO9.3 ms/frame
SDL1, ST, -use_hw9.0 ms/frame
OpenGL8.3 ms/frame
GDI, ST7.6 ms/frame
SDL1, ST, UpdateRect7.4 ms/frame
SDL1, ST, UpdateRects6.5 ms/frame
GDI, MT5.4 ms/frame
SDL1, MT5.3 ms/frame
ST=single threadedMT=multi threaded
Ouch.  And it is also most definately busted in many various other ways too... as is the OpenGL PBO...
Note: for MT, that's just how long the main thread is spending in sync_step, returning faster just means the main routine gets to sleep sooner, no performance change unless the main thread ends up waking again before the screen copy is finished.

Edit: Added GDI results for completeness.

Markohs

 Thanks for those numbers TurfIt. :)

When I finish my world limits patch I'll get my hands on the OpenGL backend again, I have new ideas to apply there, let's hope they improve things. It's quite a lot of work, but I think they will be successful. :)