No, the SDLGL-PP takes much less CPU processing, as most of it is done on the GPU. But if there is vsync, it will never output more than 60 fps (for typical monitors). Hence the frameskip needed. What kind of OS and GPU are you using?
Core-i7 with Geforce 740M GT. It is very noticeable that, with the same frameskipping, in old SDL with maxframeskip at 3 it runs as lightning fast in throttle mode, and with the new only a bit faster than without throttle. Tested also with VBLANK on immediate mode.
About the GPU processing, be careful, as sending pixel by pixel, or in small chunks of data, it can be even slower, due to API calls taking much CPU time. That in an API like 2D SDL (the old one) is not a problem, or at least not so penalizing.
If you are using the GPU for scaling and filters, using things like GL, which adds a time delay per API call, is better to write the original buffer in RAM (at native resolution, like 256x212 or 512x212 and etc.), which is of direct access from the CPU, and then when finished send all it at once to VRAM, then let the GPU do the remaining (filters and scaling).
It's possible your NVIDIA driver is having vsync enabled globally. See this thread page to check and change that: https://www.msx.org/forum/msx-talk/openmsx/please-help-testi...
The SDLGL-PP is not new, it was introduced in 2006. It's lightning fast on our systems. So let's find out what's going on on yours.
Un control panel is set to “Application decides”.
I’ll ask to others for testing in different configs.
That looks good. In the Linux NVIDIA driver you can also set "Enable Graphics API Visual Indicator". This shows whether VSYNC is enabled or not in the top left of the window. I don't know if this works on the Windows driver though.
OK I made some tests and here the results:
It seems to be VSYNC related. The indicator shows enabled always, and the set sync_to_vblank_mode immediate has no effect.
When I manually set the VSYNC Disabled on Nvidia panel, it runs fast, much faster, as it should, no matter how the sync_to_vblank_mode parameter is set.
Then seems to be an OpenGL and setting the VSYNC, that the driver always detects as enabled by application, so it leaves it enabled even when modifying the sync_to_vblank_mode.
Tested both Windows and Linux.
Don't remember how OpenGL configured VSYNC, maybe this extension is the used one?
https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_swap_control.txt
When I manually set the VSYNC Disabled on Nvidia panel, it runs fast, much faster, as it should, no matter how the sync_to_vblank_mode parameter is set.
But you will have smooth scrolling problems, right? See my test ROM here.
When I manually set the VSYNC Disabled on Nvidia panel, it runs fast, much faster, as it should, no matter how the sync_to_vblank_mode parameter is set.
But you will have smooth scrolling problems, right? See my test ROM here.
Yes without VSYNC tearing appears. But was for testing the rendering speed.
The result is that the rendering speed of the SDLGL-PP module is nice, but changing the VSYNC from the application has no effect.
What if you don't touch the NVIDIA settings, but go to full-screen? Does openMSX still have vsync in immediate mode?
On Linux openmsx has no real fullscreen mode, it only expands the borders to fill the display. Have to try on Windows when possible.
The full screen is the same on all operating systems, from openMSX point of view. We have 'soft' full screen now, no change of modes.
But it doesn't matter for that test that Grauw requested