Closed DarioSamo closed 2 years ago
1) Older versions of sm64rt would store a global mesh cache and go to that whenever they wanted to pull a mesh from it. 2) Newer versions of sm64rt use a display-list specific mesh cache instead. This works fine as long as a UID is defined, but if no UID is defined (because it's hard to determine the UID for some reason), they all go into "Display List 0" and end up recreating the meshes pretty often. 3) Display List 0 is stuff that isn't interpolated. This is the Mario head and the UI at the moment. 4) The lag happens when stuff in display list 0 changes their mesh key, and must therefore be recreated. 5) This is usually the case when changing between options in menus and the Mario head. 6) For whatever reason, this operation takes an excessively long amount of time to do in non-RT hardware compared to RT hardware.
Possible solution: do not rely on the mesh index for stuff on display list 0 to be cached. Switch to a simpler model there (like the old system).
Regression seems to have happened in this commit in particular.
60aa0c5
Cannot reproduce it myself, as no slowdown appears to happen.
Currently being tested in
reg_test_2
branch.