It's taking me a while to get used to the PlayStation 1 hardware and SDK (psn00bsdk). I am starting to see the bigger picture of how things work. Last time I showed a few screenshots with funky colors. I had a demo that showed all the splashscreens of batterycheck one after another with a 2-3 second delay. That worked great...except the colors were broken! Some of it worked but it seemed like something was...ehm...missing? See my first ever youtube short:
It's actually looking kinda scary especially in the eyes of batteryman. He looks evil! Well...as usual it was a stupid silly thing that caused all of that! Each image has a 256 color palette. A palette of 256 colors on the PS1 is 16 bits per color..so 2 bytes. But when loading an image using a color palette each pixel is only 1 bytes...and because VRAM works in 16bit's at a time you need to divide the width of the image by 2...remember this for later!
During my attempts to "hide the complex code" I have created macro's to add the textures into the "rom", make the textures usable in the code, load them into vram, and to display them. And I kinda copy-pasted that for the palette's which is where the problem of the missing colors was created! As said above a palette is actually 256 * 16 bit (or 2 bytes) in size. But because I copied the macro's for the textures what happend was that during loading of the palette it's width was divided in half, like it needs to for the textures, resulting in only 128 colors to be actually loaded into VRAM!!! A stupid and really simple mistake that took me three days to figure out! It did not help that I was actually not feeling well...so maybe it was just a day in total.
Having this issue sorted meant I could move on to the next big thing! The tiles! Tiles are little squares that are the building blocks of the levels in BatteryCheck. There are 1024 of them and originally 32x32 pixels each! That means that at 1 byte per pixel that's 1MB! That's the ENTIRE size of the VRAM in the PS1 so I have to resize it to make it fit in there! I choose 16x16 for now and had to reorder the tiles to be spread out over a total of 8 128x256 pixel textures. To make this convertion script I once again used ChatGPT. it did not want to understand what I actually wanted so it took me a long time to actually get the result I wanted. But in the end this was the result:
And a bit of handdrawn tiles gave me this:
It does not look like much...but to draw that I use the actual tileID's that are also used by the levels. Meaning I can convert the levels into a format that would work with the limited RAM of the PS1 now...but just to make that image a bit more intteresting I added some variation to it:
And yes, that laser platform is animated...by picking the correct animation tiles by hand...waiting 6 frames and changing them. It works but it's A LOT of work to make more interesting animations so I gave up on that. It's more useful if I can convert the level data and use that directly to display the actual level. This will then also include the animations.
Now that I have reached this stage in the PS1 experiments I have decided a few things to go foreword. Instead of implementing the existing code that my other ports are based on....I'll do a rewrite from scratch on the PS1. The main reason for this is to better optimize the new code and make it even more efficient and portable. Also...rendering and game logic should not be mixed as it is now. It's possible this will take a bit longer but so be it. All other platforms will benefit in the end from this.
I plan on splitting the code into these main sections:
- asset loading
- platform drivers
- game logic
- rendering
This approach should make it possible to do asset loading a little different on each platform but still make it accessible in a similar way to the rendering code. The platform drivers abstract the GPU, Sound, Input and storage just as it is now. The biggest change is going to be the game logic and rendering splitup! What I basically want to do in each frame is: take the controller input and send it to the game logic. Have the game logic change object positions, detect and correct collisions etc... This will create a memory object of where everything is in the game world, and what section of the world to show on screen. In theory this could be used as a "save state" kind of thing. Or send over to ANY of the other plaforms and have those render the graphics there! While a useless feature...it could allow playing and calculating the logic on say a wii...and have the rendering take place on: 3DS, PC, PS2....etc..... Could be a step to multi player.
Offcourse...it's as I said useless to except for a "cool" demo to make the game do this. There could still be sync issues from network latency that make it impractical. But for debugging it might be usefull...I don't know.
At least it will make the separation between these section a lot more clear and independent. Some of the issues in the current codebase come from the mix of the logic and rendering code. Among that could be the "1px jitter when walking into walls". Rewriting the code to work on a more limited platform like the PS1 also brings other benefits for existing platforms. Most notably the ones that are currently incomplete...like the PSP and DSi ports. They are nearly complete but lack the Tiles as those textures were far to big. But they share similar limitations with the PS1 making it easier to in the future complete these ports.
I am sorry for this wall of random thoughts. As usual I needed to clear my head a bit and I just wanted to share these images too.
I was also planning on a video of the laser platform animation but my editor software is broken. Actually...my whole PC is ready for a fresh reinstall of everything. Been postponing it for nearly 2 years now
Thanks for reading and until next time.
It's actually looking kinda scary especially in the eyes of batteryman. He looks evil! Well...as usual it was a stupid silly thing that caused all of that! Each image has a 256 color palette. A palette of 256 colors on the PS1 is 16 bits per color..so 2 bytes. But when loading an image using a color palette each pixel is only 1 bytes...and because VRAM works in 16bit's at a time you need to divide the width of the image by 2...remember this for later!
During my attempts to "hide the complex code" I have created macro's to add the textures into the "rom", make the textures usable in the code, load them into vram, and to display them. And I kinda copy-pasted that for the palette's which is where the problem of the missing colors was created! As said above a palette is actually 256 * 16 bit (or 2 bytes) in size. But because I copied the macro's for the textures what happend was that during loading of the palette it's width was divided in half, like it needs to for the textures, resulting in only 128 colors to be actually loaded into VRAM!!! A stupid and really simple mistake that took me three days to figure out! It did not help that I was actually not feeling well...so maybe it was just a day in total.
Having this issue sorted meant I could move on to the next big thing! The tiles! Tiles are little squares that are the building blocks of the levels in BatteryCheck. There are 1024 of them and originally 32x32 pixels each! That means that at 1 byte per pixel that's 1MB! That's the ENTIRE size of the VRAM in the PS1 so I have to resize it to make it fit in there! I choose 16x16 for now and had to reorder the tiles to be spread out over a total of 8 128x256 pixel textures. To make this convertion script I once again used ChatGPT. it did not want to understand what I actually wanted so it took me a long time to actually get the result I wanted. But in the end this was the result:
And a bit of handdrawn tiles gave me this:
It does not look like much...but to draw that I use the actual tileID's that are also used by the levels. Meaning I can convert the levels into a format that would work with the limited RAM of the PS1 now...but just to make that image a bit more intteresting I added some variation to it:
And yes, that laser platform is animated...by picking the correct animation tiles by hand...waiting 6 frames and changing them. It works but it's A LOT of work to make more interesting animations so I gave up on that. It's more useful if I can convert the level data and use that directly to display the actual level. This will then also include the animations.
Now that I have reached this stage in the PS1 experiments I have decided a few things to go foreword. Instead of implementing the existing code that my other ports are based on....I'll do a rewrite from scratch on the PS1. The main reason for this is to better optimize the new code and make it even more efficient and portable. Also...rendering and game logic should not be mixed as it is now. It's possible this will take a bit longer but so be it. All other platforms will benefit in the end from this.
I plan on splitting the code into these main sections:
- asset loading
- platform drivers
- game logic
- rendering
This approach should make it possible to do asset loading a little different on each platform but still make it accessible in a similar way to the rendering code. The platform drivers abstract the GPU, Sound, Input and storage just as it is now. The biggest change is going to be the game logic and rendering splitup! What I basically want to do in each frame is: take the controller input and send it to the game logic. Have the game logic change object positions, detect and correct collisions etc... This will create a memory object of where everything is in the game world, and what section of the world to show on screen. In theory this could be used as a "save state" kind of thing. Or send over to ANY of the other plaforms and have those render the graphics there! While a useless feature...it could allow playing and calculating the logic on say a wii...and have the rendering take place on: 3DS, PC, PS2....etc..... Could be a step to multi player.
Offcourse...it's as I said useless to except for a "cool" demo to make the game do this. There could still be sync issues from network latency that make it impractical. But for debugging it might be usefull...I don't know.
At least it will make the separation between these section a lot more clear and independent. Some of the issues in the current codebase come from the mix of the logic and rendering code. Among that could be the "1px jitter when walking into walls". Rewriting the code to work on a more limited platform like the PS1 also brings other benefits for existing platforms. Most notably the ones that are currently incomplete...like the PSP and DSi ports. They are nearly complete but lack the Tiles as those textures were far to big. But they share similar limitations with the PS1 making it easier to in the future complete these ports.
I am sorry for this wall of random thoughts. As usual I needed to clear my head a bit and I just wanted to share these images too.
I was also planning on a video of the laser platform animation but my editor software is broken. Actually...my whole PC is ready for a fresh reinstall of everything. Been postponing it for nearly 2 years now Thanks for reading and until next time.
