"Texture Packs" Format ?

[darknior]

Hello everybody

A member of forum write :

Jabo and I have discussed this at length, and it was decided it is not possible.
There are several reasons why:

1) Jabo's plugin uses MD5 checksums, Rice's uses CRC32
2) Jabo's plugin uses non power-of-two textures, Rice's only supports textures that are in a power of 2
3) Due to how the plugins emulate the N64 graphics,its unfeasible for things to be perfect.

So. basically, what you are asking is near to impossible. Sorry.

And i don't understand very well ...
Because i think he answer my question of why there are two formats of PACKs ?

With files like :
0AE21369ED692A6A5F29B13F798E8639.png
or
MARIOKART64#2C95F02E#2#1#6B24A530_ciByRG BA.png

The second format, work good on Project64 6.1.1 B10 with RiceVideoPluggin !
But the first format, i don't understand
He talk about Jabo's on Project64 1.7 Beta but it don't propose me to use the HiresTextures



Who can explain me how to use these Packs ?
Or if it is realy impossible to have one and convert to other one format ?

Thanks

[mudlord]

And i don't understand very well ...
Because i think he answer my question of why there are two formats of PACKs ?

With files like :
0AE21369ED692A6A5F29B13F798E8639.png
or
MARIOKART64#2C95F02E#2#1#6B24A530_ciByRG BA.png

The second format, work good on Project64 6.1.1 B10 with RiceVideoPluggin !
But the first format, i don't understand
He talk about Jabo's on Project64 1.7 Beta but it don't propose me to use the HiresTextures

Who can explain me how to use these Packs ?
Or if it is realy impossible to have one and convert to other one format ?

Well the answer is quite complicated to understand. But I'll do my best to explain:

First of all,the biggest technical hurdle is the idenfying method use for the textures. For example the sequence:

0AE21369ED692A6A5F29B13F798E8639

is known as a MD5 checksum. Its a special identifier used to uniquely identify a texture. Due to how MD5 works, its insanely accurate, and can be used to pick up the tiniest changes in files. Jabo's plugin uses this method, solely out of simplicity, because a MD5 checksum is so accurate, that there is no other identifiers needed. And also, Jabo's plugin uses only RGBA format PNG's, in its texture format. And RGBA's can be used as well for normal RGB textures (which is exactly how I compress PNG screenshots with the current version of my plugin), in Jabo's plugin.

Rice's, however, is a bit more complicated.

MARIOKART64#2C95F02E#2#1#6B24A530_ciByRG BA.png

The 1st bit is the internal ROM name. Second bit is the CRC32, and then theres the other part of the CRC32 checksum, followed by the texture format. Rice's plugin uses a variety of different formats, but I'm hoping to simplify things, to make it easier on me and the retexturers. The biggest problem is this identifier method. Its not feasible to go through each texture and change it because it can take quite a long time to convert textures, because of these identifiers. These identifiers are completely different to each other, because of these checksum methods. Secondly, we have another technical issue, and that is the texture format. Jabo's plugin uses only PNG textures. Rice's plugin (currently... ),
uses:

* BMP (but this can be ditched altogether, when I port more internal things to use RGBA (like the debugger code),and rewrite the hi res code
* JPG
* PNG (the best format to use)

Which means, the format of the textures HAS to be PNG, and nothing else.

On top of that,we have yet another technical hurdle. And that is the business of non power-of-two textures....

This is another big problem. Due to texture mapping in Rice's plugin, all textures are handled as powers of two. The Nintendo 64, however, uses non-power-of-two textures in cases. Jabo's plugin, also uses non power of two textures. The problem is, going through ALL textures and manually resizing will take a huge amount of work. Add on top of that how different emulation is in both plugins,and we have got quite a problem on our hands.

Which leads me to this: Its not possible currently to convert texture formats between the two different plugins in a easy fashion. I'd say its not worth the effort at all.


~whew....~

[SubDrag]

I didn't think the N64 did support (or uses?) non-power of 2 widths? Well, in reality more like non-power of 4 widths. If you've got an stored image that is Width 0x15 x Height 0x15, the game will need to pad the texture to be 0x18 x 0x15, then it will be used. I may be misinformed, or at least Goldeneye does it this way. It's possible it's just for simplicity, but not sure.

[darknior]

Thanks "mudlord" for your answer
It is not realy that i want to know but it is interesting lol

I read many more about yesterday also on the board of BETA TEST PJ64 1.7 and i finaly understand where is the problem !
BUT i understand also that there is not solution to convert PACKs at this time

It is not good, because it cut the scene in two parts, PJ64 1.6 or 1.7 !!!
And the work is more slowly like that for everybody ...

[Xenobond]

Converting between the two is a time intensive task. You'd have to redump the textures for whatever version you are going to, and then match up the new filenames and formats. I had done this with my perfect dark pack, and although I didn't have a lot of textures made at the time, it was still fairly hectic.

[Terranigma]

Yeah, this is going to be annoying for the texture makers, but hey, nothing's ever easy. I wish you guys the best of luck.

[mudlord]

Well, in reality more like non-power of 4 widths. If you've got an stored image that is Width 0x15 x Height 0x15, the game will need to pad the texture to be 0x18 x 0x15, then it will be used. I may be misinformed, or at least Goldeneye does it this way. It's possible it's just for simplicity, but not sure.

Hmmm, never knew that..Thanks for letting me know. It could be a microcode thing, too, in how the games handle texture management. But I know Jabo's plugin uses NPOT textures (he said so himself when commenting on current texture issues in his plugin on the official 1.7 beta forum).

[Cyberman]

Hmmm, never knew that..Thanks for letting me know. It could be a microcode thing, too, in how the games handle texture management. But I know Jabo's plugin uses NPOT textures (he said so himself when commenting on current texture issues in his plugin on the official 1.7 beta forum).

Jabo is using Direct X correct? PowerOfTwo Textures are primarily an issue with OpenGL? I seem to remember OpenGL liking those better.

Cyb

[mudlord]

Jabo is using Direct X correct? PowerOfTwo Textures are primarily an issue with OpenGL? I seem to remember OpenGL liking those better.

Jabo is using DX8, and polling some driver caps for NPOT textures, as well as shaders. With OGL , your right, there is a custom GL extension for handling non power of two textures, but it seems Rice wrote the texture handling code at a time where these hardware features were unavailable....So your right . With OGL, its much less of a mess doing NPOT stuff than DX...

[Toasty]

If you had the original texture packs, one ripped by Rice's plugin and one ripped by Jabo's plugin, wouldn't it be possible to automate the conversion of a hi-res pack from one naming convention to the other? For example, a program could compare the original textures ripped from both plugins, then when it finds a match it could look through the hi-res pack for a file with the same name as one of the original textures and rename it to the corresponding (ripped by the other plugin) texture's name. Or am I missing something?