Closed Kautenja closed 4 years ago
To address 1, the palette data structure was changed from 32-bit to 8-bit. This allows the palette to be stored in RGBA format irrespective of the memory model of the architecture (little-endian vs big-endian). The palette is still accessed as a 32-bit in places for copying entire pixels. This is a sketchy thing to do because the values are actually byte arrays and don't conform to the standard notion of what a uint32_t value should represent. This should be addressed to make the code more clear and less sketchy.
The loops were also replaced with memset and memcpy.
message passing using flags will not work in this case because the frame rate is much slower than the audio rate. The copy to the module is necessary
[x] The module requires screen data to be stored in RGBA for NanoSVG to render. NanoSVG doesn't offer support for RGB, BGR, or BGRA formats, just RGBA. Is there a way to change the memory organization of the palette to be more nano SVG friendly? I.e., can the palette be reorganized such that switching color spaces is no longer necessary (i.e., removing the 2D loop over the screen).
[ ] In the audio pipeline, the module currently copies the screen every time an NES frame event occurs. This was implemented to remove the flickering effect that happens when the Widget directly renders the screen from the NES. This flickering is thought to be caused by concurrency between the widget and the module that is not properly synchronized. Is there a way to remove this additional copy, but also prevent the UI thread from rendering incorrectly?