Yes graphics packages export to BIN thankfully, but like what about some level data like a bunch of bytes I'll have to compare and see if this one squishes better, or runs faster MegaLZ.bas ) - it works exactly the same way. I don't think this link is working, Na_th_an?īritlion Wrote:I've used the compressor in the zx basic library to do the same thing.
Aplib decompressor code#
Then you can #include the compressed code inside an asm context, and add in the decompressor code, and voila - zipped up graphics. Na_th_an's aplib works the same way, but obviously it's different code.
I then compress this file with megalz using a command prompt on my PC. Then, in spin, I export the data from 16384 (the screen memory) for 2K to a file. How do I do that? Well, I design the screen in a graphics package, and when it's together I test it on an emulated spectrum to make sure it looks right.
Aplib decompressor full#
1/3 of the screen is a handy size, because 2K of data fits there neatly, so it's just like doing a full screen in effect. For example, one game I'm working on (it may even get finished one day) puts up 1/3 of the screen banner graphics by decompressing to the screen memory. What you do is compress the data outside an emulator. I've used the compressor in the zx basic library to do the same thing.
How is first defined? is it an array,a memory address?Īnd how do you turn all those bytes into a BIN file? It's a good solution which works great and helps you avoid multi-loads Afterwards, the game behaves like a 48K game. Mapdata, tileset and spriteset for the current level are decompressed from there to low ram buffers when entering a level. We use this for our 128K games in C: several levels, tilesets, and spritesets are stored compressed in the extra RAM. 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". I use it all the time for almost everything.Īs 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 do as you wish - but the code is not mine, I just interfaced it. You have to store somewhere, and have several compressed maps (depending on map complexity, you can save quite a bunch of bytes:ĪplibUnpack your engine reads the current level map data from When the player finished level 1 and level 2 is needed, you just unpack from to and you have a brand new map. Your map would be a 4x4x15x10=2400 bytes binary. You can pack your map data, and have several maps stored in memory, and then unpack the current level to your reserved space.įor example, say that you are using rectangular maps for 4x4 screens of 15x10 tiles each. 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. How does someone know where to unpack a bin? - You unpack it where you need it to be.įor example, you can pack a. How do I know where there is empty space in RAM? How does someone know where to unpack a bin? What kind of data can be packed? (bytes,ints,strings?) Sub aplibUnpack (source as uInteger, destination as uInteger) Jr z,ap_r0_gamma if gamma code is 2, use old r0 offset,Ĭall ap_getgamma and a new gamma code for length Ret z if a zero is encountered here, it is EOFĬall ap_getgamma use a gamma code * 256 for offset, another gamma code for length Ld c,(hl) use 7 bit offset, length = 2 or 3 Ex de,hl write a previous byte (1-15 away from dest)
0 kommentar(er)
