Commander X16

Ed Minchau wrote: ↑Wed Aug 07, 2024 11:06 pm I've been working on a 3d first person shooter as well (on the back burner while I rewrite the META/L editor). My advice is to do as much precalculation as possible, and as few calculations at runtime as possible. For instance, I have 8 banks set aside for a single lookup table to convert a 16 bit dot product into wall height at that distance, to avoid doing division at runtime.

I am looking forward to whatever you come up with. I remember there were some very innovative ideas in the Asteroid Commander series of videos you made a while back

Simplifications by restricting camera to 90 degree angles

Coming back to why restricting the camera to 90 degree angles is so good.
As I mentioned, all the faces of the blocks facing towards camera are part of a perfectly square lattice. That means that if I hop a vertex to the right on my lattice, the y coordinate doesn't change and when I hop one vertex down, the x coordinate doesn't change. What that means is that we don't need a large 3d->2d lookup table anymore, but we need two 2d->1d lookup tables. I think the biggest benefit of that isn't so much the reduced memory requirement, but rather that it may become faster to access the correct entries of this table.

Another benfit is that all the surfaces we have to render have either perfectly horizontal or perfectly vertical edges. For block surfaces parallel to the image plane, we don't need any polygon filler helper at all because it's as simple as filling a square. We still could use a helper for the other surfaces, but the fact that two of their edges are perfectly horizontal or vertical helps reduce the complexity of that.

Rendering order

(Note: as in the original Minecraft, here, a "chunk" refers to a slice of world data. In the original Minecraft a chunk is 16x16 blocks horizontally and maybe 256 blocks (?) vertically. In our case, it could be made a different size, of course)

As outlined in the first post, I think rendering from the front to the back is beneficial because it allows to easily exclude many surfaces from being rendered.

There's a catch with this: If we want this to work efficiently, the rendering order must be such that we NEVER have to overdraw something. In other words, we can only render something when we are absolutely sure that we have checked (and rendered) everything that could go in front of that object.
At first glance, this seems very restrictive on the order in which we have to check and render blocks. We have to go near to far, and from the center of the field of view to the outside because the block directly in front of us can partially cover up the one right next to it.

But that still leaves a lot of freedom. Yes, the block(s) directly in front of the camera always go first. But after that we can choose from multiple options. We can, for example, first render the central (vertical) slice of blocks we are standing in, then the entire left half of the field of view, and finally the entire right half. Or we could go from near to far, sweeping through the whole field of view at each distance.
Or a mixture of both.
We could render chunk by chunk. First the one we are standing in; and then we can choose: the chunk to the left, the chunk to the right, the chunk further back. Of course, within a chunk, we would have to adhere to the same rules as before: stuff near us gets the first go, then the stuff further away. You get the idea.

Rendering chunks individually eliminates the problem of having to quickly switch access between chunks during the process. I imagine one would have to switch banks and recalculate pointers and indices to switch chunks during rendering, so not having to do that is a big plus.


Choice of rendering order is good for one more reason:

Chunk data will be laid out in memory so that blocks which come directly after another either lie in north-south direction, or east-west. Not both. Because it doesn't really matter which way it is, let's say it's along north-south.
This will be the "fast" direction for iterating over blocks. Given the address of a block, it is very fast to calculate the address of the block to the north or to the south of it: you just add or subtract one, which is a very fast operation with the 6502's indexed addressing modes.
For the other direction, one would have to add or subtract 8 or 16 (whatever the size of the chunk is), which is significantly more expensive. So it would be neat if we could always iterate along the "fast" direction during rendering, irrespective of whether the camera pointed north-south or east-west.
Good thing we have the choice

The only problem I have with restricting views to 90° increments is that it becomes disorienting if it's done with no sort of transition. VotV is an example of this, though the technical achievement of writing a game like this in C is quite impressive.

So if you do use this kind of view restriction, might I recommend a couple of frames of the current view 'sliding' off screen and a couple of frames of the next view 'sliding' into place?