What's new

Z64 - a LLE graphics plugin

stranno

New member
I'm trying this plugin but have a question. I've put the glew32.dll file in the Project64 folder and the three files from the R17 ZIP file into my plugin folder. I renamed my original RSP.dll to RSP.dll.old and then renamed the z64-rsp.dll file to RSP.dll.

I can select the z64 graphics plugin in Project64 but when I go to Options -> Configure Graphics Plugin, no window appears. I also noticed that one file described in the first post is not included in the ZIP file (RSPcomp-pj64.dll - the much faster RSP emulator based on Project64). I assume the missing Configuration window is just because one hasn't been made yet and the .conf file can be used to change settings but how come one of the files is missing?

The Z64 gp doesnt have configuration windows, this is why there is a config txt

BTW heres another video, World Driver Championship this time

http://es.youtube.com/watch?v=NyfANBXeajU&fmt=18
 
Last edited:

angrylion

New member
What's common about those four games that don't work under Z64 (Automobili Lamborghini, Doom 64, Quake 2, Roadsters Trophy) is that they're among the very few N64 games that utilize 32-bpp framebuffer.
 
Last edited:

MasterPhW

Master of the Emulation Flame
And I thought, ziggy posted something new and exciting here... :(
But I know the person that posted above me! ;)
 

Predator82

New member
haha :)

where are you ziggy & angrylion?

i need updates for wdc
want play it like on a n64 before i die :p

plz help me ... no, help us ;)
 
Last edited:

squall_leonhart

The Great Gunblade Wielder
z64gl conflicts with both glide64 and mupen_rsp_hle causing memory usage to rise to 110mb just viewing the pj64 settings screen.
 

Predator82

New member
hey

has anyone the older rsp-files?
i want test them (myrsp1 & myrsp2)

thanx



ps: what did aforementioned configuration mean?
 
Last edited:

DarkJezter

New member
can't find source

I've managed to get the z64 plugin working with mupen64plus on linux, and I was hoping to include angrylion's fixes into the repository. Too bad the source link is broken :(

If angrylion or anyone else can track down a copy of the source for the patches I'd love to see fresh links posted
 

angrylion

New member
is there something new to get wdc faster?

No. Emulating RSP in interpretative fashion is a tough task on any CPU and I don't intend to write a recompiler. Maybe if I had a SSE4-capable CPU, I could speed things up, but without tests I can't say by how much exactly. I had tried to write the SSE2-based interpreter core but realized that I wouldn't gain in speed without some useful opcodes that came up with later SSE revisions.

Predator82 said:
has anyone the older rsp-files?
i want test them (myrsp1 & myrsp2)

Useless. They're not only buggy but also slower.

@ DarkJezter:

Nope, they're not fixes just hackery. I don't know if you'll be able to apply the same hackery to Mupen64plus. To fix this issue properly, one should alter CPU<>RSP interaction scheme, thus rendering the RSP plugin incompatible with any existing emulator. We discussed this in another thread @ emutalk. Anyway here are my old sources:

http://w19.easy-share.com/1903124284.html
 
Last edited:

DarkJezter

New member
@ DarkJezter:

To fix this issue properly, one should alter CPU<>RSP interaction scheme, thus rendering the RSP plugin incompatible with any existing emulator. We discussed this in another thread @ emutalk.

Thanks mate, that's exactly what I needed, and is quite possibly exactly what will be done. In the mupen64plus project we've already made some extensions to the plugin api to resolve other issues. After reading your reply I dug up the earlier thread you mentioned and found it very helpful as well.

A great deal of the modifications were just as you said, hackery... some of the others were modifications I was looking at applying myself, so thanks for saving me the trouble ;)

The hacks, while they will probably be disabled for now, are a good start to resolving some of the issues with the affected games. Thanks again :D
 

angrylion

New member
At last I found a game that doesn't work well with Ziggy's plugin AND exposes a bug in MAME's RSP core. Harvest Moon 64 is CFC2-dependant. To make it work add the following hack at the end of CFC2 implementation:
if (RDREG == 1)
RTVAL &= 0xffffff00;
Unfortunately, this breaks Mario Golf and maybe other titles. I don't know a proper solution to this so far.
 

microdev

Member
At last I found a game that doesn't work well with Ziggy's plugin AND exposes a bug in MAME's RSP core. Harvest Moon 64 is CFC2-dependant. To make it work add the following hack at the end of CFC2 implementation:
if (RDREG == 1)
RTVAL &= 0xffffff00;
Unfortunately, this breaks Mario Golf and maybe other titles. I don't know a proper solution to this so far.

It's a hack but I would add a check of the rom name to the condition. Rom name can be found in gfx.HEADER position 32-52.
 

angrylion

New member
OK, the real problem was a subtle bug in the "VCL" RSP opcode. Some values shouldn't be sign-extended before summation as they're in MAME. This led to inaccurate calculation of compare flag (aka flag 1) in some cases, which broke Harvest Moon 64. Project64 1.4 RSP does this particular thing right (see RSP_Vector_VCL() function).
Now the real fix would be to change this line in MAME's VCL implementation:
Code:
if (((UINT32)(INT16)(s1) + (UINT32)(INT16)(s2)) > 0x10000)
to this:
Code:
if (((UINT32)(UINT16)(s1) + (UINT32)(UINT16)(s2)) > 0x10000)
I've tested a few games that exposed problems with my previous hack, and all worked well.
 
Last edited:

wareya

New member
Any chance of getting this to run on Nemu64? I get a straight black screen with or without an alternate RSP plugin.
 

Top