Since 2018 I have been working on a homebrew remake of an old PC platform game called BatteryCheck. At first it was more a proof of concept style level browser. Then I added a "player" and movement, show objects, implement very primitive collision detection, a point system that had bugs, and a few other hacks to make it appear to be more than it really is! The biggest mistake is wanting to do it all at once...and too soon! This had the effect that rendering and game logic are so much intertwined that it's basically impossible to separate them anymore!
Over the years I ported my "game engine" over to multiple platforms: Linux, Wii, GameCube, 3DS, PlayStation 2, Wii U and Switch. There are "failed/incomplete" ports for the PlayStation Portable and DSi, mostly because of GPU limitations like RAM and maximum texture size. My ultimate "de-make" goal is to have it run on a Sega Genesis, the console where my homebrew journey started, and in the same are of gaming also the SNES. Biggest problem is RAM on these platforms! my game engine unpacks the games assets into about 6-8MB or RAM.
My kinda recent experiment on the PlayStation 1 included resizing the tileset into 16x16 from 32x32. It's still a 256 color palette (i think, it was nearly a year ago since I worked on it). And for this version I had to start from scratch for a couple of reasons. For one, the is no easy way to load data from an SD card so it has to fit all in RAM. Of which there is only 2MB and 1MB VRAM.
I have mentioned working on GBA and GBC versions...mostly as ideas. The GBA version was serious enough...but loading from SD card was difficult so I abandoned it for the NDS version. Now...I just got thinking about it again! For personal reasons I just NEED to finish this project! I rarely finish anything...so let's this be one of the few that I DO see through and actually finish!
To do it right...I need to start from scratch! Clean slate, on all platforms! Some might say to focus on just one...but I can't! I put much time into learning about the platforms years ago...and the biggest thing needed is to setup a build environment that can compile for any of the systems I want. From the same code base! Biggest thing to do right this time is have game state and game rendering separate!!! What I need is to "render the state" in memory...and then hand that over to "graphics rendering". what this means is all movement, points, damage, collisions etc...are calculated and handled in the "state rendering". After this...it's like a frozen moment in time for the game! In theory....this same "state" in memory could be handed over to any other console...and displayed on the screen...exactly as on the original system. or...a in other words....the beginnings of implementing multi-player!And possible save states.
One crazy idea I had was to implement graphics rendering first on each platform...and then "stream" the state over a network connection. Like, run the state on a Linux PC and then stream it to a Wii, Gamecube and PS2...all at the same time. Since they receive the same state and run at the same resolution...the rendered image should be identical on each! On the other hand...the part that receives the state over the network might become too complex to start out with. But I could use a "fixed save state"...or a few of those. And I could load that from "storage" or include it into the binary. Even have some sort of "playback" of savestates. I don't know yet. At the very least have a gamestate() function followed by a render() function. Those names might change...but the idea is the same. First calculate where everything in the game is, then send it over to the drawing routines to show on screen.
Another thing I was thinking of was to reduce the resolution of the game when running on the GBA, DS, DSi and 3DS. And more in the sense of using the same reduced graphics used on the PS1 port. They do loose some details...but the conversion scripts I had created do a good job of keeping just enough to make it less noticeable. I might make it an optional thing, switchable, to let the player choose viability while playing vs the details and quality of graphics. So instead of 32x32 they will also use 16x16 tiles for the level. Effectively giving the impression of a bigger playfield, I think.
Either way, I want the game state to produce the same state object for the graphics rendering to use. regardless of using 32x32, 16x16 or maybe even 8x8 (thinking of this for gameboy Color). Yes, smaller resolution looses detail...but also reduces memory usage a lot! I have not done the calculations for it yet...and I don't remember from the PS1 version. But I am pretty sure it's significant and useful on the more resource constraint systems.
First thing to do is restore my development setup and update all relevant tools. Might take a while to sort through all of it. More updates will follow!
Over the years I ported my "game engine" over to multiple platforms: Linux, Wii, GameCube, 3DS, PlayStation 2, Wii U and Switch. There are "failed/incomplete" ports for the PlayStation Portable and DSi, mostly because of GPU limitations like RAM and maximum texture size. My ultimate "de-make" goal is to have it run on a Sega Genesis, the console where my homebrew journey started, and in the same are of gaming also the SNES. Biggest problem is RAM on these platforms! my game engine unpacks the games assets into about 6-8MB or RAM.
My kinda recent experiment on the PlayStation 1 included resizing the tileset into 16x16 from 32x32. It's still a 256 color palette (i think, it was nearly a year ago since I worked on it). And for this version I had to start from scratch for a couple of reasons. For one, the is no easy way to load data from an SD card so it has to fit all in RAM. Of which there is only 2MB and 1MB VRAM.
I have mentioned working on GBA and GBC versions...mostly as ideas. The GBA version was serious enough...but loading from SD card was difficult so I abandoned it for the NDS version. Now...I just got thinking about it again! For personal reasons I just NEED to finish this project! I rarely finish anything...so let's this be one of the few that I DO see through and actually finish!
To do it right...I need to start from scratch! Clean slate, on all platforms! Some might say to focus on just one...but I can't! I put much time into learning about the platforms years ago...and the biggest thing needed is to setup a build environment that can compile for any of the systems I want. From the same code base! Biggest thing to do right this time is have game state and game rendering separate!!! What I need is to "render the state" in memory...and then hand that over to "graphics rendering". what this means is all movement, points, damage, collisions etc...are calculated and handled in the "state rendering". After this...it's like a frozen moment in time for the game! In theory....this same "state" in memory could be handed over to any other console...and displayed on the screen...exactly as on the original system. or...a in other words....the beginnings of implementing multi-player!And possible save states.
One crazy idea I had was to implement graphics rendering first on each platform...and then "stream" the state over a network connection. Like, run the state on a Linux PC and then stream it to a Wii, Gamecube and PS2...all at the same time. Since they receive the same state and run at the same resolution...the rendered image should be identical on each! On the other hand...the part that receives the state over the network might become too complex to start out with. But I could use a "fixed save state"...or a few of those. And I could load that from "storage" or include it into the binary. Even have some sort of "playback" of savestates. I don't know yet. At the very least have a gamestate() function followed by a render() function. Those names might change...but the idea is the same. First calculate where everything in the game is, then send it over to the drawing routines to show on screen.
Another thing I was thinking of was to reduce the resolution of the game when running on the GBA, DS, DSi and 3DS. And more in the sense of using the same reduced graphics used on the PS1 port. They do loose some details...but the conversion scripts I had created do a good job of keeping just enough to make it less noticeable. I might make it an optional thing, switchable, to let the player choose viability while playing vs the details and quality of graphics. So instead of 32x32 they will also use 16x16 tiles for the level. Effectively giving the impression of a bigger playfield, I think.
Either way, I want the game state to produce the same state object for the graphics rendering to use. regardless of using 32x32, 16x16 or maybe even 8x8 (thinking of this for gameboy Color). Yes, smaller resolution looses detail...but also reduces memory usage a lot! I have not done the calculations for it yet...and I don't remember from the PS1 version. But I am pretty sure it's significant and useful on the more resource constraint systems.
First thing to do is restore my development setup and update all relevant tools. Might take a while to sort through all of it. More updates will follow!
