This new version rotates the gears while the key is held down, rather
than just once when the key is pressed. This version also supports
dynamic resizing, like the original glut gears.
http://www.libsdl.org/opengl/SDLgears-1.0.2.tar.gz
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Is this gonna end up as a sourceforge project?
I’m sure someone wants to use gears as a basis for a game engine or maybe
an SDL based windowing system?:)On Mon, 24 Jul 2000, Sam Lantinga wrote:
This new version rotates the gears while the key is held down, rather
than just once when the key is pressed. This version also supports
dynamic resizing, like the original glut gears.
Bother! said Pooh, as he tried to install Windows.
This new version rotates the gears while the key is held down, rather
than just once when the key is pressed. This version also supports
dynamic resizing, like the original glut gears.
Add -lm to the libs, it’s got sqrts and trigs and stuff in it
This new version rotates the gears while the key is held down, rather
than just once when the key is pressed. This version also supports
dynamic resizing, like the original glut gears.
Over a 15-sec period I noticed a slight performance improvement (764
frames vs. 1500 frames) but there is a severe drag in
key-responsiveness, for example, pressing any key to rotate the gears
takes nearly 3 seconds before the actual rotation begins, which then
proceeds smoothly. I’m using indirect rendering under X 4.0.1 with a
MGA 200.> http://www.libsdl.org/opengl/SDLgears-1.0.2.tar.gz
–
Ashley Clark
GCS/M d- s:-- a-- C++$ UL++++$ P+>+++ L+++ E W++ N+ o K++ w O M V–
PS+(++) PE(++) Y+ PGP++(+++) t* 5+ X+ R* tv b+ DI++ D G e* h* r++ y+
finger @Ashley_Clark for GPG public key http://ghoti.org/
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000724/08083ff0/attachment.pgp
Over a 15-sec period I noticed a slight performance improvement (764
frames vs. 1500 frames) but there is a severe drag in
key-responsiveness, for example, pressing any key to rotate the gears
takes nearly 3 seconds before the actual rotation begins, which then
proceeds smoothly. I’m using indirect rendering under X 4.0.1 with a
MGA 200.
I’m seeing this too.
The application is actually blocking in glXSwapBuffers() for about 2-3
seconds, presumeably because the X server is busy trying to catch up with
the requested calls.
I’m not sure why glut doesn’t cause this as well, but it’s interesting to
note that that X is using 99% of the CPU with SDLgears, but only 96% with
glut gears:
SDLgears:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
631 root 15 0 54040 50M 1376 R 0 99.0 40.3 18:39 X
32496 hercules 12 0 1192 1192 984 R 0 0.7 0.9 0:00 top
32495 lauren 9 0 1568 1568 1084 S 0 0.1 1.2 0:00 SDLgears
gears:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
631 root 15 0 54044 50M 1376 R 0 96.6 40.3 19:57 X
32497 lauren 9 0 1856 1856 1304 S 0 2.5 1.4 0:00 gears
32496 hercules 12 0 1192 1192 984 R 0 0.7 0.9 0:00 top
I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.
Comments?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Is this with XFree86 4.0?
DaveOn Tue, 25 Jul 2000, Sam Lantinga wrote:
Over a 15-sec period I noticed a slight performance improvement (764
frames vs. 1500 frames) but there is a severe drag in
key-responsiveness, for example, pressing any key to rotate the gears
takes nearly 3 seconds before the actual rotation begins, which then
proceeds smoothly. I’m using indirect rendering under X 4.0.1 with a
MGA 200.I’m seeing this too.
The application is actually blocking in glXSwapBuffers() for about 2-3
seconds, presumeably because the X server is busy trying to catch up with
the requested calls.I’m not sure why glut doesn’t cause this as well, but it’s interesting to
note that that X is using 99% of the CPU with SDLgears, but only 96% with
glut gears:SDLgears:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
631 root 15 0 54040 50M 1376 R 0 99.0 40.3 18:39 X
32496 hercules 12 0 1192 1192 984 R 0 0.7 0.9 0:00 top
32495 lauren 9 0 1568 1568 1084 S 0 0.1 1.2 0:00 SDLgearsgears:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
631 root 15 0 54044 50M 1376 R 0 96.6 40.3 19:57 X
32497 lauren 9 0 1856 1856 1304 S 0 2.5 1.4 0:00 gears
32496 hercules 12 0 1192 1192 984 R 0 0.7 0.9 0:00 topI’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.Comments?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Is this with XFree86 4.0?
Yes. XFree86 4.0, DRI MGA driver.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.
This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.–
“How should I know if it works? That’s what beta testers are for.
I only coded it.” – Linus Torvalds
That would be my guess as well.
–Brian>I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.Comments?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.
This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.
Inserting XFlush() didn’t seem to help though. I’ll try XSync() when I
get home.
-Sam Lantinga, Lead Programmer, Loki Entertainment SoftwareSam Lantinga wrote:
I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.Inserting XFlush() didn’t seem to help though. I’ll try XSync() when I
get home.
No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.–
“And 1.1.81 is officially BugFree™, so if you receive any bug-reports
on it, you know they are just evil lies.” – Linus Torvalds
Sam Lantinga wrote:
I’m guessing that the glut version is giving X a chance to process the
gl requests, and the SDL version is driving it as hard as it can. The
fact that the direct rendering version is very responsive seems to bear
this out.This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.Inserting XFlush() didn’t seem to help though. I’ll try XSync() when I
get home.
No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.
Should every swapbuffers call be sync’d on the X server? I suppose so,
but that’s additional time which hardware could be rendering…
Comments?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.Inserting XFlush() didn’t seem to help though. I’ll try XSync() when I
get home.
No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.
Should every swapbuffers call be sync’d on the X server? I suppose so,
but that’s additional time which hardware could be rendering…
Comments?
Well, I added an XSync() to the swap-buffers call, and the framerate
went down to the gears level and responsiveness jumped way up.
I’d really hate to add a round-trip to the server to a call that, when
hardware is available, takes very little time. I now understand why
there was a 100 FPS increase when switching to SDL gears on some cards.
Suggestions?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
This is very similar to what I had with my bare-Xlib blitting test when
I didn’t use XSync.Inserting XFlush() didn’t seem to help though. I’ll try XSync() when I
get home.No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.Should every swapbuffers call be sync’d on the X server? I suppose so,
but that’s additional time which hardware could be rendering…Comments?
Well, I added an XSync() to the swap-buffers call, and the framerate
went down to the gears level and responsiveness jumped way up.I’d really hate to add a round-trip to the server to a call that, when
hardware is available, takes very little time. I now understand why
there was a 100 FPS increase when switching to SDL gears on some cards.Suggestions?
Give the X server a little bit higher priority, than your clients.
renice -10
This should help the server to process all request.
Or reduce the priority of your client at start with nice().
Bye,
Johns–
Become famous, earn no money, create graphics for FreeCraft.
http://FreeCraft.Org - A free fantasy real-time strategy game engine
http://fgp.cjb.net - The FreeCraft Graphics Project
Sam Lantinga wrote:
No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.Should every swapbuffers call be sync’d on the X server? I suppose so,
but that’s additional time which hardware could be rendering…
Swapbuffers are for the full screen? Hmm, depends on the application I’d
think… Maybe you should take a look at the GLUT source? Often, you can
use XSync as a parallel to the old “wait for vertical retrace” function,
but this does cut on performance. That might explain the advantage of
SDL over GLUT. Isn’t this supposed to be some glXSync() call instead of
XSync()? Is there a GLX call to know if the “pipe is clogged”? Like
XPending, but in the other way?–
“There are two major products that come out of Berkeley: LSD and Unix.
We don’t believe this to be a coincidence.” – Jeremy S. Anderson
Sam Lantinga wrote:
No, XFlush doesn’t help. This just makes sure the requests makes it to
the X server, not that they are properly executed, so they just pile up
on the X server, flooding the poor thing.Should every swapbuffers call be sync’d on the X server? I suppose so,
but that’s additional time which hardware could be rendering…Well, I added an XSync() to the swap-buffers call, and the framerate
went down to the gears level and responsiveness jumped way up.I’d really hate to add a round-trip to the server to a call that, when
hardware is available, takes very little time. I now understand why
there was a 100 FPS increase when switching to SDL gears on some cards.
Hmm, on what versions of XFree86 and with which OpenGL drivers is this?
I think that for regular Xlib calls, XFree86 4.x new scheduler fixed
most of this responsiveness problem, but I wonder if GLX requests are
avoiding the regular scheduler and making things crappy just like it was
in 3.x?–
“There are two major products that come out of Berkeley: LSD and Unix.
We don’t believe this to be a coincidence.” – Jeremy S. Anderson
Hmm, on what versions of XFree86 and with which OpenGL drivers is this?
I think that for regular Xlib calls, XFree86 4.x new scheduler fixed
most of this responsiveness problem, but I wonder if GLX requests are
avoiding the regular scheduler and making things crappy just like it was
in 3.x?
This is for the software rendering implementation in XFree86 4.0.1
What’s happening is that the X server is so busy actually performing
the rendering that it doesn’t deliver key events.
Maybe this discussion should be relayed to the XFree86 list…
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Hmm, on what versions of XFree86 and with which OpenGL drivers is this?
I think that for regular Xlib calls, XFree86 4.x new scheduler fixed
most of this responsiveness problem, but I wonder if GLX requests are
avoiding the regular scheduler and making things crappy just like it was
in 3.x?This is for the software rendering implementation in XFree86 4.0.1
What’s happening is that the X server is so busy actually performing
the rendering that it doesn’t deliver key events.
Try the program I attached, first as-is, then another time with the
XSync() commented out. I suggest you try it both on 3.x and 4.0.1 to see
what I mean.
Also… If you could give me the MB/sec you get (with the XSync!) in
4.0.1 and what kind of hardware you have, I would be thankful!
Maybe this discussion should be relayed to the XFree86 list…
I’m on xpert at xfree86.org, don’t hesitate to come by!–
“Those who do not understand Unix are condemned to reinvent it,
poorly.” – Henry Spencer
-------------- next part --------------
#include <sys/time.h>
#include <stdio.h>
#include <X11/Xlib.h>
#undef TILE_TRICK
#undef GRAB_SERVER
#define WINDOW_X 640
#define WINDOW_Y 480
#define BLIT_X 640
#define BLIT_Y 480
#define DEPTH(display) DefaultDepth(display, DefaultScreen(display))
int main() {
unsigned int frames;
int i, j;
int buf;
Display* dpy;
XPixmapFormatValues* pixmapfmt;
Window win;
GC gc;
Pixmap bufs[2];
struct timeval time1;
struct timeval time2;
unsigned int diff;
unsigned int bytes_per_pixel = 0;
double mbps;
XGCValues gcvalues;
dpy = XOpenDisplay(NULL);
win = XCreateSimpleWindow(dpy,
DefaultRootWindow(dpy),
0, 0, /* x, y /
WINDOW_X, WINDOW_Y, / width, height /
0, 0, / border_width, border /
None); / background */
XSelectInput(dpy, win, ExposureMask | KeyPressMask);
XMapWindow(dpy, win);
bufs[0] = XCreatePixmap(dpy,
win,
BLIT_X, BLIT_Y, /* width, height /
DEPTH(dpy)); / depth */
bufs[1] = XCreatePixmap(dpy,
win,
BLIT_X, BLIT_Y, /* width, height /
DEPTH(dpy)); / depth */
gcvalues.function = GXcopy;
gcvalues.plane_mask = AllPlanes;
gcvalues.fill_style = FillSolid;
#ifdef TILE_TRICK
gcvalues.tile = bufs[0];
gcvalues.ts_x_origin = 0;
gcvalues.ts_y_origin = 0;
#endif
gcvalues.graphics_exposures = False;
gc = XCreateGC(dpy,
win,
GCFunction
| GCPlaneMask
| GCFillStyle
#ifdef TILE_TRICK
| GCTile
| GCTileStipXOrigin
| GCTileStipYOrigin
#endif
| GCGraphicsExposures,
&gcvalues);
XSetForeground(dpy,
gc,
WhitePixel(dpy, DefaultScreen(dpy)));
XFillRectangle(dpy,
bufs[0],
gc,
0, 0, /* x, y /
BLIT_X, BLIT_Y); / width, height */
XFillRectangle(dpy,
win,
gc,
0, 0,
640, 240);
XSetForeground(dpy,
gc,
BlackPixel(dpy, DefaultScreen(dpy)));
XFillRectangle(dpy,
bufs[1],
gc,
0, 0, /* x, y /
BLIT_X, BLIT_Y); / width, height */
pixmapfmt = XListPixmapFormats(dpy, &i);
for(j = 0; j < i; j++) {
printf(“Pixmap format #%i\n”, j);
printf(" depth = %i\n", pixmapfmt[j].depth);
printf(" bits_per_pixel = %i\n", pixmapfmt[j].bits_per_pixel);
printf(" scanline_pad = %i\n", pixmapfmt[j].scanline_pad);
if(pixmapfmt[j].depth == DEPTH(dpy)) {
printf(" is default pixmap format\n");
bytes_per_pixel = pixmapfmt[j].bits_per_pixel / 8;
}
}
XFree(pixmapfmt);
while(1) {
XEvent ev;
XNextEvent(dpy, &ev);
if(ev.type == Expose) {
printf("got Expose\n");
break;
}
}
frames = 0;
buf = 0;
XSetGraphicsExposures(dpy,
gc,
False);
gettimeofday(&time1, NULL);
#ifdef GRAB_SERVER
XGrabServer(dpy);
#endif
while(1) {
#ifdef TILE_TRICK
XSetWindowBackgroundPixmap(dpy, win, bufs[buf]);
XClearArea(dpy, win, 0, 0, BLIT_X, BLIT_Y, False);
#else
XCopyArea(dpy,
bufs[buf],
win,
gc,
0, 0, /* src_x, src_y /
BLIT_X, BLIT_Y, / width, height /
0, 0); / dest_x, dest_y */
#endif
XSync(dpy, False);
if(XPending(dpy)) {
XEvent ev;
XNextEvent(dpy, &ev);
if(ev.type == KeyPress && ev.xkey.keycode == 9)
break;
}
buf = 1 - buf;
frames++;
}
#ifdef GRAB_SERVER
XUngrabServer(dpy);
#endif
gettimeofday(&time2, NULL);
diff = (time2.tv_sec * 1000) + (time2.tv_usec / 1000);
diff -= (time1.tv_sec * 1000) + (time1.tv_usec / 1000);
printf(“frames = %i\n”, frames);
printf(“ms = %i\n”, diff);
printf(“bpp = %i\n”, bytes_per_pixel);
printf(“fps = %i\n”, (frames * 1000) / diff);
mbps = (frames * 1000) / diff;
mbps = mbps * (BLIT_X * BLIT_Y * bytes_per_pixel);
mbps = mbps / (1024 * 1024);
printf(“MB/sec = %f\n”, mbps);
XUnmapWindow(dpy, win);
XDestroyWindow(dpy, win);
XFreePixmap(dpy, bufs[0]);
XFreePixmap(dpy, bufs[1]);
XCloseDisplay(dpy);
return 0;
}