Yes, but have you actually attempted the dynamic compilation class? If the class to compile and load the dynamic classes is larger than the savings from compressing source code, then your net gains are actually worse than if you'd just used bytecode!

@Blah^3:

Quote

I can imagine that increasing bytecode size stupidly - inlining is usually used to INCREASE code size, sacrificiing it to gain performance...

This isn't C/C++, Blah. Every reference to a method or class eats up significant constant pool space over simply inlining it. i.e. implementing a "min(int a, int b)" would be far more costly than implementing "(a < b) ? a : b" in ten different places! The reason is that you have maybe three bytes (in the form of bytecodes) for the "?:" statement. For the method you need:

That's 31 bytes for the method if no one uses it! Using the "?:" syntax is already smaller by one byte, and compresses better to boot! That's not to mention the bytecode associated with each method call, plus various overhead with the stack that I'm not even counting.

Being small in Java very much about avoiding method calls and class fields as much as possible.

This isn't C/C++, Blah. Every reference to a method or class eats up significant constant pool space over simply inlining it. i.e. implementing a "min(int a, int b)" would be far more costly than implementing "(a < b) ? a :

Um, yeah, I konw that - I was thinking of non trivial code.

I was a bit surprised by the source == much smaller than code stat, usually when I'm doing these my source is approx the same size as the classfiles, prior to squeezing everything (IIRC). But... aggressive unrolling and inlining of non-trivial instructions would eat up code space.

Still, it's been so long since I was doing this that I simply don't know whether the code space is eaten up more or less quickly than the source code expands, post-compression. Hence I was wondering why he was inlining.

PS I don't tend to consider inlining a min or max method call to be inlining per se - technically speaking you could say that "every statement that is not a single method call is in fact inlined source" but I tend to think "inlining" == "multiple lines of source / non-trivial groups of statements".

Although I recommend only doing news postings for now, and limiting them to just one paragraph per item, until I finish off the module .

Logo taken from Woogley's page - is this the official one?

Once I've got the other management features working, we can transfer across all other info into appropriate extra pages and get multiple editors setup (who do you want? give me a list of JGF usernames and I'll give them appropriate access...). But, for now, only the front page is working. Including...you'll be able to upload all the previous entries for each of the "previous rounds". But not yet .

As I said via email, assuming mlk's happy, I'm keen for you (or anyone else) to take over the j4k pages on JGF, at least as far as is possible. Right now there's not much of the page design you can alter, due to technical issues (I haven't implemented those aspects yet ), but the editing of data is half-working already and I should be adding rich controls real soon.

I'd like to take it over if I had HTML-based control of the design (so J4K would have a unique look). If your module has colors settings and all that through web-based options, have an option for the coder to override all of that with custom HTML, that would make it alot easier to style it up in its unique way

as far as data goes, though, I can manage that if nobody else wants to. I'm interested in designing it, I dont really care about adding data etc

On your j4k website (http://www.woogley.net/java4k.html) you specified the login settings for your ftp-server, but don't supply the password. I guessed it in 2 times, and came in, but it wouldn't be bad to just put it there.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Personally, I see nothing wrong with multiple games. For many coders, this is their first year entering the 4K competition. Thus they may need to code a game or two to "get a feel" for what they can fit. I remember that the first year, I only used runtime generated graphics since I figured that pixmaps would be too costly. That first entry gave me a good feel for things, and the next year I came up with my SuperPack method for storing images.

Again, I felt that only bitmaps (1 bit == 1 pixel) could ever possibly fit. Yet my experience from that translated into this year's SuperPackME tools with support for up to 255 colors! (Sadly, they don't seem to be very popular. *sniff* Oh well, just means that I'll trounce everyone. ;-))

The only downside I see to multiple entries is that it makes judging that much more difficult. Still, judging only happens once, so I think the judge(s) can live with sorting through a few extra games. :-)

Speaking of which, does anyone else think that we should appoint a panel of judges instead of picking just one? The combined score from, say, three of them would help remove any unconscious bias that a given judge might have. I'm thinking that maybe ChrisM would make a good judge if we can finagle him into it. :-) BlahBlahBlahh would make another excellent judge (if not a little... ok, a lot... cynical). Any other ideas for judges?

I'm thinking that the games should then be judged on the following criteria:

Points seems quite OK. Only thing I can think of "replay points". Quite often, java games are something you only play once. It could naturally be baked into gameplay. Would be nice to promote games that you would actually come back to. Hard to judge, but just a thought.

I will add your games to the list when your server comes online again.

Quote

Only thing I can think of "replay points". Quite often, java games are something you only play once. It could naturally be baked into gameplay. Would be nice to promote games that you would actually come back to. Hard to judge, but just a thought.

I'm glad you guys like the judging system. The real thanks goes to mlk, though, for inventing most of it for last year's competition. I just "embraced and extended" it to better reflect the growing popularity of the competition. :-)

Quote

Points seems quite OK. Only thing I can think of "replay points". Quite often, java games are something you only play once. It could naturally be baked into gameplay. Would be nice to promote games that you would actually come back to.

Actually, I think that's very much a part of "gameplay". If the gameplay is good, then you'll come back. If the gameplay is poor, then you'll be less likely to play again. Note that this is independent of the graphics score which merely judges how technically impressive the game is.

Here's a few other scoring system I considered:

- A "controls" score (i.e. how natural are the game controls). I discounted this because it heavily impacts gameplay, and thus cannot be considered a separate entity.

- An "instructions" score. I discounted this because the small size doesn't provide much space for text. If the text is there, then it's almost certainly at the expense of something else. I figured that it would be best to leave instructions to the "Readme" files, where they can be spun with fun and interesting stories. :-)

- A 3D bonus. 3D is nice, but it can easily detract from the point: making a game. So if the programmer wants to use 3D as his canvas, he can do so, but he won't get any special bonuses for it. He may, however, get a higher Graphics score. :-)

I like the scoring system as well. And a 3d bonus would be cool. After working for 2 weeks I have a rotating model in 4k. Wow, how am I going to squish a game in there...

Are you using the Math.xxx methods? If so, I may be able to help you cut down on the size of your class. It just so happens I have some code lying around for Taylor Series computations of sines and the Babylonian method for square roots. If you use these to compute lookup tables, you can significantly reduce your code size by eliminating the overhead of method calls. :-)

Re: only one game, well last year some people entered multiply games. I really don't see the problem with it. More stuff to play while board at work, err wait, as I'm currently looking for work, that might be best if I don't mention I just play games at work. No no no, not at all, never play games at work...

That one would need some finessing for 4K. I was originally developing a Math.sin() implementation for a CLDC library, so it's designed to handle any and all input. (No matter how screwy.) Things that you can do to shrink it are:

1. Inline everything.2. Eliminate the check for negative angles.3. Replace Math.pow() with a loop.4. Eliminate the normalization of the angles. That's to handle angles greater than 360 degrees.5. Replace Math.PI with 3.14xxxxx (how ever many digits you want.)6. That makes the radian conversion "angle / 180 * 3.14". Alternatively, use radians to begin with.7. Instead of storing the taylor series values in an array, use a loop like "for(int i=3; i<17; i+=2);"8. As with the square root, the number of iterations affects the precision. It may be more efficient to unroll the whole damn loop into 3 operations (two additions and one subtraction). That should give plenty of precision for what you're doing.

Other things to keep in mind:

1. Cosine is equal to sin(angle+90)2. Tangent is equal to sin(angle)/cosine(angle)3. Generate lookup tables! While code is generally cheaper than method calls, you can easily destroy your savings by including to much redundant code!

Bonuses, last year I gave them out to anyone I felt deserved it. I think stating what they should be before hand takes the fun away

True. But the competiton has gotten a lot bigger. How do such bonuses work when there are multiple judges? Do they have to agree on a bonus, are bonuses cumulative across judges, and what if judges disagree about what should get a bonus? Stating them up front makes things a bit easier. Anything truly spectacular is bound to get a really good score. :-)

However, I would like to see comments from judges. It's always nice to hear both their praise and their constructive criticism. :-)

What about a bonus for cross platform compatability, after all that's a big advantage of java? It is a shame that so many entrants don't work on OS X, and that there isn't a high resolution timer in 1.4 that we can use (normally I use LWJGL for this)

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