| Summary: | Please provide more flexible surface blitting routines | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Fabian Greffrath <fabian+debian> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 2.0.2 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
|
Description
Fabian Greffrath
2015-07-16 12:43:09 UTC
Do you have a proposal on how you'd like to do that? 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. 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. 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. 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. Fine with me, thanks. |