What's new
  • Most issues reported these days stem from users not enabling their emulators to use the required amount of RAM.
    We also tend not to use the search feature but post our issues within the texture pack release page.
    Failure to load a texture pack should not be posted in the release thread unless you have already patched the emulator.

    If you don't have the resources to use Large/HD texture packs please do not attempt to do so.
    Users should have a minimum amount of System RAM not less then 4GB's.
    If you have less then 4GB's of RAM do not post about how your emulator crashes,
    RAM is dirt cheap so invest some money into your PC.

    I would like to say thanks to squall_leonhart
    for posting this Solution.

open discussion regarding texture size !

Rice

Emulator Developer
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

Just Another Wacko ;)
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. :)
 
Last edited:
OP
Rice

Rice

Emulator Developer
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

Member
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

Just Another Wacko ;)
Rice said:
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

Beta Tester
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

New member
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

New member
Federelli said:
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

New member
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

Just Another Wacko ;)
Reznor007 said:
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

New member
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

Carbon-based molecule.
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

Beta Tester
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

d1R3c764 & g1|\|64 m4|<3R
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...

[offtopic]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...[/offtopic]
 

cloudscapes

Carbon-based molecule.
Federelli said:
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.
 
OP
Rice

Rice

Emulator Developer
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.
 

Orkin

d1R3c764 & g1|\|64 m4|<3R
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?
 

krhyluv

Banned
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
 

Top