[mthoms]

This is true.

I vaguely remember there was something about the VGA architecture of the day that made this approach much slower, but I might be misremembering. My recollection of it is fuzzy. I'm hoping someone will chime in to remind me what I might be thinking of.

It might also just have been that this approach didn't work well with my lookup table optimization (see my other post).

[bananaboy]

You might be thinking of unchained VGA modes but in unchained modes you want to draw columns because that means you only have to switch which memory plane is active four times instead of every four pixels, ie select plane 0, draw column 0, 4, 8, etc then select plane 1 and draw columns 1, 5, 9, etc etc

[mthoms]

This is what I was thinking of, thanks.

[lowbloodsugar]

I imagine that far map squares are more than one pixel wide so that read is amortized. Not so if going vertically.

[mthoms]

This was part of it as well. At least - as I recall - with the early flat (MarioCart 1 inspired) versions I made. But in that case, the closer "terrain" pixels always became multiple on-screen pixels so my lookup table for each of the 360 degree viewpoints contained only a single byte to add to each x and y coordinate, plus a single byte for each length.

Had to keep the memory use down and multiplication was really computationally expensive.