Speed4k

[Alan_W]

Minor Update:
- Another attempt to improve OS X 10.3 compatibility.  NB. OS X 10.4 is Ok

Edit: Confirmed working on OS X 10.3 by c_lilian

[c_lilian]

Hey it works fine now on mac Os 10.3 !!

(also frag4k)

Thanks !

Lilian

[Alan_W]

Hey it works fine now on mac Os 10.3 !!

(also frag4k)

Hooray!  Thanks for testing it and Frag 4k again for me. 

Alan

Games published by our own members! Check 'em out!

[nonnus29]

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!

 

[Alan_W]

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

Alan

[Malohkan]

Very impressive!  I haven't quite gotten the hang of breaking at the right time before corners but for the most part controls are great!  Surprisingly though... I feel like you're too generous on collision detection   I've many times driven straight for a car and found that I missed it!  Sometimes I hit it though   Other than that it's great.

[[ERROR]]

Great Game!

Saw a game called Drivey in slashdot long back.  http://drivey.com/   Altough this is a 3D demo and doesn't use voxels,  it might be of interest to u.

[Alan_W]

@Malohkan
The collision detection is a touch primitive.  I've been short on time recently, but hope to look at that part again.

@Error
Glad you liked the game.  Thanks for the link.

Alan