4K Shooter

WIP games, tools & toy projects Archived Projects
#1

Just a little 4K Shooter I’ve written for the J4K compo. on forums.sun.com.
Any1 who frequents there will have prolly already seen it, others may not.

There are 2 flavours of it atm,

regular :-

http://www.pkl.net/~rsc/4KShooter/4KShooter.jar

Its hard coded to use 1024x768x16@60, so if your gfxcard doesn’t support that res/refresh it will most likely die on startup.
It also takes advantage of the experimental fullalpha(D3D) acceleration available on Windows.
Older graphics cards will not support this feature, and you will end up getting 1fps instead of 60.
But fear not, I have also done a version that doesn’t use the Windows experimental stuff…

SE :- (Sh*t Edition)

http://www.pkl.net/~rsc/4KShooter/4KShooterSE.jar

This version still requires fullscreen exclusive (and resolution changing ability), so it prolly wont work on linux or mac.

There is 1 more dependancy,
Sfx use midi voices, so you need a midi soundbank installed to hear anything.
The SDK comes with 1, the JRE does not. (though you may still get sfx if your soundcard has a midi soundbank of its own)

Oh and 1.4.x is required.
(its been tested with 1.5, and there is a bug in the SE version (palletes of the images are corrupt))

btw, did I forget to mention that the entire thing fits in 4Kb ;D

I’d be interested in what scores ppl manage to get,
I think my high atm is 37kills :stuck_out_tongue:
Also, any setups that the game won’t run on would be useful info too.

Gameplay Rules

  1. Shoot the enemies.
  2. Dont get Shot by the enemies.
  3. Fly into the debris from dead enemies, to charge your shield.
  4. Dont fly into the enemies :stuck_out_tongue:
#2

Impressive!!!

even has sound.

i think i would not like to see the source due to the optimizations you must have had implemented

#3

[quote]Impressive!!!

even has sound.

i think i would not like to see the source due to the optimizations you must have had implemented
[/quote]
very true :wink:

but if u ever feel like torturing yourself :-

Java Source :-
http://www.pkl.net/~rsc/4KShooter/A.java
Hand optimised bytecode (jasmin format) :-
http://www.pkl.net/~rsc/4KShooter/a.j

JAX, JoGa, BCEL and Jasmin were used to compile & optimise it.

#4

That’s really, really impressive for 4K :slight_smile: Great controls too :stuck_out_tongue:

Cas :slight_smile:

#5

[quote]Just a little 4K Shooter I’ve written for the J4K compo. on forums.sun.com.
Any1 who frequents there will have prolly already seen it, others may not.
[/quote]
Could you do me a screenshot (hint, hint)?

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Announcements;action=display;num=1077469870

#6

There you go :-

#7

[quote]This version still requires fullscreen exclusive (and resolution changing ability), so it prolly wont work on linux or mac.
[/quote]
Mac does support fullscreen mode. (Though it has it’s share of bugs at the moment.)

#8

It runs on the Mac, but it appears to have problems. The graphics seem to be wrong. I crashed into a ship and saw a strange black outline in a blue circle around my otherwise unrecognizable ‘ship’.

I can barely move around with the cursor keys and was unable to fire or tell what direction I was facing etc. This was all with the SE version.

#9

[quote]It runs on the Mac, but it appears to have problems. The graphics seem to be wrong. I crashed into a ship and saw a strange black outline in a blue circle around my otherwise unrecognizable ‘ship’.

I can barely move around with the cursor keys and was unable to fire or tell what direction I was facing etc. This was all with the SE version.
[/quote]
Very interesting, can you make a screenshot?

#10

Sure:

http://www.vaxxine.com/canaan/4kshooter.png

#11

V. interesting :o

The lasers arn’t corrupt - which indicates the problem lies in the image creation.

Looks like Apples ImageIO gif codec is as buggy as Suns used to be in 1.4.0 :smiley:

#12

I always use PNGs… but I’ve heard that there have been problems with the PNG ImageIO codec as well… though “it works for me”.

It really is too bad that such basic stuff gets broken. I mean if they could show that the image file doesn’t follow the spec then fine it isn’t really their bug… but there are only so many variations possible with GIF… you could test all of them easily.

P.S. How do you work the game? I can’t fire.

#13

[quote]I always use PNGs… but I’ve heard that there have been problems with the PNG ImageIO codec as well… though “it works for me”.

It really is too bad that such basic stuff gets broken. I mean if they could show that the image file doesn’t follow the spec then fine it isn’t really their bug… but there are only so many variations possible with GIF… you could test all of them easily.

P.S. How do you work the game? I can’t fire.
[/quote]
I would use png as well… but the filesize would be far greater :slight_smile:

As for controls :-

Arrow keys control your thrust direction. (forward,backward, strafe left, strafe right)
Mouse controls your facing (your ship turns to face the mouse cursor)
left mouse button fires
right mouse button boosts.

btw, 1 more question - when in fullscreen exclusive mode on the mac, is the framerate vsync locked?

:edit:

ok, i’ve made 2 new versions of the game to see if it is a bug in the 16color gif codec.

Uses a 16million color png(with alpha mask) :-
http://www.pkl.net/~rsc/4KShooter/4KShooterSEpng.jar
Uses a 256color gif(with bitmask) :-
http://www.pkl.net/~rsc/4KShooter/4KShooterSE256gif.jar

#14

I don’t recommend PNGs. Most tools export the alpha channel wrongly and you get a nasty rim round the edges of your sprites (see AF for example). TGA gets it right.

Cas :slight_smile:

#15

Odd, I find PNGs are usually smaller than GIFs

Ah ha… due to a particularly brain dead bug in Mac fullscreen mode mouse buttons don’t actually do anything while in full screen. I had forgotten about this - actually I hoped it had been fixed… sigh…

[quote]btw, 1 more question - when in fullscreen exclusive mode on the mac, is the framerate vsync locked?
[/quote]
I’m not sure.

this works correctly.

[quote]Uses a 256color gif(with bitmask) :-
http://www.pkl.net/~rsc/4KShooter/4KShooterSE256gif.jar
[/quote]
This works correctly and seems a bit faster than the PNG version.

What is the pixel format of the back-buffer? Mac is very sensitive to using ‘native’ pixel formats (RGBA, RGBA_PRE are best I think - I posted something about this in performance tuning a while ago).

#16

[quote]I don’t recommend PNGs. Most tools export the alpha channel wrongly and you get a nasty rim round the edges of your sprites (see AF for example). TGA gets it right.

Cas :slight_smile:
[/quote]
What tools have you had problems with?
I use GIMP to make my PNGs and they seem to be ok… Note that Photoshop is complete sh*t when it comes to dealing with an alpha channel - pathetic really.

#17

Ahh… must just be the crap tools then. Both PSP and Photoshop exhibit this behaviour. 3dsmax might too.

Cas :slight_smile:

#18

PSP can just about be persuaded to save a png with alpha channel, but its not intuitive and requires some obscure tinkering. Its a pain to actually edit them as well, so I find it much easier just to keep the alpha as a separate greyscale image and merge them at load time.

#19

for large files, that is true, but for very small files (the image is 21x50 16colors :P) gif is better, it has a smaller overhead/gives better compression ratio)

[quote]Ah ha… due to a particularly brain dead bug in Mac fullscreen mode mouse buttons don’t actually do anything while in full screen. I had forgotten about this - actually I hoped it had been fixed… sigh…
[/quote]
ahhhhh, now that kind of a bug, I can’t work around :smiley:

it’d be useful to know…

what framerate does this test give? :-

http://www.pkl.net/~rsc/downloads/Test.class

[quote]this works correctly.
This works correctly and seems a bit faster than the PNG version.

What is the pixel format of the back-buffer? Mac is very sensitive to using ‘native’ pixel formats (RGBA, RGBA_PRE are best I think - I posted something about this in performance tuning a while ago).
[/quote]
Its all using BufferStrategy and images returned from createCompatibleImage, so it should be using optimal rendering loops.

There should certainly be no speed difference between the 2 source images, as they are copied to an intermediate image, and the original is thrown away.

#20

[quote]what framerate does this test give? :-

http://www.pkl.net/~rsc/downloads/Test.class
[/quote]
Low of 19 fps, high of 24 fps… it bounces around within that range. Pretty lame eh?

Yes, createCompatibleImage should give the correct format. I could be mistaken about the perceived speed of the previous tests with PNG vs. GIF.