Tweaks to B3D accelerator code.

[Andreas Raab]

Hi Alan,

[Note that the disney email address is no longer valid]

> I got my build working well enough that I was able to play around with 
> some of the Baloon3D code. (Ask Ian why you are having problems building 
> B3D on unix... it's his fault!)

Can you say something more specifically about what the problem is? I 
have been recompiling Unix VMs on my share of obscure platforms and 
never had a problem. Something more specific than "ask Ian" would be 
greatly appreciated.

> 1. Removed many error tests... OpenGL is a safe protocol so extra error 
> checking is not required. Any sanity checks should be accomplished in 
> the gererated portion of the code, before it reaches the OpenGL 
> interface anyway. This will allow the code to run smoother, especially 
> through deep pipelines.

That was a mistake. Assuming that OpenGL is a "safe protocol" is fine as 
long as you are dealing with the specs - when it comes to the ugly 
reality of dealing with the drivers these checks can be live-saving (see 
glCompositeTransform for a rather obscure Mac driver bug we had to work 
around). Removing the checks was in particular a mistake because you can 
just #define them away, e.g., adding a

#undefine ERRORCHECK
#define ERRORCHECK

will make all of the tests dissappear so there is absolutely no reason 
to remove them from the sources.

> 2. I massacred glSetTransform. It was being overly cautious about 
> setting up the matricies, (setting them to identity before doing 
> anything), and it was manually transposing the input matrices... The 
> version of OpenGL on my system has its own transpose function which, 
> presumably, is better tuned for the implementation's internal 
> representation format. It also makes the code alot cleaner on the client 
> side.

Again, the caution you see is the result of a workaround for some 
obscure driver bug (I don't recall the details but it had to do with the 
fact that on some driver there was a bug in analyzing the transform and 
resetting the matrix did reset those flags to work properly... so much 
for the safety of OpenGL ;-)

About glLoadTransposeMatrixf - this would require OpenGL 1.3 support and 
the sources can (and should, I think) be capable of getting away with 
1.1 support - largely because this is still the latest version support 
by various Microsoft header files so people who'd want to compile Squeak 
using the MS libs would have a very hard time to figure this out.

So thanks for the proposed changes but I think we shouldn't adopt them. 
Both the error checks and being able to compile with 1.1 seem too
important to me to commit any of the changes.

> In the B3D demos of 3.7, it gets around 21-26 FPS in software rendering, 
> and around 48fps in hardware acceleration mode. There are some minor 
> glitches with the grass color but otherwise it's a good driver...

Just out of curiosity: Is there any difference when you turn on the 
error checks? I wouldn't expect any but then I've never really tried...

Cheers,
   - Andreas