I just need to figure out how to automate the step where they're converted into a similar PC-readable format. This is definitely not the sort of thing that I'd want to do by hand. 🤔
At this point, I think I have everything to rip textures from this game. Width & height, color palette size & entries, and the image data itself - including where it ends.
There's still some bytes in the header that I don't understand, but for textures, I think I can ignore them
Why rip from this game in particular?
1) It's a game from my childhood, and honestly the soundtrack (which is just CD audio) is solid 90s techno.
2) All the game files are just out in the open, organized into folders and plainly named. No unpacking or decompression required!
I'm starting with a tiny game called Impact Racing, an obscure budget combat-racer by Funcom Dublin, 1996. You destroy a certain number of cars while finishing laps before time runs out, so you can get more weapon upgrades before you reach the final stage.
Turns out there's a 4-byte entry that says how many bytes are used for the color palette, and then each color palette entry uses 3-bytes. Straight-up RGB. And then palette entries are stored in reverse order.
Also, preceded by the plain-english string "CMAP". Color Map.
I was looking at an image file that I had tried loading into IrfanView years ago, and realized that I could just use "open as > raw" on one of the images that did work, get the correct width and height out of it, and see where those numbers showed up in the header.
And then I realized that a block of numbers was actually a palette-indexed image with 16 colors. And that all of the texture images are like that. So now I just have to figure out how color palettes are ordered.
[accidentally figures out the first few steps of reading a PS1 texture format from some obscure game] Oh okay, well fuck me then.
There's also the whole issue of like... even if I *could* figure out how a file format is structured, I'd still have to learn how to program a tool (outside of Unity/Gamemaker) that could actually convert PS1 files into PC-readable formats.
Still tempted though. Maybe just pick away at it on the side.
I'd honestly love to learn how to read actual PS1 file formats for a few games. It's such an involved process though - developers kept rolling their own tools and headers, so almost everything has to be approached on a game-by-game basis. There's no "one size fits all" solution for converting PS1 images/models.
I found out last night that SCEE made a tool to assist development of PocketStation save file headers, in binary and assembly formats. The binary is useable as-is — open in a hex editor and copy/paste into an existing save file.
Tool works on W10, too!
It's an invisible feature that definitely won't be useful anywhere, BUT it adds a tiny layer of movement predictability, so in it goes!!
Skidding locks the player to the nearest position on an 8x8 grid, but tries to make sure that it can travel a minimum eight pixels before it snaps.
If a direction is held while skidding, the player will launch full speed in the new direction. If not, player will come to a dead stop. Jumping can cancel out of the skid completely.
Quickly studied the camera in Kirby's Adventure, and I'm surprised to find that its follow window is effectively a 32×32 pixel square — off-center by 16px left & 32px up.
The only reason why Kirby travels outside the square is because the majority of its rooms only scroll along one axis, horizontal or vertical.
Audio/visual artist, tip-toeing haphazardly into gamedev. Follow me on my journey as I break all the things. 💪🦊✨
Cis, He/Him! 🌹
Mastodon server focused on game development and related topics.