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.
- 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.
- 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