Back in the days, if you wanted square pixels in your games you had to either switch to 640×480 with only 16 colors or use Mode X, which offered 320×240 with all 256 colors but both of these stored their pixel data in those funky non-packed or non-linear formats.
Sure. Sure. With Mode X you could write a whole bunch of pixels at once. It’s a trade-off, and one that I’d rather not have to make. Give me linear frame buffers or give me death!
But what if there was a third option? Turns out on DOSBox’s approximation of the S3, mode 151h offers 320×240 pixels in 256 colors! Besides the need to switch memory windows to access the bottom 36-something lines, that’s as friendly to work with as anything! And if, unlike me, you write DOS games in 32 bits, even that shouldn’t be a problem!
Too bad whatever VirtualBox exposes on my system doesn’t include one of those — it has no 320×240 at all.
As a bonus for sticking with me for this tomfoolery, here’s DOSBox running a test of mine.
Makes me think, if you were designing a Hebrew computer, would it have right-to-left frame buffers?
Of course not. If it’s a frame buffer, you get per-pixel addressing. That means you got to render your characters by hand to begin with.
Now, the coordinate system is another issue altogether. There’s no rule that says the top-left corner must map to the lowest memory address — that every single video card for personal computers that I can think of did that just makes it a de facto rule.
I’m suddenly reminded of the tile map layout in Pac-Man, where the bottom strip with the level icons and lives counter is stored first in RTL, then the playfield goes TTB-RTL, then the top strip with the score counter goes RTL again: https://www.youtube.com/watch?v=NKKfW8X9uYk