The game has a name!

You may have noticed I’ve published this game under a very generic name: sgame. And no, that “s” does not stand for “special” or “spectacular”. It just means “space”. Amazing, I know.

This was always meant to be a temporary / internal name. I’ve done a similar thing with my previous game Way Home, which internally is just called “wizardgame”.

So, what is this games actual name you ask? It's Apus, named after a constellation.

I’ve also begun implementing some things to give everything a proper theme and feel. You can see the new title screen above (the old one was always intended as a placeholder as well), which goes for an oldschool NES like layout. There will be some additional flair later, but that will be the general look.

In addition, there even is a (very, very very) brief introductory cutscene now. The preview image here on itch.io is actually one frame of that. Go check it out :).

Even more texture mapping

While the last release improved texture mapping a lot, things still weren’t perfect. Especially with the software renderer. I still decided things are good enough, however. I figured textures don’t need to be perfect.

Until I implemented the credits, that is:

The credits are actually a 3D model consisting of a bunch of rectangles on a flat plane. Each one has a texture mapped onto it which actually contains the text.

What you see here is that mapping trashing perfectly fine text. This is a side-effect of the way I render polygons in combination with Q12 fixed-point arithmetic. In short: Things get super messy when a line begins on a slope due to arithmetic errors accumulating. You can actually see the effect with polygon borders drawn:

You will notice that the lower-left part mostly renders fine, while the upper right one is always broken.

The lower-left one is fine because rendering that line always starts at a precise value, with exact X/Y and U/V values. The upper-right one’s lines always start on a slope, where exact pixel values might be whatever. I would need to step U/V values exactly in unison while advancing X/Y (especially Y), but I can’t because Q12 values are just not precise enough.

So… what could one do against that? First, you could always implement triangle rendering using another algorithm. There certainly are other rendering algorithms. Even ones that take fixed-point imprecision into account! Second, you could acknowledge the flaw and work around it.

I’ve choosen the latter for now. Precise mapping is only needed (for now) when rendering text, which uses rectangles. These will always have a non-sloped edge. Things just fall apart when that edge is on the right. Sooooo… I now just render that line in reverse in that case in an attempt to always begin drawing on the non-sloped side.

This works way better!

Even more rendering bugs

Preparing the next release I always go through some basic testing. And, of course, something was amiss.

The license screen broke! But only on PSX and only for release builds. It also only happened on Mednafen. Other emulators where fine. Great.

Analyzing and isolating this took me forever. Things eventually boiled down to: This only happens if that disclaimer screen was shown long enough. I could replicate the same behavior in development builds (with development tools!). I initially suspected some form of memory corruption, but that wasn’t it. I also suspected some off-by-one in my texturing code. After all, this only affected paletted textures. My next candidates where some strange color mixing or maybe framebuffer masking mixup. Both are features of the PSX GPU that may be initialized wrong or something.

None of these got me anywhere. I eventually just manually changed the palette. Changing it in all image files did change the rendering. However, changing it in just one or just live when loading didn’t. It eventually came down to: If this one magic texture is ever rendered, textures after that will stick to it’s colors regardless of VRAM contents.

And then it struck me: Caches! The PSX’s GPU does use caching for textures and especially CLUTs (color look up tables, the PSX’s name for palettes). I was not interacting with the cache directly in any way until then, assuming the GPU would make sure to invalidate it’s cache lines on it’s own. But what if it doesn’t?

Boom! That was it. Apparently, Mednafen does emulate the CLUT cache.
I didn’t even know that! I have no idea if it actually emulates it
correctly, i.e. if real hardware would act the same in this
exact scenario. But it seems like invalidating the cache after
RAM->VRAM transfers would be a good idea anyways.

What’s missing?

Not that much, actually. I still haven’t come around to implementing more sound effects. Also music is entirely missing right now. And, of course, finalize and balance all levels and enemies (a lot of work is already done actually).

I hope to get most of that done during the next development cycle and conclude things with a final release after that.