It's depressing to see that all the previous images I sent using discord hotlinking are lost media. I might be able to go back in time and rescue a few of them from discord or some old PC backups, but this is highly unlikely.
I've trashed all of the previous code and have begun
rewriting my port from scratch with the original as a crude reference. What's currently in the main branch represents 2 previous attempts to rewrite the code and solve the memory issues, which previously I couldn't do anything about due to the amount of on-the-fly decompression I needed to do with only zx7 and no clue how to download more RAM. With zx0 I've been able to double decompression speed with smaller file sizes to boot. Here's what I've currently done, with goals to at least achieve parity with what I had completed before my death:
* Nearly all sprites all use zx0 compression with some being RLET encoded to save on memory.
* All background sprite loading is now handled dynamically using a mixture of initialized and heap memory chunks, with allocated memory being freed as soon as it's no longer needed with the intent to load obstacle sprite data afterwards.
* The main menu and the basics for the into cutscene are implemented.
* The about menu has been implemented and cut down to the important details.
* The pause menu has been implemented.
* The max FPS counter is still there and higher than ever.
* Math has been greatly simplified to prioritize speed over "feel," although I don't think many will notice a big change. I've tuned it so flying feels more like the original and believe this is an improvement
* Background sprite size on calc has gone from 137,659 bytes to 42,764 bytes. This is not indicitive of future size improvements, but it's a good sign for potential changes.
As one can see from the code, I've become accustomed to pointer witchcraft and make frequent use of it. I'm currently working on creating an engine that can handle pointers to mutliple different types of objects and use ID bytes passed to a function array to choose the right system to run them through, with a lot of flexibility for managing multiple objects on screen. I've developed prototypes for this method in other unreleased projects and hope to use a polished version here, and recently discovered that I've reinvented the
Entity Component System. This will make storing save data easier in the future and may offer a speed increase if implemented correctly.
It looks far less interesting than previous examples, but keep in mind that each new background tile is being decompressed as needed and replacing previous examples with no meaningful performance hit:
Thanks to the lurker who found me IRL and got me to keep working away at this.