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

[Wreck]

I'm just wondering something. Does anybody know if GoldenEye can support 64x64 Colour Images? I only seem to be able to see grayscale textures at that size, and whenever I attempt to add a 64x64 Colour Image to the ROM, whatever is supposed to be using it crashes the game on load. Maybe the game can, but I'm doing something incorrectly?
_________________

YOUTUBE | TWITTER/X | FACEBOOK | VAULT | MOD DB | RHDN

[radorn]

The correct question may not be if GE supports them but whether the N64 supports them or not and under what conditions.

I can't assure this 100%, but the reason may be the N64's 4kb texture cache.
A single 64x64 8bpp texture (assuming 8bpp color, like the editor accepts) takes up the whole texture cache.

Now, that wouldn't be a problem if it wasn't because N64 games tend to make use of mip-mapping.
This means that, for each texture, several lower resolution copies are made, each halving the dimensions of it's parent. These copies take up almost as much as the original.
This means that the maximum resolution for a 8bpp texture in an N64 game with mip mapping enabled (like GE and PD are) would be 64x32, or 2kbytes, because the other half of the texture cache is used for the mip maps. Actually, only one third of the original texture's size is needed for mipmaps, but if we are to use only standard sized textures, it still inutilizates the other half for any other use.

http://en.wikipedia.org/wiki/Mipmap

There are many strangely sized textures in GE though. I guess Rare did a great optimization work to better use the limited texture cache.

For a little history insight, for those interested, the N64's "GPU" is a co-processor (plus other things), that works with something called microcode.
I don't yet grasp the concept of how microcode works or is used, but the basic idea is that a processor that can be "microprogrammed" can be made to work like a different computer.
Basically, for each different microcode, you get a processor that accepts different instructions and spits out different results. It's very flexible (and normally very difficult to work with)
Nintendo and SGI provided these microcodes, although, at the end of the N64's life, a some companies modified those to fit their needs and others even dared to program their own (famous example being the Indiana Jones game, not yet widely emulated because of this). GE and PD also use modified microcodes, I think, although not as radical of a change like Indy...

Apparently, Nintendo provided 2/3 basic microcodes from the start.
They have names but I can't remember them now.
Basically one provided visuals similar to playstation in that there was no texture filtering (pixelated graphics), mip mapping, antialiasing or any of that stuff. It's performance was, reportedly, very high.
It was meant for development only, because nintendo mandated that released games used microcodes with all the parafernalia. They wanted to differentiate from playstation and saturn.
I would like to see games using a "watered down" microcode and have bigger textures, higher frame counts, unfiltered stuff and so on.

EDIT: I was using my brains a bit, and thought that it would be interesting to test the following:
64x32 8bpp yields a 2048bytes texture + 682bytes for mipmaps. Roughly 1 third of the original texture's size.
N64's texture cache is 4096bytes. Dividing it in 2 parts that follow that proportion (1 + 1/3) we end up with 3k for texture and 1k for mipmaps.
Since we are dealing with 8bit pixels (1 byte per pixel), let us count pixels instead.
If you want to experiment with bigger than 64x32 textures, try to make textures that have 3072 pixels max, like, for example, 64x48 (3072), or 72x42 (3024). I'd say to keep dimensions at even numbers, but I have seen numbers like 17 and others in GE's textures, so it may be possible to make freeform textures...
Of course I have no idea how this will result, or if the editor or the game will accept those, but if you really need bigger textures it may be worth to try.

EDIT2: no replies? fsck-off xDD

[monkeyface]

You're crazy, that's all crazy talk. MIPs? Not in my house. Seriously though, I know what MIPs are and all, but the architecture of the N64 is way above my head so I can't really comment on this. If you get it to work, great, but I wont be giving you any insightful thoughts on the topic, other than "I like big pictures with colour".

[Wreck]

Sorry, I missed out on all your edits. The thread ended up getting knocked down the list and out of mind.

Hehe, I'm at about the same mental state as monkeyface. I know some of it, but not enough for the technical understanding. You may be onto something, though it'll require further testing.
_________________

YOUTUBE | TWITTER/X | FACEBOOK | VAULT | MOD DB | RHDN

[radorn]

In any hardware 3D renderer I know of, there's a "little" (relative) patch of very fast memory embedded into the processor, used to store the current in use texture. This is called the texture cache.

As with any hardware cache, it's meant to temporarily "mirror" some content of the main memory the processor needs to use. In this case this caches textures.
The purpose of doing this is because this memory is VERY fast as it's embedded into the processor's die and not in another chip.
Commonly the texture cache can only store 1 texture at a time, even if it doesn't fill it. Other system's could store more, but not the N64, I'm afraid.
The texture cache of the N64 is only 4kbytes, and with the use of mipmapping, only standard sized textures up to 64x32 can be used in 8bpp color mode can be used because (64x32x8)/8= 2048 bytes, which is half of the texture cache, and if we add one third more of the main texture, it means you can't use bigger standard sized textures.
With standard sized I'm refering to textures that have dimensions that are powers of 2:
2 4 8 16 32 64 128...

To possibly max out the texture cache's size we would need to try to make textures that are, AS MUCH, 3072 pixels in total, so there's still 1/3 of the main texture (3072/3=1024) free for mip maps and the total doesn't exceed the texcache size (3072+1024=4096).

The best that could happen if the texture cache is exceeded is that, at certain distances, where the lower resolution mipmaps are used, things looked corrupted because that part of the texture could not be found.
But I don't know what happens with the RCP (or Goldeneye's microcode for the RCP in this case) if it can't properly read the texture cache.
In Wreck's experience, it crashes... well, that pretty much settles it, doesn't it? xD.

So, try to make a texture that is 3072 pixels max and let's see what
happens.

Actually, it may be a good idea to lower that size a bit because in my calculations, for a 64x48 texture (3072 extactly) texture, the smallest mip map is only 3 bytes/pixels (1x3? xD), and I don't know how the scaling would be done in that case...

Now all of this make me wonder something.
We know these mipmaps are precalculated since that's their very nature, but... WHEN are they calculated? I can think of 2 possibilities:
Either when the game is compiled, and so are stored statically in the ROM, or at some point during a stage load; that is, while these textures are copied into RAM.
SubDrag, does the texture importer in the GE Editor calculate mipmaps, or even, are mipmaps to be found in the ROM alongside the original textures?

[SubDrag]

Uhhh isn't that done by hardware?

[radorn]

yeah, mip mapping is a hardware feature since the hardware must be aware that a given texture in memory will consist of a number of mip-maps (fullsize and downsampled versions), but the downsampled versions are not calculated at render time. They are precalculated at some point and stored in memory and then, once everything is running, the renderer selects which mipmap to use depending on distance (or whatever other factor the programmers have decided on).

I was just wondering at what point these mipmaps are generated.
If they are generated at compile time, then they must be present in the ROM. If that's not the case, then they are generated at some point while stuff is being decompressed and loaded into RAM.
Since you make the editor, which also encodes textures to be used in the game, I guessed you would know.

[TimEh]

there might be a solution to this. while messing around with the indeces file, one block seems to change the texture size. heres what i documented

Code:

-------------------------------------------------------------------------------------------------------- // //BB - Texture Size properties // //Not required BB ?? DD ?? XX XX YY YY     |  |  | |__|__|__|-> Texture scale. Only scales bigger?? FF FF seems to be a scale of 1. lower = bigger.     |  |  |     |  |  |-> Bool: 00 Fill tris with white     |  |             01 or greater alows Size properties (probably s0mething else unkonwn)     |  |     |  |-> Amount of detail. Scales the resolution of texture, like downsampling when generating MipMaps.     |      Mabey good for a map exceeding the max texture memory. Lower#:Crisp Higher#:Blur     |     |-> Seems to do nothing

now what i point out is the 'DD'. it seems to blur the texture out as if it was downsampled. Now i couldnt get nemu64 to work to check out how the image is stored in memory with its debug tools. The 64x64 might load if DD is set to a higher number. But downsampling it (if thats even what its doing before storing to memory) wouldnt seem any better than just shrinking the dimentions in the first place. But this simply could just be some effect

[radorn]

Maybe that DD is a factor to tell the game at which distance the renderer should start using the downsampled mipmaps for that texture.
If one could find these mipmaps in the ROM or in memory, and modify them into something easily distinguishable, it could be verified.
Something like making each mipmap of a texture into a different plain color and move arround the pertaining textured surface to see when they are switched?
They would blend a bit at the limits where a different mipmap is used, I think, since the N64 uses mipmap interpolation too.

EDIT: I just remembered I read somewhere that, in Mario 64, the effect of that picture of Princess Peach that changes into Bowser's face as you get closer to it is achieved through manually adjusted mipmapping interpolation.
Peach Princess' and Bowser's faces are different mipmaps of the same texture, apparently.

[TimEh]

that could be radorn. Anyone with a 'working' debugger wanna try this? Quite curious on what DD is actually doing. The n64 sems to do its mip mapping very oddly. Well its seems like you have more controll over it than your typical graphic api. And developers usually use this for other effects using interpolation. Now normaly (im fairly certain, could be wrong) mip maps are generated at runtime(i mean when the map is first loaded and the texture list is parsed), and wouldnt be stored in the rom. But you bring up the mario situation where it uses 2 images instead of 1 being downsampled. So both must be stored in there. Now that could be done i guess by adding both those features to the mip map generating routine. Normaly it downsamples, but in special cases it can directly control/add the layers of the mip map. But now seeing that the way mip maps can be generated with control of the layers, is it possible to bypass the downsampling process all together? Who knows, not I. I dont know much about the hardware of this console. But i figure the place to be looking for the mip map images is in the memory, not the rom.

[radorn]

Hey TimEh

While preparing graphics for my texture tiling thread, I was fiddling with Mario 64's textures, and both bowser's and Peach's pictures' textures are present in the ROM in their full size (since they are also used in their own, separate pictures in other parts of the castle, and not only in the fading picture in the first bowser stage picture room).
I just realized that, the full mip-map set used for the fading picture could be calculated using both textures as a source instead of a single one, avoiding the need to store mipmaps in the ROM.
After all, mipmap calculation is probably done on the CPU, and not the RSP, or, at least, be commanded by the RSP.

[zoinkity]

Firstly, you can exceed the texture cache. Both Zeldas do this routinely.
64x64 images shouldn't be a problem if you simply texture all triads requiring it immediately and do all the proper syncs and transfers when loading the next image.

The only trouble you run into is the way GE recalls textures in the first place. All standard compressed texture types would likely fail, but you can probably use one in-line. Only trouble is that you can't use in-line images with objects that receive collisions. Crash bug, rather involved.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

How can you possibly surpass the texture cache? It's not like you can "reprogram" a bigger one, since it's a hardware feature. Either your texture data fits or it doesn't. What you do to textures before they reach the cache is a different matter, of course.
Unless you program the renderer to load and apply a texture in chunks or use some kind of on-the-fly decompression on the RSP there doesn't seem to be a way to use more than 4096bytes or 3072 if you don't use mipmapping interpolation.
You can also load bigger than 64x32 textures if they are grayscale and/or don't use mipmapping. Many Mayan tiles from GE's Drax launch base are composed of 128x64 4bpp grayscale tiles, filling the full texture cache, with no room left for standard mipmapping. Mipmaps could be used, maybe, if the rendering process is programmed to load the main texture and it's mipmaps separatelly.

I don't understand anything of what you said :S, but I'm really interested in knowing. What's that "texture inmediatelly and then sync and transfer" talk? and what about compressed textures? can you load compressed texture data in the cache and have the RSP decode on the fly? what do you mean with "in-line"? I'm utterly confused

[TimEh]

this talk is a little to technical for me but funny zoinkity brings up the zelda reference. I was playing ocrina of time last night, the first time in many many years. And i noticed in many places, actually come to think of it the very first place you start, they use almost resident evil style 2d background with a 3d invis collision model. And some use the 360 spin image thing, not sure what its called. I know its a setting on my camera.
Anyways those textures seem to be pretty large, far exceeding 64x64. Now it may not be possible the way GE does its textures but its certanly possible on the n64

[radorn]

Well, I'm not completelly sure of the specifics, but there seem to be 2 kinds of backgrounds in these RE-like stances in zelda.
The "rotating" ones and the static ones.

If you load Zelda in an emulator and use the wireframe rendering option in your graphic plugin configuration dialog, you'll easily see that the rotating ones are, in fact, composed of tiling textures, and by looking at the resolution they look to have in the normal rendering mode, they don't seem to be bigger than 64x32.
Hyrule Marketplace is like this too, and so is the sky.

The static ones, though, look like they are a single surface if we check them with the emulators' wireframe mode, but something tells me this is just a high level emulation trick, and that, in real hardware they are a simple background instead, and not a 3d rendered surface, which means the image data could be being transfered in another manner.
Another thing that could sustantiate this is the fact that, in game, these stances, specially when you select the static view (in those that let you select, I mean), the game gets quite slow.

I have no way to verify this, I'm just trying to make sense of things with the data I have, but once you consider these things, it pretty much makes sense, in my opinion.