Here are one screenshot from the mario that i´ve been working in my spare-time. Now the game has 4.5kb, without any compression.
Nothing playable yet?
Yes… the player is working fine, collision, and the scrolling related stuff… now i´m working in the npc´s and interactivity with the scene. 
[]´s
jung
[quote=“jung,post:3,topic:25758”]
I think appel means, “Nothing for us to play yet?” Which would seem to be an affirmative.
I’m curious, how are you coming up with your 4.5K without compression figure? Are you including the size of the images? What format are you using for images? Have you already included the images for the NPCs, or will those balloon your size? Are there any frames of animation, or is Mario just static?
looking good, but i find it hard to see how your gonna fit the levels in 
but thats the whole fun ok 4k
hehe… i´m trying to get a version more refined before post a playable demo. But yes and no, i´m using the superpackme scheme to get all the resources in the game, but the compression isn´t right yet (i will get a high compression with the png, before pack using the superpackme tool - now i have 3kb with resources, after compression the idea is to get 2kb or less), I have the npcs images, but off course that i won´t be able to put all the npcs from the original mario (from nes), now i´m making all the npcs tests with the interrogation image (just for tests), and the mario has 3 frames (to walk), i´m thinking in put more frames (to jump, crounch, super mario, and so on), maybe later. About the leves, i´ve created a (traditional) tile map render, all the maps will be put in (for now) a txt file, with that i could make a big level without increase the size.
erick
I highly recommend keeping it to a minimum. Even with maximum SuperPack packing (1 color at 16x16 max), I was only able to get about 21 images into my Defender 4000 game. If you want to fit everything, try to shoot low on the image count. Reducing the number of colors always helps too, but then again, Mario isn’t exactly high-color to begin with.
[quote]About the leves, i´ve created a (traditional) tile map render, all the maps will be put in (for now) a txt file, with that i could make a big level without increase the size.
[/quote]
I’m not quite sure what your idea is here. A tilemap is guaranteed to use a lot of space for any level of signifcant size. To save space via compression, you can always pack it in a string, but that’s only going to save you so much. The most tightly packed form you can use is a binary “on-off” encoding. Now if we assume that you use 64x64 tiles with 10 screens wide at 640x480, we come to about 93 bytes of data. Since you’re unlikey to take that route (since you need both blocks and coin boxes), we can assume that you’ll need 2 bits per tile. That doubles our previous figure to ~187 bytes. Each increase in the number of bits will further increase the cost of levels. Just something to keep in mind.
Good luck!
Looks nice!
Why is one coin box slightly offset?
Thankz jbane. 
Yes Markus… this is the animation test for the npcs (i´m using that box for tests right now 
)… heheh
Ahh, ok. It was really bugging me, hehe
wow, I didn’t even notice the offset coin box o_O;
Has anyone tried ‘run length encoding’ to compress images (or tile maps in this case)? There’s alot of empty space in transparent images and tilemaps…
I think it might be better to just rely on the zip compression. The RLE might actually make the zip compression less effective.
This is just speculation, though. I might be wrong.
That’s pretty much been my experience. Every time you double or triple compress data, you actually lose compression you could have had. Sometimes you make the data larger. That’s why your best bet is to tune the JAR file as well as you possibly can. SuperPackME works so well because it works with the compressor. It first throws out completely unnecessary data (similar to what MP3s do), then realigns it into a more compressable state. Finally, when it’s converted to a string, it makes it outright easy for the ZIP compressor to do its job on the data. Repeating patterns, here we come!
jung: Nice game! Really looking forward to playing it! See if you can get some procedural sound in there as well!
SuperPackME: I would never use you as you are not my creation, stupid “pride”… :-\ (or perhaps plain stupidity without pride)
My reason for “never using it” is that it takes away part of what’s fun. I want to write the image compression code myself.
For larger projects, I have no problems with using external resources and code as long as it’s free and the licenses fit, but for 4k it just feels wrong.
And we’re really jacking this thread.
yes Markus… I feel that too… but to don´t get much troble right now, this is the fast way to get the things done… i´ve been thinking this week about mario, and after see the first level for the mario (nes)… i´m thinking in create the first level (or maybe the second) identical or very close, working like that , it will be dificulty to make a multi-level game in 4kb… but make a “pseudo-remake” will be fun. heheh… .i´m thinking to make a other classical clone too, after finish mario.
Marcus: Well that’s part of my philosophy as well (even though I didn’t mention it).
jung: Will you have coins in blocks as well? Like in the real Super Mario. Your game looks quite excellent! I didn’t have any sounds in my game as I frankly do not know how to create them (I know how to play MIDI and such external resources but not how to do procedural sound). Are you planning on having any sound?
Hiz Donald… well, i´m trying to get the things little to have some space to put audio (i don´t know how i´ll do that right now, cuz i don´t have much experience with java and audio manipulation anyway ), but my idea right now is: get the 1st level very close to the original and put some audio (the life without music is not the same ). About the coins, that doesn´t work right now (but this is not a trouble anyway), i´m working in the npc interaction.
erick
The biggest lie that was ever told was that games were about technology.