No window decorations AT ALL on linux (no title bar, no edges, nothing) - or is my X playing up right now with some weird bug? 
Apart from that, works fine. One suggestion: make the avatar into a hovercraft or something else that skids. It’s weird that Sonic has greased shoes ???
Very cool.
Needs someone to race against. 
Sonics slides quite a lot, and no real feeling of speed (or my computer is incredible slow )
[I moved this to [url=http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Announcements;action=display;num=1104915706]another thread[/url] to prevent potential threadjacking]
Is it allowed to ‘assume’ tools.jar (J/SDK) is in the classpath, and read/write access in user.dir?
I would have thought read/write access in user.dir was fine but tools.jar isn’t part of the jre so I’d guess that one was out.
Kev
Dynamic compiling would have been so great… :-/
My zipped sourcecode is way smaller than my zipped bytecode. I use -g:none and use 1 letter fields.
(take out all line feeds and as much as possible spaces)
But well, for now I have more than enough space anyway, for my ridiculously simple game 
Did you actually write the compiler interface and loader? I’m willing to bet that the number of class references you’d make for the compilation and loading would completely erase any advantages you’d gain by compressing text.
FWIW, the class embedding part of my SuperPackME tools is predicated around the fact that the Deflate algorithm compresses text better than binary data. In order to embed data, SuperPackME actually has you double the size of the data by reencoding it in hexidecimal. But when compressed, the hex is actually smaller than the original binary! Can’t beat that.
zipped -g:none bytecode: 2.4kb
sourcecode: 1.4kb
and then this case is optimized for bytecode-size.
i never reuse values, i recalc them everytime (lot’s of source-code, less bytecode), so no doubt i can bring sourcecode down to 1.1kb vs 2.4kb bytecode.
that’s 1:2 :o
enough to consider dynamic compilation, if it was allowed.
[quote]zipped -g:none bytecode: 2.4kb
sourcecode: 1.4kb
and then this case is optimized for bytecode-size.
i never reuse values, i recalc them everytime
[/quote]
Uh, why?
I can imagine that increasing bytecode size stupidly - inlining is usually used to INCREASE code size, sacrificiing it to gain performance…
for every action i try a couple of versions. then i use the one with the smallest class-file.
easy as that. in most cases recalculating values requires less bytes in the classfile.
I’m not assuming things, these are facts
The state of the game is now like: 1 giant long[]
Update:
Another example you wouldn’t expect: (or at least I didn’t)
new Color(0, 0, 0, 64);
is 13 bytes smaller than
new Color(0x40000000, true);
but maybe i’m missing something here
You can save quite a few bytes with trial and error.
[quote]zipped -g:none bytecode: 2.4kb
sourcecode: 1.4kb
that’s 1:2 :o
enough to consider dynamic compilation, if it was allowed.
[/quote]
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…
[/quote]
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:
“min” (3 bytes) + CONSTANT_UTF8_Info structure (3 bytes)
“(I)II” (5 bytes) + CONSTANT_UTF8_Info structure (3 bytes)
method_info structure (8 bytes)
attribute_info structure (6 bytes)
code data (3 bytes - guesstimation)
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.
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”.
Well, a very incomplete first version of the competitions module is now up on JGF, and lucky j4k gets to be the beta test ;D :
http://javagamesfactory.org/views/view-gameprogramming-competition?name=j4k
mlk - tell me your JGF username and I’ll give you editor access for the competition, so you can post news, change the description / prize info / etc.
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 :(.
My JGF username/password is “mlk”.
As to official imagery, I was not aware it had any official anything, other than a set of rules
The JGF page is great.
well, if you need an official one, feel free to take mine. not like I put hours of work into it
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.
many thanks for pointing that out Skippy, I didn’t even notice it was missing :
fixed now
Nice stack of entries the year
Kev