This, my fellow GOG user, is the kind of very good answer that has the power to make the one getting it feel incredibly stupid.
I'm going to lie down for a few hours, now.

My response really wasn't intended to make you feel stupid.
I promise.

I don't believe you.
No one wields such powers, with such mastery, by accident.

Not that it really matters. But the whole 8-bit, 16-bit thing has been confused historically. It was a reference to the console's CPU not its graphics. It really did not have to do with tile size of color bit depth.

Even the 16-bit SNES maxed out at 256 simultaneous colors (which is 8-bit graphics).

Cool there is a demo for this.

It says it uses DirectX 9. So it's very likely the engine is drawing quads whether they are aware of it or not.
What language and graphics API are you using?

OK, well that's not an approach I would have thought to do. Long ago I did render tiles using a 2D API. I can't say I've thought thru how best to do it in a modern API. But my first thought would be to construct the geometry for the entire map programmatically as a single mesh. Ideally you could place all the tile images on a single texture for that map (or that layer of the map)

So if I had a map 128x200 tiles big I'd call a function that took that width, height, and an array of indices that mapped an image to each tile. This function could return an array of vertices that were a quad for each tile and that included the texture coordinates as well. Since this would be done on loading the map there really would not be much in the way of calculations needed during rendering.

At that point I'm not sure what advantage there would be in not using the normal vertex/fragment shader stages to draw. Because as you say they are going to be very efficient at rendering with that pattern. But you may have reasons for doing things as you are.

And yeah I don't blame you using C. That would be my preference as well.

Will this cause issues with different screen resolutions and scaling?

The advantage in not using the normal vertex/fragment shader approach is that I don't have to set up the shaders. In other words, it's simpler to program.

Also, I'm wondering if blitting would be faster than going through the 3D pipeline if using a software renderer. (Might be interesting to test this at some point.)

(I've heard that at least one OpenGL driver will actually translate a blit function call into drawing a triangle pair and applying the texture.)

When you blit in OpenGL:
* You can change the size (on both axes independently, which means I have to do extra work to maintain the aspect ration). As a result, it will be scaled to the needed resolution. I believe you can specify a filter, like GL_NEAREST (good for pixel art) or GL_LINEAR (for smoother graphics styles).
* You can even flip the image, which is useful because OpenGL's coordinate system is different from what I'd expect for computer graphics (and I believe is different from what some other graphics APIs use).

(The current tileset being used is actually an old BIOS font that I converted via script. Saves me having to actually do any art.)

I believe you are mistaken. The shaders for that would be trivial.

The shaders would be trivial, but there's still code that has to be written around the shaders. In particuar, the code needs to:
* Load the shader source code into memory (perhaps from disk, or they could be compiled into the bnary)
* Compile each shader stage
* Link the stages together to form a program
* Select the program as the one to be used
* Set up the VAO and VBO, as well as uniforms
* Then actually run the draw command

Granted, much of this I do need to do for the compute shader, but there I don't need the VAO/VBO, and I only need one shader stage. Also, I can make the VAO and VBO empty, instead computing the vertex coordinates on the fly in the shader (or just hardcoding them in; there's only 3 or 4 of them, anyway), which does simplify things a bit.

This amounts to a fair number of lines of OpenGL, and I believe the situation in Vulkan is even worse in terms of the number of lines of code that needs to be written.

OK. Using a compute shader which isn't really intended for drawing rather than what actually is intended for drawing seems a questionable choice to me but I won't try and convince you otherwise.

I'll just point out that if you really wanted to reduce the amount of code you write you may wish to look into using a library like https://www.libsdl.org/ which would give you a lot of power and compatibility w/ much less effort.

There is one particular characteristic of compute shaders that happens to fit the problem of drawing a tilemap on the screen.

When writing a compute shader, you define what's known as a workgroup, and in particular specify the workgroup size. This size has 3 dimensions, though it's possible for some of them to be 1, so I can, say, effectively have my workgroups be 2D. In particular, I can have each workgroup be the size of one tile.

Now, in the shader code itself, I have three integer vector variables that I can use:
* The global invocation ID, which here corresponds to a single pixel of the texture I'm rendering to
* The workgroup ID, which corresponds to the particular tile on the screen, and I can use it to index into what I call the nametable (terminology taken from the NES development community), to determine which tile to draw here (note that each workgroup draws one tile)
* The local invocation ID, which corresponds to the pixel chosen from the particular tile being drawn.
* Also, note that these IDs are all integers, which feels natural when you're working with tilemaps and pixel art.

It just happens that this maps *so well* to the problem of drawing a tilemap.

Doing this rendering with a vertex and fragment shader is possible, but I would have to:
* Do some conversion from floating point normalized coordinates to the integer coordinates I want (though there appears to at least get the pixel coordinates in the fragment shader)
* Do some math to convert it to the values corresponding to the workgroup and local invocation IDs. (This involves doing an integer division and using both the quotient and remainder; unfortunately GLSL doesn't seem to have a way to get both in one operation.)
* Still need that vertex shader as well, though at least that shader would be trivial in this instance.

As for SDL, I actually do use it, for creating the window, getting the OpenGL context to use, and handle input. Thing is, I could use it for the graphics drawing, but I wouldn't get hardware acceleration for the calculations (plus I find it fun to figure out how to do this stuff on the GPU). The way this would work would be something like this:
* What the compute shader is currently doing would be done in software. (It's possible to lock the surface/texture for this purpose, and write to the pixels directly.)
* Have SDL handle upscaling the image.

OK. Well I hope it goes well.