![]() ![]() Use the WGL_EXT_swap_control extension to control swap interval. This is commonly called "triple buffering". Thus, one can ease the CPU burden on waiting for v-blanks by rendering to a third buffer, then blitting that to the back buffer, and then doing a swap. Assuming that there are no other issues that would prevent such execution (trying to render to a buffer that is being read from, for example). ![]() If they do not affect the back buffer, either by rendering to a framebuffer object, another form of off-screen buffer, or something else that isn't the back or front buffers, then these rendering commands can be scheduled as normal. Note that the problem of OpenGL commands backing up due to a waiting v-blank happen because these commands are trying to affect the back buffer. Rendering calls made in that time will back up, eventually forcing a stall to wait for the actual swap. It will also induce stalls, for the same reason as above: the GPU has to wait 15.2ms every other v-blank interval for a buffer swap. It will effectively take two full v-blank intervals to display an image to the user, turning a 60fps program into a 30fps program. Therefore, the CPU driver will stall the rendering thread in an OpenGL command (it doesn't have to be in a buffer swapping command) if there are too many commands waiting for the v-blank.Īlternatively, if the renderer takes slightly longer than the v-blank intervals to render, say 18ms, then a different problem can result. For example, if the v-blank intervals come at 16.6ms intervals (60fps refresh), but the rendering of a frame only takes 4ms, then buffer swaps can back up. Exactly when that happens is subject to the swap interval setting.Ī swap interval greater than 0 means that the GPU may force the CPU to wait due to previously issued buffer swaps. Video drivers can override these values, forcing a swap interval of 1 or 0 depending on settings the user provided in the video card's control panel.Ī call to the platform-specific buffer swapping function (such as SwapBuffers in Windows) means that, once all previously issued drawing commands have completed, the contents of the back buffer should be swapped into the front buffer. A swap interval of 0 specifies that the GPU should never wait for v-blanks, thus performing buffer swaps as soon as possible when rendering for a frame is finished. A swap interval of 1 tells the GPU to wait for one v-blank before swapping the front and back buffers. The former is not supported anymore on the Pi4 - the latter works, but it's not 100% behaving the same as on a Pi3.The term "swap interval" itself refers to the number of v-blanks that must occur before the front and back frame buffers are swapped. The PI4 has a different kind of driver (it's basically emulated on top of the DRM/KMS primary video plane) which doesn't support resolution changing, as in the previous PI models.įor the Pi3, the scaling might have worked with 2 methods - either the fbcon SDL1 driver did the scaling to a resolution supported by the framebuffer, or the scaling was done by using the SDL1 dispmanx driver (PI specific). "it's to do with the framebuffer video driver included in the sdl1 library used by dosbox. Others are also finding the exact same issue as yourself, and I found this : My post was "Dosbox on a Pi4, at the moment, will never perform better than on a Pi3 it seems. There was another thread Id posted on re poor Dosbox and it's poor performance on the Pi4 - this may help? Below is one frame of video 1 (the half-way transparent green and magenta area is caused by my TV): I also noticed that even with vsync=true the game shows some tearing effects. Video 3 - vsync=false / joystick=none (shows the same issue as in video 2):Īs a side note, when setting joystick=none, the virtual keyboard in DOSBox does not work anymore, or to be precise: it cannot be operated with the joystick anymore (works fine when using a USB mouse). Video 2 - vsync=false / joystick=auto (game runs fine in the first few seconds, but after that drops down to 10-15 fps): Video 1 - vsync=true / joystick=auto (game runs fine, but crackles and stutters in other games when moving the mouse): I made some videos for comparison with different settings for vsync and the joystick (apologies for the flickering and ghosting - I'm still in love with my old plasma TV ). Unfortunately it did not solve the issue. Sorry for responding late! I tried it out today. Said in DOSBox: Games stutter and audio crackles while moving the mouse: ![]()
0 Comments
Leave a Reply. |