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.
- This also discovers an existing issue with the fog weight calculation code in both OpenGL and SoftRasterizer, since Fog Shift could be zero and thereby cause the calculations to divide by zero. This issue will have to be dealt with at a later time.
- Also rework SoftRasterizerRenderer::_UpdateFogTable() to use the same variable naming scheme as OpenGL. This is done for better code consistency.
- In reality, I'm already looking to scrapping this algorithm in OpenGL for something that could be better in every possible way, but I want to commit this SoftRasterizer-esque algorithm first so that we have a working version of it on record.
rofl0r