Was there an SDL 2.0 project?

[TurfIt]

Seems hints are treated as suggestions, not commands. Set the hint for opengl, it still gives d3d. Hence the text comparison loop method.

Processing the keydown event with control pressed seems to work ok. There's a lot of keyboard events being passed into simutrans with code=0, but so far it's not causing issues.

What SDL2 (mis)feature shall we butt heads with next...

[Ters]

Seems hints are treated as suggestions, not commands. Set the hint for opengl, it still gives d3d.

That's what hints are. I've spent some time trying to give an Oracle database hints on how to best perform a query, only to have it rush into a hopelessly inefficient execution plan.

What SDL2 (mis)feature shall we butt heads with next...

I'm fully occupied with Hibernate misfeatures for the time being, so I'll pass for now.

[Markohs]

Correct me if I'm wrong, but if I understand correctly what you said so far, this port works more or less like the OpenGL backend, no? You update a texture and render it again. I wonder if there is another gain appart from using a newer library (the new keyboard handling it's something that we'd have to change some day, and reading what you expressed, it liiks similar to http://www.ogre3d.org/tikiwiki/tiki-index.php?page=OIS , no?).

If updating the texture is the way it works it's normal the performance is close (7% less, looks like close enough), because most of the time it's spent sending the data over the PCI bus to the videocard, that bottleneck will be there forever if we don't change lots of code to use texture atlas and a brand new drawing algorithm.

[ArthurDenture]

I wonder if there is another gain apart from using a newer library

Yes: it allows using hardware rendering on a Mac, bringing the framerate on Retina displays from <5fps at 100% cpu usage to 25fps at 40% cpu usage. This changes simutrans from "barely playable" to "playable" on that platform. (In theory, it also allows hardware rendering in windowed mode on Linux, which previously would've been software endering -- but in practice I haven't seen that translate to an actual speedup, for whatever reason.)

[Markohs]

Did you tried a simutrans opengl backend build? It might give similar or better results.

[TurfIt]

Last I tried, the opengl backend was ~30% slower than the SDL1 (not on a mac though). I've now got SDL2 down to ~4% slower than SDL1 which is comparable to the slowdown with GDI. Still, if your platform handles it, SDL1 gives the best performance, and for platforms that don't - Mac, SDL2 is looking promising.

EDIT:  current attached. simply adds the CTRL-key handling.

[ArthurDenture]

I had a chance to return to this work, and the latest version of the SDL2 backend can be seen at https://github.com/artdent/simutrans/compare/sdl2-v2. It's also attached as a diff against HEAD. Notable fixes include sound stuckness and fullscreen mode, but see the commit messages on Github for the full details. It's also a separate backend option this time instead of trying to upgrade simsys_s.cc in place, since it's clear that's what people prefer.

I think it's now free of obvious bugs, though I'm sure there are some lurking.

Switching to calling SDL_UpdateTexture on only the dirty rects, with the texture locked for the whole program duration, did provide a nice performance boost over updating the entire screen, so I went that route. It's basically TurfIt's option #2.

[Ters]

Switching to calling SDL_UpdateTexture on only the dirty rects, with the texture locked for the whole program duration, did provide a nice performance boost over updating the entire screen, so I went that route. It's basically TurfIt's option #2.

Strange. I would have thought that just uploading dirty rectangles would get very slow with more than just a few rectangles, but then again, maybe there seldom are more than a handful dirty rectangles per frame.

[TurfIt]

Dirty rects vs fullscreen update just shows how slow it still is writing to video memory / copying unnecessary stuff. When redoing the dirty logic to merge the rectangles a bit, I tried ignoring single tile non dirties surrounded by dirty and just copying one larger rect, ended up slower than just doing two rects. ie. copying an extra 16x16 pixel area is slower. There's typically 300-700 dirty rects per frame in my testing, obviously less when zoomed in.

Stuck sounds - I never even though of that. Sound in Simutrans is sooo horrible, I have it on perma mute!

FULLSCREEN_DESKTOP flag - I had issues with the mouse being misaligned to the gui when I tried this. Will require more work to decouple render area from screen area.

It seems stable/functional enough now. So committed r6688. Maybe mac nightlies should be switched to this?

[Ters]

Dirty rects vs fullscreen update just shows how slow it still is writing to video memory / copying unnecessary stuff. When redoing the dirty logic to merge the rectangles a bit, I tried ignoring single tile non dirties surrounded by dirty and just copying one larger rect, ended up slower than just doing two rects. ie. copying an extra 16x16 pixel area is slower. There's typically 300-700 dirty rects per frame in my testing, obviously less when zoomed in.

It's just that with these moderns cards, it is said and written that initiating an operation is very costly. So writing one 32x32 area should be much faster than writing four 16x16 areas. I also thought than when a texture is locked in its entirety and partially updated by just writing to random parts of the locked memory region, the driver doesn't know which parts have been written to, and uploads the entire texture for system memory to video memory. Maybe the driver cooperates with the memory manager to know which pages are dirty. I guess time will show when this has been tested on a number of different machines. Unfortunately, I don't have time for testing it out for the time being.

[ArthurDenture]

Yay! Thanks for doing the merge. There's a minor oops where it segfaults at startup - see the attached diff for the trivial fix.

I think switching the mac nightlies to sdl2 is a good idea. I've also added sdl2 as a configuration over at http://ec2-54-242-171-11.compute-1.amazonaws.com/jenkins/job/. (And, yes, I think that the "run the built binary for 10 seconds" phase of the build would have caught the segfault, were not the build broken just now by an unrelated commit.)

I'll have to look into the fullscreen thing when I have more spare time. Right now I actually see the mouse position bug in either fullscreen-desktop or regular fullscreen mode, depending on the platform.

[kierongreen]

Committed the startup fix (I had come up with same solution last night but hadn't got round to committing then!).

Well done for getting this working I think there's a huge boost here for fullscreen with lots of vehicles moving on my computer at least.

[captain crunch]

Thank you very much, good Sir.
I noticed, that the keyboard might get scanned differently than in the SDL-1.2 front-end, when I used the [[CONTROL]]-click, as it did not work as expected. I have remapped [[CONTROL]] to [[CAPS LOCK]] which works in SDL-1.2, but in the SDL-2.0 front-end it is not mapped there, but to the original position.

[ArthurDenture]

I have remapped [[CONTROL]] to [[CAPS LOCK]] which works in SDL-1.2, but in the SDL-2.0 front-end it is not mapped there, but to the original position.

Sigh, confirmed. I do the same thing, and for me it works on Mac but not on Linux. If I run the checkkeys test program from the SDL2 source tree, it prints when I press caps lock: "INFO: Key pressed: scancode 57 = CapsLock, keycode 0x400000E0 = Left Ctrl  modifiers: CAPS". If I do the same from SDL1.2, it prints "Key pressed:  306-left ctrl  modifiers: LCTRL NUM". I guess it's time to file a bug with SDL...

(Fwiw, this is probably the same behavioral change that required us to explicitly treat Cmd as a control key on macs in SDL2. In SDL 1.2 it got mapped to Ctrl out of the box.)

Update: filed https://bugzilla.libsdl.org/show_bug.cgi?id=2096

[captain crunch]

Another quirk on Linux/X11 is that when I press the SPACE key two spaces are printed. Easily recognisable because I have to press BACKSPACE twice to delete the previous SPACE character.

[ArthurDenture]

Another quirk on Linux/X11 is that when I press the SPACE key two spaces are printed. Easily recognisable because I have to press BACKSPACE twice to delete the previous SPACE character.

Thanks for the report - I posted a quick patch to fix that.

Is it perhaps time for the a mod to close this thread? Reports of problems in the SDL2 backend can now just got in the normal bug reports forum.

[Ters]

We don't close threads.