GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[Ami]

Hey! How can you tell how much memory is inside each level? I still playing around with the editor before really making my own map. I come to realize sometimes my level is empty and The graphics just goes crazy.

[SubDrag]

The editor can help you find out -mt. When visual editor is loaded, in visual editor menu, choose Visual->Calculate Live -mt from PJ64. Click Try to Find to find the virtual address. Then click Start or Grab Images. As you run around in the level, it will show you live -mt. You'll need to bump the final #. The rest of the settings though, you'll have to just mess with, like -ma, but I think you're hitting a -mt issue.

[Ami]

So then, it does not matter if I'm on Mupen? Also, does the size of the object matter or is it just the different amount of images?

[SubDrag]

I don't think it works on mupen, just pj64. The size of the object doesn't matter for -mt, just amount of total textures loaded. The size of object presumably plays a factor, but not into -mt.

[MultiplayerX]

Mt makes all the difference in a level loading as well. Some levels like Aztec and Silo seem to demand pretty high mt to render textures just right. Touchy too because setting them too high can make the level not load a
t all
_________________
[img]http://imgur.com/ud785Jq[/img]

[zoinkity]

mgfx and mvtx set the amount of memory the rooms use. Setting that higher avoids blackouts, like the ones common in Silo 4P. First of those sets the display list buffer, the second the vertex buffer.

mt does textures, and the nice thing is we can estimate the size of that. These are all the textures you can normally see and replace with the facemapper. There's another texture buffer that isn't affected by this though. The estimate is based on the images always loaded, then adding all the images used by the stage and all objects. I think it's in 0x400 clusters (would have to check the docs though).

I don't have a reference for ma handy, but that should be something like the total size of allocated memory. Could be anitquated, like the language memory allocations.

Objects, stage data, and all the generated tables of data go in whatever free memory remains. That's a lot harder to estimate the size of, which is very problematic since it's the largest chunk of data.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[AL64inthedark]

How do you think Rare decided the allocation back then ?

[zoinkity]

They fudged it. Basically, they started high, then increasingly lowered it until it stopped working.

To paraphrase Hollis, when they first submitted the final game for review the testers had it crash on them in a certain stage. He fiddled with one of the values a little, didn't bother testing it, then sent out a new copy.

There's also two debug features that (could) help with it. One displays bars on screen indicating allocated memory of certain types and memory usage.
Another needs a little hacking, but generates a text listing of all allocated memory, sizes, and locations. That isn't sent anywhere--even the stderr on-screen console--but would likely have been read off using the Indy and saved as text on PC.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[Trevor]

That would be nice to have that text one being sent to screen.

Ive been testing the bars one for ... well, lets just say Ive been using it.

Editor should be able to spit out largest DList since its just the max number of continuous commands isn't it?
I Know that DLists should be kept to groups of 32 or multiples thereof (64, 96...) for optimum performance. A group of 33 would be inefficient as the cache would require re-filling just for 1 command.

Again, VTX should be doable with editor, just count vertexes, store in counter and compare every room, if higher replace.

The editor basically should be able to automatically calculate all these memory requirements since it has all the information for them.

Even textures, Using texture size (rounded up to 64bit boundary), add together all in room and add to counter, loop for each room like vtx and if higher replace.
If anything this will give the absolute minimum.

Trev
_________________

[Ami]

Okay, so I found where I could raise the "MT". Also, can other levels that have high memory be put down to increase mine?

[SubDrag]

If you increase -mt, you need to lower the other values to compensate, since there is a finite amount of memory they all share.

[Ami]

So if I lower ones MT say, 50. Should I lower the others down to 50 to?

[SubDrag]

If you lower one, it gives you freedom to raise another. And vice versa.