A couple options (totally different methods) to display big titles, e.g. a 'game over' screen or 'the end' in the style of silent movies.
Method 1 - Map and sprite tiles
You draw a few sprite tiles with corners and reusable portions to form your title.
Pros: all the advantages of Pico-8's maps and easy to edit your title
Cons: you need some free area in your Map and you spend tiles of your spritesheet
Method 2 - P8scii One-Off characters
You can use this spritesheet to P8scii string converter here to obtain a printable string that will display the title (or logo etc..).
Pros: no map, no spritesheet, just a big string
Cons: pick your image carefully, avoid one with many stray pixels (read hints in the linked One-off page) or it will eat compressed characters space.
Press:
- Z to restart the animation.
- X to swap the method (One-off gfx / map)
@dw817 actually I didn't refine much the input image so in a few spots the antialias cause 3 or 4 colours per block (it's around 2k chars)
What are the advantages/disadvantages over just using px9 for the storage of images?
Quite a few, @SquidLight. For instance, I am making use of @Heracleum's image compressor in my latest project for two reasons that outweigh PX9. (Gold star BTW)
https://www.lexaloffle.com/bbs/?tid=50113
Here are =2= main reasons I am using this program.
-
Convenience. You just PRINT a single statement that draws your picture. PX9 requires you to add a bunch of other functions and code to your existing code. Now if you had in mind a slideshow, sure, PX9 might save you in the long run, but for a single logo picture, it's overkill.
- Heracleum's own compressor is specialized for low-color images, like B&W. My own picture compressors expect 16-colors and their compression is reflected in this. Heracleum's own gives the best compression with 1-bit images.
So ... yep, there are indeed some advantages, especially for lazy coders such as myself. :)
@SquidLight sorry I need to experiment more with px9 before replying and make comparisons but as far as I've seen although it handles better multicolour its worst enemy is dithering (and any pixel complexity that breaks a streak of same colour).
It would be interesting to see how different methods work on a same sample image.
PX9 works fine with simple dithering (e.g. 50%), but it works worse with complicated images, which tend to be dithered.
the way PX9 works, roughly:
- the decompressor and compressor both start out with an identical prediction dictionary, predicting the color of any pixel based on the neighbors above and to the left.
- the compressor runs through each row of pixels. when it sees a mispredicted value, (e.g. the dictionary says the next pixel should be red but its actually green), it writes that misprediction to the stream and updates its predictionary
- when the compressor sees a lot of predicted values in a row, it "writes" those to the stream by just writing a number, telling how many predicted values it saw. this is the main way PX9 saves space!
- the de-compressor reads the stream, updating the image and keeping its own predictionary in sync with the compressor's. it can do this perfectly because it knows the image up to that point (and because it knows how the compressor works)
so, PX9 does well with images that have a lot of the same color in a row (well, on multiple rows) because it can easily predict what the next pixel will be after the first one. but it can do fine on other more complex inputs as well -- images that have a predictable structure, but not necessarily single-color runs.
>It would be interesting to see how different methods work on a same sample image.
agreed! ping me if you ever dig into this, I'd be interested to see what you find. I'd expect PX9 to perform pretty badly on images with a lot of antialiasing, or images produced from an image converter (instead of hand-drawn pixel-by-pixel)
[Please log in to post a comment]
