there were 2 logical issues which caused reproducible misbehaviour.
for example when starting up pokemon soulsilver, one can click away
the intro, but it's not possible to click on the "load savegame"
icon.
the issues were:
1) failure to record whether the down event has been
passed to the emulator before abandoning it and turning it into
a click event (on a fast click, both events would happen during
the same SDL_Pollevent loop), and
2) mouse coordinates were discarded and unless the mouse down
event was registered. that means if the down and up events happen
on the exact same coordinate, the .x and .y of the mouse weren't
updated at all.
this is probably helpful for frontends other than cli that have to repaint
and react on events in the user interface, so they can set a timeout like
100 ms, or simply poll whether the stub is active using timeout 0.
the emulator thread was consuming 100% cpu even when the debugger was
active and execution paused.
a second pipe was added to gdb stub, which allows communication in
direction stub -> emulator/frontend, and also to infinitely block
in the frontend until the debugger returns control, for example
by typing "c" (continue) in gdb.
the other frontends use an inefficient method of running usleep(1000)
or similar in a loop, which will cause high cpu usage too, albeit not
a full 100% but more like 10-20%.
in order not to fill up the pipe with data for frontends that don't use
this mechanism, the functionality needs to be explicitly enabled.
(see functions added to gdbstub.h)
the functions added could in theory also be used to communicate
other data to the frontend, and optimally even replace all the locking
between the 2 sides.
- It's a regression from commit 4578728. I'm suspecting that this particular buffer is to be read as 32-bit since all of the other Linux frontends explicitly used 16-bit except for this one.
- Added some additional comments so that I'm not tempted to change the native line tracking paradigm ever again.
- Do some refactoring to make GPUEngineBase::_targetDisplay handle more buffer associations itself instead of relying on GPUEngineBase's copies of the associations.
- For purposes of maintaining a record and make for easier reversions, the code has NOT been fully optimized or cleaned up. This will happen over a period of time as the code settles down through testing.
- All "native" buffers are no longer assumed to be in any color space and are now assumed to always be 15-bit. The native buffers are now referenced using uint16_t pointers and are now suffixed with "16" in order to reflect this change.
- Of note, all clients that reference masterNativeBuffer or nativeBuffer via NDSDisplayInfo must now assume that these native buffers will always be in the 16-bit color space.
- Any 18-bit and 24-bit rendering now happens in the custom buffers.
- Also fixes a bug in PixelOperation_SSE2::_unknownEffectMask32() that would cause 3D layers to appear black if the user was running 15-bit color mode. (Regression from commit 0db9872.)
- This fix has the side effect of greatly increasing the code size.
- Quick testing shows that this fix increases overall graphics performance by 2% - 3%. But is this small performance gain worth the massive increase in code size? Hmmm....
- In practice, no games seemed to be affected by this bug, but even so, this fix is correct.
- While technically unnecessary, when the index is singly incremented, it's better to hard reset an overrunning index to zero in order to improve the theoretical stability of the code.
- Byte swapping can now be independently controlled for both input and output data.
- As an application to this new API, VRAM display mode now shows the correct colors on big-endian systems.
rofl0r