BinaryLab
New member
I have a learning (technical) question, and I don't know exactly which topic to place it into, in the forums. I'm trying to understand a specific loop related to vBlank and gamePad reading.
In the MainASM.asm file, at the MainGameLoop, we have these lines
MainGameLoop:
JSR GamePadCheck
LDA vBlankTimer
vBlankTimerLoop:
CMP vBlankTimer
BEQ vBlankTimerLoop
Here's how I read this: we update the gamepad variable with input reads for this frame and wait for vBlank (which is updated by an interrupt) until we proceed. After this comes everything else. My question is:
Does this mean that we are using screen-rendering time to read inputs?
Since my objective is to implement a DPCM-safe version of input reading, so I'm digging deeper into the GameEngine. I have two options:
1) Read it twice and keep repeating until two consecutive readings agree. This introduce lag (which should be unnoticeable, but it is lag nevertheless) and has the probability to ignore real inputs if they change between reads.
2) Implement an even-cycle reading procedure which uses the OAM-DMA instructions to start an odd-even cycle counter. However, this can't be done during screen rendering or else the procedure would mess up the screen.
So, if anyone could confirm this, I would be happy to proceed with the implementation =)
In the MainASM.asm file, at the MainGameLoop, we have these lines
MainGameLoop:
JSR GamePadCheck
LDA vBlankTimer
vBlankTimerLoop:
CMP vBlankTimer
BEQ vBlankTimerLoop
Here's how I read this: we update the gamepad variable with input reads for this frame and wait for vBlank (which is updated by an interrupt) until we proceed. After this comes everything else. My question is:
Does this mean that we are using screen-rendering time to read inputs?
Since my objective is to implement a DPCM-safe version of input reading, so I'm digging deeper into the GameEngine. I have two options:
1) Read it twice and keep repeating until two consecutive readings agree. This introduce lag (which should be unnoticeable, but it is lag nevertheless) and has the probability to ignore real inputs if they change between reads.
2) Implement an even-cycle reading procedure which uses the OAM-DMA instructions to start an odd-even cycle counter. However, this can't be done during screen rendering or else the procedure would mess up the screen.
So, if anyone could confirm this, I would be happy to proceed with the implementation =)