It's been a while...far too long....since I have last posted anything devblog related to batterycheck. While I have nothing really new or exciting to tell...I have found some regained intterest to continue. And with continue...I basically mean start over from scratch! The main reason to start over is that the current version relies far too much on the actual Jazz2 file formats, even in memory. This is fine for systems that have enough speed and memory to deal with this. So Linux on PC, Wii, gamecube, 3DS and Wii U all have more than enough resources to deal with this "bad design". Only on PS2 I started to notice some slowdown and framedrops. I have managed to reduce the effects a lot...but it still feels not as smooth for me as the others.
The biggest thing I can do now is used prerendered graphics and such. It's a gray area...but I did get permission to distribute as I see fit. Not sure how reformating the level, tileset and sprite's would be actually. But...at least for the demo's I think I'll include it from now on. No more ZIP downloads.
What I want to do is restructure the level data in a way that I feel is much more efficient on low spec systems. Like the GBA, DSi, GBC, SNES and Genesis. Not sure how I am going to do it for each system...but that's for later. I can lay the foundations now and later optimize where needed for a specific platform. I am starting the rewrite on Linux first., keeping the portability in mind. Then I'll add 3DS support back in...since that one is easy to upload a new version too with the homebrew channel. And later also Wii, Gamecube and PS2.
The biggest change I need to make is separating the gamelogic and rendering! What is drawn on screen should have nothing to do with the actual gamestate! Gamestate does things like object position, collition detection and correction, etc. Then when the gamelogic has done it's "step", a pre-renderer should take the gamestate and load or fetch the assests required to display the scene. THis includes the tileset, or a part of it, sprites, partial level map and layer data. Set coordinates for drawing items on screen etc.
Then...if my theory is correct...the gamelogic should be mostly 100% identical for every single platform it runs on! The "pre-render" translates the gamestate to drawing objects and loading the assets in VRAM and such. Then...the actual "render" is what runs in the main VBlank routine to update the screen. Hopefully...this does not slow everything down!
Another optimization that will help a lot with the above is reformating the level map data. Right now it's kinda strange. Tiles are grouped in pairs of 4 in a row. So a unique row of 4 tiles is stored just once! Then...in a second table a reference is made into this "list of groups". and that is what draws the map. So it's an index into another array. One of these maps, if IRC is almost 1MB! Uncompressed! I'll have to look into the file sizes of various things again. And this index list of groups structure I want to reformat into more direct maps. Possibly just in the pre-render stage. So we can load a part of the level and only update and shift once we move arround.
I am sure this might sound complicated, it probablly is, but I just wanted to say I am back on it....and hopefully back soon with some sort of demo, screenshots, video's etc..
Another thing is I am going to use ChatGPT to help me assist in various parts of the project. I have been testing it out with a bunch of projects, scripts and other weird stuff. I love how interactive it is...no longer I need to search multiple pages on google...or do manual calculations. It can even do some object recognition from images...so in theory draw a sketch...upload and explain what you want. And then ChatGPT will understand and do it!
It's not good enough to do ALL of it at once..yet.
Fun things to come
The biggest thing I can do now is used prerendered graphics and such. It's a gray area...but I did get permission to distribute as I see fit. Not sure how reformating the level, tileset and sprite's would be actually. But...at least for the demo's I think I'll include it from now on. No more ZIP downloads.
What I want to do is restructure the level data in a way that I feel is much more efficient on low spec systems. Like the GBA, DSi, GBC, SNES and Genesis. Not sure how I am going to do it for each system...but that's for later. I can lay the foundations now and later optimize where needed for a specific platform. I am starting the rewrite on Linux first., keeping the portability in mind. Then I'll add 3DS support back in...since that one is easy to upload a new version too with the homebrew channel. And later also Wii, Gamecube and PS2.
The biggest change I need to make is separating the gamelogic and rendering! What is drawn on screen should have nothing to do with the actual gamestate! Gamestate does things like object position, collition detection and correction, etc. Then when the gamelogic has done it's "step", a pre-renderer should take the gamestate and load or fetch the assests required to display the scene. THis includes the tileset, or a part of it, sprites, partial level map and layer data. Set coordinates for drawing items on screen etc.
Then...if my theory is correct...the gamelogic should be mostly 100% identical for every single platform it runs on! The "pre-render" translates the gamestate to drawing objects and loading the assets in VRAM and such. Then...the actual "render" is what runs in the main VBlank routine to update the screen. Hopefully...this does not slow everything down!
Another optimization that will help a lot with the above is reformating the level map data. Right now it's kinda strange. Tiles are grouped in pairs of 4 in a row. So a unique row of 4 tiles is stored just once! Then...in a second table a reference is made into this "list of groups". and that is what draws the map. So it's an index into another array. One of these maps, if IRC is almost 1MB! Uncompressed! I'll have to look into the file sizes of various things again. And this index list of groups structure I want to reformat into more direct maps. Possibly just in the pre-render stage. So we can load a part of the level and only update and shift once we move arround.
I am sure this might sound complicated, it probablly is, but I just wanted to say I am back on it....and hopefully back soon with some sort of demo, screenshots, video's etc..
Another thing is I am going to use ChatGPT to help me assist in various parts of the project. I have been testing it out with a bunch of projects, scripts and other weird stuff. I love how interactive it is...no longer I need to search multiple pages on google...or do manual calculations. It can even do some object recognition from images...so in theory draw a sketch...upload and explain what you want. And then ChatGPT will understand and do it!
It's not good enough to do ALL of it at once..yet.
Fun things to come
