Halo’s developers explain what can go wrong with unlocked framerates in old game ports

It’s also worth remembering that these kind of weird ass behaviors and bugs can occur on games  natively developed for PCs. Older games often have to cope with hardware that is faster than anyone imagined, and totally different from what the game was developed on.

A prime problem that comes to mind is the flying APC bug in MW3. On my older Pentium D machine, APCs would often fly up into the air and usually come back down. On my Core i5 machine: they never would come back down, or even be within targeting range most of the time. Which makes it hard to complete some of the early missions, lol. Today you require limiting the CPU speed and emulating a graphics card in software just to render it playable on modern hardware.

In fact, the game was old enough that when my eyes lit up at finding a copy of Mech Warrior 3: the next problem to solve was convincing the clerk to sell it to me because there was no returns welcomed, lol. I seem to recall Pentium 3s and Pentium IIs being high end processors around the time the game was released.

Microsoft shows off how containerized apps will work in Windows 10X

My interest in dual screen productivity to go, aside, I’m kind of interested to see where this goes. Most of the experiences I’ve had with containers in Linux, be out Docker, or building on top of chroot, have been a largely positive experience. Combine that container concept with the stability of the Win32 ABI, and there’s some viable good sides to this.

As software becomes increasingly long lived, the need to support software no one is ever going to recompile: keeps going up. Not to mention software that no one is ever going to port forward to more modern APIs and tool chains.

Things that remind me 16 GB of RAM isn’t enough for anything: when opening a nearly 1 gigabyte perf.data file in perf report, both takes forever and consumes ~92.5% of memory according to htop.

And somewhere along the way it exits with a message about being killed, and a toast pops up about my WiFi disconnecting. I’m sure the kernel OOM killer had a lot of fun.

Things I can blame on ninja: finally seeing what graphviz / dot files look like, in their textual form. Which is really neat! If you wanna generate a graph from a program, definitely look at graphviz and its various tools like dot.

Things I can blame on programmers: when “ninja -t graph | dot -Tpng -ograph.png” gives me a 50meg file that is over 18,000 x 32,000 pixels. Which is due to the size and complexity of the code base.

On a positive side, my part of the job was mainly getting it to build in a non broken way. Not writing software several times the size of Jurassic Park.

https://www.humblebundle.com/books/oreilly-classics-oreilly-books

While I can’t speak for the reference books, O’Reilly technical books are usually worth the money. Two on this list that I can vouch for are Programming Perl, as I own a hard copy of a previous edition, and Java in a Nutshell which is a rather good book for getting up to speed on the language.

I remember buying the Camel book for about $56 nearly a decade ago. Came for a means of thinking through the documentation that didn’t require alt+tab, stayed for the wonderful wit, anecdotes, and stories. If you’re serious about Perl, you probably should own a copy or three.

Java in a Nutshell, I had checked out from the public library over a decade ago wanting to brush up on how the language has evolved since my study, and really found its explanations wonderful. Especially if you’ve ever wondered why the answer to Generics in Java is so often no. The only Java  book on my shelf, by contrast was written while JDK had yet to reach a 1.0 release. Needless to say, I had needed updating, lol.

Captain’s log, stardate 2019.334

Misc thoughts from the holiday.

Despite how depressing my life might appear to some outsiders, I’m actually pretty happy. Thankful for the good things in my life, and hopeful that they stay that way. As the old prayer goes, “Grant me dexterity for things I cannot kill, Crit for things I can, And enough points in wisdom to know the difference”

Making reuben sandwiches reminded me just how damned delicious a good sandwich is. Didn’t find any cuban or rye bread when I went shopping, so I grabbed a loaf of Texas Toast in the hopes that it would at least hold up to the frying. Experiments in eating leftovers make me think, getting this again might be a good plan. It’s thick enough that I can actually pack a sandwich well, the kind my momma would make; without being as cost and space ineffective as a hoggy roll.

I might be a terrible human being if I’m inclined to share my sandwich with the doggos, and then threaten them with hugs as the price of giving me a “Hey, where’s the follow up treats?”. Or just a weirdo.  Yeah, I’m going with that last one.

Willow and Misty are definitely smarter than me when it comes to being comfortable.

Revising one of my old projects, I’ve come to two conclusions, well three but that’s another paragraph. First is when I do stuff at home: the working conditions are kind of brutal. A positive side of working on work stuff at work, is there is more encouragement to take micro breaks. You know, like drinking a cup of coffee or taking a piss. It’s very draining to code at home, and I’m not a seventeen year old kid no more.

The suffering of CMake while reviving one of my own projects, finally crossed the “Just live with it” point, and I spent my day making a really good start on a simple json -> build.ninja generator. It probably helps that C++ and I are long time companions, and that I’ve a high tendency of hand writing build.ninja files rather than using a tool to generate them.

And whoever the hell decided to wake the neighborhood up at 0400, better knock that shit off. My first thought was neighbor taking the family on a their own Vacation ’83, my second thought was wondering if they’re skipping town before rent’s due. In any case Corky and I didn’t enjoy the sleep disruption.

In spending the past week abusing myself with CMake, I think two things are fundamentally true and unlikely to ever change:

  1. CMake 3.16 beats the crap(!) out of 2.x.
  2. I will never, ever love CMake. Period.
On the positive side, in the years since it last pissed me off, they’ve added support for generating the build for Ninja—a tool which I do love very much. So at least, I get to solve my problem, and I don’t have to deal with MSBuild, NMake Makefiles, or Unix Makefiles. Although, I might have gained a few new grey hairs along the way. I very much would prefer the generated build did more actions in ninja than in cmake, for a multitude of reasons.
My hate for CMake 2.x mostly stems from its tendency to complicate my cross platform efforts rather than aid them. Quotes I’ve made over the years about autotools, often stem from dealing with either CMake or SCons.
My hate for CMake 3.x mostly stems from the nature of what it is: configure, generate, build shit; and consistency issues that follow that. Actually, it makes me remember the compile versus runtime stuff in Perl 5, and recall the times I’ve muttered: “Yeah, please just don’t !@#$ with that, pal.”
The difference there, is perl and I are old friends. CMake and I are old enemies. That, and I suppose these days the number of people that like the former outweigh the latter.

How Much of a Genius-Level Move Was Using Binary Space Partitioning in Doom?

I still remember the first time that I played Wolfenstein 3D. It was on a contemporary hardware, as a minigame in a far more recent Wolfenstein game. My first thought was how rudimentary simple it was; my second was “Holy crap, you could do this on a 286?”.

By modern definitions, I don’t think anyone would be thrilled by the limitations Id’s early engines had for map geometry. But I think for their times, it was a small price to pay given the hardware. And to be fair, as a kid, when I first played DooM ’93 on a Sega 32X^, I certainly didn’t notice. Years later when I would play it on a PC, I didn’t care—because it was still fun. All these years later, I still find DooM ’93 to be a lot of fun. That’s the real success of a video game, I’d say :P.

For the time, even the console ports were pretty impressive games. I mean, most of the games we had looked like this:

Meanwhile if you popped in DooM, this was what you got:

That just didn’t happen, lol.

Many times that I’ve read about porting PC games to the Super Nintendo, and other consoles, they’ve usually been stories that I would describe as “Lossy” or “Brutal” depending on the complexity gap. Such as when an arcade machine was far more powerful than a console, or a PC simply had more oompth than a console.

Id’s games were kind of revolutionary: both in their visual technology, and in their portability. Wolf 3D, DooM, and Quake were pretty widely ported during their era of commercial viability. Post open sourcing of their code, they have come to run on virtually everything, and anything. As technology has advanced, we’ve probably reached the point where it is no longer a surprise if your wrist watch is more powerful than many of the things DooM ’93 was ported to in the ’90s.

Today, I think that DooM’s use of BSP is somewhat novel. You should think of that today, or your hardware is probably so powerful compared to your goal: that you just don’t care. Given a decent computer science education, the concept isn’t the leap into rocket science. Today though, I imagine most people aren’t tasked with solving such a problem, because they live in the world John Carmack helped create: one where we have this thing called a Game Engine.

When Carmack programmed these games, I don’t think it was so obvious a technique. People were still struggling to make PCs do this kind of thing at all. Resources for learning these things have also changed a lot over time. Many of us have the advantage of knowledge built on the minds of geniuses, if we have any education at all—and the code.

Two of my favourite engines to read: are modern source ports of the Quake III: Arena and DooM engines. By releasing the code into the wild, I think it helped all of us learn better how to solve these problems. Both the things you can go off and learn, and the code you can get ahold of have evolved since these games were written. But thanks to games like DooM: it’s easier for us to do that today. Because technology is built upon what came before, by extending the ideas of others in new directions and taking advantage of improved hardware.

Genius isn’t in using a rock to smash something, it is in realizing you can smash things with a rock far better than your thick head.

^ Being around 25 years later, my brain cells are foggy. But DooM was one of my brother’s games, so the first thing we had that played that would probably have been the Sega Genesis, which AFAIK means 32X release. We also had the PlayStation versions of DooM, Final DooM, and Quake II but those were later in our childhood.

Random LOL

In porting an old multi-headed hydra, I found myself cackling.

Somewhere down in the beast’s HAL, is an utility function that returns the device name. This is what I found:
if (access(“normal device”, F_OK) == 0) {
    strcpy(devName, “normal device”);
} else if (access(“device not used in many years”, F_OK) == 0) {
    strcpy(“devName”, “device not used in many years“);
}
And in realizing why the stack trace was in such a simple function, I bust a gut when I noticed the quotes in the lower string copy. Ahh, the joys we inherit ^_^.