Lollie (Gamedev) @Lollie@mastodon.gamedev.place

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.
https://www.youtube.com/watch?v=ouIGHt2LBro

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'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!!

Having a quick look at one-way platforms before bed, and... Oh no. That can't be good for his neck.

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.

Been working on a little something, and it's slowly coming together! Here's me running, skidding, and jumping around.

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.

Preparing for take-off!! 🦊💨

First steps! Following a tutorial to get a feel for simple platforming in gamemaker *without* relying on its physics engine. No jump/fall sprites yet, I'll fix that eventually lol.

This is the gamedev equivalent of sticking my hand into a running shower to check water temperature, but what I'm doing is checking that child objects work as expected. Only the body has move code attached, the tail inherits everything.

It's worth noting that this isn't like Unity, where a child object is physically nested inside it's parent. In GameMaker, the parent doesn't need to be present, the child will simply behave the same - unless it is told to override specific events.