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

[Sogun]

Hi guys.

I've been gathering data about the levels in both GE and PD and noticed a couple of things.

-Textures:
Surprisingly almost all of PD's textures are 4-bit (16 colors) according to the pdromimages folder in editor. The only exceptions are head textures and very few more. On the other hand, I would say almost all colored textures in GE are 8-bit (up to 256 colors). Even simplier things like the alarm texture which only has grey and red is 8-bit.
PD levels don't use a huge amount of textures compared to GE actually. In fact, Depot is the one which uses more textures of all.
So if you look at it that way (taking into account that PD uses more textures on guards and props), both games are using about the same amount of memory for textures.

-PD allocations:
Texture memory is managed by the -mt allocation in GE, but I can't find that same allocation for PD in the 39850 Menu. I wanted to compare them because of the exposed before. -mt in GE is usually the highest allocation.
The other important allocation is -ma (which manages the amount of tris loaded on screen), en PD's is 2 or 3 times higher than GE's (levels have 2 or 3 times more polygons too).

So what manages texture memory in PD? Does the game use the remaining memory after all the allocations are set?
In GE the total amount of allocations is around 1000 (I guess 1 MB). That means the other 3 MB are used for other stuff.
So what about PD? I'm beginning to wonder if the solo missions would be playable without the expansion pak if cooperative mode was discarted. :S I'm sure maps alone are possible, but even with PD's props and guards?

And well, amazing job on textures in PD.

[SubDrag]

I remember trying to calculate mt for PD, then realizing, the images aren't laid out in a nice table like GoldenEye. I've not figured out how it works yet, but they are scattered from 8050000 in RAM to 80800000. They must somehow be organized in some big linked list, but as far as I can tell, images are stored along with the models themselves in RAM. I have been meaning to get back to that. I suspect if you exceed the range, the game just crashes, unlike GE where images wrap.

PD did do very nice sharp 4-bit textures all over. I suspect they realized it took up far less memory, and in many cases is good enough quality where you wouldn't even notice. I thought they used more textures than GE though, at least for things like characters, where it's 30 textures instead of 8.

[Sogun]

SubDrag wrote:

PD did do very nice sharp 4-bit textures all over. I suspect they realized it took up far less memory, and in many cases is good enough quality where you wouldn't even notice. I thought they used more textures than GE though, at least for things like characters, where it's 30 textures instead of 8.

Another advantage of 4-bit textures is that they mipmap easier and the game doesn't look pixelated. An 8-bit 64x32 texture won't mipmap and look pixelated (like SM64 white brick castle texture), while a 4-bit version of that same texture will mip map and look better from the distance.
I'm not sure if the game performs better with 4-bit textures than with 8-bit. I tried in my Kakariko map and didn't noticed any difference.

PD uses a lot of texture for characters indeed. But since they are 4-bit (except the head ones) and the background is 4-bit too, you need to double the texture amount to meet GE's levels. That's why I think they use about the same memory for textures.

Speaking of textures. PD also uses textures with more resolution than GE's. Even some sizes that I thought weren't possible.
-009B and 06B3 are 4-bit colored 64x64 texture. I know some other games use them, but GE doesn't. Do they mipmap correctly?
-00F7 is a 4-bit greyscaled 64x128 texture. Insane!
What is the secret behind these textures? XD

[SubDrag]

Ah right, I forgot, yeah mipmapping may have been most important criteria for using 4-bit too.

GE supports 4-bit 15 color 64 x 64 too, but it won't mipmap. Same with that greyscale size. That's the absolute maximum. 64 x 64 color 4-bit and 128 x 64 4-bit greyscale. They won't mipmap though. I think that's why even in PD using sparingly.

[SATURN_81]

no se si esto tiene que ver exactamente con lo que estais hablando. los niveles de GE que han sido portados a GEX , se ven mucho mejor en GE, yo hablo especialmente sobre la nitidez ya que en GE casi todo parece mas limpio y nitido. ¿ puede ser que las texturas usadas para GEX , de forma automatica PD las convierta en texturas de 4 bits aun cuando se guardaron para GEX en 8 bits ?
¿ puede comprometer o reducir la velocidad de juego en GEX si los niveles usaran texturas de 8 bits para parecerse lo mas posible a GE, en lugar de las texturas de 4 bits? esto quizas sea una buena idea para sacar el maximo partido para GEX, es decir utilizar por ejemplo texturas de 8 bits en niveles pequeños para que la velocidad no se vea comprometida , y quizas usar las texturas de 4 bits en niveles grandes.

todo esto se nota en niveles portados como Facility o Bunker, pueden compararlos con los niveles en GE.

ENGLISH:
do not know if this has to do exactly what you talking about. GE levels that have been ported to GEX, they look much better in GE, I speak especially about sharpness because in GE almost everything seems more clean and crisp. Can be used for GEX textures so PD's become automatic 4-bit textures even when kept for GEX in 8 bits?
Can compromise or slow game if levels GEX will use 8-bit textures to resemble as much as possible to GE, instead of the 4-bit textures? maybe this is a good idea to get the most out for GEX, ie use eg 8-bit textures small levels so that the speed is not compromised, and perhaps use the 4-bit textures large levels.
 
all it shows in levels or Bunker Facility ported as can compare with levels in GE.

[Sogun]

Hola SATURN_81

No he mirado las texturas de GE:X pero imagino que se han copiado tal cual de GE, por lo que en un principio no debería de haber ninguna diferencia (aunque algo sí que noto, como diré más adelante). Habría que preguntarle a Wreck por si hubiese algún cambio, pero PD no convierte las texturas a 4-bit automáticamente.
Respecto a si mejoraría la velocidad usando texturas de 4-bit respecto a 8-bit, yo lo probé en mi mapa de Kakariko en su versión de GE (porque en consola se veía todo muy pixelizado ya que muchas texturas no hacían mipmapping) y no noté ninguna diferencia; aunque en un principio pudiera parecer que sí que podría haberla (hay menos colores en pantalla).
De todas formas GE:X debería de funcionar mejor que GE, o al menos eso creo, ya que el motor gráfico está más optimizado. Recuerdo que en una entrevista a Rare mientras desarrollaban Perfect Dark decían que habían mejorado el motor tanto, que GE podría funcionar a 30 fps sin problemas si lo usase.

Respecto a lo que dices que los niveles se ven mejor en GE:X que en GE. En consola si se activa el modo de alta resolución por supuesto que se deberían de ver mejor. Pero incluso en emulador, donde no debería influir la resolución, yo también los veo más nítidos como dices. Es como si los colores estuviesen más definidos, quizás porque el sistema de iluminación no es el mismo.

ENGLISH
I haven't checked GE:X textures but I assume they are exactly as in GE. We should ask Wreck if some changes were done; but PD doesn't convert textures to 4-bit automatically.
Regarding if the game will perform better with 4-bit textures intead of 8-bit textures I already tried it in my Kakariko map for GE (because most textures didn't mipmap on console and it looked very pixelated). I didn't notice any improvement, although you'll think there would be since there are less colors on screen.
Anyway, GE:X should perform better than original GE since the engine is better. I remember an interview with Rare when they were developing PD were they said that the engine was so good that it could run GE at steady 30 fps.

About GE:X levels looking better than original GE. On console if you activate Hi res mode of course they will look better. But even on emu, where resolution doesn't matter, I also see them sharper as you say. It's like the colors are more defined, perhaps because the lighting engine isn't the same?

SubDrag wrote:

GE supports 4-bit 15 color 64 x 64 too, but it won't mipmap. Same with that greyscale size. That's the absolute maximum. 64 x 64 color 4-bit and 128 x 64 4-bit greyscale. They won't mipmap though.

Which would be the max size for every texture to mipmap? Because PD uses a lot of weird textures sizes as 56x56, 64x48, 72x48, 80x66... and I think it has something to do with mipmapping.
If 64x64 4-bit greyscale mipmaps, shouldn't 64x64 4-bit color mipmap too?


PD amazes me more every day, hehe. You would think it looks so good because they managed to use all the power of the N64, but it's more because of design decisions than pure numbers.

[SubDrag]

I think greyscale has more room in the 4kb buffer, than paletted, but I'm speculating from vague nintendo documentation. 4-bit color 64 x 64 definitely doesn't mipmap.

[Wreck]

The interesting thing about the memory allocations in PD, is that every level uses roughly the same amounts. Each mission shares one set of values (with differing -ma), while the Combat Simulator maps have their own identical numbers. The only exception is Fortress Lo-Res, which for some reason has lower -ma. Bonus missions are a little different, as is the Institute. Also, standard missions feature a new allocation called -mgfxtra.

If you compare original colour textures from GoldenEye that also make an appearance in Perfect Dark, you'll see that they changed them from 8bit to 4bit. How they managed to maintain such high quality I would love to know. Those I could use were incorporated into GEX.

And you are correct in assuming that most mission levels will not load in Lo-Res mode. I'm pretty sure that the G5 Building is one of the only ones that do (though maybe only with fewer props, since my old tests were done as an attempt to make it into a multi setup). Also, some of the GE maps in GEX do the same thing. When SubDrag made an auto-covertor test to reduce all the 8bit colour images in Facility to be 4bit, it did load. However, the loss in detail was quite visible on the majority of images.
_________________

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

[Sogun]

Wreck wrote:

The interesting thing about the memory allocations in PD, is that every level uses roughly the same amounts. Each mission shares one set of values (with differing -ma), while the Combat Simulator maps have their own identical numbers. The only exception is Fortress Lo-Res, which for some reason has lower -ma. Bonus missions are a little different, as is the Institute. Also, standard missions feature a new allocation called -mgfxtra.

Ah, so there's high and low res versions of the multi maps? That would explain why they appear twice in the 39850 menu.

Wreck wrote:

If you compare original colour textures from GoldenEye that also make an appearance in Perfect Dark, you'll see that they changed them from 8bit to 4bit. How they managed to maintain such high quality I would love to know. Those I could use were incorporated into GEX.

Yeah, I noticed some textures that are in both games and they were converted to 4-bit for PD. Specially the monitor textures (the ones with the space shuttle) are amazing. I guess since they are so small you can still make them look good with 16 colors.

Wreck wrote:

And you are correct in assuming that most mission levels will not load in Lo-Res mode. I'm pretty sure that the G5 Building is one of the only ones that do (though maybe only with fewer props, since my old tests were done as an attempt to make it into a multi setup). Also, some of the GE maps in GEX do the same thing. When SubDrag made an auto-covertor test to reduce all the 8bit colour images in Facility to be 4bit, it did load. However, the loss in detail was quite visible on the majority of images.

Heh, I meant mission levels would run with no expansion pak. I'm pretty sure the backgrounds alone will after my experiences with GF64. The only thing that prevents PD levels to work in GE is that they are splite in more rooms that GE allows. But you could merge rooms and fit the limit. Props and guards are another matter, though.

----------------

More about textures:
-64x64 4-bit greyscaled mipmaps because 64x64x4/8 = 2048 (resolution x bit depth / byte conversion). The cache halves to 2048 bytes when mipmap is available. So this textures is at the limit of mipmapping.
-128x64 4-bit greyscaled. 128x64x4/8 = 4096 (full cache, so they can't get any bigger than this).
-64x64 4-bit colored doesn't mipmap because its size is 2048 bytes + X bytes with the palette. A slighty smaller texture might mipmap.
-128x64 4-bit colored can't be done because its size is 4096 bytes + X bytes with the palette. But a slighty smaller texture might work.
-64x64 8-bit colored can't be done because 64x64x8/8 = 4096 + X bytes with the palette. But a slighty smaller texture might work.
-64x32 8-bit colored doesn't mipmap because 64x32x8/8 = 2048 + X bytes with the palette. But a slighty smaller texture might work.

I think my greyscaled texture assumptions are right, but I don't know about the colored ones. What do you think?

[SubDrag]

I'm not sure, we had done some tests before, it sounds reasonable, but I also think greyscale can use 4kb instead of 2kb like paletted. This is all speculation. I think the eye in Bunker is an 8-bit 56 x 56 image and it mipmaps. The problem with images not aligned to certain heights, is they automatically pad to that height, so if you do 64 x 31, it's really stored as 64 x 32, so if your uvs are > 1.0, it will wrap badly.

[Trevor]

"More about textures:
-64x64 4-bit greyscaled mipmaps because 64x64x4/8 = 2048 (resolution x bit depth / byte conversion). The cache halves to 2048 bytes when mipmap is available. So this textures is at the limit of mipmapping. Edit 2015: Oh my god I was so wrong here, got this info from someone else here on forum.
-128x64 4-bit greyscaled. 128x64x4/8 = 4096 (full cache, so they can't get any bigger than this).
-64x64 4-bit colored doesn't mipmap because its size is 2048 bytes + X bytes with the palette. A slighty smaller texture might mipmap.
-128x64 4-bit colored can't be done because its size is 4096 bytes + X bytes with the palette. But a slighty smaller texture might work.
-64x64 8-bit colored can't be done because 64x64x8/8 = 4096 + X bytes with the palette. But a slighty smaller texture might work.
-64x32 8-bit colored doesn't mipmap because 64x32x8/8 = 2048 + X bytes with the palette. But a slighty smaller texture might work.

I think my greyscaled texture assumptions are right, but I don't know about the colored ones. What do you think?"

Correct
But since the TLUT is always loaded into HiTMEM it 'may' be possible to mipmap since the image texles still reside under 2048.
Sub and I have seen examples of both. Most of the time it does not mip-map.
However I have seen one of my test levels actually mip-map with a 64x64x4 (grassleaveborder.bmp) so... more testing is required.

64Docs-
"For color index (CI) textures, the texture is stored in the lower half of TMEM, and the Texture/Color Look-Up Table (TLUT) is stored in the upper half of TMEM"

As for greysale (or intensity as refranced by N), because Intensity Types do not have a TLUT they are the size of WxHxD/8 and so correctly fit below 2048 boundry.
Again, as said previously though, technicly 4Bit CI fit too since TLUT is after boundry ALWAYS.



"you'll see that they changed them from 8bit to 4bit. How they managed to maintain such high quality I would love to know. Those I could use were incorporated into GEX."

If you want I can do it, well... not all at once as Im buisy with GF. In GF I almost always use 4bit only.
As long as you get a good palette then everythings great.
I have often commented to sub about rares stupidity over GE's 8bit textures.



"Regarding if the game will perform better with 4-bit textures intead of 8-bit textures "

Nope, ... well... kinda....
4Bit allows you to either:
Double Total Resolution ((x2H) OR (x2W) OR Approx(1.5W + 1.5H)) for sharper textures
OR
Load 2 textures at once in TMEM (Provided both fit under 2048)

If you follow the second route then yes, but I am not sure of noticability.
I prefere option 1 and I beleve rare did too.
TWINE definalty prefered option 1.



"It's like the colors are more defined, perhaps because the lighting engine isn't the same? "

as far as I know (though Sub, Zoink and wreck would know) both engines employ the static lighting model which saves a lot of resources over dynamic lighting.
Static lighting is simply Texture Texle Colour * Vert Colour.
PD I beleve simply sets all verts of a room to Vert Colour * 0.2ish IF lights = destroyed.

Funnelly enough, Environment mapping is actually a dynamic lighting mode, well, a function of.
Now, Im sure sub and I noticed that when we environment Maped an object it seemed... Lit from the center of level, like you see in a modeling program (automatic lighting).
It was a series of cubes to test his new envmapping tool but each side was a different shade whilst having the envmap 'slide' over the face.




"The problem with images not aligned to certain heights, is they automatically pad to that height"

Sub, you mean Width :

64Docs-
"Dependent on tile row width as well as texel type/size. When tiles are loaded using the LoadTile command, the rows are padded to 64-bit boundaries. When LoadBlock is used to load a texture, it is assumed that the rows have already been padded."

So, saving a 33x32x4 texture means that on rom it will be 33x32x4 and then compressed.
However upon loading into TMEM it will now be 48x32x4 (15 texles padding). If you u'v the image to repeat twice you will see the padding as messy noise in the middle of the image.

If the image is 8bit (like GE's types) then padding is 7 texles just like GE.
33x32x8 = 40x32x8

So... basic rule... dont do odd widths, its a huge waist.

I actually did a calculation once and came to the conclusion that the most efficiant texture is 64x32x4 since it has the following attributes.
Resolution AND 2 loaded into TMEM at once.
If you need a square texture then, 40x48 is similar (45x45x4 allows 2 but due to padding it needs to be 40 or 48.)


Anyway, Ive blabbed enough, the topic just grabbed my attention.
I will need to visit here more again

Trev
_________________