a surprisingly large part of my enjoyment of retroprogramming is that they are the only ones who say "blit" with any frequency.
I love that work. Love me a good blit. I can even get by on a Blt, like a WinGStretchBlt, to randomly name an API from 30 years ago.
retroprogramming lets me enter a time when blits were a thick forest, instead of the paved subdivision that remains, where the blits are few and far between.
I currently have a file on my computer that I wrote this week called FooneBlit. It's 60 lines of low-level x86 assembly.
Why would anyone write such a thing in 2024?
We've got high level languages and GPUs and such, you don't even have to know x86 assembly! You can program high-tech 3D graphics game and write it in that old language that used to only be used for setting the window titlebar for your geocities page! You can program a whole game and not write a line of code, with visual blueprints!
so why write 32bit x86 assembly in 2024?
Simple: For love of the blit!
I'm writing code to intercept the game's blits and reroute them to my own custom blit subroutines that modify the arguments and call different underlying graphics calls.
There's blits inside blits. detoured blits. blit patches. I had to move the blit code from one assembler to another, for more efficient blitting.
You go to modern graphics and your low level is triangles, not blits. And yo'u're probably not that low level, not anywhere near it: your low level are game objects with their own shaders and lighting engines and layers and such.
which is neat and can make some neat games and can be fun, but sometimes you just want to blit
and that's one nice thing about hacking on software from the 90s:
so many blits.
I own books with entire chapters dedicated to documenting how the blits in Doom and Wolfenstein 3D worked, because they were groundbreaking and clever and a huge part or why those games were so successful: they took great use of the hardware to maximize their performance, in a genre where fast action really mattered.
@foone Last week I moved the common sprite/frame drawing code in my Dune project into a package called `blit`. It felt good.
actually one of my first big C projects (after a Super Mario Bros 1 pseuoleveleditor) was a port of Doom to Windows, using the Allegro toolkit. I recall a lot of that work was hooking up different blits to different parts of allegro.
because Doom needs multiple blits, as it draws the weapon, walls, ceiling+floors, enemies, text, and statusbar in different and complicated ways!
I believe there's at least two different image formats in use in Doom and they differ on if they're stored in horizontal-then-vertical rectangles or vertical-than-horizontal.
So parts of the screen are drawn horizontally and parts are drawn vertically.
Fabien Sanglard (who wrote the two books I'm talking about) made a page that explains (And shows!) how doom renders:
https://fabiensanglard.net/doomIphone/doomClassicRenderer.php
@foone I was an Amiga kid growing up and even though low level programming was mostly beyond me at the time I recall reading about the Amiga's awesome "Blitter" chip that allowed it to keep up with DOS PCs for 2D gaming even a decade after it was otherwise obsolete
@nicklockwood yeah. Don't get me wrong, I love DOS games, but we went HOW LONG without a blitter? Are you kidding me?
This DOS gaming world could have been so much more amazing if it was easier to make it run fast, like putting a blitter in. like consoles have had for years and years, PC!
@foone the wingdi function BitBlt is honestly the pinnacle of function naming, and all programming names since then can only aspire to someday reach that level again
@phlip it's true. as much as I prefer when they spell it out as "blit", for BitBlt it works, because it makes it match the length of the "Bit", for a nice symmetrical name