Post
by DRW » Tue Sep 10, 2019 1:37 am
I would only use one-dimensional arrays for NES programming. This makes it clearer what's going on below.
The advantage that a two-dimensional array only has single-byte indices is not really an advantage. Because for the compiler, it's all just one long stripe of data. (No, a two-dimensional array is not a pointer to pointer.)
So, the access: array[y][x] still amounts to &(array[0]) + (y * width + x). Which means the compiler does an int-based calculation anyway.
Performance-wise, both should end up identical. (I'm not sure, though. You should test it out.)
But as I said, with a one-dimensional array, you see more directly what's going on.
For example, the index calculation y * width + x is only fast because your width is a potency of 2. That's why the compiler can convert this into a bit shift: (y * 32) == (y << 5)
If your array was 30 x 30, then the compiler really had to start doing multiplication which is slow. And in this case, a one-dimensional array potentially lets you find the slowness faster. Because accessing with array[y][x] might not clue you why the code is so slow. But in array[y * 30 + x] you see: "Oh, right, I'm using a multiplication."
But yeah, for such a big playfield, you have no choice but to use an array with an int-based index.
That's why the granularity of a single screen in my current game is only 16 x 15 items, i.e. the smallest background object, including destroyable objects, can only be 16 x 16 pixels, not 8 x 8 pixels. This way, I have an array of 240 entires for the background status and can easily use a byte index.
By the way, the playfield on the NES for a non-scrolling screen is only 32 x 30, not 32 x 32.