ExpiredPopsicle @ExpiredPopsicle@mastodon.social

My inspiration after #magfest to work on this project is competing with the overwhelming juggernaut that is my technical debt.

Every time I come back to this project I'm like "I should tidy up this basic Makefile or switch to Autotools." and then I start doing it, and realize that it's going to take longer to do that (or rewrite it in another build system) because of dependencies I want to remove anyway.

I swear I've gone through this process at least 5 times now. Better finish migrating over to the new system and dropping the old dependencies before reworking the build, I guess.

It involved mismatched new/delete, which made hell with UE4's overloaded global new/delete. (In theory you should be able to replace those in a single TU and have it apply to everything in the linked binary, but somehow it only applied to like... half the std::* types?)

Wow this string function looks a lot like the one in my utilities lib I take from project to project... Oh. It *is* that function... Except it uses a different string type... Because I made a new string type... Because of an old bug in UE4's Linux build with std::string.

Dusting off an old project is like a form of archaeology.

FWIW I'm not using UE4 for this project anymore, but I think that bug in UE4 (or possibly in Clang itself) is long dead by now... I hope.

I'm going to take a break from the 486 for a bit to work on my other indie game, but I guess the next step is to start working on VRAM-to-VRAM copies via the latches, and then find clever ways to use my available VRAM.

Back to Michael Abrash's Black Book!

... where the cache would have run out of room like it did for the RAM.

Also, the VRAM write is slooooooooooow. It's nearly 2x the time of the non-cache-enabled RAM write from the last chart. There's no way around it. VRAM write time just sucks on this 486 with standard VGA.

Alright. Time for more 486DX2 charts. This time, it's RAM(+cache) timing against VRAM read/write.

This basically confirms what I read in the confusing spec document about writes to memory-mapped IO not going through the cache. Notice there's no bump at around 8kb on the VRAM...

Most of the gamedev circles I'm in are talking about Unity's disastrous license change today. A ton of questions about Godot popping up again. The open source hippie inside me is pleased.

And by that I don't mean that it's interesting that modern stuff is so much faster. That's obvious. It's interesting that the *difference* between RAM access and cache hits has stretched out to something so far apart compared to back then.

Interesting stuff to note: 1. strlen() is slower than everything else. Possibly because they're using different string repetition instructions (rep movsd, etc).
2. There's a bump in the runtime of the cache-enabled operations when it hits the 8kb cache limit (expected).
3. But the most interesting thing is that the difference the cache makes seems to be vastly less significant than on a modern CPU. We're talking factors of about 2-3 (486) vs. factors of hundreds (i7), here!

You know what's awesome about my 486DX2? I can turn the cache off in the BIOS settings. Now I can start to get a better view of just how the cache on this hardware is affecting my performance. Probably a somewhat flawed methodology here, but it's an interesting first-pass.

The talk by @flibitijibibo at the end of #magfest was really cool. It was a hell of a lot more info than I was expecting, and it was really fun to chat about Linux game stuff!

OMG! I won the #magfest demoparty workshop competition! Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

#magfest is amazing, but I feel like I'm bumping into some limit on social interaction that's hardcoded into my brain. It's exhausting and I definitely want to crawl into a hole and hide for the next month.

I'm flying out to #MAGFest tomorrow and I am so unprepared.

Looking forward to seeing all my east-coast friends, though.

I discovered a new bottleneck in my game code. Somehow the compiled sprite generation is more time consuming on the 486DX2 than loading a PCX from the disk. I know it was some unoptimized load-time code, but that still seems fishy.

Question is how the heck to I profile on a 486?

It's almost 2019 and I'm writing a ZSoft PCX loader from scratch and I would not have it any other way.

I finally got on that trans t-shirt meme. Took me long enough!

Love ya all. ❤

#mastoart

Somehow my 486 gained an IRQ conflict while it was in storage. Maybe the settings on the NIC got reset after sitting for two long?

It's all fixed now (and networked!) so I'm just about ready to dive back into Mode X stuff. Also implementing XM support in my MOD player.

I know I could just have been emulating the games, but I've also had this 2-month-long itch to get back into writing some Mode X support for my game, and that's going to need some performance testing on real hardware for accurate cycle timing, cache performance, and bus speed.