open discussion regarding texture size !

[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]

video ram size recommendation

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