Hi there.
I've noticed that windowed applications, when incorporating any sort of camera system with vertical scrolling, generates pixel gaps between bitmap tiles.
Here's an image:
{"name":"nlosyh.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/f\/ef0ebffbd1a685f8ea20e16c27b20319.png","w":482,"h":509,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/f\/ef0ebffbd1a685f8ea20e16c27b20319"}
Notice the al_clear_to_color() call bleeding between the tiles. This does not occur until the camera begins scrolling vertically (horizontal scrolling has no affect).
Here's my crude example code:
I am running x86_64 Ubuntu 13.10 with Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) graphics card.
Do you see anything wrong with the way I'm structuring the example code? What could be causing this?
I've attached the example source and bitmap files to this post. Your feedback is most appreciated.
Unable to reproduce here, no matter how I set driver vsync etc. Slackware 14.1 with Nvidia driver 330.20 and GeForce GTX 650 card.
{"name":"608217","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/7\/3738f2640796239829ae936f503ccd8f.png","w":480,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/7\/3738f2640796239829ae936f503ccd8f"}
I am running x86_64 Ubuntu 13.10 with Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) graphics card.
Intel Graphics Chipsets = Severely Lame
What's probably happening is your graphics chipset can't properly handle floating-point positions, since you're only moving everything in half-block increments. That said though, you really should round all your coordinates for drawing stuff down to the next whole number in order to avoid aliasing and to keep fine details in the graphics from flickering. This may also solve the issue you're having.
Unable to reproduce here, no matter how I set driver vsync etc. Slackware 14.1 with Nvidia driver 330.20 and GeForce GTX 650 card.
Thank you for giving it a go, Arthur. It is good to know that it is an issue with just my machine.
Intel Graphics Chipsets = Severely Lame
What's probably happening is your graphics chipset can't properly handle floating-point positions, since you're only moving everything in half-block increments. That said though, you really should round all your coordinates for drawing stuff down to the next whole number in order to avoid aliasing and to keep fine details in the graphics from flickering. This may also solve the issue you're having.
About the floating-point positions, I knew this; I just wanted to ensure that IS the issue (which you've confirmed). I've known that whole value movement (1px instead of 0.5px, for example) works just fine, but a speed of 1 is too fast (for my liking) after transforming the display.
I recall not having this issue several months ago. This all began after messing with some things in Ubuntu. What do you think: would a factory re-install of Linux potentially solve the issue?
On my XUbuntu laptop using the i915 driver (Intel 3000?) I get the same gaps.
What do you think: would a factory re-install of Linux potentially solve the issue?
It's most likely related to your graphics drivers so the simplest thing to do would be to roll back to earlier drivers and see if the problem goes away, or install the latest drivers and see if that helps. I seriously doubt the problem would be related to anything else.
Plus, I didn't say you had to move everything by whole-pixel increments, just round down the coordinates used for drawing when you draw them. You can still store and move positions at the floating-point level.
With my own game objects, because I use a frame interpolation system that can run a game at a fixed framerate yet render at whatever framerate the end user can achieve, all of my game objects track the coordinates they are currently in, the coordinates they were in on the last fixed frame, and the coordinates they should render to.
Plus, I didn't say you had to move everything by whole-pixel increments, just round down the coordinates used for drawing when you draw them. You can still store and move positions at the floating-point level.
With my own game objects, because I use a frame interpolation system that can run a game at a fixed framerate yet render at whatever framerate the end user can achieve, all of my game objects track the coordinates they are currently in, the coordinates they were in on the last fixed frame, and the coordinates they should render to.
Hmm, what an interesting concept. Would you mind posting pseudo code? What immediately came to my mind was to change the camera values to ints, and then to pass the player's floats as arguments (thus accumulating whole-values after 0.5+ goes for two cycles). This corrected the gaps, but, to no surprise, resulted in jittery player movement.
Hmm, what an interesting concept. Would you mind posting pseudo code?
Not sure of a good way to write this in pseudo-code, but if you're experiencing jitter it's typically related to not rounding things in the right order, rounding values together that should be rounded separately, or figuring out positions based on rounded values instead of actual values or vice versa. The best way to scan this is to cut all your movement rates down by a factor of 100 or so, write the values on-screen for each step of the calculations and watch them as they slowly change. This is what I do when one of my math equations does funny stuff like this and watching the numbers change is a good way to gauge what's causing things like jitter to happen.
Also, since the Allegro drawing functions take floats, not ints, you probably shouldn't convert to them at any point and just stick with using floor().