Instrux are included in the main program.
Now that I have a way to compress my game logo, I'll go to work on that Halloween game I promised. :)
Very cool, and very slick demo to go with it. How many tokens does it cost just to decode and display the image? Even with the 3 second delay, this would be perfect for displaying awesome full-color title screens that don't take up any tile or graphics space. I might (re: definitely will) use this in my upcoming project!
You know, I should optimize the code for that very thing. Gimme a sec ...
Also, as I understand it, a really long string doesn't use up any more tokens than a short string would, but string length still contributes to the overall 32kb cartridge limit, correct?
That's got me thinking, since you're reading/writing the data to file. Has anyone experimented with installer cartridges before? Like, your game has multiple installer cartridges that writes a bunch of compressed music, sprites, and tile maps to file, then you run your actual game cartridge that reads in new music/sprites/maps at the start of each level, effectively bypassing the cartridge limits. As long as your game engine and logic fits on one cartridge, you can add unlimited levels just by making more installer cartridges. But there's no way to swap cartridges in the web player, is there? So that idea might only work on the standalone Pico8 player...
Looks like 282 tokens. A few routines had to be included. I did set it so it doesn't disturb the tiles at all now. It converts the compressed string directly to the screen.
Glad you're liking it, Jamish ! :)
Let's see what else you wrote ...
You know it's funny. I put a "--" to make that string a REM in front to see what happens and very little changes in the way of memory as far as I can see.
282 tokens of 8192 as is.
279 tokens of 8192 with "--" in front.
279 tokens of 8192 with pic removed.
6662 char of 65536 count as is.
6664 char count of 65536 with "--" in front.
1299 char count of 65536 with pic removed.
Looks to me like it cuts into the 65536. As long as you only have one logo screen or something, I think it won't take any more than 5k-7k of the 64k.
Yes, I think that idea of booting multiple carts to load data would only work LOCALLY, not ONLINE.
. . .
Minju, you don't just have to save screen or tile data. You should be able to use these routines to load/save/compress any data from anywhere in PICO.
TO EVERYONE
If you find any bugs or just have some confusion about how to use this, feel free to ask. It's not a game but I suspect a very good tool that could be used to help game production.
Oh, so it's 64k not 32k.
Dang, that's not a bad trade-off. Very much worth it. I'll keep you updated when I get around to using it. Thank you for sharing.
Good deal, Jamish. You know, since PICO has the ability to recover any memory that was changed back to default. You could definitely use multiple sets of 256-tiles w this compressor.
The default set could be used for the logo and in starting the game, a new one for traveling outside a map, like a continent, the 2nd set for traveling inside, like a city or castle, and the 3rd set for dungeons and caves.
Yielding a total of 1024 16-color 8x8 tiles. It's certainly possible to do. :)
Since my compressor looks for matching bytes, I suspect any logo screens that are custom-made, that is, not a conversion of a 24-bit or 256-color picture, but a true image doodled by the gamewriter themselves using the 16-colors for text/borders and other images and designed to fit within the 128x128 pixel screen - I suspect that will compress remarkably well.
dw, I am not a huge enthusiast for the details of compression and other more nitty-gritty aspects of development, but this is just awesome. For me, I can see this being a reasonable way to fit title screen graphics into a game - I remember the game-over screens and title screens in games like DOnkey Kong COuntry adding a huge amount of character to the game.
Bravo!
PaloBG, very glad you like it ! And I hope it is of good use for you !
Me ? I live for algorithms, compression, tables, and those neat little numbers that stick to the roof of your mouth at night while you're trying to sleep. :)
I'm making headway on my own Halloween game. Have a title screen, a story screen, a YOU WIN screen.
I'm also experimenting with transparency effects w pixels. Doesn't seem possible ? It is, and it involves - well, to really let you know - here is a little song I wrote just now for the occasion. drum roll
♫ It's naught but simple education, when it comes to multiplication, division, and hypotenuse, it's all there for us to use ! ♪
♪ Math ! It's math, it's all about the math ! Come celebrate and calculate, our passion for the math ! ♫
Thanks, MHughson. I'm looking at the data it compresses - think I can do a better job if I work a little harder at it. Once i finish this game, I'll certainly take a crack at it !
Thought I would give this a bump.
I'm seeing some people make logo screens from the decompressed tiles and they might find these routines useful - especially to add a bonus "winning" screen to their game that is 128x128x16 resolution in size and depth.
hey all, i was taking a look at this really great work from dw817 today but it seemed too slow for my next game.
So i made it a whole lot faster by switching all the packing to bit arithmetic and fixing the output length issue. So the image loads from the string just about as instantly as you could hope for, there is no pause at all.
So if you run you will see it also copies the output string to the clipboard, but you need to download the cart and run locally for the copy to clipboard to work!
I also changed the run length encoding functions because the existing ones were giving me errors on occasion!
let me know if any of you have questions about it. NOTE: this is not compatible with the dw817 strings because i extended the encoding table for 6-bit packing (2^6 characters)
Wow, this is unprecedented, Jasper.
Here I am right =NOW= getting ready to post my new compressor (which is 6-bit).
What are the odds of us both upgrading my code ??? Welp, here goes !
https://www.lexaloffle.com/bbs/?tid=31725
Jasper, if you want to update my NEW compressor, please, help yourself ! I'm interested to see what you are doing ...
cool! 6-bit definitely helps but i think the big upgrade is all the bitmath, instead of doing things like 2^n, bit-testing, looping, etc... feel free to use it in your new compressor!
cheers,
Jasper
Please compare my new compressor with the speed you are looking for additionally. I'm just now looking at the upgrade you did with my old compressor.
??? And ...
That's my brain exploding. Hoo-wee ! I cannot wrap this in my head at all:
-- w = a>>2 local w = lshr(band(a, 0xfc), 2) -- x = (a & 0x3)<<4)|(b>>4) local x = bor(shl(band(a, 0x3),4), lshr(band(b, 0xf0),4)) -- y = (b & 0xf)<<2)|(c>>6) local y = bor(shl(band(b, 0xf),2), lshr(band(c, 0xc0),6)) -- z = c & 0x3f local z = band(c, 0x3f) |
I guess the good news is my new compressor/decompressor is quite a bit faster than my old one. Is it fast enough for you is a question ?
hey this little chunk of code is masking and bit shifting to grab the 6-bit chunks out of the 8-bit data. I think there is a deeper optimization to use peek4 and poke4 with this, but i didn't dig into it.
so i'll try to do a decent explanation and then hopefully you can extrapolate what you need from it.
Lets say we read 3 bytes from memory a,b,c and we want to turn that in to 4 6-bit values, each temporarily packed into a number that can be converted to text.
so for the first 6-bits of data (w), we mask the 8-bit data "a" with 0xFC (11111100) using a binary AND to clear out the bits we don't need and then shift it right 2 bits. (a & 0xFC >> 2). so something like 10101010 would mask to 10101000 and then shift to 00101010, which is the 6-bit number we want for the table lookup.
for the second 6-bits of data (x), we are taking 2 bits of data from "a" and 4 from "b" to make up our 6-bits. So we mask 0x3 (0011) and shift left by 4 (10101010 -> 00000010 -> 00100000). confusing but we want the 2 bottom bits from a at the top of the new 6-bit value. similarly we mask 0xF0 from b (11110000) because we want those top 4-bits but nothing else, and then shifting it right by 4 (example would be 10101010 -> 10100000 -> 00001010), and then binary OR these two values to get the 6-bits we need.
It kind of goes on like that for all the values, and the inverse works the same way. just kind of shuffling data around! Bit arithmetic is crazy powerful!
thanks for making such a cool addition to pico-8 i'm excited about embedding all kinds of data as strings. This setup would also probably work great with a pre-pass from px8.
Cheers,
Jasper
Oh my god, now my head really hurts ... :D
I remember doing this back in 6502 assembly ! Oh lord, I was just 12-years old. Okay, yeah. What was I doing ?
Oh I was making a machine-language routine to display 8-pixels across and 8-pixels down on the Apple ][ which as you know by hardware allows only 7-pixels across per byte, the 8th being a shift for color.
I had to do some tricky shifting and lookup tables to get there.
I think it might be possible instead of using bit shifting to use mere bit masking from a fat array
12345678 12345678 12345678 12345612 34561234 56123456 |
Jasper, where can I find your game ? You have me interested now. :)
load #55520 |
https://www.lexaloffle.com/bbs/?tid=31725
Also, I have updated my compressor (links above). Once I finish working on my game I was going to get back here and convert it to proper _INIT(), _DRAW, and _UPDATE(), and compare it (for space used) with outright hex data.
I'm new to Pico. I have no idea how to use this. How do I tell it what image to use and then where is source I use in my game?
[Please log in to post a comment]
