A More Techincal Explanation of the ADND Collision Viewing

This will be a bit more of a technical explication behind the collision viewer. A more general explanation can be found here: https://pastebin.com/rNLEssw7

OoT always has the collision mesh loaded for the entire scene. Each polygon is a triangle. Each polygon has the following properties stored in the mesh: coordinates for all 3 of the vertices, a fixed point representation of the normal vector, and a polygon type that gives it the various properties (climbability / voiding / walking sound / loading zone / etc ...). More information can be found here: http://wiki.cloudmodding.com/oot/Collision_Format_(Scenes)

For this script, the scene's mesh is parsed to generate a list of triangles. Only the 3 vertices are stored, all other information is disregarded. A random color is chosen for each vertex of each triangle, and vertex shading is used to color the whole triangle. The triangle is then drawn with with both the forward and backwards orientation. This was chosen to get around the backface culling of the game without actually disabling it, potentially making the rest of the rendering of the scene unrecognizable.

To actually draw these triangles, a display list is generated at for these custom triangles at in memory for the n64 expansion pack (this way as to not affect OoT, specifically to reduce the potential of desyncing the TAS from a clean version). Then a branch command is appended to the main display list buffer for the frame currently being constructed.

The way this was done was using the breakpoint callback in bizhawk's lua scripting system. The advantage of choosing this was it allows the custom list to be appended every frame and drawn (specifically a write breakpoint callback on link's x-coordinate ). Attempting to just do it between every 2 emu.frameadvance() will cause the custom display list to not be called every frame (I still need to look into why this happens). While these function callbacks removes the flickering issue, it has 2 main disadvantages. The first is that breakpoint callback system is broken in recent versions of bizhawk. The other disadvantage is that the callback system is implemented purely in bizhawk's lua system, instead of using the mupen core's native callback system. This causes the emulator to slow down to at most 5 fps. When being used for TASing this isn't an issue, but for encoding or testing this can be an issue.