I've been warming myself up to hex-editing and tinkering with PS1 stuff, because I'm a big gay dork who can't leave an idea alone!!
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.
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.
[accidentally figures out the first few steps of reading a PS1 texture format from some obscure game] Oh okay, well fuck me then.
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.
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.
https://www.youtube.com/watch?v=ouIGHt2LBro
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!
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
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. 🤔
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.