Not that it would be used by an entry, but is there an easy way to write an application that can be launched both by Web Start and as an imbedded applet?

Are there any performance issues in using applets? Does the browser set the threads to ultra low priority or something?

Do applets respond to events as effectively as web start applications? Why do you have to click on an applet to gain the keyboard focus? Anyone experience dropped keyboard events on some browsers? On a related issue, did anyone notice that if you setup a KeyListener, sometimes you do not get the key released event (this has nothing to do with applets)? I know that no one uses KeyListeners for this competition, but I am not sure at what point in the chain keyboard events get dropped and why.

Any idea when it would be a problem? Will it only affect people not set to 24-bit color or if we attempt to load bitmaps less than 24-bit color?

It'll be a problem when you're drawing either a decent amount of shapes or images to a window, regardless of your color rate or whatever. Obviously smaller images will be cheaper and fewer of them is also cheaper. But to learn when this is a problem, basically imagine how many things you could draw in OpenGL (or with hardware acceleration) and divide that by 10.

Minecraft4k is currently less than 2kb. If I had 16kb to work with, I could do pretty much anything with enough effort. It's just no fun.With 4kb only, there's a very real limit on how much stuff you can fit in there.

However, I wouldn't mind an 4kb compo where you can use JOGL or LWJGL. =D

I'd actually like to see a competition like Java4k that uses Slick. We have a pretty long off season, could there be a Java4k+Slick competition in the summer? Or perhaps even a Java16k?

Java 6 is actually quite fast. Not as fast as Slick, but it's sufficiently fast for most 2D games. I don't believe you'll be able to do cooler games in Slick having a 4KB limit, after all, Slick is meant to simulate Java2D API in a way.If you're looking for faster framerates, then next year I believe Java 6 will be the target JRE.

Besides, there is a huge overhead and learning curve with additional libraries, which will result in a subset of programmers participating, e.g. there are fewer Java programmers interested in Slick, Lwjgl, Jogl, etc. If you're doing Java game programming, you know Java2D, but not all the other libraries. Slick, Lwjgl, Jogl, etc. are all subsets really. Java2D is more mainstream oriented.

There are two new things already this year that should make the contest VERY exciting for 4K nerds.Those are 1) pack200 that allows you to squeeze in 20-30% more game code 2) Applet only.

Java 6 is actually quite fast. Not as fast as Slick, but it's sufficiently fast for most 2D games.

I am actually really impressed with how fast 2D graphics are in Java 6 including things like scaling and sprite rotation, but if I don't restrict myself to 4K (obviously for games outside this competition) does it make sense to stick with just the standard graphics library? Is Slick the best direction to go in? It looks like the kind of layer I would be forced to build on top of LWJGL anyway; it looks like the Slick developers saved me a lot of work.

As for the 4K limit, as pointed out on the Java 4K wiki:

Quote

This may explain why spinoff contests targeting 8K, 16K, or a specific API like LWJGL have never taken off. In fact, the contestants seem to believe that 4K is the "sweet spot" that balances what an individual can do. Because of the tricks developed for the 4K contest, it's believed that adding even a single kilobyte would open the doors to far more complex games that are beyond the ability of a single developer.

I think that is very true. 4K gives you just enough to work with such that it is an excellent and fun challenge. Though, I have often though that it is unfair that we aren't all using the same build tool. I think we should only be concerned about the code. I'm also surprized that people don't readily share their source or why the submission isn't just the source itself that is built against a common compression tool.

A 4K competition against a specific graphics library could work. Things like that have taken off in the demo scene.

Though, I have often though that it is unfair that we aren't all using the same build tool. I think we should only be concerned about the code. I'm also surprized that people don't readily share their source or why the submission isn't just the source itself that is built against a common compression tool.

Half the fun is hacking the code just right together and compress it in a specific manner!

Although, I might enable programmers to optionally attach the source-code to their submitted games, and then allow normal users to see the source code behind each game. (I'd have to have a checkbox so programmers can make the source-code invisible until the contest is over). But this is very simple to do.

Is there really anything worth hiding? Does anyone really think they invented something so amazing that giving out the source would affect the contest results? The submissions keep getting better, but the majority of graphics algorithms and coding techniques are highly documented out there. The source does not reveal any secrets. Besides, if someone did invent something really useful for this competition, let them share the knowledge. Spur innovation.

Though, I have often though that it is unfair that we aren't all using the same build tool. I think we should only be concerned about the code. I'm also surprized that people don't readily share their source or why the submission isn't just the source itself that is built against a common compression tool.

Making everyone use the same build tool would be a major complication - to guarantee consistency you'd have to have a central compiler, which would make testing the effect of a tweak a very slow process.

Moreover, it would place extra constraints. Last year I couldn't have submitted Java code which a centralised build tool would fit into 4k: I ended up tweaking bytecode manually and assembling it with Jasmin to get the size down. I'm probably going to do the same this year.

As for sharing the source: we're not necessarily proud of all the hacks we use to reduce size...

Moreover, it would place extra constraints. Last year I couldn't have submitted Java code which a centralised build tool would fit into 4k: I ended up tweaking bytecode manually and assembling it with Jasmin to get the size down. I'm probably going to do the same this year.

Holy crap! I didn't know that people went that far. How much did that save you? What are you chopping out by doing that?

Quote

As for sharing the source: we're not necessarily proud of all the hacks we use to reduce size...

My source code tends to evolve as the competition continues, so it's it bit premature to post it. I did open source my code back in 2005/6 (the last time I entered), when the competion closed and intend to do the same this time. Readability tends to be poor as almost everything gets stuffed in one method in a single class.

Holy crap! I didn't know that people went that far. How much did that save you? What are you chopping out by doing that?

It's hard to say how much it saved me, because I had to go back to do some bug fixes. When I went to bytecode I needed to chop off 22 bytes to fit in budget. It was mainly peephole optimisations which Proguard inexplicably doesn't do. I've restructured the repository since then so it would be quite a lot of work to go back and get a diff of the changes I made to the bytecode.

Now, I am getting really excited about Slick. I think I'd rather spend my time messing around with it rather than focusing on a 4K game. Anyone available to answer some coding questions about it?

Kev,

If you are around, any chance you can visit the Slick forums. I have lots of technical questions that I need help on. I'm so confused. I promise I'll return the favor by posting sample Slick games with the source and I'll create some tutorials after I am more experienced with it. Your API rocks.

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