We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3064 - Please provide more flexible surface blitting routines
Summary: Please provide more flexible surface blitting routines
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.2
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-16 12:43 UTC by Fabian Greffrath
Modified: 2017-09-11 10:17 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Greffrath 2015-07-16 12:43:09 UTC 
Hi there,

I am currently in the course of porting Chocolate Doom to use SDL2's hardware scaling capability to render its buffer content to screen. For some background, Doom renders into a 8-bit paletted 320x200 pixel framebuffer that we want to seamlessly stretch to fill the entire screen, e.g. windows or full screen. On this way, however, we don't want to lose the gritty and pixelated look of the original Doom due to linear scaling or similar mechanisms which make the game appear too smooth and soft. We achieve this by upscaling the original framebuffer by an integer scale, i.e. without any interpolation, and then feeding it into the texture to scale it back to screen.

So, currently this means we have to blit the 8-bit paletted 320x200 surface into an intermediate RGBA 320x200 surface which we then scale up to 1280x800 by a scaled blit into another intermediate surface. This last surface is then loaded into the texture which is then scaled back into the renderer (with linear interpolation) and finally rendered to screen.

This sums up to a lot of intermediate surfaces and conversions between these surfaces which has proven to be a real performance killer. What I'd like to have is a means to directly do a scaled blit from the 320x200 8-bit surface into the upscaled 1280x800 RGBA surface that I can immediately load into the texture.

For reference, the initial implementation and discussion is here

https://github.com/chocolate-doom/chocolate-doom/commit/caf7461a4075352fd77b45dff58533900bd96e03

the latest commit introducing the additional intermediate surface can be found here

https://github.com/chocolate-doom/chocolate-doom/commit/777148cae2032bc2a33754329e7ecb52017a21cc

Thank you and best regards,

Fabian
Comment 1 Sam Lantinga 2017-08-12 23:31:13 UTC 
Do you have a proposal on how you'd like to do that?
Comment 2 Fabian Greffrath 2017-08-17 09:19:33 UTC 
Sorry, I don't have any code.

Just an idea that there could be a check if the source and destination surfaces match in terms of color space and dimensions. If they don't, the intermediate blitting could be done behind the scenes, so the user isn't forced to manually perform these steps himself.
Comment 3 Sam Lantinga 2017-08-18 18:03:31 UTC 
Well, it sounds like you could do the intermediate scaling in hardware by using a render target (SDL_RENDERER_TARGETTEXTURE). By default point sampling will be used, which will give you the gritty look that you're hoping for, and then the final texture can be rendered on the screen with the SDL_HINT_RENDER_SCALE_QUALITY set to "linear" to get a little bit of softening for the final blit.
Comment 4 Fabian Greffrath 2017-08-22 12:42:17 UTC 
This is pretty much how we are doing it today.

Back then, we did the first step (i.e. the pixelesque upscaling of the original framebuffer) by means of blitting, which in turn required two steps: one to turn it from a paletted 8-bit frambuffer into an RGBA buffer and another one to scale this up. What I was asking for was a single multi-step blitting function which does the "320x200 8-bit -> 1280x800 RGBA" blitting without user-visible intermediate steps.
Comment 5 Sam Lantinga 2017-09-10 02:04:13 UTC 
Yeah, there really isn't any way to do this other than provide a shader, or something similar for software rendering. I'm not opposed to this, if someone has a good proposal and need for implementation.

For now I'm going to mark it as won't fix.
Comment 6 Fabian Greffrath 2017-09-11 10:17:15 UTC 
Fine with me, thanks.