Menu
What's new
By:
Filters
  • 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.

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

G

gitech

N64 Artist
I am no programmer so forgive me if I don't really know what I am talking about in my explanation:

1. It seems that the problem is textures that are similar in some way are dumped with the same CRC. (?)
2. Slowdown occurs only when they are up-sized and two or more of these textures are on screen at the same time.
3. They are always _ciByRGBA.png type (ci_by_png) textures.
4. _ci.bmp (ci_png) doesn't dump all textures/any of the CRC dupes (because the CRC is the whole name right?)
5. They are not redundant dupes. They are different and necessary textures that happen to have the same CRC portion of their name.

Maybe the plugin is thinking it's looking for/processing them as "_rgb" and "_a" files because those have the same CRC? ie...it's looking for textures that are more than 1 file with the same CRC?

Background:

A couple of days ago I was working on the LAST boss I have to retexture in LOD...the spider queen boss...when for the first time...a boss itself contained what I call "Trouble Textures"! Causing severe slowdown. From 60 fps down to ~10 fps! Needless to say I was...insert profanity...

This made me stop and look more closely at these "trouble textures" that were slowing down this scene.

The textures slowing it down are:

1. The "spider legs" texture used for her "hair" (CASTLEVANIA2#58E2333F#2#0#DFB4484F_ciByRGBA.png)
2. The "spider legs" texture used for her "legs" (CASTLEVANIA2#58E2333F#2#0#D7A5C6D9_ciByRGBA.png)

First I noticed was it was 2 textures.
These two textures were the same size. (original dump size)
These two textures were the same "design", only with different color.
Then I noticed they had the same file name...almost.

So I went over to another "trouble texture" folder to see if the same similarities applied to other trouble textures I had found before. They did. Ah-ha!

So I spent hours looking for other textures that have the same first part of their file name. I think it's called the "CRC" portion of the file name.

I found a ton! All of them were the same size as their dupe(s), but not all of these textures I found create slowdown during the game.

What I realized was it's only textures that happen to be on screen at the same time as their "CRC dupes" that cause slowdown during play.

This is why when there are say 2 different color Armor Knights or 2 different color Skeletons on screen, slowdown occurs. The same applies to backgrounds too such as the carpets, walls, doors, door handles, chairs and paintings in the Villa. I found over 100 of them in the Villa! But, again it's only when 2 or more of them have to be drawn at the same time that it slows down. As soon as you enter the Villa mansion (the foyer with the stair case) is a great example. Their are a lot of trouble textures in there.

Here are the two textures with the same CRC for the spider queen and a save state right before the fight begins for your convenience during testing:

1. To experience slowdown, just make one or both of these textures larger.
2. To crash the emulator, go back to the game without re-loading textures.
3. To see the object disappear, return it to it's original size and return to the game without re-loading textures.

Anyone else ever experience any of this before? I've typed all this up because I know Mudlord is very busy right now and maybe we can "think tank" this over to save him valuable time.

Textures and save state download: http://www.megaupload.com/?d=AC5YRQXT

Edit: You'll need to choose save state 4 in PJ64 for the above download. ;)
 
Last edited:
MasterPhW

MasterPhW

Master of the Emulation Flame
I've tested it and confirmed it.
If you resize this two textures to 8x the VI/s drop down to 15-20 and at 4x they drop to 40-50...
Had this problem with some textures on my texture pack aswell, but fixed it with smaller textures (I have nearly all 8x, but that "trouble textures" in Castlevania are even badder...)
Btw: you have to use PJ64 and change the savestate name to "...PJ.zip" instead of "...PJ4.zip" to get it loaded with "load savestate" and the textures have to be into a folder called "CASTLEVANIA2". And the mempack isn't needed... :p
 
Last edited:
OP
G

gitech

N64 Artist
Yep, the download is for PJ64 and you have to choose save state 4 or do what MasterPhW said with the file name to load the test. I included my mempack file in the download but it turns out you do not need it to perform the test. Replacing your own mempack file with mine would erase all of your mempak saves, if you don't make a backup of it first. To be safe, don't use it (over right your own mempack file) unless your sure of what you are doing so you don't erase all of your mempack game saves. ;)

Thank you MPHW for your assistance so far! ;) It has been a great help! :) Good luck with your exams!!!
 
Last edited:
mudlord

mudlord

Banned
1. It seems that the problem is textures that are similar in some way are dumped with the same CRC. (?)
Click to expand...

No, these textures don't have the same checksum.

5. They are not redundant dupes. They are different and necessary textures that happen to have the same CRC portion of their name.
Click to expand...

Again, no. They don't have the same checksum.

Maybe the plugin is thinking it's looking for/processing them as "_rgb" and "_a" files because those have the same CRC? ie...it's looking for textures that are more than 1 file with the same CRC?
Click to expand...

Wrong, yet again.

1. The "spider legs" texture used for her "hair" (CASTLEVANIA2#58E2333F#2#0#DFB4484F_ciBy RGBA.png)
2. The "spider legs" texture used for her "legs" (CASTLEVANIA2#58E2333F#2#0#D7A5C6D9_ciBy RGBA.png)

First I noticed was it was 2 textures.
These two textures were the same size. (original dump size)
These two textures were the same "design", only with different color.
Then I noticed they had the same file name...almost.

So I went over to another "trouble texture" folder to see if the same similarities applied to other trouble textures I had found before. They did. Ah-ha!

So I spent hours looking for other textures that have the same first part of their file name. I think it's called the "CRC" portion of the file name.

I found a ton! All of them were the same size as their dupe(s), but not all of these textures I found create slowdown during the game.

What I realized was it's only textures that happen to be on screen at the same time as their "CRC dupes" that cause slowdown during play.

This is why when there are say 2 different color Armor Knights or 2 different color Skeletons on screen, slowdown occurs. The same applies to backgrounds too such as the carpets, walls, doors, door handles, chairs and paintings in the Villa. I found over 100 of them in the Villa! But, again it's only when 2 or more of them have to be drawn at the same time that it slows down. As soon as you enter the Villa mansion (the foyer with the stair case) is a great example. Their are a lot of trouble textures in there.

Here are the two textures with the same CRC for the spider queen and a save state right before the fight begins for your convenience during testing:

1. To experience slowdown, just make one or both of these textures larger.
2. To crash the emulator, go back to the game without re-loading textures.
3. To see the object disappear, return it to it's original size and return to the game without re-loading textures.

Anyone else ever experience any of this before? I've typed all this up because I know Mudlord is very busy right now and maybe we can "think tank" this over to save him valuable time.
Click to expand...

Again, no no and no.

The textures are different. The 1st two portions of the file naming convention are the ROM identifiers. What is really the CRC is this:

CASTLEVANIA2#58E2333F#2#0#DFB4484F_ciBy RGBA.png
CASTLEVANIA2#58E2333F#2#0#D7A5C6D9_ciBy RGBA.png

Those highlighted portions are the texture CRC. Jabo done away with the complexity by simply using RGBA PNGs and MD5s in his plugin. Which I reckon is cool as its super simple to understand, and plus, MD5s are much more cryptographically secure than CRCs (anyone doing computer science or networking would know this). But thats best left explaining elsewhere.

The point is, the textures are different. The CRCs say so.
 
OP
G

gitech

N64 Artist
Hehehe...I am dumb! But I tried. ;) I do not know anything about programing!

Thanks for helping me understand mudlord! So every time I used the term "CRC" I was using the wrong term.

What is the correct term for the first set of identifiers within the file naming convention? The ones that are the same in these textures?

I will take what I learn from you and do some research to educate myself so I am not so ignorant when it comes to this. ;)

So, do you think there is a way to fix it? Theoretically at least as I know it's exam time right now?

BTW I wish you the very best with your exams! :)
 
Last edited:
X-Fi6

X-Fi6

New member
Yeah remember with things like CRC it's completely digital. It's either that the CRCs are exactly the same or not alike at all. Nothing in between.
 
OP
G

gitech

N64 Artist
Nevertheless, there is something about the fact that the first part in the name the of these textures being the same is causing a phenomenon.

Before I go on with what I have spent 100's of hours learning so far...

I have one question that needs to be answered first:

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

There is an answer to this simple question. I know I have read it somewhere last year in a thread that compared the differences between the file naming convention used by Rice and Jabo. I can not find it again.

Please, if you know the answer, please post it. It will help me speak using the correct terms when explaining what I have found and possible solutions.

Thank you. ;)

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

(CRC, CRC1, CRC2, CRC-32, MD5, other, ya' know?! I do not know. Please help me understand this and what they do)
 
Last edited:
Cyberman

Cyberman

Moderator
Moderator
Either they have the same palette (the first number is either the bitmap CRC or the palette CRC) or the same bitmap. the CI means COLOR INDEX :D
donno about which are which, however #12345678 and #12345678 are 32 bit CRCs one for the CI/palette data and one for the bitmap data. The other 2 numbers are probably BPP and a color index or how the bitmap is used (IE transparent etc)

Cyb
 
Last edited:
OP
G

gitech

N64 Artist
Thanks Cyberman! Though, does anyone know the complete answer to my question in post #7? Please. :)

It is just semantics as my proposed solution does not need this info, but I would like to get this answered before I post my idea for a SOLUTION that will not only retain the current functionality of the plugin but increase performance for ALL hi-res games during playback. ;) :) ie...it will be better for everyone! Just asking for a little help first so I don't sound like an idiot when I type.

Thank you. :)
 
M

Mollymutt

Member
I had a problem with SSB, when I was retexturing the characters, and there was four characters onscreen at one time. There was a massive slowdown even at 4x. I thought it was just the emulator, but gitech wanted me to add this to the thread, so all of the bugs could be ironed out of the plugin.
 
Cyberman

Cyberman

Moderator
Moderator
Bounty Source died? That stinks. You have a source forge account? That might work since it has a large distribution of places to download etc. Also CVS although I am partial to Subversion instead. GIT though looks good as well. I'm turn between these version control systems. CVS has direct support from Eclipse which is handy. Subversion gives better control and internal back up so you don't wipe out the repository with a silly mistake. automatic versioning is a good thing in this case. On source forge I'm cyberman.ff just in case you go with that. Cyb
 
mudlord

mudlord

Banned
Bounty Source died?
Click to expand...

Yep, BountySource went kaput. All projects that were on it, use SourceForge or thier own repository now. Like what happened with ZSNES's SVN.

You have a source forge account? That might work since it has a large distribution of places to download etc.
Click to expand...

Yep, I do. So I might look into SF hosting. Since thats much more stable.
 
X-Fi6

X-Fi6

New member
Well it's strange because

I don't notice any slowdowns at ALL with your two textures and load your savestate.

I'm using mudlord's continuation of Rice Video (6.1.4), and Glide64 Napalm. Neither give me any slowdowns.
 
OP
G

gitech

N64 Artist
Thanks for the attention and feedback guys! :)

X-fi6,

Can you confirm or have you tried this?

1. To experience slowdown, just make one or both of these textures larger.
2. To crash the emulator, go back to the game without re-loading textures.
3. To see the object disappear, return it to it's original size and return to the game without re-loading textures.

Here in lies the problem. You should have severe slowdown after increasing the textures size using MRV and no slowdown with Glide Napalm. I use 512x512 for this boss. Let me know...;)

I am now working on typing my latest observations and proposed solution...it will be up latter today.


PS: Sorry for the wait! I have also been working on Majora's Mask, Turok DH HD and Castlevania LOD, preparing re-texture tutorials for each at the same time and helping others with tons of questions. So I've been busy. ;)

You can preview some of this here:

Majora's Mask Retexture--> Pictures and Feedback

and here:

Retexture Project {{Turok}}***

With the permission of the thread starters/teams these will be mirrored here on emutalk. Along with a new dedicated retexturing tutorial thread I will be starting soon, and a new post in my LOD thread with pics of the new re-re-textured Forest of Silence! ;) :)
 
Last edited:
OP
G

gitech

N64 Artist
First, about the bug because we can forget about it in a minute with my proposed solution a little further down in the post:

With MRV (Mudlords Rice Video), when you increase the size of even just one texture that has other textures with the same first part of their file name AND they are on screen (loaded) at the same, the game slows down due to the checking and updating (loading) of the texture(s) with every frame. In LOD the only thing that makes them different from the other 95% of the textures in the game that do not cause slowdown...is the same thing that they have in common with each other...the same first part of their file name((and size BTW)).

Moving on:

This is exacerbated by the way MRV only "checks" the texture file names in the hires_texture folder at startup (and upon loading a save state), and then only loads the current textures to be drawn from the hard drive on the fly during game play. (I think. I could be wrong about the specifics of what it is really doing ;) ) Though this is great and quick for retexturing as it updates the texture file name cache (?) quickly upon loading a save state to check your retexture work, this is not great for playback as it has to load the actual textures in real time on the fly during play. This also has another "stuttering" side effect I will describe in more detail further down.

In contrast Glide Napalm seems to load (or cache?) ALL of the textures themselves into main memory(or video memory, I don't know) during the plugins initial start up. It does not load or check the textures from the hard drive on the fly after all the textures are loaded at game start up, or when loading of a save state. Though this makes working with Napalm for retexturing impractical as it takes a very long time to load (or reload the textures by opening and closing the plugin options during play) all the textures themselves into memory from the hard drive.

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.

It could be a check box option in the Texture Enhancement tab named something like…

“load all hires textures into memory”

with a Tooltip saying something like…

“Select: this option for smooth playback when “Load hi-resolution textures if available” is enabled. Deselect: this option when working on a hires texture pack unless you run into slowdown caused by your larger texture size. Note: Selecting this option will use a lot of memory and can take a long time to load.”

As a beneficial side effect and advantage of doing this (and this is the part that can improve the performance of any texture pack playback for everyone) ...because Napalm loads the textures into memory from the start, the little stuttering we also see when any texture is loaded during play with MRV, is not present with Napalm. This frame rate stuttering that is caused by the loading textures on the fly is very apparent with MRV during the opening scene of a new game with Cornell of my Castlevania LOD pack. MRV stutters as it loads up the textures for the next scene.

With a new option like this, all retextured games would run smoother as textures would not need to be loaded “on the fly” during play. ;)


Note: looking into the “bug” itself could be beneficial still as it may lead to an undiscovered problem with the code, but with the above proposed solution, the bug is not only irrelevant to the solution but it makes things “better” for both retexture work and playback for everyone.

PS: Please be kind with my ignorance of correct terms. ;) ;)
 
Last edited:
Cyberman

Cyberman

Moderator
Moderator
mudlord said:
Yep, BountySource went kaput. All projects that were on it, use SourceForge or thier own repository now. Like what happened with ZSNES's SVN.
Click to expand...
Well it looked like an interesting idea but I kind of like what many projects do this day. Use SourceForge for project management/backend and have a different site for the forum and update page.

mudlord said:
Yep, I do. So I might look into SF hosting. Since thats much more stable.
Click to expand...
Ok dokey, let me know if you need anything (apart from your last source release that was on bounty source, don't have that). Hopefully with Eclox I can do an SVN branch.

Cyb
 
OP
G

gitech

N64 Artist
Hey, I got a new video for y'all! :D

Edit: (New link) Turok Lava Animation Retexture Video

Prepare to pause to read the text, when it slows down and increase in quality half way through. Let me know if the link works for you. ;)

How's it goin' mates? LTNS ;) :)
 
Last edited:
mudlord

mudlord

Banned
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.
Click to expand...

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.
 
Last edited:
You must log in or register to reply here.

Top