Besides dumping a load of 4k source code, I decided also to explain some of the algorithms and effects I used in my games, in the hope that they would be useful, together with a set of tips I learned during the coding. The full list of java 4k tips and tutorials
And the full source code of my six games can be found here. It includes a template you might want to use for your games.
I plan to add there some games that I didn’t have the time to finish.
Very nice. Thanks for sharing.
Some additions to the optimisations stuff I have done:
if you group constant values together the compiler will optimise them before.
Say you have 200 - X + 5 (bad example I know, but used to showcase what I mean)
If you reorder the constants to group them together the compiler will do the math during compile time and thus reduce calculations and thus size. so 200 - X + 5 could be 200 + 5 - X and the compiler would turn it into 205 - X.
Another thing I used to do in my mobile game programming days was to take the compiled code and decompile it and look what the compiler did to it. Sometimes I would see the compiler do stuff that I had presumed would turn out differently. Especially when trying to optimise the code by hand.
That’s true when programming for J2ME, where you have very tight runtime memory constraints. But in Java4K, your #1 aim is not to optimize the bytecode, but the size of the compressed jar. It is actually better to generate more redundant and repetitive code. Given a task X to code, the program that results in the smallest class size is not necessarily the program that results in the smallest archive.
True, but partially people would do stuff that actually created larger code.
F.i. (I> 2 ? 3 : 4) was actually a couple of bytes larger then an if/else structure. It looks smaller but it was not.
(dunno about >= jdk1.5 as we could only use 1.4)
There was also a problem when people would access fields from inside a thread, causing the compiler to create access methods.
(remembering all this out of memory, could be that the fields were private and that was what caused the added code)
Another thing you can do is when you have large data arrays, to load them from a file during runtime. You could pack the data better this way.
Also remove file extensions (at least it works on mobile) and subdirs.
If you are really going for gold, dump all data into a file and also load them during runtime. Also packs better.
Dumb question: Were you allowed to use an obfuscator?
Edit:
Have you tried removing/changing the field visibilities? IIRC that can help a little as well.
Edit2:
K looked into your code for the Abducer 4K and you had already stripped it down very well.
You can replace 2* and similar code segments with binary shifts, saves about 2 bytes per. Though I found it only effects segments where additional calculations are done.
example:
2kernelSize > kernelSize<<1 = no effect
2kernelSize-2 > kernelSize<<1-2 = 2 bytes
Not much but sometimes every little bit helps 
ahristov: on a completely unrelated note - if you want me to, I will include your games in my unofficial feedback (since I am under the impression a lack of feedback is one of the reasons you withdrew your games from the contest). Please respond in a PM or in this thread, and keep those webstart links alive 
My decision to withdraw has nothing to do with that. It was because of the combination of insults+censorship by the organizer.
But of course, any feedback is very welcome
just for interest sake:
200 - X + 5 does not equal 200 + 5 - X
200 - X + 5 equals 200 - (X + 5)
The order of the operations matters…remember BODMAS at all times
You are joking, aren’t you? :
You totally missed what I was trying to say.
The idea was to group together constant values so that the compiler would eliminate them during compile time.
The example given (which I said was bad!) was just to make clear the intentions.
Not for others to copy. Next people will complain that pseudo-code does not compile.
200 - X + 5 subtraction is not associative, (200-x)+5 addition is 5+(200-x) addition is also commutative 200+5 -X yields 205 - X ?
200 - (X+5) for (X = 1) 200 - 6 = 194
200 - X + 5 for (X = 1) 199 + 5 = 204
205 - 1 = 204
ok so I’m poor at explaining this… oh well if you don’t believe me trust your JVM:
public class MathProgram {
public static void main(String[] args) {
int x = 1;
System.out.println(200 - x + 5);
System.out.println(200 - (x + 5));
System.out.println(205 - x);
}
}
Your addition of parenthesis changes the problem completely because you are changing a negative x to a positive x.
200 - (x+ 5)
should read
200 + (-x + 5)
and can read
200 + 5 - x
because x is still negative
What you are actually doing is this.
200 + (-x) + 5
This is why you are getting different values. This is a common mistake. If you change the order of things, do not change a positive to a negative or visa versa.
why does it sound like your explaining me that? Dark prophet is the one who introduced them ???
i know the program yields differend results, and I expected it too.
it’s there to illustrate/proof that “200 - X + 5 equals 200 - (X + 5)” is false.
I know. I probably just got in a hurry and made it sound wrong.
The point of my post was to break down the explanation a little simpler than you had already done.
yeah, sorry I’m afraid you just hit a sore spot. my bad.
Is Java’s HSB system correct? As far as I know, and I’ve tested it on Paintshop Pro and FreeHand, a Brightness of 100% should yield white and 0% black irrespective of the H and S values.
Basically I don’t get white with 100% brightness, only the color on its brightest. At 0% I do get black but then using that grass/sand tile thing I get white specks at 0% brightness.
Anyone got an idea?
Are you sure PSP uses HSB? My (very old) version uses HSL, which is not exactly the same. In HSL, 100% Luminance is white, but in HSB 100% Brightness is the specific colour at its brightest point. See here, for example.
Ah, I see. Thanks. I thought they were the same.
PSP uses HSL as do FreeHand.
I’ll have a look at Photoshop then.
The Gimp does it the same way Java does. The saturation and the brightness control the colour. I saturation is 0 with brightness to 100 then the colour is white. As the saturation goes up the colour becomes fuller.