#260 Sharpen Filter

Unstable_(example)
open
nobody
None
1
2013-10-26
2013-10-09
bredbored
No

<H1>Sharpen Filter</H1>

This is a new filter for the opengl output mode. It uses a fragment program that performs a sharp magnification filter. Instead of linearly blending every texel in the source texture, and thereby blurring it uniformly, each destination texel that is fully contained by a source texel after stretching the source across the destination gets the source texel color. Destination texels that straddle the edge of two source texels linearly blend the appropriate amount of each. This approaches the clarity achieved with nearest-neighbour filtering while hiding the error in cases where the ratios of the dimensions of the destination and the source are not integers. When the ratios are integers, the result will match the nearest-neighbour filter.

The filter to use can be specified in the config file. The sharpen filter requires OpenGL 2.0. If that is not available, linear filtering will be used when the sharpen filter is selected. The config file filter setting is only respected when the output mode is opengl. The openglnb output mode always uses nearest-neighbour filtering. The other output modes can't run fragment programs.

<H3>Aspect Correction</H3>

In the ddraw, overlay, and opengl output modes, the viewport is adjusted to render the output at 4:3 aspect ratio no matter the physical dimensions of the display or the dimensions of the current video mode. The only exception is in fullscreen when the video mode is not fixed, in which case it is assumed to be displayed at the correct aspect ratio. The physical dimensions of the display are guessed from the desktop resolution, or can be specified as a ratio in the config file.

<H3>Pixel Buffer Object</H3>

Use of an unpack pixel buffer object in the opengl output mode is disabled. It was being used in a way that required that the previous frame finish uploading to the GPU before the next frame could start rendering. To prevent this, new storage must be allocated for the unpack buffer before it is mapped, which DOSBox is not doing. The point of the unpack buffer is to reduce the number of buffers required to send data to the GPU. With respect to this, DOSBox is using it correctly. Ideally, the unpack buffer data would be allocated, mapped, updated, unmapped and loaded into the texture each frame. Unfortunately, DOSBox makes partial updates to the framebuffer when only small regions of it have changed. This means it would have to copy the previous framebuffer into the newly allocated unpack buffer, which would mean it would have to have a second copy of the buffer. Finally, the pixel buffer object code path always uploads the entire buffer to the GPU, which is a waste of bandwidth. The normal code path only uploads the changes. In the worst case, the normal path will allocate a copy of the framebuffer to upload to the GPU, which is exactly what DOSBox needs to prevent blocking while the buffer is uploaded, and to be able to partially update the framebuffer with the next frame.

The first alternative to disabling the unpack buffer altogether is to reallocate it each frame and copy the framebuffer into it after rendering. This achieves the same thing as simply uploading the data directly, but with added inconvenience. The second is to create multiple unpack buffers that retain their storage and copy the framebuffer into one that is currently unreferenced by the GPU. This might prevent memory fragmentation, but is a much more complex strategy. Neither of these are particularly attractive, so pixel buffer objects are disabled. This allows DOSBox to start work on the next frame while the GPU is updated with the previous one.

<H3>Vsync</H3>

Vsync can be enabled in the config file for the opengl output mode. Because most games are already synchronizing with the emulated vertical refresh in DOSBox, this has the potential to cause hitching. However, if everything's running in phase, it's fine. The other output modes do not respect this setting. The surface and overlay output modes never use vsync. The ddraw output mode uses it when it is double buffered.

<H3>Resizable Window</H3>

The window is resizable in the ddraw, overlay, and opengl output modes.

<H3>Scalers</H3>

RGB only scalers are enabled in the opengl output mode. This is a bug fix. The opengl output mode is working with an RGB framebuffer.

1 Attachments

Discussion

  • bredbored

    bredbored - 2013-10-12

    I fixed a bug in the OpenGL version check. The minor version test was incorrect. It didn't matter, because the minor version to test for is 0, but I fixed it anyway.

     
  • bredbored

    bredbored - 2013-10-16

    I fixed a crash in the aspect correction changes I made to GFX_SetupSurfaceScaled that occurred when SDL_SetVideoMode returned a null pointer.

     
  • bredbored

    bredbored - 2013-10-26

    I improved the vsync implementation so that it only flips once per physical refresh. Multiple dosbox refreshes can occur before a flip. For example, if your display's physical refresh rate is 60 hz, and the video mode in dosbox has a refresh rate of 85 hz, you'll get two dosbox refreshes approximately every other physical refresh. If you're syncing with the physical refresh, this will cause hitching. With my latest change, the flip is skipped for the first of the two dosbox refreshes with vsync on.

    Unfortunately, SDL 1.2 doesn't seem to provide the refresh rate of the display mode, so I used EnumDisplaySettings on WIN32, and everything else will hitch in display modes whose refresh rates aren't close to dosbox's with vsync on.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks