Graph alloc expansion doc

From en64 wiki
Jump to navigation Jump to search

Ocarina of Time graph-alloc Expansion Worth it?

So OOT has a limitation for how many polygons it can have on the screen. It will start to complain internally and "throw away" actor animations and prevent more polygons from spawning.

This limitation prevented the OoTTer hack (a terminal overlaid in OOT) from using the entire screen.

So I took the liberty to find out how to force OOT to use more space for its graph_alloc function.

First step was to run OoTTer with 24 lines. When they've all printed the game enters the state I mentioned earlier. When you destroy things like pots, the game doesn't render the next N frames until graphic memory is available.

The game will internally start to print:

So I looked to see what function was calling this. It was the cache code that was calling it.

After a couple hours, I figured out the size of the caches: 64kb, plus some other stuff which makes it a total of 73kb. There is a huge problem though. The cache size, in the original OOT source code, is a flipping #define!!! So there is no easy way to change everything in the game without having to do it all by hand, changing everything that refers to those numbers.

The caches start at 0x801B41C0+0x12410 in RAM.
0x12410 is the constant I'm talking about.

They have identifiers for sanity checks in the code. The first cache has an id of 0x1234, and the second an id of 0x5678.

Important addresses: 0x800C38C0 <- returns true or false if the caches are full??, that is what I observed. Forcing it to return 0 all the time still made the game miss frames.

If you return from 0x800C38C0 you can see where the constant is calculated/defined and the BEQ instructions that do the sanity checks for 0x1234 and 0x5678.

CONCLUSION: Plausible, but waste of time.