hold on, memory (and ASP) tell me I've got a Rage 128 Pro, now I come to think of it. I've got a G4/400 too, so perhaps the "Rage 128" and "Rage 128 Pro" strings have got swapped somewhere? After all, you'd expect that the "Pro" one would be faster.

I like my machine a lot though - it may be a bit old now, but it stayed beefy for longer than any other machine I've had.

Quote:Originally posted by codemattic this is on a G4 400 b/w ati128. w_reade clearly has a beefier machine than me - rascal!

That's one problem with it. Doing the backface culling and silhouette determination is a significant cost on slow CPUs.

Quote:The aa looks very nice in the 'Demo' app. From 'Speed Test' it looks like there isnt much of a speed hit. When you patent it make sure to post your licensing terms!

I'd certainly consider case-by-case licenses for small developers .

Quote:'Demo' actually looks very cool - are you writing a level-editor editor or 3d-modeller or both. Is it purely in-house - or are you planning on making it into a product itself?

It was originally going to be a generic in-house framework for editors (sorta like Kai's demo shell), but I have a few apps that use it that I'm considering releasing at some point (they're still way to buggy now to even consider releasing though).

I am also running a G4 400, but mine has been stuffed over the years. I found the gf2mx to be a worthy companion to the CPU. Under 9 it is still a reasonalble gaming machine, unfortunately less so on X. I will do this speed test as soon as I get around to it.

Running on an 867MHz G4 with X.2.3. Definitely a speed hit with the AA, but not the 70% you said.

Wow, that's weird. Shows ya how long it's been since I deved this thing. Under 10.1 the gl backface cull sets would run as fast as that first set, and the anti-aliased sets would run at about the speed that the later gl backface culls are running. I really need to look into what apple changed.

Quote:Originally posted by ghettotek cant you just do glEnable(GL_POLYGON_SMOOTH); to antialias polygons?

You certainly can, but you may not want to for several reasons:

1. It requires that every single pixel in the image get blended, something that is slow on older cards. and
2. It also requires that you either:
&nbsp;a. Draw the entire scene back to front, foregoing any z-fail optimizations your graphic card might do, and potentially generating visible seams where two polygons meat. or
&nbsp;b. draw the scene front to back, using a potentially slow source-dependant blending algorithm
3. as a result of 2, no matter what you do you have to decompose your scene into a single polygon list, and then depth-sort this list. and
4. dealing with transparency and anti-aliasing at the same time is difficult to impossible if you chose 2b.