Sprite sheet overlap when using hardware textures |
Sprite sheet overlap when using hardware textures |
Sik
|
Yeah, that sounds like a rounding issue. No idea whether it's within
SDL or your hardware's fault (since I know some low-end GPUs are rather lackluster when it comes to it). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Re: Sprite sheet overlap when using hardware textures |
Dark_Oppressor
|
I've got a Geforce GTX 760 in this machine. I also tested it with the same results on a box with a Geforce GTS 250. I just tested it on Android (a Galaxy S4), and 1920x1080 actual resolution on there looks fine! Hrm... |
|||||||||||||
|
mr_tawan
|
Have you tried setting the SDL_HINT_RENDER_SCALE_QUALITY hint to 0 (nearest neighborhood) ?
|
|||||||||||
|
Dark_Oppressor
|
Yes, I'm sorry, I mentioned in my original post that I was using nearest render scale quality, but I should have made it more clear. Setting that hint to "nearest" is what I'm currently doing. |
|||||||||||||
|
Sprite sheet overlap when using hardware textures |
Joseph Carter
|
http://www.gamedev.net/topic/627546-solved-spritesheet-bleeding/
Note this thread is from 2012 and the OP's use of OpenGL was less than optimal in 2002 (glBegin(GL_QUADS), really?!) but it discusses some of the problems and is worth a look. You should not be having this problem with nearest neighbor pixel filtering, but hardware sometimes optimizes fast in place of correct. Is your text MOVING when the artifacts show up, and what's your blend function? On Wed, Jan 07, 2015 at 10:51:39AM +0000, Dark_Oppressor wrote:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Sprite sheet overlap when using hardware textures |
Sik
|
2015-01-08 2:48 GMT-03:00, Dark_Oppressor:
OK, that definitely looks like something to look into SDL then, I doubt *those* cards have that kind of bugs. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Re: Sprite sheet overlap when using hardware textures |
Dark_Oppressor
|
The text is not moving when the artifacts show up. I can put a letter of my bitmap font in a specific place in the window each time I test and it will always show up messed up. By blend function do you mean: 'SDL_SetTextureBlendMode(texture,SDL_BLENDMODE_BLEND);' ? I use that whenever I create a texture from an image file, including my bitmap fonts. I'm just using SDL's 2D accelerated rendering stuff. I'm going to go read that link now, thanks! |
|||||||||||||
|
Dark_Oppressor
|
OK, I read that link, and it sounds like the kind of thing I'm thinking might be happening. Some sort of hardware texture filtering something or other, but it's happening below the level that I can access through SDL's 2D rendering API. Does that sound reasonable?
I ran a test on my laptop with a Radeon HD 7520G (integrated graphics), and it works fine there in 640x360 (one of the resolutions that fails on the ones that have issues). It also works fine in 1600x900 (my laptop's max resolution), just for the record, as well as 1280x720 (which has worked on all machines so far). So, I know I have only tested on 4 machines so far, but I've seen it: Work in software mode (albeit slowly!) on the initial machine where I noted a problem Fail to work in either OpenGL or DirectX hardware accelerated modes on the initial machine Fail to work in OpenGL (did not test DirectX) on a second machine Work on a Samsung Galaxy S4 Work on a laptop with a Radeon HD 7520G Where "work" is defined as no weird sprite display issues cropping up. The two machines that are having issues are both using Nvidia cards. Not sure if that means something, but it might be a direction to look in... |
|||||||||||
|
Dark_Oppressor
|
Is this perhaps something I could/should submit a bug report about?
|
|||||||||||
|
MikeyPro
|
I'm running into the same problem of sprite frame bleeding.
I can say to a 99% certainty that this is on the end of SDL. I still need to look at SDL's source code to verify where. The frame information you pass into SDL (SDL_RenderCopy) is an SDL_Rect, which is all integers. That makes it impossible to deviate from those specifications, As long as those numbers have not changed from some calculation with floats you did beforehand, the width and height will always be correct and would not cause frame bleed. With my case, I have verified my data is always correct, and yes, my quality has been set to nearest for pixel perfect drawing, or as close to as I am offered from the library. One thing about this bug is I only see it occur in windowed mode. When I go fullscreen the bleeding does not occur. I always use the desktop resolution and then set a logical resolution of 320x240, with windowed mode using an 800x600 window. So until I look at the source, I can only assume SDL itself is actually using floats somewhere in the texture lookup for the source rectangle and messing it up. It's a common mistake and with SDL2 being a new iteration of SDL, it's not that big of a shocker it has some bugs. This is being done on a Windows 7 x64 machine. If anybody has anything else to add, that'd be great. |
|||||||||||
|
MikeyPro
|
I believe the problems for the opengl renderer, which is the one I use and assume is the OP's renderer as well, might be coming from the source file SDL_render_gl.c starting at line 1209 where it uses floats to calculate the rectangles for the texture:
|
|||||||||||||
|
MikeyPro
|
Maybe some kind soul could check it out and compile to see? I believe ( )'s surrounding the integer calculations before the cast to GLFloat might be what is needed to prevent the issue... I may be wrong, but I don't think the GLfloat cast is casting the entire op and only the lefthand operand of the divisions... I could be wrong but it would make sense considering the issue.
|
|||||||||||
|
MikeyPro
|
Or SDL could use the integer form of the GL functions, instead. Why use floats anyway? Anyone who calls the RenderCopy function call can only pass integers to it in the form of SDL_Rect....
|
|||||||||||
|
MikeyPro
|
So after all that and a bug report, it comes down to the GPU handling of texels. The way around it is to just add an empty pixel border around every single image and sprite frame you do. It's not fun, but it's worth it... grumble... grumble..
|
|||||||||||
|