New LLE RSP Plugin (accurate, fast but untested?)

[the_randomizer]

Originally Posted by FatCat

Umm, and that's an issue with zilmar's 1.7.0.9 PJ64 RSP but not mine?
Might be fixed by switching to another lle gfx?

And you saw my reply to your earlier bug post right?
Post #70 end of the previous page, just making sure you read my solution.

Nope, happened on your's too. Okay.

[HatCat]

Well, if it happened on both mine and zilmar's RSP interpreters I think it's safe to say it almost certainly can't be an RSP-related bug, but, you're welcome to help me test a saved state to help me find where in the game it happens or whatever if you have any disagreement.

[the_randomizer]

Originally Posted by FatCat

Ah, sorry I totally blacked that part of your post out, missed it.

Umm...it should not be possible to get any gfx at all when using Glide64 or Jabo's 1.6 (not 1.7 which features LLE gfx) with my LLE RSP dll??
It should require a LLE gfx plugin unless using the HLE versions of my plugin.

Anyway, regarding your report.
I'm not sure where in the game that is, but Conker's chin looks just fine when I use ziggy's OpenGL plugin. If I use Jabo's Direct3D then I have that issue you reported, but it appears to be a fault of the Direct3D renderer.

With z64gl by ziggy:


With Jabo's Direct3D 1.7 LLE:


So I would suggest that you try changing to a different LLE gfx plugin to fix the issue.

Never mind, it's fine now since I reset the ROM settings.

[HatCat]

I would most like it if people could test weird N64 ROMs, usually ones with special gfx microcodes most HLE gfx plugins don't support, things most likely to raise "error" messages in my RSP plugin so that I can comment their support more informatively.

I just tested Mario no Photopie actually.
Before I had to use Project64 RSP 1.7.0.9 to get any gfx to show.
Now that I support SP semaphore correctly using zilmar's new semaphore handler in PJ64 2.0, however, my RSP plugin sends the correct data....





First case I have ever seen of the semaphore mfc0 rewrites making a difference in emulation support.

[the_randomizer]

Originally Posted by FatCat

I would most like it if people could test weird N64 ROMs, usually ones with special gfx microcodes most HLE gfx plugins don't support, things most likely to raise "error" messages in my RSP plugin so that I can comment their support more informatively.

I just tested Mario no Photopie actually.
Before I had to use Project64 RSP 1.7.0.9 to get any gfx to show.
Now that I support SP semaphore correctly using zilmar's new semaphore handler in PJ64 2.0, however, my RSP plugin sends the correct data....





First case I have ever seen of the semaphore mfc0 rewrites making a difference in emulation support.

So essentially games from companies like Factor 5 or Rare that used unorthodox microcode? And also to report messages that pop up during the ROM boot execution?

[HatCat]

Definitely! Any message boxes from my dll, very good to know

Factor 5, Rareware, Boss Game Studios, ... a few other games using unique gfx.
I made a list a very long time ago; I don't remember.

Also games using special tasks like JPEG decoding (PKMN Stadium 1/2), HVQM video decompression (PKMN Puzzle League), other task types or stuff in Resident Evil 2, but that's not the best guideline to give you folks since you can never know just by playing a game whether it does customized tasks, just if video plugin supports it....

I'm going to download Neon64 homebrew image since angrylion said that was one of the ROMs entering a permanent loop caused by SP status signal semaphores. Any weird ROMs people can think of... go ahead.

[shunyuan]

Question:

How to test Gauntlet Legends with Project64 2.0 + LLE RSP?

I still can't let this game run will LLE RSP.

[HatCat]

You will have to use rsp_pj64.dll, not rsp.dll.

rsp_pj64.dll is the base RSP plugin with the following macros defined:

#define SEMAPHORE_LOCK_CORRECTIONS // Recommended only for CPUs supporting it
#define WAIT_FOR_CPU_HOST // Never use, except with some ROMs on Project64 2.

CPU semaphore wait corrections unfortunately will only work on Project64 2.0 as of this time, so this is currently the only way to play that game in LLE gfx.

[shunyuan]

Originally Posted by FatCat

I just tested Mario no Photopie actually.
Before I had to use Project64 RSP 1.7.0.9 to get any gfx to show.
Now that I support SP semaphore correctly using zilmar's new semaphore handler in PJ64 2.0, however, my RSP plugin sends the correct data....

But one year ago, someone already made this game run with Project64 1.6.1, and put a video on Youtube.

Search Youtube with "Mario no Photopie on Project64 1.6.1" then you can find this video.

[HatCat]

The challenge was getting it to work with LLE gfx.

Getting it to work on HLE gfx plugins is easy.