@fery65 quel intérêt un recalbox en 64bits quand quasi rien n'est pensé en 64bits ? Ca consommera plus de RAM (ce qui ne nous arrange pas), et on va perdre une partie du code optimisé en assembleur armv7 (qui n'est pas compatible armv8, le mode 64bits)
Sprite flicker isn't a performance issue, it's an issue with the capability of the NES. The PPU (Picture Processing Unit) had some serious sprite limitations. There's a maximum of 64 sprites that can be stored in the chip, and there's a maximum of 8 sprites that can appear on a scanline at any given time. Horizontally let's assume that a player sprite took up two sprites on a given scanline--this is usually the case if the PC was a human because they would need legs to move one at a time--that means that there were only 6 sprites left for the scanlines taken by the PC. Game developers were very aware of this and tried what they could to limit enemy sprites as well as shuffling the order of sprites on display. This way for any given frame there are a random assortment of invisible sprites, instead of specific sprites always being invisible, shuffling allows it to be relatively unnoticable. However issues arise in situations where something would normally look smooth like Mario letting loose a turtle shell to take out three Goombas, the screen can't process the shell sliding and the Goombas flying off the screen each frame so it appears to be blinking and stuttering.
When emulating the NES system the emulator is to perform in ways identical to the original system, meaning that although it has everything that made the system great, it will also contain in it the same flaws the original had.