AGL Reference?

Sta7ic
Unregistered
 
Post: #1
A reasonable step from GLUT seems to be to use AGL instead. Are there any articles on this on the 'Net that would explain how to use AGL?
Also, what kind of performance differences are there between the two function sets? A GLUT program that I have spends about 2/3rds of its cycle time doing something other than drawing or checking the keyboard func -- clearing a 640*480 doubled RGB/Depth window can't take that long, can it?

-Sta7ic
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Lots of people say that GLUT is slow. I don't know whether I believe them Smile

Whether the values you're seeing are reasonable or not depends on what you're drawing, whether you're hardware accelerated, &c.

SDL, Carbon/AGL or Cocoa/NSGL are the obvious next steps from GLUT. There's a very good Cocoa/NSGL sample on this site called GLCubes.

I don't know of any simple Carbon/AGL code, but QTValuePak does the absolute minimum AGL setup. Using Carbon Events isn't particularly hard, but is pretty daunting if you've never done that kind of stuff before.

There's lots of good SDL/OpenGL sample code around on the web.
Quote this message in a reply
Sta7ic
Unregistered
 
Post: #3
The engine that I'm working on is cycling at 8 hz or so with lighting, under 300 tris (lighting and translations only), on an iMac/333. The drawing is requiring about 30ms, tops, with another 100ms+ used for glClear, glLoadIdent, and whatever voodoo GLUT is doing. After several hundred cycles, the numbers I'm using are about average.

I poked back through the more traditional sources and found a bare-bones AGL prog in the (surprise surprise!) AGL Reference.pdf provided with the OpenGL SDK archive off of apple.com. AGL seems to be more legacy than not, using CWindows and GrafPorts, and shuffling pictures in with QT. Gives better control over the context settings, near as I can tell (as a newB to OGL coding).

I spotted a pdf in the Developer Docs folder about assembly with the Builder apps. Should this be reserved for inducing headaches only?

-Sta7ic
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
Quote:AGL seems to be more legacy than not, using CWindows and GrafPorts, and shuffling pictures in with QT. Gives better control over the context settings, near as I can tell (as a newB to OGL coding).

Not legacy any more than Carbon is...

Apple seems to be treating Carbon more and more as a first-class citizen alongside Cocoa these days, although why you'd want to use it is beyond me Wink

Quote:I spotted a pdf in the Developer Docs folder about assembly with the Builder apps. Should this be reserved for inducing headaches only?

Definitely Smile Wouldn't touch it with a barge pole Smile

glClear is very expensive on a Rage128. Avoid it if possible.
Quote this message in a reply
Member
Posts: 145
Joined: 2002.06
Post: #5
Quote:Originally posted by Sta7ic
The engine that I'm working on is cycling at 8 hz or so with lighting, under 300 tris (lighting and translations only), on an iMac/333. The drawing is requiring about 30ms, tops, with another 100ms+ used for glClear, glLoadIdent, and whatever voodoo GLUT is doing. After several hundred cycles, the numbers I'm using are about average.

9 or X? if X: PB, CW/Mach-o, or CW/Carbon?

glClear might be taking so long because it's waiting for the drawing to finish. put a call to glFinish before the glClear and see which one takes more time.

questions if glClear still does: Do you disable blending, stipple*, and LogicOp before you glClear? Are you clearing any buffers you don't use?

questions if glFinish takes the time: Have you enabled any fancy drawing modes? (e.g. Logic Op, Blending with dst factors)? Are you requesting any special drawing capabilites?

* I just noticed that stipple doesn't show up on The OpenGL Machine! It has to be in the fragment pipeline though and thus come after glClear's entry point.

"He who breaks a thing to find out what it is, has left the path of wisdom."
- Gandalf the Gray-Hat

Bring Alistair Cooke's America to DVD!
Quote this message in a reply
Sta7ic
Unregistered
 
Post: #6
Why use Carbon instead of Cocoa? I'm much more familiar with Cpp than I am with Cocoa, even though learning the latter is on the "To Do" list.

Avoid glClear if possible on a Rage128? What should I do instead, recreate the context?
PB in X.1.?, lighting and depth enabled. Part of the delay's likely the fact that I'm being lazy with display lists, but the cycle goes (1) glClear, (2) loop 0-49's glCallList([1 or 2]), (3) glFlush. The call for just the lists takes ~30ms, but the actual runtime on that is up in the air.
Still trying to find/clear up problems.

-Sta7ic
Quote this message in a reply
Member
Posts: 145
Joined: 2002.06
Post: #7
Quote:Originally posted by Sta7ic
Avoid glClear if possible on a Rage128?
Only clear the depth buffer. Rely on drawing the full frame to effectively clear the color buffer.

"He who breaks a thing to find out what it is, has left the path of wisdom."
- Gandalf the Gray-Hat

Bring Alistair Cooke's America to DVD!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
There is also a hack you can use with OpenGL which halves your depth-buffer precision, but allows you to avoid clearing depth. YMMV, but I've seen this hack provide performance improvements on a Rage128. Any better card and it's probably not worth it.

From memory, since I don't have the code here, every frame:

Code:
static int evenFrame = 0;
if (evenFrame == 0)
{
    glDepthRange(0.0, 0.5);
    glDepthFunc(GL_LEQUAL);
}
else
{
    glDepthRange(1.0, 0.5);
    glDepthFunc(GL_GEQUAL);
}
evenFrame = !evenFrame;
Quote this message in a reply
Sta7ic
Unregistered
 
Post: #9
Interesting. I guess I'll need to accelerate a bit of design to fill up the whole screen for a change to try that.

Just half precision? Could the depth buffer be derezed and still work decently for a sidescrolling engine between 1/4 and 1/10th precision?

Thanks for the advice. If I can get an engine running at half-decent rates on a less-than-half-decent card in time, I might have something for uDevGames.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
If you're looking at doing a 2D engine, check out the Astro source code from last year -- it avoids clearing the color buffer each frame even though it doesn't fill the whole frame each time.

I had to take the color clear out to get enough performance on my Rage128.

Astro does clear the depth buffer, but I've had it working successfully (and subjectively faster) using the hack I explained above.

Typically these days, you'll get a 24-bit depth buffer, ie one that can represent 16777216 distinct depth values. I think the Rage128 uses a 24-bit depth buffer, but it could only be 16-bit (65535 distinct values).

Obviously, halving your precision like the hack above isn't going to work for all games, but it should work just fine for most nearly-2D games at any rate.

You're talking about quartering your precision, though -- what were you going to try?
Quote this message in a reply
Sta7ic
Unregistered
 
Post: #11
I was thinking that rather than using a binary variable, have it roll from pass to pass, and clearing once it hit one. Looking back, though, it'd likely work better going

GLclampd depthCheck=1.0;
glDepthCheck(GL_LEQUAL);
(in the loop...)
glDepthRange(depthCheck, (depthCheck-=0.25));
if (depthCheck<=0.0) {depthCheck=1.0; glClear(GL_DEPTH_BUFFER);

The above code was put up on the spot (so don't quote the enums), since I'm trying to make an AGL prog start working (needs more bludgeoning), and haven't revisited the engine. The constant 0.25 could be replaced with anything that shouldn't create rounding errors, and I haven't checked to see what GLclampd is typedefing. Since you're shifting forwards with the loop, every successive pass'd pass the test.

Pseudo-2D engine. Sorta like Duke Nukem/Abuse with trid graphics. The actual z drawing only goes between 0.0 and 3.0, with a light at 15, so precision is only needed to keep things from overdrawing badly. (Try putting three perpendicular squares on the origin w/o depth checking)

EDIT: Stupid auto-smilies...
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  best online or dl'able reference guide to OpenGL? sealfin 6 5,309 Jun 29, 2002 04:29 AM
Last Post: inio