Yes I can see the 4 top label headers…
sorry to bother you with all these mac issues… I should test on my win xp box ! 
Lilian
New Version:
- Lap counter fixed
- Spurious pixels on overlay fixed
- Invisible Car on OS X 10.3 possibly fixed
- Steering improved - but may need more work
- Window resized to make room for ‘Java Application Window’ when webstarted
Edit: The original steering control concept increased the rate of turn the longer you held the left/right cursor keys down. Thus just dabbing the keys gave small corrections, whilst a long press gave a bigger turn. All steering stopped on key up. This didn’t give enough steering control on the bends.
Currently the steering sensitivity is varied with velocity, decreasing with speed. However mid-range speeds are tricky. I need high sensitivity to give a small turning radius to get round the hairpin turns, yet this is too sensitive really for fine maneouvring.
Maybe I need a composite of the two? It’s ridiculous. Steering should be the easy part, but is proving awkward. I’ll get there eventually
Great game Alan. What did you do to compensate for the webstart window, did you just leave some extra space.
I’m using:
// Create Window
setIconImage(carImage[1]);
setResizable(false);
show();
setSize(SCREENWIDTH, SCREENHEIGHT +
getHeight()-getContentPane().getHeight());
show();
It might be possible to improve on this though 
/Edit: …and I’m painting on getContentPane().getGraphics(). If you don’t mind clipping the bottom of the window, this might be sufficient without the resizing stuff.
Update:
- Added Speedometer
- Updated steering
Steer is fine now.
man, this is a masterpiece in 4k
cars always missing on mac… sorry
Lilian
:o WOW!!!
Only a few days into the competition and already some amazing games entered. Amazing look and I really like the feeling that you are going absolutely flat out!!! One interesting thing I noticed is that when you get closer to a tree, it grows on the screen as you would expect, but when you get really close, it shrinks down (and dies)…
I think gameplay score might be hurting quite a bit from only left turn track But quite impressive what you have squeezed in already!
This just keeps getting better! Good work on speedometer, or whavetever it’s called. Oh, and the steering works much better now 
I added that effect to avoid attempting to draw infinitely large trees as you pass through them. An alternative would be to implement collision detection for the trees, but this would take a few more bytes, which are in short supply.
The track is generated from an ellipse equation. It is possible to make much more interesting tracks with more complex equations, but the catch is that it must be easy to convert from cartesian to polar coordinates and back really easily. The bottom line is that I can easily do a much more wiggly track, but can’t easily compute the positions of the computer controlled cars on the track. It might be possible to do something with a linear combination of several ellipses. Certainly worth a try
/Edit: Nope - A linear combination of two ellipses is just another ellipse.
Alan
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
Hey it works fine now on mac Os 10.3 !!
(also frag4k)
Thanks !
Lilian
Hooray! Thanks for testing it and Frag 4k again for me.
Alan
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
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.
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.
@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