SoftGraphic graphic plugin

[GPDP]

Yeah, I tested this using SoftGraphic together with your RSP plugin, and I get a similar result, on top of the main menu not displaying at all. I then tried with z64gl, which does display the menus, but got the same graphical in-game glitches. I tried setting the core to Interpreter, but I get an error and the emulation stops.

I then tried it with mupen64plus, using z64gl and your RSP, and while there are a few glitches mainly concerning level geometry, it looks nowhere near that bad, and actually appears to be somewhat playable.

[HatCat]

That's a relief to hear.

I was afraid that after countless hours of literally copy-pasting the literal text from GoogleCode commit logs, making it 95% impossible that I mis-translated any of angrylion's code, that I'd somehow managed to screw up the RDP emulation in the process.

As for the bug it is one of few imperfections I have seen and very rare, so I'm still impressed. I'm sure he has more than enough talent to resolve it.

Meanwhile the naive and arrogant goal of approaching closer to full speed with this plugin is much more important to me.

[GPDP]

Still, now I am curious as to why Mupen64Plus displays the game with less glitches than Project64 does using the same plugins. Could the Mupen64Plus CPU core be more accurate, perhaps?

Although I sang its praises too soon, in any case. It froze on me eventually while looking around, and setting the core to Interpreter causes a Divide by Zero error right before Indy speaks when beginning the first mission. That said, before that happens, it does look like there's fewer level geometry glitches than on Recompiler.

[HatCat]

The VR4300 CPU recompiler does break some of the graphics in Project64.

The RSP CPU recompiler also does this, but I evade all hazards of a dynamic recompiler by weighing maximized performance of an accurate interpreter, vs. the static recompilers you guys all virtually use when doing GFX or audio in HLE (static code pre-readied by the HLE authors, better than dynarec's).

[GPDP]

I see, makes sense. Unfortunately it looks like Infernal Machine may be trickier to emulate than even Rogue Squadron. It has massive glitches in Recompiler mode, and seems to break in Interpreter on both emulators. And I'm guessing at this point it really does come down to the VR4300 cores on both emulators, unless I'm missing something somehow.

[shunyuan]

Originally Posted by FatCat

Ugh. Please tell me this is not something I did to this plugin.

The menu is also broken in my fork of angrylion r72.
This used to work in the MAME-based SDL plugin I maintained so what went wrong...

Or are other people having this bug, too?
Like with the dll posted in this thread (which I don't generally bother testing)?

Shouldn't you verify this kind of issues with angrylion's RDP, since you're porting his rdp?

[HatCat]

suanyuan, there is nothing to port.

angrylion's RDP is already a valid zilmar-spec-conformant plugin.
The code differences between his plugin and my build of it are far apart, but still there.

I have put enough work into my own independent changes away from his, that I would really prefer to not have to start over with his raw source files.

And besides that, I cannot stand, everything being clustered into one single source file (n64video.cpp).
I'll never tolerate that method of organization in my work space.

Originally Posted by GPDP

I see, makes sense. Unfortunately it looks like Infernal Machine may be trickier to emulate than even Rogue Squadron. It has massive glitches in Recompiler mode, and seems to break in Interpreter on both emulators. And I'm guessing at this point it really does come down to the VR4300 cores on both emulators, unless I'm missing something somehow.

It was perfectly rendered on the SDL version where I had none of angrylion's more independent, modern changes into it, just MAME code.

Something must have changed since then to break it.

Infernal Machine used a little bit of unique RSP code I have never seen, but implementing it was easy enough once I found out about it.
It shouldn't crash the interpreter CPU. Well, I won't speak for Project64 2.x. I use 1.6.

[angrylion]

Originally Posted by FatCat

It was perfectly rendered on the SDL version where I had none of angrylion's more independent, modern changes into it, just MAME code.

Something must have changed since then to break it.

The broken geometry is a core/CPU emulation bug, as was already discussed in z64gl thread at emutalk. The game only renders correct geometry in 1964 v0.8.4 / v0.8.5. The same applies to Battle for Naboo. It definitely couldn't render levels correctly with Ziggy's MAME SDL port, it's a lapse of your memory. If you think otherwise, please upload that binary.

[HatCat]

Not really, I believe you. I just forgot enough cases of the host CPU conflicting that it could have made that much of a difference.

I was probably using Project64 2.0 then. I tend to alternate between cores to cover more testing.
I most likely wasn't using 1964 though....

Originally Posted by angrylion

It definitely couldn't render levels correctly with Ziggy's MAME SDL port, it's a lapse of your memory. If you think otherwise, please upload that binary.

lol, I can assure you it wasn't that bad (at least as you pointed out, with the correct CPU)

Or did you forget that I didn't just take ziggy's z64 SDL plugin, re-build it myself and call it macaroni?
Before I encountered your plugin I merged all of the recent MAME commits related to accuracy, into ziggy's SDL rasterizer, and the results were very crystal nice on any game except for a few things here and there.

It looked more than perfect.
Shame I can't say the same for this DirectDraw version because it still keeps blurring half of the screen for both me and suanyuan but not at all for you for some reason. It's probably some build config neither of us know about.

But I have no intention of releasing my forked plugin using the DirectDraw code anyway. I want it to use something else.

[angrylion]

Originally Posted by FatCat

lol, I can assure you it wasn't that bad (at least as you pointed out, with the correct CPU)

I don't care if it was better or worse with one CPU core or another, because it has nothing to do with the RDP and it has everything to do with the CPU. Another game that has bad geometry presumably due to CPU issues is Battlezone -Rise of the Black Dogs. My RDP plugin renders Indiana Jones and Battle for Naboo without any obvious deficiencies in 1964 0.8.4/0.8.5. I haven't tested them in Project64 2.0 yet.

Originally Posted by FatCat

Shame I can't say the same for this DirectDraw version because it still keeps blurring half of the screen for both me and suanyuan but not at all for you for some reason. It's probably some build config neither of us know about.

There are no special build parameters. I link it in MSVC 2002 with ddraw.lib and dxguid.lib from DX8 SDK. So the cause of the fixated blur is either a bug in your GPU drivers, or your code changes, or some post-XP changes to the Windows implementation of DirectDraw, or some errors in MinGW versions of these two static libraries.