[SDL] SDL Graphics Tutorials Run SLOW for Modern PC

[Alan Wolfe]

yeah actualy if you are saying you get about 80fps, 80hz is a common refresh
rate.

you can disable vsync (and get things that go crazy fast like your saying
old nes games that go so fast they are unplayable) but then you also get
tearing and shearing which is generaly no good.

----- Original Message ----- 
From: "Bob Ippolito" <bob at redivi.com>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<sdl at libsdl.org>
Sent: Monday, December 20, 2004 2:44 PM
Subject: Re: [SDL] SDL Graphics Tutorials Run SLOW for Modern PC


> On Dec 20, 2004, at 5:35 PM, G B wrote:
>
> > What do you mean by fine?  Does it take 8 seconds to
> > move the 130x130 bmp across the 640 width screen.
> > Being that it scrolls 1 pixel at a time, I'm getting
> > only 640/8, or ~80 frames for this incredibly simple
> > animation.
> >
> > I'm running it using an ATI Mach64 3D Rage II (an
> > older card), but it performs maybe only 2 times better
> > (~160 frames) on my Centrino laptop with Intel 832
> > chipset integrated graphics card that runs Quake III
> > Arena (modern 3D game), for example, like a champion.
> >
> > Maybe ~160 frames sounds ok, but glxgears runs at,
> > what 2000+ frames with any decent 3D card.  Also,
> > maybe 160 frames is ok for 2D stuff, but then, what
> > visual trick is happening in ancient games that
> > allowed them to appear to smoothly scroll with
> > technology that was, what, 1/(2^10) ~1000th the speed
> > it is today.  The lesson2 graphic should zoom across
> > the screen like lightning, like some old games to when
> > you play them on modern PCs.  Is it zooming across the
> > screen for you? Why not?
>
> You shouldn't expect it to go at a million miles per hour, it depends
> on the buffer swapping code for your platform.  In some cases, a buffer
> swap waits for a vertical retrace, so your maximum frames per second
> will be about the same as the refresh rate of the monitor.  This is
> actually a good thing, because you won't see tearing.  It's a horrible
> waste of CPU time to do it any other way.
>
> Also note that you're probably also pushing around 2^10th more data
> around between RAM and VRAM with a double or triple buffered context,
> at 32bpp, at higher resolutions than old devices.  OpenGL doesn't
> really have this problem, because all the hard stuff (hopefully)
> happens inside the card, which is fast.
>
> -bob
>
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl