Given that probably yoi'll.use first (or last) two rows for a scoreboard then you have to decompress a column of 22bytes (but if you use a full 24 tiles column things don't change). It's easy to do and really fast.
A (very) simple example.
Having a pixel scrolling reduce a lot your tiles variety. And as the video.shows they are often combined togheter.
And you have a lot of background empty spaces. So you can:
- assign a value for every tile combinarion (remember that you need to consider only the first frame)
- having low tile's variety you can avoid to do combinations (actually it seems you have less than 16 different tiles) so you can assingn a given value for every tile
- assign a value for every quantity of empty spaces (probably better starting with spaces and use consequent values for tiles)
So you'll have values from 1 to 24 (if you use the full screen height) for empty chunks and values 25 to 40 (considering 16 types of tiles) for your starting tiles.
Your compresses 22tiles column sequence can be 4,25,26,10,27,4,30,0 that means: 4 background empty space tilesz tile 25, tile 26, 10 empty, tile 27, 4 empty, tile 30, end of compressed column (0)
Dexompressing it is fast. If the number is lower than 22 then you have a bground empty chunk. Set the value on Reg B as a counter and put the bgound tiles b times, else put correspondant tile on screen
Amd if you have repeated tiles you can use the same way for them assigning a value for every group of tile combination. Example: use for tile's tyle numbers from 128 to 144 (16 types+1empty) and values 1to22 for quantity; 0 marks end of column:
4,145,2,128,10,145,6,130,0
Means: 4xbground empty, 2xtile 128,10xbground, 6xtile 130, end of column
Very cool Andrés!
Thanks @santiontanon and @thegeps.
Indeed, RLE encoding may be feasible. I was thinking of some "heavy" compressor such as Pletter, but often RLE solves, as it seems to be the case here.
But, I'm afraid this project ends up as one more to never be finished, so I will make some playable game before to mess with this kind of optimization. But very cool hints, thanks again.
How nice, it looks very promising!
But, I'm afraid this project ends up as one more to never be finished, so I will make some playable game before to mess with this kind of optimization. But very cool hints, thanks again.
Yes please, much better to finish a simple game than leave unfinished a big one!. Make it easy and understandable and you'll be able to come back later to enhance it
Indeed, I agree! Focus first on having the gameplay ready
And also, as I mentioned, optimize space only if you care about it. If these types of optimizations are not what motivates you to work on the game, then I'd ignore them completely, and focus on the part that you are excited to work on
But, I'm afraid this project ends up as one more to never be finished, so I will make some playable game before to mess with this kind of optimization. But very cool hints, thanks again.
Work at one thing @ the time and work around those little sucesses. First build the engine. Then make a player and within those things focus on each detail as a small project. Never look forward enjoy the moment within those small works. Take summer breaks. Trust me I know how that works.
Yep, I'd coded Freedom Fighter for more than 2 years, adding contents and objectives many times. If there weren't last msxdev deadline probably I wouldn't completed it... even if I've delivered a bugged amd gameplay defective version. Then, finally having relax, I've coded two small games (Farty Pig and Earth Attack) and now I'm again on Freedom Fighter to finally release it as a physical version. New prologue gfx are almost done: without an incoming deadline I've been focused on draw better pics and I've embedded pletter to pack/depack them.
So relax, take your time, have fun coding. Complexity add could be done in future
Thanks @santiontanon and @thegeps.
Indeed, RLE encoding may be feasible. I was thinking of some "heavy" compressor such as Pletter, but often RLE solves, as it seems to be the case here.
But, I'm afraid this project ends up as one more to never be finished, so I will make some playable game before to mess with this kind of optimization. But very cool hints, thanks again.
Not to distract you from actually working on the gameplay , but another idea for level compression is to exploit repetitiveness in columns of tiles. Using columns as metatiles, as it were. You could store the unique tile columns, and then have a long array spanning the width of the level with column metatile indices.
New video, now with some basic gameplay, still with a few bugs (platformers are hard).
Hope you enjoy: https://youtu.be/xHis8gAWIGo
oh wow, that's a huge change, very nice progress!! Are you planning something super mario-style?