The SuperPackME toolset is now available! This release includes the complete toolset for generating SuperPackME files, as well as the Hexidecimal encoder and Class Inliner! With these tools, you should be able to get an 80% or more reduction in code and data sizes!

... Current results for 3-4 color images, is 37% of the original crushed PNG size! I've also developed a new tool that allows the data to be inlined into the class file. This not only saves space from the ZIP Headers, but it also allows the data to be processed without expensive references to the java.io package. Current results have 1126 bytes of PNG data, plus SuperPack loader, plus fullscreen support fitting into ~1.6K. That leaves about 2.4K for game logic! ...

Quote

... The new format can pack images with up to 255 colors. And the fewer colors you use, the better the images pack! With about 127 colors, you can get between 5-15% reduction over crushed PNG files. With 63 colors, you can get about 25% reduction! Even better is that the output file compresses even more in the JAR! ...

re: one letter var names, private var names arecompiled out, as are method params and vars inmethods if compiling with -g:none, public stuff canbe removed with a obfuscator. If you are really evil(like me) you can even use a precompiler (stopstairing at me like that).I hope you don't mind, but I took the liberty ofthrowing it through ProGuard [http://proguard.sourceforge.net/ ], shrinking thesize of the jar to 3936 bytes (giving you loads ofspace for more levels, yeay!).

How about a section on JGF? I've got some placeholders pencilled-in for programming competitions (c.f. the thread on here about rules, sizes, etc, that is being used as the basis for a JGF competition, although that's not ready yet). With 4k games, the biggest issue is simply how to integrate the comp information with the JGF site so that all the information is there but the rest of JGF doesn't get in the way.

Current thinking is/was (open to better ideas): - games entered for competitions have a unique category in the DB - each competition can be selected individually, giving a list of entries + metadata + a screenshot + logo for each one - ...or all competitions at once, with sort-by-size, sort-by-date, sort-by-name, etc - a "competitions" index page acts as a bookmarkable entry point with: - news on current and upcoming competitions - section listing winners of all recent competitions - links to rules + details of organizers + etc for each known competition - quick-links for submitting games to competitions via the JGF site (free hosting, game appears in the main JGF games list as well, etc)

If you'd like to get a set of pages up on the JGF preview site (http://javagamesfactory.org) I can get it up and running pretty fast (it's only cunning stuff like automatic JNLP that is broken - the basic stuff like making new pages etc is all working fine ).

If you could collate all the existing info you have (rules, guidelines, useful links, previous games, current games - anything you can think of) then I'll format it all into pages (and stick your name on it as the contact ).

Just copy/paste into a long email to ceo @ grexengine.com all the info you have.

(Obviously, in the future, I'd hope to have this A) automated and B) something you can administer/configure directly as the "owner" of the competition; right now I'm concentrating on getting games + auto-jnlp working :/)

Reakon Woogley would extend the current j4k site to include a definitive list of entries each year?

Kev

...trying to get it all into JGF at the moment, which would preserve them all indefinitely, using W's design + data along with all the other info. It's a bit worrying that on the first pass of a list of pages needed for the competition I forgot to include a results-per-year page . So, um, if anyone can think of any other pages that are needed and not present on W's site, please post them.

Hoping to get the site minus binaries up PDQ (today?), with binaries to follow once the game-submission thing is tested/working.

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. :-)

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 enough to consider dynamic compilation, if it was allowed.

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

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