There’s seems to be a problem inside SDL 1.3 RenderCopy function, which by default clips source (texture) together with destination (window relative) rect, when destination rect is out of window bounds. I hit this problem when I am using stretched LOW resolution texture together with destination rect which overflows window rect (has negative coords for example).
RenderCopy is using both integers for destination and source (texture) coords. While it is OK using ints for destination coords, it isn’t for texture. Here goes the sample:
[1] Imagine I want to stretch 2x2 (two by two pixels) texture like that: (See ASCII art below ;P, You need to have fixed size font :>)±--------------------------------+
| |
±—|---±--------+ |
| : | | |<----- window
| : | 1 pixel |<— texture |
| : | | |
±—|---±--------+ |
| : | | |
| : | | |
| : | | |
±—|---±--------+ |
| |
±--------------------------------+
[2] Unfortunately RenderCopy will try to clip both destination and source (texture) rects to make destination rect not to overflow window. Both clippings (including texture coords) will be done using integers not floats so we will get following VERY INACCURATE output:
+---------------------------------+
| |
+---------+ |
| | |<----- window
| 1 pixel |<--- texture |
| | |
+---------+ |
| | |
| | |
| | |
+---------+ |
| |
+---------------------------------+
[3] Instead of this, if we have used floats (accurate source rect clipping).
+---------------------------------+
| |
|---+---------+ |
: | | |<----- window
: | 1 pixel |<--- texture |
: | | |
|---+---------+ |
: | | |
: | | |
: | | |
|---+---------+ |
| |
+---------------------------------+
Attaching some patch that adds SetTextureClipMode and GetTextureClipMode functions that controls (turns on/off src/dst clipping). By default it uses default behavior that clips. But we can turn off selectively src or dst clipping using SetTextureClipMode.
While having negative or overflowing destination coordinates (or texture source coords) is absolutely legal in OpenGL (D3D too I believe), I have absolutely no idea if it is legal in software renderer or others such as DirectFB or Windows GDI. So I have no idea if this simple fix is enough.
Anyway this patch does good job for me. And doesn’t break anything by default.
Alternatively (to my patch) internal renderer->RenderCopy implementation could take floats or doubles for texture (source coord) instead of ints, this would solve inaccuracy, keeping clipping as it was before. See image [3]
Waiting for your comments,
Adam Strzelecki | nanoant.com
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL-SVN-SetTextureClipMode.patch
Type: application/octet-stream
Size: 4793 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20091110/badd2bf2/attachment.obj
