http://meatfighter.com/java4k2011/keystonekapers4k/
excelent !! Just like the original .
I don’t remember if that’s allowed, but the thief climbed from the 3rd floor to the roof in the left side, that is, without using an escalator .
[quote]excelent !! Just like the original .
I don’t remember if that’s allowed, but the thief climbed from the 3rd floor to the roof in the left side, that is, without using an escalator .
[/quote]
As in the original game, the thief can do some pretty sneaky things that the player cannot. Somehow, he is able to run out of the frame and reappear on a different floor. Be especially careful while chasing him around escalators. If you hop on an escalator while he is directly above, he may turn around, run out of the frame and return to the floor that you just departed. Instead, wait for him to run beyond the escalator.
amazing! 
I was looking at the source code… how exactly do you proceed to generate the compressed sprites in the final String s variable? Do you use any program to generate that big String?
I really like to understand that compress/decompress stuff, maybe I could re entry my previous entry PacPitall4k but this time much better looking…
Thanks for the great work.
[quote]how exactly do you proceed to generate the compressed sprites in the final String s variable? Do you use any program to generate that big String?
[/quote]
See this thread: http://www.java-gaming.org/index.php/topic,21648.0.html
[quote]I really like to understand that compress/decompress stuff, maybe I could re entry my previous entry PacPitall4k but this time much better looking…
[/quote]
If you do decide to recreate Pitfall, try to make it as true to the original as possible.
yes, I’ll try it. Last time I did the PacPitfall (http://www.java4k.com/index.php?action=games&method=view&gid=253) because I was not able to fit the sprites in 4k…
thanks
[quote]yes, I’ll try it. Last time I did the PacPitfall (http://www.java4k.com/index.php?action=games&method=view&gid=253) because I was not able to fit the sprites in 4k…
thanks
[/quote]
Study the original source code carefully:
http://www.qotile.net/minidig/disassembly/pitfall.asm
You need to reproduce the byte sequences that represent the sprites and the color tables in the long String. See the following link and the references within to better understand the palette:
From the source code, here is how the maze is generated:
oh, really nice remake of one of the great classics. If you can somehow fit sound effects into this, it’d be super awesome 
Very nice. I had the original game when it was new Loads of fun.
Did you do the same for Keystone Kapers and the other games you’re doing? I have to confess that I’m not so smart to read assembler code… besides that, I’m reading the source code you provided and trying to get how the compress/decompress works and also about the color/palette stuff that I still find it complicated to understand… :persecutioncomplex:
Nice! Very authentic!
Thankfully I can truthfully say this game predates me.
Just another question… do you use the same compress method for all the games? Or do you create a specific compress method for each one? Would you mind posting an example of how do you perform the sprite compress? I’m tired of trying making 4k games just using procedural graphics, I’m trying to incorporate sprites like you do in your games, but I’m not really able to figure out how to achieve a great compression of the graphics. Thanks! :-\
IMO the thing to do for bitmap graphics is to use a small palette and don’t try to be clever. E.g. use a 16-colour palette, but encode each pixel as a character in a string rather than trying to pack two pixels or four into each character. That way the pack200 compressor can do a better job.
[quote]Did you do the same for Keystone Kapers and the other games you’re doing? I have to confess that I’m not so smart to read assembler code… besides that, I’m reading the source code you provided and trying to get how the compress/decompress works and also about the color/palette stuff that I still find it complicated to understand…
[/quote]
[quote]Just another question… do you use the same compress method for all the games? Or do you create a specific compress method for each one? Would you mind posting an example of how do you perform the sprite compress? I’m tired of trying making 4k games just using procedural graphics, I’m trying to incorporate sprites like you do in your games, but I’m not really able to figure out how to achieve a great compression of the graphics. Thanks!
[/quote]
I’ll try update the Wiki with a discussion of various ways to add bit-mapped sprites to 4K games at some point when I have more time, but I’ll try to explain the gist of it here.
Obviously, I do not want to promote piracy of intellectual property. But, if you want to borrow graphics and gameplay from Atari 2600 games, then the first thing you should do is install an Atari 2600 emulator and download the associated game ROMs. Google will show you the way if you haven’t already done this step. At the very least, this will allow you to carefully the study the game that you are attempting to recreate.
The ROM files contain the compiled code and graphics data. Write a program that reads in a ROM file, one byte at a time, and prints out each byte on a separate line in binary. But, instead of printing ones and zeros, print X’s and periods instead. Carefully study the results. You’ll find the same upside-down silhouette sprites that appear in that assembly source file.
The Atari 2600 used rectangular pixels, with a 2x1 ratio if I recall correctly. So, each row of 8 bits actually represents 16 pixels on a computer monitor (each pixel repeating twice).
For compression and hardware reasons, each row is assigned only one color and the Atari 2600 game artists often did an amazing job with that limitation. The color palette is essentially in HSV color space as described in one of the links. For each row in the sprite, there is a byte somewhere else containing the associated color. Finding the color tables can be a challenge without decompiling the source. But, in the case of Pitfall, someone already did the work for you.
As for storing the graphics in a 4K game, you can take the bytes representing the upside-down silhouette sprites and the associated color table bytes and generate a Unicode String out of them. For instance, you can take the 4 bytes 0xDE, 0xAD, 0xBE, 0xEF and generate the String, “\uDEAD\uBEEF”. You can reference each Unicode character within the String using the charAt() method. From there, it’s just a matter of extracting the individual bits. But, if you were able to print out the Atari 2600 ROM as I described above, you should be able to handle that step.
pjt33 writes:
[quote]IMO the thing to do for bitmap graphics is to use a small palette and don’t try to be clever. E.g. use a 16-colour palette, but encode each pixel as a character in a string rather than trying to pack two pixels or four into each character. That way the pack200 compressor can do a better job.
[/quote]
That may be very true. You can try it either way. That technique probably works better for level maps as opposed to the bit-mapped graphics because levels contain a lot of empty areas.
