[quote]shoot.wav - yes, from doom :). Is it the first time it loads it, or everytime? Couldn’t work out if Java Sound was caching them for me.
[/quote]
Nah… I ment that it hurt my ears 
Try a not-that-loud-sample… just something wich doesn’t sound like a “BLAM!” (because it get’s annoying after awhile) 
[quote]24 bit images - convienience, tile set was just an initial play about. Have since learnt that 256 colours can save me rendering speed, but then I suppose in windowed mode I have no choice.
[/quote]
256 colors is usually enough for pixelated graphics.
Well… I don’t mean 8bit graphics mode - I mean 256 colors for each tile/sprite set. The display running at 16, 24 or 32bit isn’t a problem, it will get converted in realtime (at no cost).
The benefits of 256cols are sharp graphics (w/o any artifacts thus the seams would be gone) and smaller filesize.
And now something completly different:
Atm you have autofire wich is Ok and definitly better than single fire but there is a nicer way, wich was shown in the newer shoot 'em ups (Gigawing, Mars Matrix, 19XX…):
Instead of on shoot per keypress you fire 4…lets say one shot every 250msecs. That means that you have to press the button once every second to fire all the time. If you press the button faster you can ramp the firerate up to 8 shoots per second (but not more).
I think I would do that with an int array (since boolean is somewhat slow) wich can hold 8 values…
|00000000 <- at the beginning... then I press fire
|10101010 <- that the way it looks now
000|01010 <- 375msecs later... and I press fire again
010|11111 <- and now the ship/plane fires fast
(The ‘|’ is the position of the “pointer” wich get moved one step ahead every 125msecs)
That allows charging (hold 1/2 second for the superblast) without that single shot per keypress problem (wich everyone hates ;)).
Another way to allow charging is simply charge when the player is not shooting - this way you can keep the autofire.