Re: Problem gettting a smooth continous background scroll (SDL2)

BenoitRen wrote:
> 
> -The duration of one frame when rendering at 60 frames per second is not 16 milliseconds, but 16.67 milliseconds (1000 / 60 = 16.67). This difference in timing adds up.


Right. But I tried with different delays, speeds, etc. configurable while processing the scroll so I could see the changes in runtime.
Problem is still there.
I'm not completely sure if it's tearing. Looks so, if I understood correctly what tearing is.


BenoitRen wrote:
> 
> -Every frame you insert a waiting period of 16 milliseconds. This does not take into account the time it takes to process one frame between the delays.
> 


Right. But I tried to use more advanced timing control and the problem is still there.


BenoitRen wrote:
> 
> -SDL_Delay is not very reliable. The operating system's scheduler might decide to allocate some time to another process instead of yours at the time you expect control back.
> 


True. I was reading about that the last days and applied some timing methods withotu using SDL_Delay, related to previous suggestions. Some improvement but I still see the problem.



BenoitRen wrote:
> 
> There are two approaches you can take.
> 
> One approach is using timers, which Lazy Foo' also explains in one of his tutorials. To solve the problem of one second not cleanly being divisible by 60, you can combine it with the approach explained by Aaron at Wolfire (http://forums.wolfire.com/viewtopic.php?f=1&t=16539). In short, it makes every first and second frame take 17 milliseconds, and every third frame 16 milliseconds. Personally, I combined all of that with what Disch explained at NESDev (http://forums.nesdev.com/viewtopic.php?f=3&t=6107) to try to mitigate SDL_Delay's unreliability.
> 
> The second approach is to have your program wait for vsync after rendering a frame. To use this, pass the SDL_RENDERER_PRESENTVSYNC flag to SDL_CreateRenderer's flags parameter.


Timers... pending subject. I'll start with them.

I tried enabling Vsync before reading your suggestion. The scroll is smooth, perfect. Although I don't want to use this, because it limits the frame rate to the monitor refresh (60Hz in my case), and for this simple example is ok but for more complex processing can be a big limitation. Anyway I don't know much about game development to see if this can be or not an issue for a real 2D game.

I found many examples claiming "smooth" scrolls but 99% of them use VSync.
Few days ago I found 1 example with a very smooth scroll without using Vsync. This example (http://olofson.net/download/smoothscroll-1.1.tar.gz) uses SDL1 or GL (selectable), and a "time filter" to deal with shedulling jitter.
The example shows a very smooth scroll with a map bigger than screen (in fact it's a parallax scroll of 3 layers).
It comes with a precompiled example. The example works nicely. I compiled the source in VS2013, and... tadaaaaa with the new compiled code the scroll is not smooth [Crying or Very sad]

I have to explore this, because makes no sense unless something is happening related to my especific hardware (I'm using a laptop). Again from my novice perspective a simple smooth scrool shouldn't be so hard, but  it looks it is a challenge (of course without using Vsync).



Jonny D wrote:
> 
> If you have a low rate of scrolling, like on the order of 10 pixels per second or less, you will experience pixel-sized jitter.


Yep, I was reading indirectly about that, when people use floats for calculating speeds and positioning what is correct then rendering with floats results and weird things happened.


I'll try all your suggestions (and read the websites you posted), and will return with the results. I don't want to use Vsyng. If anyone has more to say, don't hesitate, I'll read the forum often.

------------------------
Signature under construction.

_______________________________________________
SDL mailing list
[email protected]
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org