| Summary: | Rotation and flipping implementation for accelerated backends | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Gabriel Jacobo <gabomdq> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | etc0de, pallavnawani |
| Version: | HG 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
RenderCopyRotate
RenderCopyRotate cleaned up version RenderCopyEx, adds rotation and flips to RenderCopy RenderCopyEx, rotation and flipping for OpenGL, ES1, ES2 and D3D RenderCopyEx, rotation and flipping for all renderer backends Test for RenderCopyEx RenderCopyEx, rotation and flipping for all renderer backends Test for RenderCopyEx RenderCopyEx, rotation and flipping for all renderer backends v2 |
||
Created attachment 706 [details]
RenderCopyRotate cleaned up version
I've cleaned up the patch a bit, it should be fully independent of RenderCopy now for all the backends supported.
Created attachment 710 [details]
RenderCopyEx, adds rotation and flips to RenderCopy
I've changed RenderCopyRotate to RenderCopyEx and added flipping as well as rotation. Original plans included color modulation but that's already implemented with sdl texture color and alpha modulation functions.
Would it be possible that we can both have this in SDL 1.3, and at some point also a software implementation? The software renderer is a nice fallback and can do scaling already, it would be awesome if this new rotation (which I guess is badly needed due to SDL_gfx as an external lib not really being able to do it in SDL 1.3 with the new accelerated backends) also had a software fallback. Sure it's going to be slow, but I bet the scaling isn't exactly fast either and software fallbacks are simply good to have. Great patch, thanks! All we need now is the software rendering version... ;) I have just applied the patch to my SDL copy. There is one big problem with the line numbers in SDL changing with every minor change, which makes this patch hard to apply. However, it still applies fine despite the all the off line numbers which require manual work. I am willing to look into implementing this for the software renderer but I don't know if I'm up to it. I just hope we can get this into mainstream soon (with or without software renderer implementation), so that not everyone else who wants to have this essential and very useful functionality has to go through the same patching oddness again. Looking forward to rotation in SDL! :-) Well I digged the source a bit. The idea is to write some additional function to SDL_BlitScaled, SDL_BlitScaledRotatedFlipped or something, I guess. The code from SDL_UpperBlitScaled is already too scaling-specific to be used really, since the dest-clipping doesn't make much sense when it's rotated afterwards. Now I think I could do is provide an alternative to SDL_stretch.c which also handles rotation, I'd suggest naming it SDL_stretchrotation.c. The problem is however, that the only approach I can think of would be fairly slow: First, rotate the corner points of the scaled dest rectangle, then make a new rectangle that has the minimum required dimensions to keep them all. Then, iterate all points of that new rectangle, and rotate the points on it back with negative/backwards rotation applied, reverse-apply scale and see where we land and get the pixel value from there (or do nothing when it is outside the image bounds). If someone has a better idea, then shoot. Or maybe that person with a better idea wants to implement it instead of me :) I'm not exactly a lowlevel ubercoder. The things above such an SDL_stretchrotation.c implementation seem fairly trivial to me and just a matter of how to organise things and adding the proper checks. Well forget about the name SDL_stretchrotation.c, should be SDL_stretchrotate.c rather. Of course, we could also try to borrow from SDL_gfx here. I don't know how good its code is, but I guess it might be a lot better than what I could spontaneously come up with. But I suppose we'd need to sort out the licensing first? Hey Sam, can we incorporate this and place a dummy version of the software renderer equivalent? I promise to give it a shot next week if that's what will get this functionality incorporated. Thanks! There's another implementation of the flipping in bug 1181. I would raise it on the mailing list and see what people think, especially with regards to the software renderer. I'm not opposed to adding CopyEx with flip/rotate with an angle, although a pivot point seems like overkill to me. I like what you did there about making it optional though. Created attachment 798 [details]
RenderCopyEx, rotation and flipping for OpenGL, ES1, ES2 and D3D
Updating patch, applies cleanly on current tip.
Created attachment 801 [details]
RenderCopyEx, rotation and flipping for all renderer backends
Attaching new patch with a first pass at a software renderer, 99.9% lifted from SDL_gfx. With the test I'm running it behaves almost like the OpenGL one minus some clipping issues I've still got to figure out. Feedback is welcome!
Created attachment 802 [details]
Test for RenderCopyEx
Created attachment 805 [details]
RenderCopyEx, rotation and flipping for all renderer backends
Attaching cleaned up patch, the software backend seems to work nicely, I'm getting 130fps with the test in my machine (vs 3300fps with OpenGL!).
Created attachment 806 [details]
Test for RenderCopyEx
So, the vote on the list so far is an overwhelming 3 yay (including my vote), 0 nay, 1 "why don't you do something else entirely". It's not the massive endorsement/petty fight I expected, but is it enough? Still waiting for a decision on this. Sam has said that this will likely be incorporated, I'll poke him when I have a chance to see if we can get it done soon. Compilation issues under Win7, VC 2008 Express, Dx2007 SDK with the patch applied. The issues are related to use of functions sin(), cos(), fabs(), ceil(), memset() in SDL_rotate.c. Replacing sin(), cos() etc with SDL_sin(), SDL_cos() etc fixes the problem, but I don't know how it will affect compilation under other platforms. Also in SDL_render_d3d.c, there is an compilation issue because of use of sprintf() on line 472. Can be fixed by switching to SDL_snprintf(). Also, in SW_RenderCopyEx() in SDL_render_sw.c, the variable 'retval' can possibly be used uninitialized in one particular case, so perhaps it should be initialized to -1 beforehand. Thanks! Good catches! Sam, can we incorporate this patch with those fixes Pallav mentions? Sure! Have you already updated the patch with those changes? Created attachment 852 [details]
RenderCopyEx, rotation and flipping for all renderer backends v2
Attaching patch with Pallav Nawani's comments incorporated. I verified that it compiles under Linux (not Visual Studio)
|
Created attachment 705 [details] RenderCopyRotate I had the need to have rotation of sprites in SDL 1.3, and as I've seen a few request along the years to have this implemented I'm leaving this patch here that implements RenderCopyRotate which takes an angle in degrees and a SDL_Point to act as the center of rotation. I tried to keep it separate from the code of RenderCopyRotate where possible (even though RenderCopy is a special case of RenderCopyRotate with angle=0), at the cost of some code duplication, to make mantaining the patch easier. The notable exception to this being the OpenGL ES 2.0 backend where due to the vertex shaders I had to combine them. The patch implements rotation in Direct3D, OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0.