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

[zoinkity]

First, the basic format of all C0- pseudocommands. Depending on the command type is how much of this data is used.

C0 commands
upper command
00C00000 S mirror(2), clamp(1)
00300000 T mirror(2), clamp(1)
000C0000 ST settilesize offset, which may only be 2 or 0. Avoids pixelization on edges.
0003C000 S shift
00003C00 T shift
000003F0 RESERVED
00000007 type 0-4

lower command
FF000000 level of detail (LOD): primary color diffuse level, used to determine visible distance of image swapping
00FFF000 Overlay image ID. Appears when close to the object.
00000FFF Base image ID. When overlay present, used at a distance and replaced at close range.


Now the specific command types
type 0 C0.FFFF.00 LL.000.iii
Loads image [i] using LOD level [L]. All flags are acceptable.
Functionally similiar to type 2, except it always sets the LOD.
In addition, if "joy2 detail edit" is activated, the first instance of an image [i] sets the LOD and shift for all subsequent instances. See below for more details.

type 1 C0.FFFF.01 LL.ooo.iii
Level of detail image shifting. Replaces base image [i] with overlay image [o] when within LOD range. All flags apply.
Command requires two image IDs to function or is otherwise ignored.
Note: technically the "base" and "overlay" are actually the other way around, but this describes the actual behaviour.

type 2 C0.FC00.02 00000.iii
Loads image [i]. Only mirror, clamp, and offset flags are read.
Most common image loading type. Sets up to 7 tiles of diminishing size depending on proportions.
Additionally, if "joy2 detail edit" is activated and LOD data has been saved for this image, the image will be applied at the specified level similiar to a type 0 command. See below for more details.

type 3 C0.FC00.03 00000.iii
Loads image [i]. Only mirror, clamp, and offset flags are read.
Used predominantly for 32x32 indexed images. Sets the tile twice.

type 4 C0.FC00.04 00000.iii
Loads image [i]. Only mirror, clamp, and offset flags are read.
Used especially for large greyscale images. Only sets the tile once in memory.

For practical purposes, you always want the ST offset flag set to 2 (C0080000). Also, in case you are unfamiliar with it, mirror will reflect the image when it repeats and clamp inhibits stretching.
In the case you get improper or garbled graphics, especially at particular distances, that is likely the result of choosing the wrong kind of expansion.
Note these are just expansion types. Actual image features are dictated by the image format itself. In the case of the huffman images, not only the compression but image format are instrumental for decompression much less texture application.

+_+

About the type 0 and type special features:
"Joy2 detail edit" is a debug feature which to some degree still functions. When activated, a buffer is allocated in memory range 4 to accomidate an index for every image (0xC00 max).
Whenever a non-character texture is shot the texture ID is set in memory. The first time a type 0 command matching this ID is loaded, the command's diffuse and shift values are stored. Note, only if the type 0's image ID matches the current shot image ID will the rcord be updated.
Whenever a type 2 command is loaded, it tests its image ID against the current one. If saved LOD data is found, it loads the image using these values. Otherwise, normal behaviour occurs.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[TimEh]

Pwnage. Wish i had this info a while ago. Correct me if im wrong, but it reads here like with type 1 you could be able to pull off the Princess/Bowser LOD texture swap like the first boss entrance in mario64

[zoinkity]

Yep. You could swap images just like that. You'd want to use a LOD distance that's a bit longer, or leave it at zero. F0 or F8 would be fine.

I'm compiling this data on Rare's LOD technique to send it off to the Glide project. If anyone is going to emulate it, it would be them.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

I thought texture LOD (which I call mip-mapping) was mainly a result of the screen area a projected texture took and managed automatically by the hardware.
Is this some kind of system to override that?

[Trevor]

Not that Im refering to this in particular but I would say that mip-mapping is done by HW do 'discise' moiring whereas LOD is set by SW to improve framerates, where by setting a lower res texture to an object (of also 'usualy' lesser polly count) reduces RAM/CPU(GPU?) usage.
I would also think that mip-mapping would also still kick in with LOD, but at greater distance due to the smaller texture still being bigger than screen area it covers (if not hidden by Fog after said distance).

Tell me if Im wrong?

Trev
_________________

[zoinkity]

LOD is a hardware aspect, which should be obvious concidering it is set via hardware ops and settings. Unlike geometry clipping which is used to decrease framerate by simply not processing a chunk of data, LOD is designed to increase quality.
It appears that it is more an extension of the FG/BG colours, or if you prefer foreground/enviroment--at least in this implementation. It should be noted that if no enviroment-level image is in use and LOD is used the surface will be flattened against the enviroment; effectively, it will disappear at LOD distance.
Since the primary point of this feature is quality, it does eat a little more time. However, being a hardware-driven feature, it is processed really blasted quickly so the point really is moot.

I'm compiling the doc on this to hand over to the Glide project. I'm also going to try testing if the same technique used to swap images works on other versions of this same microcode, for example Mario64.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

when talking about texture LOD, I prefer to call it mip-mapping, as to differentiate it from geometry LOD, like when they make near and far versions of a model so when they are far from view, a simpler version of the model is rendered to save processing. This happens in any decent game on the n64, mario64, ge, pilotwings...

http://en.wikipedia.org/wiki/Level_of_detail
http://www.futuretech.blinkenlights.nl/graphics.html

[Trevor]

Well as far as Im awayer theres nothing stopping a texture LOD (as I specified inclusive of your geometry example).

Again, unless Im wrong, mip-mapping cant be used to replace an image with a 'different' one at given distance. LOD however can.

I suppose, looking back at what Ive just said, they (if 2 different things) are very similer...
... Im confused now...

Trev
_________________

[TimEh]

Quote:

Again, unless Im wrong, mip-mapping cant be used to replace an image with a 'different' one at given distance. LOD however can.

Im sure most 3d api's will allow for custom mip levels. The .dds format stores generated mips in the file itself so they are not to be created at load time, and with that said could be replaced with whatever u want.

Now i dont know the .dds file format, im not sure if you can have 2 mip levels of the same dimentions, or if one has any control over each of the levels dimentions. But the image data is there, so it can be modified.

But to put the word debate to rest, i think the best way to put it is that mipmapping is a type of LOD. So they could be used interchangeably, at least in the context of GE, where other filter types dont apply on this hardware. I know LOD is used synonymously with performance with geometry and doesnt have the same use with textures, but its hard not to look at a series of mipmaps and not see that infact its all just differing levels of detail.

[zoinkity]

I had stripped the name from the name given the tag in a few in-game debuggers.
Also keep in mind that swapping different display lists is usually handled by DLbranches/jumps at program level and not by hardware. In fact, I have as of yet to personally hack an N64 title that handles it on the hardware level. Rare's games, as well as Eurocom's, as well as the Custom Robos and Animal Forest all do software redirection instead of hardware level model swapping. Haven't bothered to confirm others.

I want to say Gimp lets you save a .dds file with same-size alternate images. I find it funny how few games utilize this though. Mark of Chaos sure as heck didn't.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

zoinkity wrote:

I had stripped the name from the name given the tag in a few in-game debuggers. Also keep in mind that swapping different display lists is usually handled by DLbranches/jumps at program level and not by hardware. In fact, I have as of yet to personally hack an N64 title that handles it on the hardware level. Rare's games, as well as Eurocom's, as well as the Custom Robos and Animal Forest all do software redirection instead of hardware level model swapping. Haven't bothered to confirm others. I want to say Gimp lets you save a .dds file with same-size alternate images. I find it funny how few games utilize this though. Mark of Chaos sure as heck didn't.

I never said geometry LOD was handled in hardware, I was talking about mipmapping exclusively, as that's what this thread is about (or so it seems to me).

As I see it the basic functioning of mipmapping is:

1: texture is loaded from secondary storage (cart) into primary storage (RAM), at which point an algorithm generates several high quality scaled down versions of it which are stored along with the full res one.
2: when a texture is needed by the renderer, the full set of mipmaps is loaded into TMEM (texture cache) and the TLMMI functionality decides which mipmap (or blend of 2 adjacent ones) to use for each pixel depending on it's metric of distance, which I assume is based on the screen area in pixels that it takes rather than "physical" distance from the camera to the object.

These commands you are docummenting here sound to me like they are intended to override hardware TLMMI's decissions on what mipmaps to use in order to make custom effects, like the mario 64 peach/bowser crossfade effect.

[zoinkity]

Not exactly. See, the really funny part is that as far as I can tell the hardware handles generating mipmapping unless you tell it explicitly not to. Then, it only attempts to use it if you tell it to. Could be wrong, but you'd be hard-pressed to find alts at runtime.

It would be nice if there was some real documentation of this stuff someplace.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

zoinkity wrote:

It would be nice if there was some real documentation of this stuff someplace.

deep within a dungeon hidden under nintendo's HQ, guarded by a giant dodongo boss...

[zoinkity]

More like warioworld.com, though by now most of the N64 docs are likely removed.
Shame. From what I've heard there were a lot of resources provided, like the code for different console emulators. The NES and GB support seen in N64 games was available there.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[radorn]

mmm, yeah, it makes one angry to think of all these goodies being lost to time because of corporate decissions.