Pitch is the offset between the start of consecutive rows of pixels in the image, used to convert y coordinates into the start of any given row, so you access a pixel as buffer[y*pitch+x]. Often this is the image width, but can be greater depending on required alignment.
So at the end of each run increment the relevant pointer by (pitch - w) not pitch which I'm sure it's one of the bugs they saw all the time in this interview :)
Some of my earliest programming exposure was a dBASE IV book my dad had for work, though it was some time before I put any of it into action. At that time I was reading manuals like fiction, only slowly realizing that I could actually use some of it with our computer.
It was still an extremely exciting period of time that everyone was enjoying at the time. Mostly because it was augmenting existing friendships rather than replacing them with algorithmic content.
> Or you do not consider MUL/DIV "arithmetic", or something.
Multiplier and divider are usually not considered part of the ALU, yes. Not uncommon for those to be shared between execution threads while there's an ALU for each.
Even on NES a lot of games use CHR-RAM so arbitrary bitmaps are at least possible, though only a small part of the screen is unique without some rarely used mapper hardware. Zelda and Metroid mostly just use this to compress the graphics in ROM, Qix is a simple example with line drawing, Elite is an extreme one.
I made a demo of the Mystify screensaver using the typical 8KB CHR-RAM. Even with a lot of compromises it has pretty large borders to avoid running out of unique tiles. https://youtube.com/watch?v=1_MymcLeew8
Funny because I rewrote a bad port of dragons lair for a custom console with a tiny engine and huge dataset relatively, each frame having one "if press X goto frame Y" instruction.
reply