Uploaded October 2025 | Updated September 2026, 1 hour ago
This shows an edit to the angrylion-rdp-plus LLE graphics plugin to display the number of times a pixel in the framebuffer was accessed over the course of a frame.
This is a useful feature for developers as overdraw is a key metric to minimize to achieve good performance on N64; it can reveal where culling is not working correctly, where draw order is suboptimal, and where transparent primitives are covering more screen area than it would seem by just inspecting them visually.
This is a quick demo of running around in OoT in this visualization. Brighter patches indicate a higher density of access to those pixels. Red areas indicate very high densities of access.
Throughout the video I toggle between two modes, the first mode only shows the density of framebuffer writes while the second mode shows the density of all of framebuffer reads/writes and z-buffer reads/writes for each pixel.
Builds of the plugin can be found at
github.com/Thar0/angrylion-rdp-plus/releases/tag/overdraw-vis-rel1
This shows an edit to the angrylion-rdp-plus LLE graphics plugin to display the number of times a pixel in the framebuffer was accessed over the course of a frame.
This is a useful feature for developers as overdraw is a key metric to minimize to achieve good performance on N64; it can reveal where culling is not working correctly, where draw order is suboptimal, and where transparent primitives are covering more screen area than it would seem by just inspecting them visually.
This is a quick demo of running around in OoT in this visualization. Brighter patches indicate a higher density of access to those pixels. Red areas indicate very high densities of access.
Throughout the video I toggle between two modes, the first mode only shows the density of framebuffer writes while the second mode shows the density of all of framebuffer reads/writes and z-buffer reads/writes for each pixel.
Builds of the plugin can be found at
github.com/Thar0/angrylion-rdp-plus/releases/tag/overdraw-vis-rel1







![[Proof of Concept] ACE Void Warps
Here I show it is possible in the restricted setting of Darunia ACE that it is possible to warp to unintended scenes with very simple ACE. This takes advantage of the Zoneout variables in the games Save Context, the same values used by Void Warp.
The variable I modified here is the Zoneout Respawn Entrance Index (8011B948 on NTSC-1.0), a 2-byte value that stores the index into the entrance table of the scene to return you to when you void out. The value I set it to was 008D, a value for Twinrovas room, so when I void out it took me to Twinrovas room with the room number and coordinates of where I entered Goron City.
Since this makes use of Void Warp related values, similar restrictions apply. That is, void warping to a scene with a room number higher than one available on that scene will crash, and coordinates being bad may end up with you voiding out indefinitely upon arrival or getting stuck.
This is significantly easier than triggering a Wrong Warp, as the only value I strictly must edit is the Zoneout Respawn Entrance Index (but could also possibly modify the Room Number with some additional work) while for an ACE Wrong Warp you would have to modify the Next Entrance Index and the Warp Flag, and to play a Cutscene at your destination you must also modify the Cutscene Setter, which takes specific values FFF0 to FFFC to denote cutscenes 0-C.
As for the ACE process leading up to this, it is much the same as in Figs ACE video, however I shot a second deku seed to store the entrance I want to load as its y-rotation for ease of access. [Proof of Concept] ACE Void Warps](https://i.ytimg.com/vi/p736Py3W41E/mqdefault.jpg)


