Mzxrules: Mzxrules moved page Lee's graph alloc notes to Notes/Lee's graph alloc notes without leaving a redirect

2016-06-18T21:31:24Z

Mzxrules moved page Lee's graph alloc notes to Notes/Lee's graph alloc notes without leaving a redirect

Vexiant: Created page with "''graph_alloc expansion talk with Lee'' 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..."

2015-11-22T03:25:06Z

Created page with "''graph_alloc expansion talk with Lee'' 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..."

New page

''graph_alloc expansion talk with Lee''

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.

[https://github.com/lf94/ootter otter - (Rudimentary Ocarina of Time Terminal)]

[[Category:Notes]]

← Older revision	Revision as of 21:31, 18 June 2016
(No difference)

Notes/Lee's graph alloc notes - Revision history

Mzxrules: Mzxrules moved page Lee's graph alloc notes to Notes/Lee's graph alloc notes without leaving a redirect

Vexiant: Created page with "''graph_alloc expansion talk with Lee'' 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..."