"Static Interpreter"
 

Current releases and conversation moved to:
http://www.emutalk.net/threads/56919...rpreter-Plugin


Old info: The interpreter plugin has successfully outperformed Jabo's RSP re-compiler plugin for Project64 in games particularly with audio HLE'd (not handled by the RSP) and LLE graphics (emulated by the RSP). Today's RSP plugin included with Project64 2.x was modified by RPGMaster / LegendOfDragoon subsequently to adjust this gap so that the recompiler plugin is once again faster with that pool of games.

still won't boot RS unless Interpreter CPU Method is set in the debug menu :\

any instruction to compile your RSP project with VC and gcc? and how to configure to build a specific type of RSP?

he specifically said you don't need to do anything, it will just compile :p

Thanks, I will try.

You're not using the correct RSP plugin. :/

There is no Debug menu for anything of the RSP unless it's a zilmar spec #1.2 RSP plugin, and this is a #1.1.

Make sure per-ROM plugins for Rogue Squadron was not left at "RSP 1.7.0.9" because that is not the name of my plugin.

Using the recompiler with my plugin is impossible because it is interpreter-only. :)

The native C build is done with GCC/MinGW up-to-date packages all as of 04-10-2013 (latest RT, GCC core, binutils).

The C++ build was done by Microsoft Visual Studio 2010.
I have the project files somewhere, but I didn't upload them.
(I guess I will add the Visual Studio project files in the next package release, if I get enough bug reports/suggestions to upload a new version to the thread.)

They should be able to compile straight out of the box without any code changes, as long as your compiler supports ANSI C rules + `inline` keyword.

So just copy all that stuff out of the .7z\SRC folder, and compile the main file `rsp.c`. It should get straight to work. :)

Gauntlet Legends boots, but the audio crackles like hell. Suggestions?

I should note pressing F1 crashes the ROM and emulator.

I want to sent you a pull request with some fixes but can't find you on github/gitorious/googlecode/bitbucket/sourceforge

Hmmm it does crash on F1, and Shift+F1.

However it seems to only be this game, maybe WDC/SR64.
Any other game I tried seems to reset fine with F1 without crashing.

It probably is because of how zilmar manages the threading during the intermission of re-starting an SP task.
I can't really control that from within the RSP, so that bug is not on my end.

You might need to play with the AI update/VI refresh values in PJ64 RDB.
I guess zilmar never had much of a chance to since it was hard just getting this game to boot in the first place, let alone run at full speed.

I just tested this game on PJ64 1.7.0.48 with Jabo's 1.7 audio, sync-game-to-audio LLE on my RSP, the sound is perfect.
It is bad only on this current 2.0 EXE we are using, so it's because of his timing bypasses. I can't control how the core is doing the audio.

But if you do downgrade to that older EXE the audio should sound just fine.

It's a shame but I really can't test audio HLE....
AziAudio.dll hasn't HLE'd the audio ucode for Gauntlet Legends,
and I can't seem to get the new 1964 Audio Plugin to work anywhere except on 1964 :D but then my RSP doesn't initialize on 1964. :p (But I did that on purpose; they really need to fix that DllConfig bug on their end.)

Maybe I'll let Zilmar know of the regression, it's weird that the older beta works fine, but how it breaks in the newest. Now if I can only get World Driver Championship to work. I've yet to figure out which RDB plugin to use, too bad I can only have one in the folder at the time, otherwise they show up as ten duplicate names in the plugin selection window.

Not really a problem.
He might not even be able to control it himself necessarily.

The nature of interrupting and re-starting especially in a way that is meant for compatibility but not necessarily accuracy, does not mean for it to also be the most stable solution. To "fix" it he might have to cancel the support.

Could be wrong; it's just not my focus.

If possible you might prefer testing on PJ64 1.6 or MUPEN64; those will be void of the new audio timing bypass settings so that they don't factor into the equation of testing for accuracy.

For games like this though obviously it requires PJ64 1.7 or later.

Clicking the "About" button says "RSP Interpreter" for the normal rsp.dll, "Iconoclast's MLE Test" for the title if it's HLE gfx + LLE aud or the other way around, and "Basic RSP Simulator" if vid + aud are both HLE.

You just need rsp_pj64.dll to get World Driver Championship to work.
You need to use Jabo's DirectSound or zilmar's No Sound, not any other plugin.
e.g. AziAudio, zilmaraudio dll will crash the game at boot.

Huh, tried rdp_pj64.dll + Jabo's DSound 1.7.1 but all I got was a black screen, also set to interpreter, but I'll try again. What about the GPU plugin? I tried it with Jabo's D3D 1.7.1 and LLE but it looked horrible, and it won't even work on glide since it has funky uCodes.

Hmm I thought you said all you got was a black screen?

The GPU needs to be a LLE gfx plugin.
Jabo's D3D 1.7 ("1.7.1?" you don't mean "1.6.1" do you?) will work, but it has RDP emulation bugs, so the game's textures are a bit screwy. You're much better off using ziggy's z64gl OpenGL LLE plugin for better gfx with that game.

Make sure you don't have per-ROM plugins set.
e.g. your global plugins are different from the game-specific one you have assigned to World Driver.

If the RSP dll you're using boots up Gauntlet Legends, I guarantee you it will boot up World Driver Championship.
I'm currently in-game using rsp_pj64.dll and z64gl for the gfx plugin.

Sorry I forgot to go back and confirm this.

The issue happens with zilmar's RSP 1.7.0.9, not just my DLL.
So it almost certainly is indeed because of event handling with re-starting tasks for WDC/SR64.

Just making sure that it's not an issue I need to fix (heh, sounds funny I know).

So things I should do in the next release / zip upload:

• add vs project build config files so that people compile using the correct settings, maybe an easy MinGW invocation script to build all those DLLs easily too

Nothing else?
No error messages about corner cases and edge conditions I get to test in the RSP emulator?
Never-before-exploited features? :p


Otherwise I can only judge my RSP emulator to be perfect as of the current implementation. There might be one or two things I could still have done to speed it up faster.


Use `config.h`.

...

Yes i am, and Yes there is.

when the Debugger is enabled the Debug menu is displayed, and RS only boots with RSP CPU Method set to Interpreter.

No there isn't.

http://ft.trillian.im/785abe041074fd...aMtaWo01zc.jpg

From a fresh install of the public release I did just to screenshot without having my name in the title window.

There is NO debug facility for the RSP integrated into Project64 2.0 with respect to a #1.1 spec RSP plugin.

Then you are not using a #1.1 spec RSP plugin.

http://ft.trillian.im/785abe041074fd...pBOGcYGUS9.jpg

^ That's what it looks like with a #1.2 spec RSP plugin, the pj64 1.7.0.9 rsp.
Which means you are using the wrong RSP plugin. :)

Thanks for playing, bye.

Resident Evil 2 (U) v1.1 with LLE RSP, Jabo D3D8 1.7.0.57ver5, 1964Audio v2.7

- audio correct with 1964audio (include audio of movie)

- video error
project64 v2.0 gfx LLE, title screen not correct, video not correct (partial correct)
project64 v1.6 gfx LLE, title screen not correct, movie not correct (partial)
proect64 v1.6 gfx HLE, title screen not correct, movie not correct (partial)


I cannot test with z64gl plugin, this plugin will crash.

Remember that if you use HLE gfx, my RSP is not responsible for drawing the gfx.
All it does is set an interrupt, signal to the CPU and redirect the CPU host to call the HLE graphics plugin to handle the drawings.

My RSP plugin affects how the graphics look, *if* you are using LLE gfx.
HLE here means the control is external.

I'm aware of this; it's a known issue with Jabo's graphics plugin.
You should encounter the same issue when using zilmar's RSP 1.7.0.9 RSP.

The way to fix it is to check "Software rendering" in the advanced options since the Direct3D renderer doesn't even come close to parsing the data correctly yet.

http://ft.trillian.im/785abe041074fd...3jQyXrKj9l.jpg

http://ft.trillian.im/785abe041074fd...7vuUCrIRO4.jpg

Then this indicates that setting the RSP plugin per game doesnt work.

True...I forgot about that.
I stopped paying attention to changes in the Project64 core when it got down to things like that and the plugin handler.

I have no idea why but I almost never use per-ROM plugins on PJ64, almost always use them on mupen.
But I did just recently notice that per-game RSP is broken.

No matter. The whole configuration layout is undeniably flawed.
It should still be reproducible and interact just fine with the Debugger interface if the RSP plugin is only set globally.

My only fear is that once these regressions are pinpointed, how much coding will have to be done to fix them and properly re-test them. I can confirm that the RSP per-game configuration is definitely an issue.

Did a fast test of speed comparisons for RSP emulators.

I tested a) motionless logo screen of Mario64,
b) standstill file select screen in mario

Both tests with Project64 2.0 VR4300 interpreter, HLE audio on the No Sound plugin, LLE gfx.

5. RSP 1.7.0.9 RSP interpreter by zilmar
a. 24-26 VI/s
b. 56-58 VI/s

4. ziggy's port of the MAME RSP, before angrylion's WDC/SR64 hack (slower)
a. 32-33 VI/s
b. 69-72 VI/s

3. My rsp_lle.dll in this thread (again, as with the others, HLE audio, LLE gfx)
a. 38-39 VI/s
b. 75-78 VI/s

2. RSP 1.7.0.9 RSP recompiler by Jabo/zilmar
a. 50-52 VI/s
b. 93-98 VI/s

1. RCP HLE (This time, both audio and gfx are HLE; RSP is not executed.)
a. 301-302 vi/s
b. 166-178 vi/s

So Jabo's RSP recompiler is between 10 to 20 VI/s faster than my RSP interpreter.
My RSP interpreter is 6 VI/s faster than the z64 RSP,
z64 RSP is 8 to 14 VI/s faster than RSP interpreter for pj64 2.0

So apparently I hardly even came close (40% increase basing off z64 speed) to coinciding the goal of besting the accuracy of the interpreter, with also getting it to be fast as the RSP recompiler plugin.
But, oh well.
I can still play Zelda64 at full speed (at some maps I need HLE audio on my lowly 1.90 GHz Athlon).
and squall says Rogue Squadron is playing at full speed on RSP that I release here XD, then again he has like almost 4 ghz

More speed tests but this time with HLE gfx, LLE audio (removes intervention of RDP threading)

3. RSP 1.7.0.9 interpreter for project64

a. 160-166 VI/s ? (difficult to measure, flies by and fluctuates too fast)
b. 62-81 VI/s

2. rsp_mle.dll in this thread (my SP interpreter compiled for LLE audio, HLE gfx)

a. 212-216 VI/s ?
b. 92-112 VI/s

1. RSP 1.7.0.9 recompiler for project64 by jabo/zilmar

a. 274-277 VI/s ?
b. 146-164 VI/s

A much more logarithmic (sort of metric) relationship there.
It is obvious that the interpreter could never catch up without SSSE3 replicas of direct parallel vector executions of what goes on in the RCP.

but a) that's unfair (recompiler could do that too, not just interpreter)
b) Most people today couldn't use an RSP emulator needing SSSE3 so what's the point :)

nah, its mostly fullscreen during the menu's but missions with lots of updating geometry / effects brings it down to 30fps

Menus are easy. I guessed you meant the 3-D intro and such, that would have been impressive.

And star wars abi wasn't one of the ucodes Azimer reversed to work in HLE audio so no speed-up there; I don't recall seeing the ucode decompiled for the 1964 Audio Plugin (hle) either.

And there is no working hle gfx except if you use Lemmy's Direct3D off of nemu.

So, it isn't easy.
Maybe the RSP recompiler should be used for rs, but since that in its self is still far from full speed, I think I would rather investigate into why RDP emulation is so slow! Figure out why z64gl is barely faster than Jabo's LLE but still not fast enough.

Sort of shame though, z64gl is only faster with threaded=0 in the conf which atm on pj2 can't be applied without putting it under the Screenshots dir

It is weird, but I can get correct Resident Evil 2 title screen and movie with Zilmar's RSP plugin 1.7 and 1.6 and Jabo Direct3D8 v1.7 for both Project64 1.6 and Project64 2.0.

Your RSP plugin must handle graphics HLE differently from Zilmar's plugin.

There is no HLE gfx feature in the rsp dll.

You have to use rsp_hle.dll or rsp_mle.dll to get HLE gfx.
rsp_lle.dll or rsp.dll means you are not using HLE gfx, in which case you would need Jabo's software rasterizer to fix the pictures as would be needed on zilmar's RSP LLE (not HLE).

It helps if you keep only one, maybe 2 of the DLLs installed and stick only to them. There is not a whole lot to test about HLE RSP; they're just useful for speed.

I guess I needed to clarify this before.

If you guys think those "Use HLE gfx?" , "Use HLE audio?" checkboxes in the Project64 settings make one bit of difference, think twice.
They only affect the Rsp #1.2 spec.

The only way is to install the correct DLL if you're attempting to test HLE.
What you set in the Project64 options besides other plugins makes no difference there.

I know exactly what you mean, but this is not the case.

I chage your RSP plugin a little bit, add a configuration dialog box, enable graphics HLE & audio HLE code, and controlled with configurations. So, I can swith gfx & audio LLE/HLE rendering calls without change RSP plugin.

All other games work just fine for graphics HLE through your plugin, such as Mario 64, F-zero 6x, RR64, StarFox 64, CBFD and Kirby 64.

The only exception for me is Resident Evil 64.

Sorry I didn't make it clear about the modification I have made for your RSP plugin.

That's fine.

I personally didn't do an interactive config method because then I had to constantly check whether HLE or LLE was set every time there was a SP task, which slowed the plugin down just a bit in exchange for user convenience.
You are free to distribute your version anyway, post about it etc. as long as my legacy isn't uncredited. :p


So, what you're saying is,
- You'll use the exact same gfx plugin,
- The exact same emulator (stick to Project64 2.0 or 1.6 for both),
- but my original "rsp_mle.dll" has different HLE gfx than zilmar's RSP 1.7.0.7 HLE gfx for Resident Evil 2?

I know you can set HLE gfx in the config with the version you wrote but please just this time try to test with my original rsp_mle.dll to see if maybe it could be a bug with how you implemented the config, just trying to rule as much out as we can.

if so, where can I see the different gfx in re2?

I've heard you are now working together with these mupen64plus sellouts. I will not put any of my work into the pockets of these guys

I don't plan to distribute the modified RSP plugin since I know nothing about the RSP emulation and don't know how to fix the bugs of it (if any).


Go back to the topic, I tested with your build of rsp_mle.dll, and I got the same result for both project64 2.0 and 1.6.

So would you mind to take a look about it and let me know what the differences between your and zilmar's plugin for GFX HLE handling.

Yes suanyuan it seems you're right; I'm having a look at why the GBI processing is so different on both builds.
I was unaware there could be a bug with the simple HLE redirection, looking into it now.

pokefan999, I presume.

I have never worked with Mupen64Plus.
I did however get pressured into talking with Mupen64++ developer okaygo and involved in IRC chats etc. that way.
Mupen64Plus effectively was born because okaygo lost his other source code, so I didn't participate.

And if your idea of determining whether I have anything to do with them or not is accusing me outright and seeing how I react, I suppose you don't really have anything to contribute; that's okay. :)

The purpose of this thread is testing. The only thing I really need to see is very rare corner cases that will render a debugging message to the DLL, or bug reports. There is not a whole lot of other things to do with the RSP, you may find.

suanyuan, seems Resident Evil 2 initializes the OS SP task structure with zeroed data sent to *(DMEM + OS_TASK_OFF_DATA). How exactly this pointer is used I don't know since I don't work with HLE much, but neither Glide64 nor Jabo's HLE Direct3D seem to like it.
That's why Hacktarux's RSP interface shelled out of older mupen64 and Project64 1.6/1.7 RSP (but not pj64 1.4 RSP which still has the bug you reported) check to see if this pointer is 0 to know how to HLE it.

So I just needed to factor in an extra check before attempting to rely on the external GBI command list handling.

You should compile that line of code in for the quick fix.
I'll add it in the next release if I can get people to report at least one LLE bug or debug exploit message with my LLE plugin. :p

I was unaware HLE redirection from the RSP could have a bug since it's incredibly simple code...there was little documentation or examples of how to request a HLE operation that I just went with the method zilmar demonstrated in 1.4 which obviously was incomplete.

Liar. I saw you are in mail contact with them to get it running in their proprietary sellout crap

Thanks, and how will your RSP interpreter handle this kind of data? Is it a valid data for RSP or not?

The data pointer serves a purpose unknown to me.
It should get sent to the gfx plugin as some sort of variable data for the ucode to process with, but I don't really know.

But it will certainly execute natively on my RSP in LLE, just like it seems to do on zilmar's RSP, so the bug with HLE gfx on RE2 will be gone in the same way.
The other HLE gfx stuff of course will still be handled by the video plugin, so no big speed loss.

Nope, I am not in mail contact with them about anything.

Not that it's natural to back up your claims with proof or anything, since liars cannot prove lies.

And there you have just proved that you didn't "hear" I was in contact with anyone.
You simply hallucinated over the Internet. :p

I was only invited to join some mupen64plus discussion by okaygo, but I left quickly cause I got bored.

I guess this fix is not 100% correct. After I add this check to RSP interpreter, graphics rendering is correct, but the dialog voices of Resident Evil 2 movie are also be filtered out just like Zilmar's RSP 1.7.

But I have those dialog voices with Zilmar's RSP 1.6, and before I applied this fix, the dialog voices are there.

Could it possible that part of these data are related to mpeg decoding for GFX HLE function? Such as Jabo's Direct3D8 plugin decoded the mpeg data and write back audio data to emulator's memory?

Yes it's possible, but, first I need to reproduce your report.

Maybe I'm using the wrong core settings for this game?
For some reason I'm not getting the voices at all no matter what I do--zilmar's RSP 1.6, take out that code I just put in, whatever you said.

Here are my settings.

http://ft.trillian.im/785abe041074fd...35HwVUtQTN.jpg
http://ft.trillian.im/785abe041074fd...41dYUNeW8z.jpg
http://ft.trillian.im/785abe041074fd...bPMkG14Cy1.jpg

I think you are missing 1964Audio, without it you can't have the correct audio.

And my guess is wrong, I forgot I have the all the dialog voices at 1964 with Zilmar's RSP 1.7, so your fix shouldn't filter out those voices.

Sorry for the wrong bug report.