First of all, that section of code has changed in the latest releases, so what you have above is a little out of date.
Anyway, I don't want to get too
deep into this, since it can quickly get very complicated. This is the order of processing:
- Controller is read from the host in EventHandler::poll()
- Results from actual controllers are cached in virtual Controller objects (ie, in myDigitalPinState andmyAnalogPinValue)
- Various M6532::update() method is called at the end of EventHandler::poll(), which processes the arrays above
In the current code, the controller update() methods are already moved inside M6532. I'm not sure it will fix the problem you're seeing, though, since a 'read' from a virtual controller is just returning cached data in the various arrays. The main problem is that at that point in time, there may be new controller data potentially coming in from the host system, but it will be done in EventHandler::poll(), and that's not where we are right now
. So the issue is one of timing, and the ordering of doing the operations.
Perhaps a timeline would help explain. Consider the current algorithm in more detail:
1. Read actual controllers from host in EventHandler::poll()
1. Poll system
2. Call 6532::update(), which processes/caches the events from reading the controllers into the various virtual controller arrays
2. Update framebuffer (a full frame, consisting of multiple scanlines), by running the CPU an appropriate amount of time
1. At some point during the run, the ROM will read from 6532 to get controller state; it gets the cached info instead
So the problem is that by the time we're at 2.1 and wanting controller info, you're going to get the cached version. But you might be moving the paddle in real-time at that point
, and that info won't be available until the next frame.
This is the push method, since the controllers are polled up-front, the results cached, and pushed
to the objects that need them. The other option is the pull
method, where the controller polling (part 1.1) is put directly inside part 2.1. IOW, the 6532 pulls/requests the info when necessary
. But this creates other issues I won't get into right now.
Finally, I'm not entirely convinced any of this will make a difference at all. AFAICT, there are at least 3 things happening, and all could contribute to lag:
- The Stelladaptor/2600-daptor itself might have internal buffering, as it's polling and sending data over USB. This cannot be fixed in Stella at all.
- Once the OS reads the controller, it might have buffering too, in that the event is placed in a queue or something, and not available right away (again, nothing Stella can do about it).
- Once Stella actually gets the event, it has it cached/buffered too. This may be somewhat fixable.
- If you're using the mouse to emulate the paddle, the emulation itself might not be exact. Again, this may be fixable.
I'm not saying it's a lost cause and there's no room for improvement, but there are some major obstacles to overcome. In the first 2 cases, it can't be fixed. For the third case, it involves a complete reworking of event handing. The 4th is probably the easiest, but doesn't address your specific issue.
This is all a consequence of emulating an extremely simple console on a multi-tasking operating system with many levels of software. The 2600 console was extremely simple in that pressing a joystick direction literally grounded the input, and the 6532 was connected directly to that input line. A modern OS is much