[$threadinfo[title]]

[Rice]

When making a high resolution texture from the original texture, most people increase the texture by 4x4, making a 32x32 to 128x128, a 64x64 to 256x256 and so on.

Memory requirement is increased dramatically by increasing the texture size, and the texture package file size gets easily to a few megabytes.

Shall we reconsider the texture size? Do we really need a new 256x256 texture for the original 64x64 one? Could a 128x128 be just enough for our N64 emulation purpose?

To look at the memory requirement quickly (32bit RGBA textures):

16x16 1KB
16x32 2KB
32x32 4KB
32x64 8KB
64x64 16KB
64x128 32KB
128x128 64KB
256x256 256KB
512x512 1MB

We clearly don't need a texture larger than 256x256.

Btw, because most original textures have width and height of 2's powers, it does not have to save the memory to create a 3 times larger texture instead of 4 times. A 3 times larger texture of original 32*32 is a 96x96, which will be loaded in DirectX and OpenGL as a 128x128, uses the same memory as a 4 times larger texture.

[PsyMan]

Let's be reasonable. The native resolution of N64 games is 320x240. By doubling the textures' size we manage to make them look better on high resolution monitors that miss some features that TV screens have (when we use higher resolutions).
A texture that is four times larger than the original whould be useful only if we use resolution equal to 1280x960 (or higher) and only if the creator of the textures enchanced them enough in order to make them better than smaller textures.

Since it's not possible to gain more memory by creating slightly smaller textures, the usage of textures that are four times larger than the originals does not help when we use lower resolutions (either because of a slow video card or because some people use their TV screen when running console emulators) and the size of these textures is quite big it whould be better to use textures that are two times larger than the original ones.
On the other hand, people with better hardware will gain better quality when using higher resolutions together with textures that are four times larger than the originals.

So we now have to choose between 2x textures and 4x textures... Why not adding support for both of them, plus 8x textures? Of course the textures will have to be drawn again but the whole idea sounds quite good if you think about it (there will be support for PCs of multiple classes/hardware capabilities).
The only drawback (apart from the system requirements) is the will of the texture creator to make textures of different sizes and then to categorize them. :)

[Rice]

It could be better for the texture creators to just create 4x textures, and use automatic resizing tools to downsize all the 4x textures to 2x ones in a batch processing (Paintshop can do it for sure).

it is also possible that texture creators only create 4x textures, and the plugin will determine the texture size to load (4x or 2x) depending on a user selectable option (which allows user to select 4x, 2x or automatic decision by the plugin according to the current screen resolution). The plugin should be able to downsize a 4x texture to 2x one.

[pilm]

A resizing option in the plugin would be a nice idea, it would let the choice between "hi-rez" and "ultra hi-rez", and/or maybe some exclusions for big textures...

[PsyMan]

it is also possible that texture creators only create 4x textures, and the plugin will determine the texture size to load (4x or 2x) depending on a user selectable option (which allows user to select 4x, 2x or automatic decision by the plugin according to the current screen resolution). The plugin should be able to downsize a 4x texture to 2x one.
I see... By downsizing the size of a texture through the plugin you manage to have textures that have quality and multiple memory requirements without having to re-create them multiple times. This option could also be used for other texture sizes (8x, 6x, 5x, 3x).

Since there aren't any video cards nor monitors that can handle resolutions up to 2560x1920 (it's unlikely that there will be in the near future) a x8 option is not needed yet.
Of course the memory requirements for any other options do not worth the trouble (except maybe from the 6x option that can be fully handled by some monitors and video cards).

[Federelli]

Since most of the textures are so small, i really don't see an issue here. Specially when 512MB Vid Cards are available :).

Don't like the texture size? Downsize it yourself, or don't use it :).
If it where my call i'd make everything 2kx2k ;).

Still for those that don't want 4x, a plugin option would be neat.

[Reznor007]

Actually, 640x480 is 4x 320x240, so 1280x960 would be 16x the standard res.

Even an old PC game like Quake3 uses textures that are 256x256-512x512 on average. A quick glance through one of the game files finds a 256x1553(yes) texture, 384x856, and 196x1408.

I would say that 8-16x the base N64 texture would be no problem at all. In fact, Rice could add something from the DX SDK that will compress the new textures to DXTC texture compression as it loads them to save on texture memory with slightly lower quality, or no compression for people that have 256MB or 512MB video cards.

[optimus$prime]

Since most of the textures are so small, i really don't see an issue here. Specially when 512MB Vid Cards are available :).

Don't like the texture size? Downsize it yourself, or don't use it :).
If it where my call i'd make everything 2kx2k ;).

Still for those that don't want 4x, a plugin option would be neat.


i agree

there are also lots of ci textures which don't reach superb quality

[Kolano]

Texture memory is currently plentiful. I don't think there is a real concern from most folks with using 4x textures. As others have also noted, I'd be in support of even higher resolutions myself.

[PsyMan]

Actually, 640x480 is 4x 320x240, so 1280x960 would be 16x the standard res.

Even an old PC game like Quake3 uses textures that are 256x256-512x512 on average. A quick glance through one of the game files finds a 256x1553(yes) texture, 384x856, and 196x1408.

I would say that 8-16x the base N64 texture would be no problem at all. In fact, Rice could add something from the DX SDK that will compress the new textures to DXTC texture compression as it loads them to save on texture memory with slightly lower quality, or no compression for people that have 256MB or 512MB video cards.
You don't seem to understand how "2x" and "4x" are meant. We are not talking about the sum of the texture's size but for each of its axis independenly (ie: (A)x(B) will be (2A)x(2B), (4A)x(4B)... ...(yA)x(yB). If the texture is 16x16 it will be 32x32, 64x64... ...(y16)x(y16)).

That's because we want to keep the original aspect ratio which is 4:3. In order to achive that each texture must have size that "fits" with each resolution. Some examples:
Resolution: 320x240 Texture: (A)x(B)
Resolution: 640x480 Texture: (2A)x(2B)
Resolution: 1280x960 Texture: (4A)x(4B)

If we don't keep the original aspect ratio of each texture the new textures will look bad unless we use specific non 4:3 resolutions (in that case the rest of the game may look bad).

[hizoka10]

Here is an example of how resizing depend of the place of the texture in the game :
- grass textures are 8x (yes 8x as I explain in my hires textures thread, could you get an eye rice please)
- the hand of the chrismath guy is only 2x and it's great.
- for my texture pack, don't juge it in the first level and outside the castle, because it's in progress. all other level are fully done I think.

[cloudscapes]

For fits 'n giggles, I tried 512 textures when I had started retexturing, didn't work for some odd reason, but simply rescaling it down to 256 and it worked.

Personally, I don't see a point to go beyond 4 times the original size (or 16 times the filesize, 32x32 = 128x128 for example). The meshes (characters, environment) are so low res that I don't see the point. It's quite a bit more effort to repaint/detail a texture the larger you rescale it, so if you (as a retexturer) don't want to spend an eternity doing the whole game, 4x*4x is fine IMHO.

Also, I don't see the point in upgrading textures which are so finely tiled anyway (kind of like the top of those flowerbeds in bomb omb battlefield), because then you get this texture that's ultra detailed, supersharp and "pixel-less" among the other textures which are only 4x*4x (still blurry, but more detailed and pleasing to look at).

I've noticed the games don,t really load that many textures at all, compared to semi-recent PC games (I work in game developpement btw). It uses maybe around twelve/fifteen unique textures (unique for that environment), and most of the rest are common textures that are reused everwhere (coins, mario, reused enemies, etc..). I don't think we're bottlenecked in texturesize unless you have a TNT2 with 8 megs VRAM.

But still, I think 4x*4x is perfect for most textures. Maybe 2x*2x for ones that are tiled tighter or are far-off from the camera (excluding skybox) and maybe 8x*8x for a few special cases, like a texture that's stretched enormous right under you.

[Federelli]

If you don't keep it consistent with the original size, and give everything a ratio of 4x (or 2x, or 8x) Things will look weird, and not how they where meant to look like.

[Orkin]

I think 4x size is a good size. I mean, the N64 runs at 320x240 (on most games), so 4x that is 1280x960, which is what I run my box at. So assuming the textures were designed to look good at 320x240, 4x should be about right (although, some textures were blurry even at 320x240).

I'm not sure about Rice's plugin, but Direct64 uses around 1MB of memory for textures in Mario, 4MB in Zelda, and 8MB+ in heavy sprite-based games like KI Gold with default texture sizes (with my new code anyway, the current release will keep going until you max out). Going to 4x texture sizes, it would still only hit about 64MB in most games, and the majority of people have at least a 64MB video card these days...

Speaking of Direct64...I'm still working on the whole hi-res texture thing. I could implement it pretty easily, but I want to make it compatible with the texture packs coming out for Rice's, which is presenting a bit of a problem since our plugins handle textures differently...

[cloudscapes]

If you don't keep it consistent with the original size, and give everything a ratio of 4x (or 2x, or 8x) Things will look weird, and not how they where meant to look like.

Normally that's true, but in some special circumstances it may be preferable to bend those rules. Texel-to-world resolution isn't consitant thruout the game.

[Rice]

Orkin, I hope the difference in implementation of texture loading won't give you too much trouble. The big thing is that I am not actually emulating the real TMEM unit (even though it is possible to enable the full TMEM emulation in my plugin), instead, I am loading textures directly from RDRAM, and CRC calculation is also done on the content in RDRAM. I understand the loading from RDRAM isn't the best way at all, but it is faster and could make some sense for texture caching.

[SubCog]

I've got 768 megs of ram, and I demand 1600*1200 textures! :D

[Orkin]

Rice: I noticed that while looking through your code yesterday. I had actually done it that way in the beginnings of glN64, but I found it was easier to do it through TMEM emulation (although, as you said, slower).

I saw you used a simple summation of double word values for CRC calculation in the, now commented out, C code. Is this what you're still doing in your newer assembler version?

[cloudscapes]

I've got 768 megs of ram, and I demand 1600*1200 textures! :D

Textures are stored in video memory, not the main RAM. ;)

[krhyluv]

I can say that the monopoly textures would benefit from improved size. Also, it'd be nice if I wasn't stuck with bmp files, but I can't get any other kind of file to load. Probably because I'm a retard. Oh well, ban me. ;D

[Reznor007]

You don't seem to understand how "2x" and "4x" are meant. We are not talking about the sum of the texture's size but for each of its axis independenly (ie: (A)x(B) will be (2A)x(2B), (4A)x(4B)... ...(yA)x(yB). If the texture is 16x16 it will be 32x32, 64x64... ...(y16)x(y16)).

That's because we want to keep the original aspect ratio which is 4:3. In order to achive that each texture must have size that "fits" with each resolution. Some examples:
Resolution: 320x240 Texture: (A)x(B)
Resolution: 640x480 Texture: (2A)x(2B)
Resolution: 1280x960 Texture: (4A)x(4B)

If we don't keep the original aspect ratio of each texture the new textures will look bad unless we use specific non 4:3 resolutions (in that case the rest of the game may look bad).

I know what you meant by saying 2x/4x, I was just saying that 640x480 is 4x the data of 320x240.

However, the size of the texture has nothing to do with the 4:3 aspect ratio of the game. The size of the texture should be an even match to the original, but the original texture is not 4:3, they are usually 1:1(64x64=1:1). If you use a different ratio than what the original texture used, that specific texture will look weird, but not the whole game. Using a 64x128 instead of 64x64 would look funny, but only that 1 texture.

4:3 is the aspect of the final display, but the size of an individual texture has nothing to do with that.

[PsyMan]

I know what you meant by saying 2x/4x, I was just saying that 640x480 is 4x the data of 320x240.
Yes you did. I thought that you were refering to the size but it doesn't matter since you're right in both cases. I just wanted to make clear that if the textures are not created with specific resolutions in mind they will look bad. :)
However, the size of the texture has nothing to do with the 4:3 aspect ratio of the game. The size of the texture should be an even match to the original, but the original texture is not 4:3, they are usually 1:1(64x64=1:1).
The original aspect ratio of a texture doesn't matter (it might be 1:1, 1:2, 15:1 or whatever, that's why I give (A)x(B) and not (A)x(A) as an example) but the original textures were created while having a specific resolution and aspect ratio in mind. I suggest that you read my previous post again.
If you use a different ratio than what the original texture used, that specific texture will look weird, but not the whole game. Using a 64x128 instead of 64x64 would look funny, but only that 1 texture.
That's what I've said in my previous post. I also said that the specific texture will not look bad if we use a specific non 4:3 resolution but the rest of the game will.

[hizoka10]

A question for rice : it's not possible to use colors that were not in the original palette for ci texture but how do the texture enhancement filters do when interpolating, don't they create new colors? maybe it'a step problem but if it is you could do dumping step after palette processing ?

[Rice]

CI textures are converted to RGBA before they are used in the game. Texture enhancement filters are working on the RGBA image instead of the original CI texture. If palette is changed, the then CI texture is converted again to a new RGBA, and then enhanced by the filters ...

Of course we can do dump after the CI is converted to RGBA, then you have other problems. The same texture could be dumpped 10 times for 10 different palette. It is even worse than you don't know how the palette will change in the game.

[Reznor007]

Yes you did. I thought that you were refering to the size but it doesn't matter since you're right in both cases. I just wanted to make clear that if the textures are not created with specific resolutions in mind they will look bad. :)

The original aspect ratio of a texture doesn't matter (it might be 1:1, 1:2, 15:1 or whatever, that's why I give (A)x(B) and not (A)x(A) as an example) but the original textures were created while having a specific resolution and aspect ratio in mind. I suggest that you read my previous post again.

That's what I've said in my previous post. I also said that the specific texture will not look bad if we use a specific non 4:3 resolution but the rest of the game will.


Textures aren't created to fit a certain resolution though, they were designed for 4:3 output, but resolution and aspect ratio are not tied together(unless you are on a fixed pixel device like an LCD). That's why N64 emulation and PC games work...the textures are scaled to fit the geometry, not the resolution. As long as the geometry is rendered at a 4:3 aspect the textures will look right.

Technically, textures don't even have to be designed for a certain aspect ratio though, as some PC games(and N64) will allow 4:3 or 16:9, but have to be programmed to do so by widening the viewpoint and adjusting the rendering window to squish things in so that they look right when stretched to 16:9.

[dtm]

Do you guys think it's possible to optimize a texture pack for a 64MB card, perhaps by some automated means? Or to change some options to make it work and still look better than the original?

I have a geforce 4 440MX AGP4x 64MB and a 1200 MHz Sempron which plays the stock games just fine in Mupen64, but chokes the bus (4-8 VI/S in Zelda64) when I enable high res. I even scaled them down to 50% and it's less slow (20-30 VI/S in Zelda64). When I scaled them to 25%, it was almost playable (40-50 VI/S in Zelda64) but just as blurry as the originals. I'm talking about the three part texture pack ( http://www.emutalk.net/showpost.php?p=366439&postcount=343 ), not Federelli's, which I can't download coz all emutalk urls are broken.

Here's the command I'm using to scale them down, which should work on any system with bash and imagemagick installed:

find . -type f | while read file; do echo "PROCESSING $file" ; mv "${file}"{,_backup} ; convert -quality 0 -depth 8 -scale 50% "${file}"_backup "${file}" ; rm -f "${file}"_backup ; done

AFAICT, that should yield the same format as the source high res texture pack, which is an 8bpp png file. And then I guess the Rice plugin converts them to 16bpp in video ram.

Any tips, other than buying a new card, which I'm also working on? The point is that you should design the textures to be future-proofed, but also at least think about backward compatibility. Also if there was a total conversion, like adapting all textures to cel shading, maybe it could still provide a pleasingly new experience on low end systems.

Thanks!

[dtm]

I'm sure most of you guys have fairly high end cards compared to the task at hand. But what's the minimum amount of video ram needed for using the texture packs at their default resolution?

I dont know how textures work in memory, but I'm amazed that these high res ones are so slow on a 64MB card. The whole high res texture pack, uncompressed, is only about 20 MB. Even doubling that for 16bit color is still 40MB. Does anyone have a 64MB card on which it works ok?

Would a 128MB card be absolutely enough, and a 256MB card be vicious overkill?

[macphisto]

I do think 4x4 is sufficient, but there were certain textures when I was texturing some parts of Banjo that I wished could have been at a much higher res. Usually it were textures that were stretched to cover a large area and not tiled as normal. I think an option for higher res textures (from a texturer's perspective) would be ideal and very welcome.

[Doomulation]

Though I may be wrong, I don't think it's the graphics card that is the bottleneck here. As Rice may have pointed out, these new textures are loaded, converted to RGBA and filtered and so on. That takes CPU processing power. The larger the textures, the more CPU it needs.
As for texture size, mudlord is continuing on Rice's plugin, so you should probably bug him about what size you think should be the maximum.

[Cyberman]

First this is a VERY old thread (resurected after 2 years) please Don't do this. It not only is confusing it is somewhat toward the irritating.
Second mudlord is currently continuing Rice's work.
Third I do recomend carefully reading the discussion Rice had.

The display resolution (current) and render window resolution affect how much memory is available. Example
1024x768 32bit is 3megs you need 2 of these 6 megs you have 58megs of display memory left. Seems like a lot right? Textures aren't allocated like computer memory. The memory chunks have to be a binary multiple. IE 32xN 64xN 128xN 256xN 1024xN where N is the same. It does not need to be square however. For N64 games the textures are already fairly compact (remember it has it fit in a ROM cartridge). You shouldn't have trouble running the game without hirez texturing on. If you do turn it on, you may need a card with more RAM. It's hard to get a card with 64M these days. Most come with 128M 256M and some have 512M and 1G (obviously high end).
Well to keep things from being confusing, you shouldn't have trouble with hirez textures if you are using ones with < 4x.

As for big textures, I can understand your desire but big textures will have a performance penalty. As Rice noted anything above 512x512 was pushing it hard 2 years ago. A 1024x1024 sized texture is STILL huge that's 4M of space 6% of a 64M cards space 3% of a 128M card 1.56% of a 256M card. That precludes the display area (which does use space too). What I suggested to mudlord is to check what's available and shrink something that didn't allocate as well as shrink anything else to create space. The problem with texture memory again is that it's NOT allocated linearly. This means you could run out of texture space VERY quick if you are not careful.

Cyb