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.

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.

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:2*kernelSize > kernelSize<<1 = no effect2*kernelSize-2 > kernelSize<<1-2 = 2 bytesNot 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

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

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.

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.

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?

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org