Log In  
Log In  

Cart [#39947#] | 2017-04-26 | No License | Embed

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:

Cart [#39706#] | 2017-04-15 | No License | Embed

Cart [#39098#] | 2017-04-05 | No License | Embed

Cart [#39021#] | 2017-04-03 | No License | Embed

Cart [#38834#] | 2017-03-29 | No License | Embed

Cart [#38770#] | 2017-03-27 | No License | Embed

Cart [#38741#] | 2017-03-26 | No License | Embed

Cart [#38605#] | 2017-03-23 | No License | Embed

Cart [#38496#] | 2017-03-21 | No License | Embed

Cart [#38398#] | 2017-03-19 | No License | Embed

Cart [#38300#] | 2017-03-17 | No License | Embed

Cart [#38204#] | 2017-03-12 | No License | Embed

Cart [#38172#] | 2017-03-12 | No License | Embed

Cart [#38148#] | 2017-03-11 | No License | Embed

Cart [#38129#] | 2017-03-10 | No License | Embed

Cart [#38116#] | 2017-03-09 | No License | Embed

P#38117 2017-03-09 02:34 ( Edited 2018-09-10 05:00)

The spritework is very cute! I have no idea how you're supposed to play the game, though.

P#38152 2017-03-11 03:10 ( Edited 2017-03-11 08:10)

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

P#38173 2017-03-11 21:08 ( Edited 2017-03-12 02:08)
:: sax3

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

P#38301 2017-03-17 02:39 ( Edited 2017-03-17 06:39)

@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!

P#38382 2017-03-18 18:49 ( Edited 2017-03-18 22:49)
:: 9tk

I love the latest build already!
This is gonna be perfect puzzle/maze action. ^^

P#38400 2017-03-19 04:50 ( Edited 2017-03-19 08:50)
:: sax3

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!

P#38502 2017-03-21 07:27 ( Edited 2017-03-21 11:27)

@sax3: The original actually had 2 players too, but not until the later levels. :)

P#38518 2017-03-21 19:01 ( Edited 2017-03-21 23:01)
:: Scathe

I like how this is progressing!

P#38766 2017-03-26 23:24 ( Edited 2017-03-27 03:24)

This is really fun. I love these "speed-run" type platformers.

P#39707 2017-04-15 22:48 ( Edited 2017-04-16 02:48)

Fantastic! Special shout-outs for the compressed title screen and animated booklet gif, great stuff.

P#39979 2017-04-27 11:29 ( Edited 2017-04-27 15:29)

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

P#39981 2017-04-27 13:18 ( Edited 2017-04-27 17:18)

Oh my! This is wonderful! Reminds me of Solomon's Key perhaps, but I love the music/atmosphere of this.

P#40146 2017-05-02 21:54 ( Edited 2017-05-03 01:54)

@daann: It was my first time trying to create a game booklet like this. Glad you enjoyed it!

@01010111: Thanks! Catrap is truly one of the most underrated games I've ever played!

@gradualgames: Thanks! Music and sound was by Gruber music (https://twitter.com/gruber_music) if you want to hear more.

P#40475 2017-05-11 17:23 ( Edited 2017-05-11 21:23)
:: dw817

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:


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 !


P#56037 2018-09-02 02:32 ( Edited 2018-09-02 06:36)
:: Felice


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.

P#56069 2018-09-02 16:39 ( Edited 2018-09-02 21:22)
:: dw817

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 ?

P#56089 2018-09-02 23:06 ( Edited 2018-09-03 03:35)
:: Felice

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.

P#56124 2018-09-03 15:21 ( Edited 2018-09-03 19:21)
:: dw817

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 ?

P#56126 2018-09-03 15:26 ( Edited 2018-09-03 19:26)
:: Felice

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.

P#56127 2018-09-03 15:33 ( Edited 2018-09-03 19:40)
:: dw817

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 ?"

P#56129 2018-09-03 16:06 ( Edited 2018-09-03 20:06)
:: dw817

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.

P#56146 2018-09-03 21:15 ( Edited 2018-09-04 01:26)
:: Felice

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.

P#56154 2018-09-04 02:49 ( Edited 2018-09-04 06:49)
:: dw817

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.

P#56162 2018-09-04 12:26 ( Edited 2018-09-04 16:26)

Does anyone have any thoughts on Image Compression......?

P#56472 2018-09-10 01:00 ( Edited 2018-09-10 05:00)

[Please log in to post a comment]

About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2018-12-12 17:02 | 0.156s | 4194k | Q:197