In my last DevBlog I already listed a few requirements before the elevators will work in normal game play. We first need working battery holders the player can activate and an animation should play of swapping the empty battery for a full one, which looks pretty cool actually. 
Then your full and empty battery counters are updated accordingly and the machine linked to that battery holder is activated. That is how it works in the original game and so it will in mine...eventually.
I was just looking at the state of the code that I need to modify and it's a big mess of ugly hacks to work around other things! Most of it comes from the fact that at the very beginning I just had a level browser that could load the level and tiles and show them in the correct location on screen. Moving the screen reloaded the tiles on the fly and many improvements in the way this happens made the engine faster and more memory efficient. I was encouraged to make the "game" playable and therefore just patched a few things and hacked my way through the rendering code to make it "appear like this was a game".
Because the sprites can change size depending on the current frame, for example when battery man is walking or jumping, offsets need to be recalculated based on the current position and the players surroundings. For example when walking into a wall or when falling of a platform the player's state is changed, and so is the sprite, animation and frame shown on screen.
For the objects like recharge gate, floats on the water surface, the green "doors/stampers", the belts...actually just about everything you see that is interactive in some way or another...its exactly the same process! For each animation frame the offset could be different and needs to be recalculated!
Without making this even more long or complex....my point is that this recalculation happens EVERY-SINGLE-FRAME even when an object does not even move or change sprites of frames! Meaning it takes up precious rendering time which needs to happen as quick as possible to not show lag anywhere! This is what caused the enormous slowdown on the PlayStation 2 at first before I cleanup a lot of unnecessary things like this. It felt like it was running at maybe 10-15 fps....after the changes more like 30-40 at the moment. Maybe I fixed it enough to pass as "smooth enough" on the PS2 but I don't really remember clearly.
Besides this inefficient recalculating stuff...and what is the worst problem...is that game logic is happening DURING rendering of the frame! And i suspect some of the bugs in the collision detection to be a result of this fact! The truth is that I should really rewrite the entire rendering and game logic into a MUCH cleaner format than what it is now. It will be an awful task and take a lot of time to complete but in the end it will benefit the entire project and all it's supported platforms!
Maybe even worse than this....the BatteryCheck game logic and rendering which is specific to only this game is included in what should have been a universal "libengine" library! It should only provide helpful classes and functions to load and render the game files. All of it's logic should be separated unless it can be useful to other games this engine could run. Biggest one is asked a lot: Jazz Jackrabbit 2 and the answer is: Yes, it can load the game files because they are 99% identical to BatteryCheck. And Yes it can show and render the level's.....but it can not show any of the Jazz2 objects.....yet! Each one needs to be implemented separately to draw and behave the way it should. To compare the work required: BatteryCheck has just about 30 objects. And Jazz2 has a massive list of over 250+ objects!!!!!!
Anyway....for the moment I will just "add into the mess" and make the elevators work somehow! All they need is to:
- Activate
- Go up and down
- Reverse direction when a STOP is in their way at either end
In the case of the puzzle element involved the battery runs out after a few seconds of being on. This should only require the elevator to be deactivated and it should stop at it's resting position. I am thinking of doing some screen recording while working on this to give a sort of timelapse video impression of what's involved in this. I have seen other coding youtube video's doing this and it's quite fun to see....at least to me
If it turns out to be fun and interesting I'll do it for every future change and addition to the game and have a nice history of how the game was build. Or at least re-build into a better version of itself. It's just a thought though....not sure if anyone would actually like video's like this. But it might be interesting to see how a homebrew game is being created from the developers view...right? Maybe?
Just wanted to get this little point of frustration out of my head. Thanks for your time
Then your full and empty battery counters are updated accordingly and the machine linked to that battery holder is activated. That is how it works in the original game and so it will in mine...eventually.I was just looking at the state of the code that I need to modify and it's a big mess of ugly hacks to work around other things! Most of it comes from the fact that at the very beginning I just had a level browser that could load the level and tiles and show them in the correct location on screen. Moving the screen reloaded the tiles on the fly and many improvements in the way this happens made the engine faster and more memory efficient. I was encouraged to make the "game" playable and therefore just patched a few things and hacked my way through the rendering code to make it "appear like this was a game".
Because the sprites can change size depending on the current frame, for example when battery man is walking or jumping, offsets need to be recalculated based on the current position and the players surroundings. For example when walking into a wall or when falling of a platform the player's state is changed, and so is the sprite, animation and frame shown on screen.
For the objects like recharge gate, floats on the water surface, the green "doors/stampers", the belts...actually just about everything you see that is interactive in some way or another...its exactly the same process! For each animation frame the offset could be different and needs to be recalculated!
Without making this even more long or complex....my point is that this recalculation happens EVERY-SINGLE-FRAME even when an object does not even move or change sprites of frames! Meaning it takes up precious rendering time which needs to happen as quick as possible to not show lag anywhere! This is what caused the enormous slowdown on the PlayStation 2 at first before I cleanup a lot of unnecessary things like this. It felt like it was running at maybe 10-15 fps....after the changes more like 30-40 at the moment. Maybe I fixed it enough to pass as "smooth enough" on the PS2 but I don't really remember clearly.
Besides this inefficient recalculating stuff...and what is the worst problem...is that game logic is happening DURING rendering of the frame! And i suspect some of the bugs in the collision detection to be a result of this fact! The truth is that I should really rewrite the entire rendering and game logic into a MUCH cleaner format than what it is now. It will be an awful task and take a lot of time to complete but in the end it will benefit the entire project and all it's supported platforms!
Maybe even worse than this....the BatteryCheck game logic and rendering which is specific to only this game is included in what should have been a universal "libengine" library! It should only provide helpful classes and functions to load and render the game files. All of it's logic should be separated unless it can be useful to other games this engine could run. Biggest one is asked a lot: Jazz Jackrabbit 2
and the answer is: Yes, it can load the game files because they are 99% identical to BatteryCheck. And Yes it can show and render the level's.....but it can not show any of the Jazz2 objects.....yet! Each one needs to be implemented separately to draw and behave the way it should. To compare the work required: BatteryCheck has just about 30 objects. And Jazz2 has a massive list of over 250+ objects!!!!!!Anyway....for the moment I will just "add into the mess" and make the elevators work somehow! All they need is to:
- Activate
- Go up and down
- Reverse direction when a STOP is in their way at either end
In the case of the puzzle element involved the battery runs out after a few seconds of being on. This should only require the elevator to be deactivated and it should stop at it's resting position. I am thinking of doing some screen recording while working on this to give a sort of timelapse video impression of what's involved in this. I have seen other coding youtube video's doing this and it's quite fun to see....at least to me
If it turns out to be fun and interesting I'll do it for every future change and addition to the game and have a nice history of how the game was build. Or at least re-build into a better version of itself. It's just a thought though....not sure if anyone would actually like video's like this. But it might be interesting to see how a homebrew game is being created from the developers view...right? Maybe?
Just wanted to get this little point of frustration out of my head. Thanks for your time
