Video problem

hi, im asking for you help on this issue,

im making calls SDL_BlitSurface without regulating frame rate, and everything was working just fine, my player sprite is composed by other five smaller sprites that arrange by the x and y blitting coordinates, now im regulating frame rate and im having this problem: the smaller sprites that should arrange using the coordinates now they are not, if the player sprite is moving fast across the screen the smaller sprites seem to be left behind and chase later the player sprite, thought this may be a problem with the code but i had other problem, i have a ‘bullet’ sprite, some thing, worked fine without regulating frame rate, but when the framerate was set to 30fps now this ‘bullet’ sprite seems to have a ‘ghost bullet’ behind chassing it, seems like a double bullet,is this an optic effect?, I made some other code on directX time before with the very same problem, im reusing the idea in this code following some tutorials and finally got the SDL one, so is this ‘double blit problem’ common?, how can i get it solved?, hope you can help me and have this working again, thanks for all your help and time on this one!!

greetings
P.D. english is not my first language so please excuse any mistake!_________________________________________________________________
Tenemos lo que b?scas?JUEGOS.
http://club.prodigymsn.com/

Seems like your code was made to work in a different way. I would make a copy and cut out everything except the object and bullet. It should make the issue easy to find and then you can take the fix to the original. That’s one way.

---- javier morante <javiermor_g at hotmail.com> wrote:> hi, im asking for you help on this issue,

im making calls SDL_BlitSurface without regulating frame rate, and everything was working just fine, my player sprite is composed by other five smaller sprites that arrange by the x and y blitting coordinates, now im regulating frame rate and im having this problem: the smaller sprites that should arrange using the coordinates now they are not, if the player sprite is moving fast across the screen the smaller sprites seem to be left behind and chase later the player sprite, thought this may be a problem with the code but i had other problem, i have a ‘bullet’ sprite, some thing, worked fine without regulating frame rate, but when the framerate was set to 30fps now this ‘bullet’ sprite seems to have a ‘ghost bullet’ behind chassing it, seems like a double bullet,is this an optic effect?, I made some other code on directX time before with the very same problem, im reusing the idea in this code following some tutorials and finally got the SDL one, so is this ‘double blit problem’ common?, how can i get it solved?, hope you can help me and have this working again, thanks for all your help and time on this one!!

greetings
P.D. english is not my first language so please excuse any mistake!


Tenemos lo que b?scas?JUEGOS.
http://club.prodigymsn.com/

[…]

worked fine without regulating frame rate, but when the framerate
was set to 30fps now this ‘bullet’ sprite seems to have a ‘ghost
bullet’ behind chassing it, seems like a double bullet,is this an
optic effect?,
[…]

What was your frame rate without regulating it? Did you use a double
buffered hardware display surface? (That is, potentially hardware
page flipping.) Are you using a CRT or LCD monitor?

I suspect what you’re seeing is just a perfectly normal side effect of
the frame rate dropping below the display refresh rate: Ghosting. The
effect is very obvious on CRTs as each refresh just briefly "flash"
the image, whereas an LCD keeps the entire image fixed until the next
refresh.

What happens is, when your eyes are tracking moving objects on the
screen, they’re smoothly tracking the intended motion. Obviously,
the objects are not actually moving; they just jump a small
distance at a time, once for each update. As the eyes are constantly
receiving and registering light, it becomes very important what
happens between updates, and even between display refreshes.

With a CRT and one update per refresh, it will look absolutely smooth,
as the objects will “hit” your retina in the same spot every update,
and go away “instantly”, before any blurring occurs. You’ll not see
the “flashing” (unless you’re using a very low refresh rate,
obviously), nor any side effects of it. This is how many games back
in the 8 and 16 bit days could achieve silk smooth scrolling and
animation, despite the low PAL or NTSC refresh rates.

Now, if you don’t update the screen every refresh, the moving objects
will be “flashed” in the same physical spot several times in a row
before they move. However, your eyes are still tracking the intended
motion, catching undesired multiple exposures of the objects in wrong
places. Basically, your eyes move to track the objects - but the
objects don’t move all the time, so you get ghost exposures.

With an LCD or other similar typ of display, a similar thing happens,
but here, the objects are actually visible at all times, just holding
still between updates, causing continous exposure. So, you get
smearing, looking much like motion blur, rather than ghost images.

To avoid ghosting on a CRT display, you need to produce a new frame
with correct object positions for each display refresh, regardless of
what refresh rate is used. The best way is to use OpenGL or Direct3D
to implement sub-pixel accurate rendering, as otherwise, you’ll get
jittering or vibration when objects move at certain speeds.

Unfortunately, the only way to “eliminate” this phenomenon on an LCD
is to use ridiculously high refresh rates. (Hundreds of Hz probably;
I’ve tried it with 300 Hz refresh rate and 150 fps on a CRT, and that
wasn’t even close…) As that’s a waste of rendering power, and
probably won’t work on any LCDs available at this time, the only
reasonable “solution” is to just pretend you’re dealing with a CRT,
and at least get the “one update per refresh” part right. An LCD with
a stroboscopic backlight would do the trick, but I haven’t seen one
of those yet… Probably won’t happen anyway, as “everything” is
either 3D or barely moving “2D” these days, which means most people
won’t notice the diffecence. (It’s not an issue if you wave the
virtual camera around while keeping your eyes fixed on the screen.)

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 07 August 2008, javier morante wrote: