Last year I was dealing with an optimizing compiler that went berzerk, and when I tried writing it up without using that informal vocabulary I found that this improved neither clarity nor concision.

As part of my current #retrocomputing projects I'm playing around a bit with the 8-bit Sega systems. The "Master System" that competed with the NES was MUCH more powerful than I was expecting. 16 colors per tile and the full EGA palette to choose from? I can fit the whole Progress Pride flag in here

One big advantage the NES still has, though, is that it can pack 4 colors into an 8x8 pixel square, while (at this resolution) the C64 can only manage two. That's why we couldn't do the drop shadow or the rivets up there.

...or could we?

More recently, I decided to push the implementation to get as close as I could to the NES version while keeping the simpler and easier keyboard controls. Take One wasn't bad at all:

I revisited it a bit later on, and it did end up nicer that time, though there are definitely still some glaring gaps between it and the NES version.

The C64 was my *first* attempt and it just made use of the default text capabiltiies. A far cry from the NES, despite the two systems releasing only a year apart!

The most recent edition, though, was for the NES and I tried to lean as hard into its aesthetic as I could. (Here and throughout the thread, alt-text will be describing elements of interest and should be understood as part of the story here.)

Just sayin'...

That means that there's nothing stopping you from just having a single sprite take up the *entire height of the screen.* There's only so much you can do with that when it's 8 pixels wide, but it's not nothing... 8/

But around the time that, say, The Legend of Zelda comes out, a body of knowledge had developed that would let you combine its capabilities in more sophisticated ways, changing every scanline and combining to produce accents and background elements as well as the actual gameplay screens. 6/

That's pretty tight timing, so lots of games only did that every 2 or 4 lines, giving you blocky graphics like in Combat. 5/

I've been meaning to do a #retrocomputing thread for awhile. So let's talk sprites!

Old-school screens were generally text grids. Some machines could draw movable objects on top. TI engineers named them "sprites" because they floated over the text like pixies, sprites, or, well, butterflies. 1/

Relax, it's fine.

It's tradition.

But you can mix and match them *completely* freely, at no cost to the CPU, because "stack of mode lines, and some chunks of memory for screen contents" is just what its graphics chip consumed directly! I played with this awhile back, with a low-res graphics display bracketed by high-res text.

Goofy little thing here. I had some tricky 6502 code I didn't want to try to wrangle in a debugger, so instead I built a tiny visualizer on the #C64 and ran the loop at 5% normal speed. That was enough to observe what I needed to with the good old Mark 1 Eyeball.

#retrocomputing

Digging through my old birdsite archive, I found this funny little hack I made. Back when Mario X Rabbids first came out and was described to me as "It's a Mario X-COM game", I was moved to immediately hit up the game-mod wikis to see how to edit text and graphics in the original DOS X-COM.

Behold:

Can't believe I'm the first to cite Solstice, but I am here to carry out this duty.