[SDL] Speeding up glClear?
tompsson at hotmail.com
Fri Jan 7 11:14:55 PST 2005
Something must be wrong here.. glClear just cant take that long time. I
personally used to develope stuff for glQuake in Win98 on a AMD 450 with a
Voodoo2 and later a TNT 16Mb card. And it never ran under 30-40 fps. And
thats with a glClear every frame.
----Original Message Follows----
From: Steve Smith <onecrane at gmail.com>
Reply-To: Steve Smith <onecrane at gmail.com>,"A list for developers using the
SDL library. (includesSDL-announce)" <sdl at libsdl.org>
To: Johannes Schmidt <sdl at myrealbox.com>
CC: "A list for developers using the SDL library. (includes
SDL-announce)"<sdl at libsdl.org>
Subject: Re: [SDL] Speeding up glClear?
Date: Fri, 7 Jan 2005 09:33:15 -0600
On Fri, 7 Jan 2005 13:59:33 +0100, Johannes Schmidt <sdl at myrealbox.com>
> Sorry, I have to ask:
> Are you really sure that it is glClear that takes this long?
> glClear just fills the buffers with 0's or the given clear color.
> Every software renderer does a better job on this.
I suspected it should as well, but I don't know how else to explain
it. I don't have the code right in front of me, but it looks
something like this:
COutput::Clear(); // this function just calls glClear() with color
and depth bits
printf("display cleared in %d ms\n", clearWatch.getTime());
And when I look in stdout.txt after running this from my P2 550
running Win98, I see a bunch of lines that look like this:
display cleared in 278 ms
display cleared in 266 ms
It might be completely far-fetched, but is it possible that because
I'm double buffering, all of my rendering calls are just being cached
instead of actually executed, and the rendering itself isn't happening
until the next frame is being cleared?
I hope that makes sense to somebody other than me, and I hope I'm way
Thanks all for your help,
SDL mailing list
SDL at libsdl.org
Auktioner: Tjäna en hacka på gamla prylar http://tradera.msn.se
More information about the SDL