Rice's Plugin Source <discussion>

[klasa]

I was wondering...
In Paper Mario, when I save my textures as an png (with alpha layer) it seems that the game just sees... ehm... GIF-transparency (transparent on/off, if you get it )
Would there be a way to make the plugin, or game (dunno who'se the culprit) force to see the alpha layer?

And please, whatever you do with texture dumping, also put the palette in the filename. Because for things like the font in Paper Mario, it's a hella lot easier that you can just change something in that name to make an different colored font. If you had to get every letter+variation of the letter dumped...

 

[mudlord]

In Paper Mario, when I save my textures as an png (with alpha layer) it seems that the game just sees... ehm... GIF-transparency (transparent on/off, if you get it )

That doesnt seem right....unless they are dumped as RGB..(without the alpha channels) Does it occur with the official versions?

 

[Doomulation]

I created a dev ftp. I'll PM the ftp, username and password.
Feel free to PM around to whomever wants access.
I set quota to 100 mb. That should do plenty, right?
Also remember that the dev builds can only be accessed from the FTP. Try to get them off HTTP and you'll get a Forbidden error. So there.

Also, if you want, I could make two accounts. One for the developer, to upload and delete builds and one for the public, to download builds.
If there is anything else you need, you need only ask.

 

[mudlord]

A 100MB will be perfect. the current system is fine as is

Legend,

I checked out that Hydro Thunder prob, it works with build 46...but messes up with the later builds...sorta like the screen changing prob....

Whats weird though is that I got it to work on build 49, after messing with build 46....

 

[Iconoclast]

Three things.

One: Write Back & Reload and Basic & Write Back setting for Rice's are the two rendering-to-texture settings that have chances of crashing some games at some point (Star Wars RS, World Driver Championship, Stunt Racer 64, Gauntlet Legends, etc.) most respondingly on the 1.7 beta through returning errors like "interface.c" and things that have little to do with emulation. There is something in these two rendering-to-texture settings that causes problems in some games that don't in the other settings. Could be something required for them to work; could also be something nasty in the sourcecode or compilation process.

Gauntlet Legends, the only one of these games crashing with these settings BUT also using rendering-to-texture to fix issues, will only crash until you use Basic render-to-texture or lower and then back up to the crashing settings after getting through that point to survive without a crash, restarting the ROM and returning to the same point where the crash would normally occur (probably a thing with FX 5200s, I'm guessing).

Two: 5.9.9 has something in it that emulates Star Wars RS and Shadows of the Empire WAY differently, and in better ways, therefore requiring different INI settings. Turns out my INI config for RS was really for the 5.9.9 plugin...Whatever it is, these things should become options, if possible, for extra config improvement.

Three: It would be nice to change the window resolution as well as other settings DURING emulation if this can be achieved; would help things a bit for texture mapping accuracy tests.

 

[klasa]

Finally found some time to make the screenshot...
Here is how it looks with rice's last version, and the textures I've used.

 

[mudlord]

Finally found some time to make the screenshot...
Here is how it looks with rice's last version, and the textures I've used.

Brilliant! I'll see bout doing something bout that,in the next process of refining hi res textures, and adding Cyb's database engine.

could also be something nasty in the sourcecode or compilation process.

Main nasties in the compilation are the compression, which mangles the PE headers, compiler optimizations, and settings used when using threading runtime libraries. Recently, I switched BMGLib to use the same multithreaded runtimes as the plugin...

Two: 5.9.9 has something in it that emulates Star Wars RS and Shadows of the Empire WAY differently, and in better ways, therefore requiring different INI settings. Turns out my INI config for RS was really for the 5.9.9 plugin...Whatever it is, these things should become options, if possible, for extra config improvement.

Hmmm, I'll see bout getting the source to 5.9.9....

Three: It would be nice to change the window resolution as well as other settings DURING emulation if this can be achieved; would help things a bit for texture mapping accuracy tests.

That is possible, the windowed res code needs to be changed to resize the main emulator window (which is simply a case of Win32 API use), since just unlocking windowed reses from being changed manifests with issues dealing with the main emu window,due to the window not being resized...heheheheh

And Legend, I double checked Hydro Thunder, it definately works with newest 1.7 builds. I'm using Jabo's newest sound plugin tho .

 

[Iconoclast]

Okay, and, also, I forgot something else.

You know how, when you want an animated GIF of something from an N64 game, you want to hold the screenshots button down with a very low FPS, and sometimes remove the background from the main object through animation editing?

Well, it's difficult to do with Rice's because of the JPEG compression. Obviously, it's still possible, but I hate JPEG compression, and it adds thousands of colors to images due to a simple loss of quality and makes optimizing to 256 colors much less pretty, having being impossible to restore to its original quality. That's why I'm stuck just pressing F2, Alt+PrtScrn, paste into AS, repeated, frame-by-frame of the animation.

I mean, I could use a plugin like glN64, which saves screenshots in .bmp, but I want to use either Rice's or Jabo's 1.7. Through retexturing, you can remove the background beforehand from the rectangular animation you are recording instead of erasing all those pixels after being pasted into an animation.

Better yet, maybe have a feature in Rice's that can continually log PNG/BMP screenshots for each frame until the user presses a key. All I want at least is an option to use PNG compression instead, which Jabo doesn't seem to be focused on right now.

 

[Legend]

Well, no games crash the emu like Hydro Thunder for me. Right after game boot, the emu crashes. It works PERFECTLY when I use OpenGL, but when I go back to DirectX, CRASH!! I tried toggling EVERY option for DirectX, but nothing prevents this. BUT, since no one else runs into this and I don't really care, its probably nothing for you to worry about.

 

[mudlord]

Well, no games crash the emu like Hydro Thunder for me. Right after game boot, the emu crashes. It works PERFECTLY when I use OpenGL, but when I go back to DirectX, CRASH!! I tried toggling EVERY option for DirectX, but nothing prevents this. BUT, since no one else runs into this and I don't really care, its probably nothing for you to worry about.

Sure you got the right RBD settings? Have you tried build 46 on it?

 

[Legend]

That was with all the PJ64s, including 1.6. And if it works fine on Opengl mode, then how could it be a RDB problem? But again, you have work to do, don't even worry about this.

 

[mudlord]

And if it works fine on Opengl mode, then how could it be a RDB problem?

Well, true. I havent payed much attention to the details of what you said about it..but since your willing to let this issue slide, meh...the game works flawlessly for me though. But its completely inexcusable that it wrecks up with your PC.. . It should have been perfect all along...but then, I guess perfection itself is quite hard to chase though...

 

[Iconoclast]

Thanks to Doomulation for the server space and mudlord for giving me participation, from here on I will be uploading my changes to the 5.9.9 and 6.1.1 plugin configuration files on the given FTP, and new ini updates will hereon be posted by mudlord on each plugin release.

So, as I came to review a question I was asked, I had a look at why I thought 6.1.1 was better for Rogue Squadron than 5.9.9. Turns out, I was wrong. They're pretty much the exact same for this game, though 5.9.9 is better for Shadows of the Empire. I thought that you needed Normal Color Combiner checked in 5.9.9 config but not 6.1.1 config to fix some issues. But then I thought, wait, why do I have Force Buffer Clear checked on 6.1.1? Duh! Obviously, back then, I was still learning about the risks of Rice's settings, although I could've sworn there was a reason...so yeah, they're about equal. Except, in the in-game emulation attempt, 5.9.9 is very hesitant but occassional with showing the GUI graphics, whereas 6.1.1 holds them on for longer.

This is my configuration for 6.1.1 for the United States version of this game.

{ec4ba2664fd9ad2e-45}
Name=Rogue Squadron
AccurateTextureMapping=1
NormalAlphaBlender=1
NormalColorCombiner=1
ForceScreenClear=1
FrameBufferEmulation=2
RenderToTexture=2
ScreenUpdateSetting=1

May as well use the same thing for 5.9.9 again as it turns out.

Accurate Texture Mapping only affects the N Logo bitmap at the very beginning of the ROM, whereas the graphics look slightly better with the setting disabled. Normal Alpha Blender if on will make the N Logo invisible but not affect any other area of the game with what can be seen using the plugin for now. All Star Wars games seem to be designed to not like this option being on, and as well as you may expect Normal Color Combiner. Force Screen Clear fixes afterimages of shitty alpha emulation attempts, screen update on VI origin update (NOT after screen is drawn) is the only setting that makes frame update constant and working throught the whole game, and hiding rendering-to-texture effects and frame buffer drawings I thought was necessary because Basic Framebuffer and Write Back rendering-to-texture are both settings that crash in the game at some point, so I took that as a sign.

 

[poly_pusher]

just wanted to say you're doing some great work. Would love to see more custom dx9 shaders utilized in n64 roms.

 

[mudlord]

thanks.

During coding there was a large number of changes to the renderer to pull those off...

First of all, it uses multiple render targets. The code creates a render target, like a framebuffer. All post processing occurs on the render target texture. Then the shaders do thier work, and its rendered back to the main screen buffer. This is very similar to how gulikoza's dosbox DX9 shader imple. works. Of course, there are issues on slow DX9 cards...it was fun though seeing them in action. But then again, there's more important things in the plugin to tend to, like the 1.7 probs, and updates to hi-res texture rendering. I admit I've been a bit lazy with working on this in the last few days, since I have currently other important things to tend to (university, mainly, got 2 programming assesment tasks to do...)

 

[toe_head2001]

Thank you my good man. One thing, I don't get it, why the discontinue of executable compression?

 

[mudlord]

One thing, I don't get it, why the discontinue of executable compression?

There was a interesting discussion a while back about what actual benefits this even offered...

One of the reasons for dropping it is to save RAM. Executable compressors generally add a extra section in the EXE/DLL as a loader for the compressed sections. One of the side effects of this, is that increased memory usage can be a issue, due to the decompressor decompressing the compressed sections into RAM upon init...

So, a tradeoff was done for speed over size. Plus,as you noticed, RAR compression does a decent job in keeping size down on download, so it seems a bit pointless compressing it anyway. Another benefit is that some antivirus programs sometimes detect the packed content (the executable data) as malware/viruses. This is definately the case for using packers different to the common ones (UPX, ASPack, etc...) like FSG, kkrunchy, MuCruncher, Petite etc..(even though they offer better compression than UPX)..

So thats basically why: The speed tradeoff and a workaround for overprotective virus scanners. Not to mention we need all the speed we can get since MS Visual Studio 2005 completely b0rks code by its optimizations which are insanely unstable with code like this....Oh well.

 

[mudlord]

Don't Post on the Developement thread.

Can you please refrain from asking those sort of questions in this thread? The other thread is meant for discussions like the question you asked. You'll see you got a answer in there (if only I was a mod, then I could look after my own threads....I can only dream I guess....)

BTW: The builds got a repack. It seems from that Icono noticed, signing didnt work on his legit version due to licensing issues with my version. Thus, to make myself legally indemnifiable, and to avoid the possible warning messages, archives are repacked with 7-Zip. WinRAR can still read them though.

 

[The Siskoo]

Hello,

I dont"t know if you're interesting by this, here some settings to improve some games :

- GT 64 Championship Edition (E) [!] --> Increase Texture Rec
- GT 64 Championship Edition (U) [!] --> Increase Texture Rec
- Mario Golf (J) [!] --> N64 Framebuffer --> Basic Framebuffer , Rendering to Texture --> Basic Render To Texture
- Mega Man 64 (U) [!] --> Increase Texture Rec
- Parlor! Pro 64 Pachinko Jikki Simulation Game (J) --> Increase Texture Rec
- Puyo Puyo 4 - Puyo Puyo Party (J) [!] --> IncTexRectEdge

 

[JHdD]

Good job it is a great plugin .
But could you host the files in a zip or rar archive (or make a self-extractor)?
Because I don't think that the "mainstream" pc user has 7Zip installed.

JHdD