Now can you start a thread/tutorial about how to code so games will work on the mac? That would be really cool.... and greatly appreciated!
I don't really know enough for a tutorial and a lot of what I think I know is based on other folks statements & guesswork.
However the jist of it is that the Mac AWT drawing insists on an image of TYPE_INT_ARGB_PRE. (Although if you create a compatibleimage, it returns type 0 - custom.) If you create a BufferedImage of another type (e.g. TYPE_INT_RGB or TYPE_INT_ARGB), then on each call to a drawing primitive (e.g. g.drawLine(...), the entire buffer is converted to TYPE_INT_ARGB_PRE, the graphic drawn, and then the resulting image converted back. On OS X 10.4, this works, but is about 40 times slower than the equivalent on Windows. On OS X 10.3, there appears to be a bug & sometime the converting back stage doesn't happen, causing the drawing to be lost. This results in Invisible Monsters, Cars etc. This may be specific to BufferedImages that have become unaccelerated due to getRaster() having been used on them (which is the case in Speed4k & Frag4k). The bug appears to be related to BufferedImages of TYPE_INT_ARGB (i.e. without premultiplied Alpha channel). Drawing on images of TYPE_INT_RGB appears to work on OS X 10.3.
The solution (as mentioned numerous times on this forum) is to use TYPE_INT_ARGB_PRE whereever you would otherwise use INT_TYPE_ARGB. This still works fine on Windows. It is also advisable to use TYPE_INT_ARGB_PRE instead of TYPE_INT_RGB, if you are regularly drawing on the buffer using awt calls in the main loop. However if you use getRaster(), and solely generate the image by manipulating bytes, then TYPE_INT_RGB works fine.
Lastly, if you have a screen image built up in a BufferedImage & want to blit it to the screen, then for maximum speed it needs to be TYPE_INT_RGB or TYPE_INT_ARGB_PRE. On OS X 10.4, both of these take about the same time. I don't know about OS X 10.3, but my code uses a TYPE_INT_RGB as a frame buffer, and there haven't been any complaints (yet).