Art by: 9tk (https://www.lexaloffle.com/bbs/?uid=23566)
Code by: mhughson (https://www.lexaloffle.com/bbs/?uid=15406)
Sound by: gruber music (https://twitter.com/gruber_music)
Previous Versions:
The spritework is very cute! I have no idea how you're supposed to play the game, though.
Just kill all the monsters (by moving onto their space), @tepuitrouble. There is only one level right now though; it just repeats forever. WIP! :D
Is it an adaptation of the gameboy game? never played it, but the name sounds familiar!
The witch sprite is adorable indeed and the game quite fun, can't wait for the 1.0 :) the music drove me nuts though
@sax3: Yes it is based on Catrap for the GB. Sorry, 'music' is just placeholder! Don't worry; we'll have something amazing for version 1.0!
I love the latest build already!
This is gonna be perfect puzzle/maze action. ^^
oh wow, is this a reinterpretation of catrap with now 2 players ? o_o beautiful idea! i like the stars effect and all those transitions!
This is really fun. I love these "speed-run" type platformers.
Fantastic! Special shout-outs for the compressed title screen and animated booklet gif, great stuff.
This is really amazing! Catrap is one of my favorite gameboy games, and this captures the feel perfectly, and you've really gone beyond the original. Great work! Also, I just posted something similar to what you're doing with your title screen - I thought I was being original :P
Oh my! This is wonderful! Reminds me of Solomon's Key perhaps, but I love the music/atmosphere of this.
I was looking at the source to your game, MHughson. Your logo is taking over 6700 bytes in sourcecode string space. might save a bit of space if you used my compressor:
https://www.lexaloffle.com/bbs/?tid=31725
And yes, this is a very cute version of Cattrap. That's one of the first games I bought at Funcoland for my Gameboy at the time. The REWIND ability was the best - and you definitely included that in your game too. Nice !
dw--
He doesn't need to compress the string representation of the graphics. The text of the source code, which includes string initializers of course, is automatically compressed by PICO-8 (using a form of LZSS, as I recall) during the save to .p8.png or @clip, and then decompressed on load.
All he'd be doing is wasting tokens on the decompression code.
Edit: I checked, and the encoded string by itself compresses from 6718 to 2964 bytes. You can confirm this by deleting all but the string and entering info at the PICO-8 command line.
I'm glad you brought this up, Felice. This is something I wanted to check on.
If you click twice in the bottom-right-hand corner of the sourcecode editor (IDE) you have a value listed as "COMPRESSED SIZE."
Is this the amount of compression that PICO internally gives for all data, maps tiles, sfx, music ? Or if not, what does it represent ?
If PICO is indeed applying its own compression, then outside of sourcecode space, code that compresses such as both myself and ZEP have written are not needed in light of this latest version of PICO ?
PICO-8's been compressing the source code for years.
ROM space (0x0000-0x4300) is stored as-is in its entirety, presumably for quick reload()s, so there's no way to compress it.
You can write compressors that take advantage of foreknowledge about data formats, and those might be worth it, but for generic data compression, I'd say no, it's mostly not worth the bother or the tokens. Some people even find that compressing their data so that the string initializers are smaller causes the built-in compressor to do more poorly and produce compressed source no better or even worse than the original. Entropy is as entropy does.
Can you answer this then ?
Let's say I store an image that is 4-bits for color, so you get 2-pixels per byte, yielding 8192-bytes for the total string size.
If I were to store a logo like this using only hex notation, it would look like this: "EF8A43392615"
Now would this compression be better this way than as I am doing now with converting 8-bit to 6-bit characters, where you the average is 6000-characters in the string ?
As you mentioned, compressing data can cause the built-in compressor to do more poorly ?
You could answer the question yourself by converting your image to each representation and simply typing info on a cart with each one in turn. However, remember to include the source for the decompressor with your compressed version, since it's effectively a required part of the data.
I would assume your version would do less well, since the built-in compression is (to the best of my knowledge) byte-based. Repeating patterns in the image will align with compression boundaries, whereas your base64 representation basically has a granularity of 3 bytes, or 6 bytes if the image pattern is, say, 2x2 dithering rather than solid colors.
No, my compressor looks for patterns too, and compresses based on that. Currently the compressor is set to level 2, that is, to find up to 2-character patterns in any data.
It can go all the way up to 255 if you like, but it's quite slow then. :)
It has shown good compression at a level of 8 with varying data, including the screen, sprites, and mapper data.
But yes, I can check to see with info(). The results will likely be of interest to others besides ourselves - to answer the question, "Is writing a compressor for image data or otherwise even useful in current version of Pico-8 ?"
Alright, a little research done. Yes, my compressor with one single compressed picture is indeed larger than a single program with one logo stored as 2-character hex. That's a very good observation you made, Felice.
But for more than one logo in the same code, my compressor yields a far smaller footprint.
In fact, in my compression demo, you will see that I have 6 full screens showing their compression size. I doubt you could put that many decompressed strings as straight out 16384-bytes per hex code per picture in one program of PICO. You would run out of coding space long before then.
Even the most robust logo uses 4,000 - 7,000 6-bit text characters by itself in using the compressor.
So ... results ? If you just want =one= 128x128 picture in your game, let's say the logo, you would do better to not use my compressor.
But if you want more than one, that includes elements such as a logo, introduction/instructions page, author page, win game screen, and lose game screen, you'd do better to use my compressor.
And it stands to reason, I could optimize my compressor. Rewriting software is always better the next time around ...
So saying here, one picture is enough for this good puzzle game. :) And this game certainly does deserve a star. ⭐
I've only been responding in the context of your suggestion that Matt compress his title screen.
Obviously things are more complicated in the event that you want to put >64k of source image text in the game, but that wasn't what we were talking about.
Well now if I could just encode a raw 8-bit set in the source, I'd be all set, Felice. :)
In any case, my recent venture of compressing and saving as a semi 4-bit data is satisfactory enough for myself. I can continue my main project now.
I can see how converting a screen to 6-bit may be a bit smaller but would be more difficult to find solid-painted areas instead of true 4-bit where one character represents one pixel.
[Please log in to post a comment]
