08-03-2012, 07:27 AM
You can pack whatever binary data.
how does someone know where to unpack a bin? - You unpack it where you need it to be.
For example, you can pack a .scr picture (6912 bytes usually compress to under 3 Kb, and even less if the screen is not very complex: I've gotten ~500 bytes for a logo or a frame) and then unpack it to 16384 to display it. You can pack your map data, and have several maps stored in memory, and then unpack the current level to your reserved space.
For example, say that you are using rectangular maps for 4x4 screens of 15x10 tiles each. Your map would be a 4x4x15x10=2400 bytes binary. You have to store somewhere, and have several compressed maps (depending on map complexity, you can save quite a bunch of bytes:
To unpack level1 and use it, just...
Then your engine reads the current level map data from @mapdata. When the player finished level 1 and level 2 is needed, you just unpack from @level2 to @mapdata and you have a brand new map.
Stuff like that. I use it all the time for almost everything.
As for examples, I have to clean up the source code of this game, which I hope to be sharing with you all very soon - and you'll have a working example (the logo and the backdrop are compressed images).
@Boriel: do as you wish - but the code is not mine, I just interfaced it. I'm releasing a 128K version soon - an easy way to use the extra RAM pages to store data - like some kind of "virtual storage". We use this for our 128K games in C: several levels, tilesets, and spritesets are stored compressed in the extra RAM. Mapdata, tileset and spriteset for the current level are decompressed from there to low ram buffers when entering a level. Afterwards, the game behaves like a 48K game. It's a good solution which works great and helps you avoid multi-loads
how does someone know where to unpack a bin? - You unpack it where you need it to be.
For example, you can pack a .scr picture (6912 bytes usually compress to under 3 Kb, and even less if the screen is not very complex: I've gotten ~500 bytes for a logo or a frame) and then unpack it to 16384 to display it. You can pack your map data, and have several maps stored in memory, and then unpack the current level to your reserved space.
For example, say that you are using rectangular maps for 4x4 screens of 15x10 tiles each. Your map would be a 4x4x15x10=2400 bytes binary. You have to store somewhere, and have several compressed maps (depending on map complexity, you can save quite a bunch of bytes:
Code:
Sub mapContainer ()
mapdata:
Asm
mymap: defs 2400, 0
End Asm
level1:
Asm
binary "level1c.bin"
End Asm
level2:
Asm
binary "level2c.bin"
End Asm
level3:
Asm
binary "level3c.bin"
End Asm
End SubTo unpack level1 and use it, just...
Code:
' unpack level 1:
aplibUnpack (@level1, @mapdata)Then your engine reads the current level map data from @mapdata. When the player finished level 1 and level 2 is needed, you just unpack from @level2 to @mapdata and you have a brand new map.
Stuff like that. I use it all the time for almost everything.
As for examples, I have to clean up the source code of this game, which I hope to be sharing with you all very soon - and you'll have a working example (the logo and the backdrop are compressed images).
@Boriel: do as you wish - but the code is not mine, I just interfaced it. I'm releasing a 128K version soon - an easy way to use the extra RAM pages to store data - like some kind of "virtual storage". We use this for our 128K games in C: several levels, tilesets, and spritesets are stored compressed in the extra RAM. Mapdata, tileset and spriteset for the current level are decompressed from there to low ram buffers when entering a level. Afterwards, the game behaves like a 48K game. It's a good solution which works great and helps you avoid multi-loads