Aristotle's Mudlord & Rice Video

[squall_leonhart]

Cyberman just WTF'd me.

 

[X-Fi6]

K so, how does this release by Aristotle differ from the lost-source-code 6.1.4? Is one technically better than the other?

 

[Aristotle900]

K so, how does this release by Aristotle differ from the lost-source-code 6.1.4? Is one technically better than the other?

The source actually compills now, the fog effect is fixed, texture caching fully works (No longer re-loads graphics, for now, it's not an option and you will need a nice amount of RAM, like 256MBs or more. I will add an option for it later.), texture handling is improved thanks to Microdev, and I'm about to make that release shortly after I post this. I will edit this post with it. I still need to get pre-loading going..Then texture loading will no longer halt the games, which gets annoying. Atleast now it only happens once.

Gitech: I'm not sure if I'm doing something wrong and it just keeps working for me my way, but even your smaller graphics won't load for me.. Like the one of the the new Yellow sun, for the time of day at the top of the screen, even when I made it smaller. I took the one from the old pack, resizing it to the size of your new sun, and it showed up on this plugin..I even copied the sun graphic from the new pack, pasted it over the old sun from the official pack, resizing it to your new pack, and it shows up.. Even if something is wrong with the plugin, and I have yet to see where this problem is, I am 80% sure something is up with your newer graphics. Unless my Thinkpad is that picky or the plugin..I don't know. I guess I'll removing error handling or something so they load. I'll keep trying.

Cyberman: Thanks..But that totally confused me. :huh: I'm going to keep releasing it this way, keep backups of the current source on laptop and Flash Memory Card, and any past releases can stay online at the hosting site. I get mixed up making bunches of copy's, but it is better to do that, I agree. Now this source change, logging..? Don't need that. Anyone can read over what is changed. also, commenting this source will take forever. >.> I'm just going to keep working at it, and probably put comments in as I learn areas.

Mudlord: Thanks for that information on Structures, that helped me a bit with some areas in the rendering section.

 

[microdev]

Mudlord just confirmed it. This version of the plugin only has the ability to load textures up to 4x the original texture size.

Try it by downsizing any large texture from my newest pack to 256x256 or 128x128 (it depends on what the original texture size is) and let me know if it appears in game.

Yes, it's true that the currently available version of the source code just supports 4x textures. That was one of the reasons why I doubted that we are working on the most recent code. Which has been confirmed in the meantime. But concerning the hires size support this is very easy to fix.

@Aristotle:
Just change the function FindScaleFactor() in TextureFilters.cpp like shown below & all hires textures of gitech will show up:

int FindScaleFactor(ExtTxtrInfo &info, TxtrCacheEntry &entry)
{
    int scaleShift = -1;
    // load hires textures with original size
    if( info.height == entry.ti.HeightToLoad && info.width == entry.ti.WidthToLoad )
    {
        scaleShift = 0;
    }
    // load hires textures with 2x size
    else if (info.height == entry.ti.HeightToLoad*2 && info.width == entry.ti.WidthToLoad*2 )
    {
        scaleShift = 1;
    }
    // load hires textures with 4x size
    else if (info.height == entry.ti.HeightToLoad*4 && info.width == entry.ti.WidthToLoad*4)
    {
        scaleShift = 2;
    }
[B]    // load hires textures with 8x size
    else if (info.height == entry.ti.HeightToLoad*8 && info.width == entry.ti.WidthToLoad*8)
    {
        scaleShift = 3;
    }
    // load hires textures with 16x size
    else if (info.height == entry.ti.HeightToLoad*16 && info.width == entry.ti.WidthToLoad*16)
    {
        scaleShift = 4;
    }
    // load hires textures with 32x size (although I don't know if that makes sense...)
    else if (info.height == entry.ti.HeightToLoad*32 && info.width == entry.ti.WidthToLoad*32)
    {
        scaleShift = 5;
    }[/B]

    info.scaleShift = scaleShift;
    return scaleShift;
}

The save method I use in Photoshop is: Merge Visible, CTRL-S. (oh, and I never use/allow a background layer, not sure if it matters though, I just don't like locked "background layers" )

Your approach should be ok. The only requirement should be that you don't use the background layer - which you didn't. Painting the hires textures on the background layer will prevent them from showing up in the game. That was an experience I had to make at coding HighResEaser.

After having another look on the code I can say the following concering my findings so far:

The reason for the slowdown with 2 textures having the same CRC (the first crc, not the second crc value which is the pal-crc) seems to be as follows:

1. The texture cache lists are checked if they contain this texture
2. If the texture is found it will be used & displayed
3. If it is not found, it will be reloaded from file system (which causes a slow down)

So far, so good. But what happens now is:

1. Texture A with crc 58E2333F is written to the list
2. Texture B with crc 58E2333F is written to the list
3. Unfortunately it seems like the key for the textures is only generated by using the crc & the pal crc is ignored
4. In the next cycle the system tries to lookup texture A in the cachlist & finds the key in the list
5. But as explained above, only the crc value generates the key for the lookup & therefore texture B has overwritten texture a in the cachlist
6. Now other texture attributes are compared with the cachlist entry to assure, that the texture is really the right one.
7. Of course it isn't and therefore it is reloaded from the file system, added to the cachlist & overwrites texture B.
8. and so on and so on - voilà you got the slowdown...

==> All the changes we did to the code before are without any effect concerning speedup as this version has already been faster than Mudlords last release. Try it by compiling the sources w/o any changes.

Correct me if I'm wrong

Btw. a compile under DirectX9 works by far better for me than DirectX8.

Well, it looks like there is really a wrong calculation of the texture id.

For example in function CheckTextureInfos():

     ...
    // crc64a = 0x0000000058E2333F if crc=58E2333F
    uint64 crc64a = entry.dwCRC;
    // I think the intention was to shift the crc 8bytes to the left but for that not <<32 but <<20 has to be used
    //    crc64a <<= 32;
    // crc64a = 0x58E2333F00000000
    crc64a <<= 20;
    // crc64b = 0x58E2333F00000000
    uint64 crc64b = crc64a;
    // crc64a = 0x58E2333FFFFFFF20 if format is 2 and size is 0
    crc64a |= (0xFFFFFF00|(entry.ti.Format<<4)|entry.ti.Size);
    // crc64a = 0x58E2333FDFB44820 if palcrc is DFB4484F, format is 2 and size is 0
    crc64b |= ((entry.dwPalCRC&0xFFFFFF00)|(entry.ti.Format<<4)|entry.ti.Size);
                ...

To me it makes sense but when I change this behavior to the one - I think - was the intended one not all textures load anymore what means there is still no match in some cases. Of cource one have to change it at all occurrences.

Did someone manage to successfully compile the DebugD3D9x plugin version and run it in hires mode w/o crashing? This would drastically ease the debugging. But so far it allways crashes for me when it tries to load hires textures. The release version works fine.

 

[Aristotle900]

I added the repaired scaling code, in this release too. Why it didn't work for me like this, will never be known.

Download

-----------

1/3/09 - Version 6.1.7

Microdev:
-Fixed some texture handling slowdowns-
-Fixed texture scaling code, All textures load now-

 

[mudlord88]

Just change the function FindScaleFactor() in TextureFilters.cpp like shown below & all hires textures of gitech will show up:

Why not make it allocate a scalefactor without limits (so you can get even crazier tex limits)? GlideHQ does this just fine......

 

[gitech]

Downloading and trying.

WOW! Just the info presented here and the work that's being done almost brings tears to my eyes.

Thank you,
Jay

 

[microdev]

Why not make it allocate a scalefactor without limits (so you can get even crazier tex limits)? GlideHQ does this just fine......

Sure, if it is actually needed, it is no deal to make it completely flexible. But it is up to Aristotle to decide if he want's to add it. I'm just contributing a view things here & there.

But do you want to/can say anything about the crc issue? I think this might be the bug, that Gonetz identified in the hires code of Rice. I think not all textures are diplayed anymore if I correct it as the calculated keys than are differing from the wrong one's that have been calculated before.

I added the repaired scaling code, in this release too. Why it didn't work for me like this, will never be known.

What do you mean with that? Are the textures not showing up for you?

 

[X-Fi6]

Nice.

 

[squall_leonhart]

The source actually compills now, the fog effect is fixed, texture caching fully works (No longer re-loads graphics, for now, it's not an option and you will need a nice amount of RAM, like 256MBs or more. I will add an option for it later.), texture handling is improved thanks to Microdev, and I'm about to make that release shortly after I post this. I will edit this post with it. I still need to get pre-loading going..Then texture loading will no longer halt the games, which gets annoying. Atleast now it only happens once.

Gitech: I'm not sure if I'm doing something wrong and it just keeps working for me my way, but even your smaller graphics won't load for me.. Like the one of the the new Yellow sun, for the time of day at the top of the screen, even when I made it smaller. I took the one from the old pack, resizing it to the size of your new sun, and it showed up on this plugin..I even copied the sun graphic from the new pack, pasted it over the old sun from the official pack, resizing it to your new pack, and it shows up.. Even if something is wrong with the plugin, and I have yet to see where this problem is, I am 80% sure something is up with your newer graphics. Unless my Thinkpad is that picky or the plugin..I don't know. I guess I'll removing error handling or something so they load. I'll keep trying.

Cyberman: Thanks..But that totally confused me. :huh: I'm going to keep releasing it this way, keep backups of the current source on laptop and Flash Memory Card, and any past releases can stay online at the hosting site. I get mixed up making bunches of copy's, but it is better to do that, I agree. Now this source change, logging..? Don't need that. Anyone can read over what is changed. also, commenting this source will take forever. >.> I'm just going to keep working at it, and probably put comments in as I learn areas.

Mudlord: Thanks for that information on Structures, that helped me a bit with some areas in the rendering section.

You should keep the source on googlecode, that way more people can contribute fixes, and ideas, and patches etc,

Btw. a compile under DirectX9 works by far better for me than DirectX8.

No it doesn't, it causes VM Allocation issues in the emulator whenever you open the plugin select screen on both versions of pj64

 

[microdev]

No it doesn't, it causes VM Allocation issues in the emulator whenever you open the plugin select screen on both versions of pj64

No, not for me. At least I don't see any error popping up, any strange behavior, unusual high memory usage or what so ever...

But it might be different for you. That's why I wrote that it works best for me.

 

[gitech]

Good news on my end!

Works as advertized! Great!

All textures show up and speed is up ~20-30% durring CRC bug slowdown such as the knights hallway in the castle center and for Spider Queen Algenie.

Also, texture loading between scenes is slightly faster.

It's better and congratulations!

Now just the texture preloading, and fixing the bug right?

With the CRC bug fixing, I would be willing to do the required name changing of the bad texture names in my pack as I already have them separated for the most part (trouble textures folders).

Thank you,
Jay

 

[Sparx]

I'm having some trouble getting Aristotle's plugin to load hi-resolution textures. I've provided as much detail as possible to help get to the bottom of the issue quickly and efficiently. Here's an exact timeline of what I did:

1) Moved old RiceVideo6.1.0.ini file into a backup folder
2) Copied files to/from my pj64 emulator and plugin directories
3) SSB & Star Fox64 immediately stopped working after loading the hi-res texture packs (default settings). I tried rendering with both DirectX and OpenGL.
4) Both games loaded fine with "load hi-res textures" unchecked
5) Downloaded and installed Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) from Microsoft's website as mentioned by gitech.
6) Again, both games stopped working after loading hi-res textures.
7) Hi-resolution texture packs still work with Mudlord's 6.1.3 and 6.1.4 releases. I still can't get SSB to work without crashing with the newest hi-res pack, but that's a separate issue.

I'm using Jabo's DirectSound 1.6 and N-Rage's Direct-Input8 V2 2.00b. I have a Core 2 Extreme X6800 with an Nvidia GTX 260 running a fullscreen resolution of 1680x1050. I use Windows Vista 32-bit.

Questions:
1) Is there an error log I can refer to so I can fix the problem? The only logs created in the "logs" folder of the PJ64 root directory are for DirectInput 7 and DirectSound.
2) I took a programming class this semester in C# (and did well). Is there any way I could port some of this knowledge to help develop this plugin? I'm familiar with VisualStudio 2005 and 2008.
3) Can I use VisualStudio to debug the problem? Vista gives you this prompt whenever a program stops working and allows you to debug it using VisualStudio.

@gitech - Those screenshots comparing DirectX and OpenGL were helpful! Thanks for taking the time to post them.

 

[gitech]

Hi Sparx,

I have no idea, but try using Jabo's direct input? I seem to remember strange crashes with nrage as the input plugin.

My newest "as is" release has controller profiles in it for Jabo input to make it easy for you to use. I use "...-2" while retexturing and "...-3" while playing. It's up to you which one you like better for play.

Thanks for your contributions,
Jay

 

[squall_leonhart]

never had an issue with nrage v2.1 :\

No, not for me. At least I don't see any error popping up, any strange behavior, unusual high memory usage or what so ever...

But it might be different for you. That's why I wrote that it works best for me.

its not an unusually high memory usage, its the Dx9 plugin being locked into a memory range required for pj64 to start emulating a game.

 

[gitech]

New bug to report: Full Screen Flicker

With your latest build I get "screen flicker" while in full screen sometimes. Most noticeable/reliable location this occurs is during the "intro movie" for Cornell's quest.

TTYL,
Jay

Edit: Ok, I was using 1360x768 for full screen. I just changed it to 1920x1080 and then back to 1360x768 and it went away. (?)

But, I let the game begin and I found a new problem while on the deck of the ghost ship.

The texture surfaces are flickering, whether in full screen or windowed mode.

Any ideas?

Pic:

 

[Aristotle900]

New bug to report: Full Screen Flicker

With your latest build I get "screen flicker" while in full screen sometimes. Most noticeable/reliable location this occurs is during the "intro movie" for Cornell's quest.

TTYL,
Jay

Edit: Ok, I was using 1360x768 for full screen. I just changed it to 1920x1080 and then back to 1360x768 and it went away. (?)

But, I let the game begin and I found a new problem while on the deck of the ghost ship.

The texture surfaces are flickering, whether in full screen or windowed mode.

Any ideas?

Pic:

I always have this problem with the ghost ship. It's to do with some of your graphics conflicting, oddly, but it's the plugin's fault. I don't know how to fix it, but I've always removed the graphics that cause that problem for me, even at 640x480. >.> I think that's related to the CRC bug. The CRC problem, is in an area of the coding that I'm totally lost in, I'm still learning C++ and all, so I don't think I'd be able to fix it anytime soon. It's too confusing for me as a newbie. :sleeping:

Okay, time once again, to get Texture pre-loading to work.

And great work Microdev on the speedups, and scale fix. My last post did sound confusing..I meant, I didn't seem to have a scaling problem. Anyway, it's working great now.

 

[gitech]

That's so odd.

While continuing testing I found it does this with MRV 6.1.4 now too.

It never used to for me (pretty sure). What could have changed to make it happen with 6.1.4?

Could it be with the config file?

I will try the old one.

Jay

Edit: Nope, still flickering.

Looking closely at the pic above it looks like the "blank" parts are like a "ghost" just a few pixels over from the "game" itself. Like you can see his right hand and just next to it is the "blank ghost" of it. Look at the ships "railing posts" and the net on the side as well. The "blank" parts are "shifted" over.

Any one know why this happens/what this is?

Thanks,
Jay

 

[microdev]

That's so odd.
Any one know why this happens/what this is?

Could you post a savestate, please?

And great work Microdev on the speedups, and scale fix. My last post did sound confusing..I meant, I didn't seem to have a scaling problem. Anyway, it's working great now.

ah, ok. Yes the scaling function deals with the hires scaling.

 

[gitech]

Could you post a savestate, please?

Here: http://www.megaupload.com/?d=95D409HK

Thanks,
Jay