Research thread for slowdown fix, "Trouble Textures" = CRC dupes ?

[gitech]

Good news: Here is the new RV SVN
http://code.google.com/p/ricevideo/

Theres the code microdev.

The solution, without even addressing the "bug" related to the similar file names, would be an option incorporated into MRV that will allow a user to select whether the hi-res textures would be “checked” (as they are now) for fast reloading and checking while retexturing, or if the hi-res textures will be loaded fully into memory the same way Glide Napalm does to allow smooth playback without the “loading on the fly texture caused slowdowns” we are experiencing now.

No.

Glide64 Napalm, or to be more precise, GlideHQ, uses extremely unorthodox methods to optimize texture cache usage. Things like S3TC texture compression, using ZLIB to compress textures, as well as using Boost libraries to optimize file reading all play a role in efficient texture usage. Jabo's plugin eliminates all this via file streaming directly from the ZIP file, and only loading textures when they are needed.

Great to see your new project page up and running!

No? I tried.

So what does MRV do in regards to texture cache and loading? (I'd like to understand ) And is there a theoretical solution?


Edit: FYE: (New link) Turok Lava Animation Retexture Video

 

[microdev]

Good news: Here is the new RV SVN
http://code.google.com/p/ricevideo/

Theres the code microdev.

Thank you mudlord!

 

[gitech]

Bump...in the name of progress.

We, the entire retexturing community still needs a "texture caching option" for Rice Video that I proposed in post #17 on page 2.

Microdev, any luck?

 

[shaoranmps]

OHHHHHHH God i hope someone fix this

 

[cerebus5]

gitech are you working on a Turok texture pack? What's that vid all about?

 

[gitech]

I started to do a Turok texture pack for PSProgramer because it was his first attempt but he has dropped it I think. Some day, once the emulation bugs are worked out I may pick it up again. The project page for it can be found here: Retexture Project {{Turok}}***

 

[microdev]

What are the names of and what does EACH portion of the file naming convention do or mean?


Edit: The answer (may) look something like this:

(CASTLEVANIA2)(#58E2333F)(#2#0#)(D7A5C6D9)_ciByRGBA.png
(---------1--------)(------2-------)(----3----)(------4------)_ciByRGBA.png

1. ROM internal name = The internal name of the ROM. The purpose of this is..... It does this... ...ect...
2. ? = ?. The purpose of this is..... It does this... ...ect...
3. ? = ?. The purpose of this is..... It does this... ...ect...
4. ? = ?. The purpose of this is..... It does this... ...ect...

The format seems to be the following:

(CASTLEVANIA2)(#58E2333F)(#2#0#)(D7A5C6D9)_ciByRGBA.png
(---------1--------)(------2-----)(-3-)(-4-)(------5------)_ciByRGBA.png

1. Internal ROM name
2. The DRAM CRC
3. The image pixel size (8b=0, 16b=1, 24b=2, 32b=3)
4. The texture format (RGBA=0, YUV=1, CI=2, IA=3, I=4)
5. The pal CRC

==> <internal Rom name>#<DRAM CRC>#<24bit>#<RGBA>#<pal CRC>_ciByRGBA.png

 

[gitech]

Dude...nice!!!

So in this case it's the DRAM CRC that is causing the problem.

THANK YOU! Now I will be able to call it it's correct name!

I almost sounds like you've been making progress. Are you still looking into the texture caching option? No pressure!

PS: your answer couldn't be better! Thanks again!

 

[mdtauk]

The format seems to be the following:

(CASTLEVANIA2)(#58E2333F)(#2#0#)(D7A5C6D9)_ciByRGBA.png
(---------1--------)(------2-----)(-3-)(-4-)(------5------)_ciByRGBA.png

1. Internal ROM name
2. The DRAM CRC
3. The image pixel size (8b=0, 16b=1, 24b=2, 32b=3)
4. The texture format (RGBA=0, YUV=1, CI=2, IA=3, I=4)
5. The pal CRC

==> <internal Rom name><DRAM CRC><24bit><RGBA><pal CRC>_ciByRGBA.png

Can I just ask a theoretical question here...

Would it be possible to create say a master file, which matches the complicated filename to a filename and folder location. So for example...

"CASTLEVANIA2#58E2333F#2#0#D7A5C6D9_ciByRGBA.png" _=_ "/characters/soma/hair.dds"

So you can have more inteligable filenames and fodler structures, also, you could associate one texture to multiple uses, which saves on disk-space.

 

[microdev]

Can I just ask a theoretical question here...

Would it be possible to create say a master file, which matches the complicated filename to a filename and folder location. So for example...

"CASTLEVANIA2#58E2333F#2#0#D7A5C6D9_ciByRGBA.png" _=_ "/characters/soma/hair.dds"

So you can have more inteligable filenames and fodler structures, also, you could associate one texture to multiple uses, which saves on disk-space.

Well, possible is (nearly) everything. But I do not really see the advantage here. Because folders are already supported afaik &
if you would use such a master file, someone would have to do the mapping between the cryptical names and the speeking ones.
This part could not be automated & thus would cause a lot of work.

A compromise would be to allow the addition of a speaking part to the filename. That should also be easy to accomplish.

But I don't want to rise wrong hopes here. So far I just downloaded Visual C++and had a short glance on the source code.
I also realized that I'm far out of C++ as the last time I used it was 10 years ago.

So far I didn't even manage to compile the code as I don't have the D3D9 header files...

If I find some time in the future I will be happy to have a deeper look into it (especially to support gitech and his increadible work).
It should not be too hard to implement texture caching as one just would have to custimize the texture load function.

But once again, I can't make any promisses here without a high chance of disappointing you.

 

[Mollymutt]

One thing that would help immensely, is to have a feature that would recognize that a texture is already in the hi res folder, so it wouldn't be redumped. That way you would never come across duplicate textures being done.

 

[Xenobond]

Just don't remove any of the previously dumped textures. You can sort your directory by date. Makes it a lot easier to find stuff as they'll be dumped in intervals.

 

[gitech]

Yes, I do the same thing as Xenobond. For BH I have even begun a new thing to add to that. I will paste my hires textures back into the dump folders after I finish them so I can see what I have done and not done as well. It seems to be working well.

 

[Mollymutt]

Just don't remove any of the previously dumped textures. You can sort your directory by date. Makes it a lot easier to find stuff as they'll be dumped in intervals.

You're right, but that just makes the loading take forever. I usually delete the dumped textures folder before I start a new area. Another case for a texture cache option.

 

[shaoranmps]

Rice needs a texture caching option God or any other programer make that wish come true

 

[Cyberman]

Rice needs a texture caching option God or any other programer make that wish come true

What has that to do with this thread though? It seems a bit off topic doesn't it? Try asking stating or whatever in the right forum next time ... such as plugins maybe? Rice has a real life, maybe you should work on it?

Cyb

 

[gitech]

Rice needs a texture caching option God or any other programmer make that wish come true

Just wanted this^ post to be seen since it still holds true, and...

Bump this thread do to the revival of awareness, and new efforts into making this happen.

Thanks guys,
Jay

 

[gitech]

Aristotle900 and microdev,

Just wondering how things are going in regards to your progress on this.

No rush, just wondering.

I am IM'ing with eliteknight and Rice as well.

I am thinking we may be getting close to the point that we should all join an IM chat and talk as a group.

Can you PM me and we will start to work out the details on that.

I am going to try to coordinate this in some way that all of the talent (you guys) can work together and share your work and thoughts in some efficient manor.

Thanks guys,
Jay