Z64 - a LLE graphics plugin

[ziggy]

Hi all,

I am pleased to release a very experimental LLE graphics plugins for N64 that I started to develop about a month ago. I've called it Z64. It is originally based on the excellent work of Ville Linde in Mame/Mess, even though there isn't much of his own code left, it was the starting point of this project without which it wouln't exist today. Also , thanks for other plugin authors that released their source code, as it provided a lot of valuable informations (in particular but not limited to : glN64, Rivevideo, Glide64)

What is it exactly : it is mainly an RDP emulator implemented in OpenGL. Contrary to usual graphics plugins, it doesn't emulate the RSP part, so it requires a functionnal RSP emulator plugin to give any results. I'm providing two solutions to emulate the RSP, one that is based on the plugin from Project64 v1.4 with a few fixes, and another one slower based again on the work of Ville Linde in Mame/Mess. The first is much faster , but still has a few problems. My suggestion is to use the first one by default, and use the second one if the game freezes or crashes.

The advantage of emulating the RDP and RSP separately is that it is more direct and thus more accurate. It is also, in a way, much simpler, because you don't have to reverse engineer the RSP ucode of each specific games. The drawback is that it's pretty CPU intensive, because the RSP is quite heavy to emulate (and this even though the RSP emulator from Project64 is very well optimized)

What it is not ? :) Well , this project at the moment doesn't aim at competing with existing mature video plugins like for example Glide64. They have years of development behind them, and as said before , also are much faster. The aim instead is rather to possibly emulate those rare games that no other plugins could emulate fully yet, because the ucode wasn't reversed engineered. And of course, for me to have fun developing it.

Instructions to use it

You need to install in your core emulator plugins directory a few files :

- z64gl.dll the RDP emulator
- z64gl.conf the configuration file
- z64-rsp.dll the slow RSP emulator
- RSPcomp-pj64.dll the much faster RSP emulator based on Project64

To select the RSP plugin, it depends on which core emulator you're using :

- with mupen64, simply select it just like you would select an audio or video plugin
- with Project64, you need to rename the plugin "RSP.dll". Don't forget to backup your original RSP.dll plugin (that is the one provided by the core emulator) before doing that Indeed, the RSP plugins I'm providing won't work with other standard HLE video plugins.

Under Linux, it's similar, but you'll need before that to compile it, just type "make" in the source directory for both Z64 and the RSP emulator.

I am not looking yet for feedbacks about emulation inacuracies. There are still many problems, and they are pretty obvious. However I'm interested in feedbacks related to compatibility with hardware as well as "success stories", that is if you find a game that is actually better emulated with Z64 than with other plugins.

Regarding hardware requirement, you'll need a graphics card with GLSL extensions as well as Framebuffer Objects extension. That means mainly a decent nVidia or ATI card. You'll also need a pretty fast CPU because of the RSP emulation part. Regarding multicore CPU, in the future I plan to emulate the RSP in a separate thread, meaning that multicore CPUs will greatly benefit from it. This is not done yet however.

Finally, it is early development, so in particular there aren't yet any configuration dialog. There is now a configuration file though.

Well, have fun :)

Below a screenshot of Goldeneye showing the sky, one effect that uses a "non standard" ucode.

EDIT : forgot to include glew32 dll that is required for z64gl.dll. Just install this dll either in your windows installation path, either in the core emulator directory (not in the plugin directory)

EDIT : release R2 that write debug messages into a file called z64log.txt, fix black border texels and possibly crash on exit

EDIT : release R3 (now R4) that should fix crash on exit in Pj64. However, you should toggle windowed mode before exiting a game, otherwise the screen resolution isn't going to be restored until you run a new ROM.

EDIT : release R5 that should fix part of the slowness issues on ATI cards

EDIT : R6 that should fix depth issue introduced in R5 . Now R7 that fixes a second depth issue.

EDIT : R8 possibly fixing another slowness issue on ATI when using certain clamping mode on non power of two sized textures.

EDIT : R9 another attempt at fixing slowness issue for ATI (based on the idea in the test tp2), seems to also speed a bit things on nVidia. Also fix black screen issue in Shadowgate

EDIT : R10 with again more ATI slowness fixes, plus a configuration file called z64gl.conf. This file should be copied into your Plugin/ directory, it allows to select screen resolution as well as other options.

EDIT : R11 with some framebuffer effects, multitexturing and screen setup fixes.

EDIT : R12 fixes in combiner/blender, 2d mapping, zbuffer for triangles in no Z mode, mapping in non perspective mode

EDIT : new version of the modified pj64 rsp plugin (R3). It fixes most differences with the z64-rsp plugin, games that now work fine with it include : Jet Force Gemini, Mario Party, Yoshi's Story , Zelda (these two had not visible problems because there was a hack in the rdp emulator), Telefoot. EDIT now R4 to get rid of a dialog box that pop up in Telefoot.

EDIT : z64 R13 with some texture formats fixes, a new option for video cards that do not support non power of two textures, the hack for the RSP plugin bug is now removed (make sure you use latest rsp plugin) EDIT now R14 to fix stupid bug in the z64-rsp plugin (some leftover debug code causing problems under windows)

EDIT : R15 more combiners improvements and fixes usage of tile #7.

EDIT : R17 now support asynchronous RDP emulation (try it preferably on dual core processors). To use it, set both "threaded" and "async" to 1 in the config file. It's a bit unstable, though once a game is booted successfully it should work well enough. Plus other various improvements.

[ziggy]

Another screenshot showing motion blur effect in Conker's Bad Fur Day.

[PsyMan]

Nice to see that there is still interest on N64 emulation. :)

Unfortunately I wasn't able to try this myself since I'm using Windows and the GFX plugin doesn't seem to be recognized by any of the emulators I use... PJ64 fails to load it and Mupen as well as 1964 fail to see it entirely.

The RSP plugins are both recognized by all emus but in conjunction with other GFX plugins (HLE plugins) they don't seem to work (I doubt they are even supposed to).

Edit: I just looked at the source and realized you use the glew libraries which means that I'll need the necessary dll to run it. :doh:

[ziggy]

Yes, I just noticed my mistake, I've added the glew32 dll into in my original post.

I'm currently trying it under windows, it does work with Mupen64 and Project64, however there's a crash on exit with Pj64. That should be easy to fix, I'll do a new release soon.

[PsyMan]

Nice thing that you attached glew32 to your post. :)
By the way, the speeds I get here are about 2fps... is it normal to run so slow? I understand that this is LLE (and it's probably missing speed optimizations) so it's supposed to be much slower than HLE plugins but I don't know what's the target speed of the plugin...

[ziggy]

Nice thing that you attached glew32 to your post. :)
By the way, the speeds I get here are about 2fps... is it normal to run so slow? I understand that this is LLE (and it's probably missing speed optimizations) so it's supposed to be much slower than HLE plugins but I don't know what's the target speed of the plugin...

Thanks for testing :) It should be much faster, but it also depends on your hardware of course. What CPU and graphics card are you testing with ? I suspect the problem is with GLSL (pixel shaders). When the GL hardware driver doesn't support a feature, then it fallback to CPU emulation, which is typically 100 times slower.

I'm using a nVidia 7600Gt (but I tried also on a 6800Gt and it was running fine as well), and an Athlon 64x2 5200 (2.6Ghz, but only one core used by the emulator at the moment). I get usually full speed emulation except in certain very crowded cases.

[PsyMan]

I use an ATi mobility Radeon X600 (it supports shaders v2.0) and a Pentium M 740 (32bit at 1.73GHz).
I believe that something is wrong with the shaders here...

[ziggy]

Yes, it's most likely a shader problem. If you're ok to do more tests, I'll make a benchmark application to try to pinpoint where exactly the problem is.

[PsyMan]

Yeah, no problem. :)

My card supports up to OpenGL 2.0. When it comes to v2.1 it supports only GL_ARB_pixel_buffer_object. This of course excludes missing extensions.

[toe_head2001]

Very Nice! I Love to see new things being developed.
I tried it with Mupen64 and Project64 and both crashed on game load. Maybe I did some thing wrong?

Digg it (http://digg.com/software/Z64_A_New_LLE_Graphics_Plugin_for_Ninten do_64_Emulators)

[Trotterwatch]

Very Nice! I Love to see new things being developed.
I tried it with Mupen64 and Project64 and both crashed on game load. Maybe I did some thing wrong?

Digg it (http://digg.com/submit?phase=3&url=http://www.emutalk.net/showthread.php?t=40640)

It's your graphics card, it doesn't support OpenGL 2.0.

////


I'm having the same issues as Psyman, using an ATI X700 graphics card, it either crashes or runs at a fraction of a frame per second.

[mudlord]

I did some testing with this sucker...

Suffice to say, it works exceedingly well....I didn't test other games though, yet...

[cooliscool]

Simply incredible. Outstanding work, Ziggy. :king:

[smcd]

I used the lle rsp and video plugin and rogue squadron shows some stuff, battle for naboo shows the initial screen (about the expansion pack) and then dies. Also, switching between games tends to crash the emulator. Nice :)

[Iconoclast]

Dark Rift, LLE, full speed?

Holy fuck. Sad part is, I must miss out on it all. Don't have the required OpenGL support for those who didn't know.

[toe_head2001]

It's your graphics card, it doesn't support OpenGL 2.0.

////


I'm having the same issues as Psyman, using an ATI X700 graphics card, it either crashes or runs at a fraction of a frame per second.


Yea, my video card only supports OpenGL v1.4. I think it's about time I upgraded!

[cooliscool]

Yea, it only supports OpenGL v1.4. I think it's about time I upgraded!

Not even compliant with 1.4... maximum 1.3. Lacks basic OGL 1.4 functions, such as ARB_Imaging or any shaders.

[ziggy]

Thanks for the feedbacks. I'll make a new release soon, my problem is that under Windows I do not have network connection at the moment so I'm doing a lot of switch back and forth between linux and windows which is pretty annoying.

About OpenGL requirement, version 1.5 should be enough. The necessary extensions are GL_ARB_fragment_program, GL_ARB_fragment_shader (so basically GLSL), GL_EXT_texture_mirror_clamp, GL_ARB_depth_texture, GL_EXT_packed_pixels, GL_EXT_framebuffer_object.

I'm going to make a debug release that dump some error messages in a file, that might help debugging for ATI card. I'm not surprised there are problems with ATI, GLSL on ATI tends to be much more tricky.

Nice screenshots Mudlord. I notice there are black borders in textures in your screenshot, the problem should be fixed already in next release, it's a problem with the texture clamping mode I was using (and for strange reasons, it doesn't behave the same under linux and windows)

EDIT : ok I made a new release called R2 in the original post .

[axcc123]

can't get it to work in vista

[mudlord]

Nice screenshots Mudlord. I notice there are black borders in textures in your screenshot, the problem should be fixed already in next release, it's a problem with the texture clamping mode I was using (and for strange reasons, it doesn't behave the same under linux and windows)


Glad you thought so. I'm more than happy to test out the R2 release and post screens with that too :). I must say, with your plugin and modified RSP plugin, LLE runs a fair bit faster than Jabo's video/RSP set (which seems to be the method you're doing LLE with too.)

BTW, in case for the people who don't know, I'm running on a 3GHz P4 with a GeForce 6600 GT, so that might give a ballpark of what specs are needed :) (of course, the greater the specs, the faster things will be).

[PsyMan]

OK, here is the log using the z64 RSP:


rglInit()
rglClose()
demarrage r4300
dynamic recompiler

ABI set to ABI 1


And here is the log using the modified PJ64 RSP:


rglInit()
rglClose()
demarrage r4300
dynamic recompiler
PC=80246ddc:0
reg[ 0]: 0 0 reg[16]: 0 0
reg[ 1]: 0 0 reg[17]: 0 0
reg[ 2]: 0 0 reg[18]: 0 0
reg[ 3]: 0 0 reg[19]: 0 0
reg[ 4]: 0 1 reg[20]: 0 0
reg[ 5]:ffffffff80364c60 reg[21]: 0 0
reg[ 6]:ffffffff803230f4 reg[22]: 0 0
reg[ 7]: 0 0 reg[23]: 0 0
reg[ 8]: 0 ff01 reg[24]:ffffffff8033a730
reg[ 9]:ffffffff80364c60 reg[25]:ffffffff8033a730
reg[10]: 0 fe reg[26]:ffffffffa430000c
reg[11]:ffffffff80364c60 reg[27]: 0 aaa
reg[12]:ffffffffa4400000 reg[28]: 0 0
reg[13]:ffffffffa4400000 reg[29]:ffffffff80200dc8
reg[14]:ffffffffffffffff reg[30]: 0 0
reg[15]: 0 fe reg[31]:ffffffff80246dd8
hi: 0 0 lo: 0 0
aprθs 84401108 instructions soit 507dbd4
Freeing 4194304 bytes at e8d0000
Freeing 1048576 bytes at ef60000
Freeing 2097152 bytes at ecd0000
rglClose()


I had to use Mupen to get logging working since PJ64 crashes on exit and the created log file is empty with it.
Both logs were created while running Mario 64. I closed the emu 3-5 frames after the Mario 64 logo showed up.

Edit: Forgot to mention that according to OpenGL Extensions Viewer ATi Mobility x600 supports all the needed extensions. :)

[squall_leonhart]

I used the lle rsp and video plugin and rogue squadron shows some stuff, battle for naboo shows the initial screen (about the expansion pack) and then dies. Also, switching between games tends to crash the emulator. Nice :)

it requires advanced interpreter method to get further (naboo)

under 1.7, it doesn't work just by setting the rom settings to interpreter, you actually have to force the emulator into Interpreter mode using the debug settings.

[squall_leonhart]

the modified rsp's would only crash battle for naboo in 1.7.. so i switched it to the 1.7 rsp and forced it to interpreter

meh.. screw this... back to the *working* 1.7 plugins for me...

[revl8er]

Nice to see someone working on a new gfx plugin. I'll give it a try when I have some extra time.

[ziggy]

I made a new release (R3) that produce a second file called z64err.txt, possibly showing more detailed errors.

It also fixes crash on exit in Pj64, however , you should toggle windowed mode before stopping emulation, otherwise the screen resolution won't be restored properly until you run the next ROM.

[ShadowFX]

Are the attachements working? I can't seem to get any files.

[ziggy]

Hmm they should, I can see them at least.

[ShadowFX]

Alright, got it... thanks :)

EDIT: I'm getting a message that SDL.dll is not founding and therefore I'm unable to load the plugin in PJ64 1.6. Any comments?
EDIT2: it seems it is required to put SDL.dll in the core directory of the emulator. Maybe a little something to mention on the first post.

[PsyMan]

OK... Here are the logs i get now (using PJ64 v1.6 this time).


Using the z64 RSP:

z64err.txt

viewportOffset 23
fix hend
creating fbo 400 320 x 240 fmt 0
Creating depth buffer 400 1024 x 777
creating fbo 38f800 320 x 240 fmt 0
creating fbo 3b5000 320 x 240 fmt 0
fix hend
creating fbo 3da800 320 x 240 fmt 0
fix hend

z64log.txt

rglInit()
rglClose()

ABI set to ABI 1

ABI set to AutoDetect
cache hit 146978 miss 1148 0.781069%

ABI set to AutoDetect


Using the PJ64 RSP

z64err.txt

viewportOffset 23
fix hend
creating fbo 400 320 x 240 fmt 0
Creating depth buffer 400 1024 x 777
creating fbo 38f800 320 x 240 fmt 0
creating fbo 3b5000 320 x 240 fmt 0
fix hend
creating fbo 3da800 320 x 240 fmt 0
fix hend

z64log.txt

rglInit()
rglClose()

ABI set to ABI 1

ABI set to AutoDetect
Freeing 4194304 bytes at 1fd0000
Freeing 1048576 bytes at 23d6000
Freeing 2097152 bytes at 27b0000

ABI set to AutoDetect

[ziggy]

Alright, got it... thanks :)

EDIT: I'm getting a message that SDL.dll is not founding and therefore I'm unable to load the plugin in PJ64 1.6. Any comments?
EDIT2: it seems it is required to put SDL.dll in the core directory of the emulator. Maybe a little something to mention on the first post.

Oops you're right, I forgot SDL is now used. I'll get rid of this dependency instead. (EDIT done in R4 on original post)

PsyMan, thanks for the log. So there's not much useful yet . I'll make another release with hopefully more informations in the log.

[ShadowFX]

ziggy, you were able to get ingame with Conker seeing you posted that screenshot. I can't get any further with either RSP files:

http://www.xs4all.nl/~vdnoort/emulation/z64_conker_error.jpg

[Trotterwatch]

There is no way I could post the error log using the supplied PJ64 RSP, as within the matter of a few seconds it created a file 70mb and growing!

Edit/
I do have one, but it's over 5 megs in size, so let me know if it'll be any use for you and I'll post it.

Z64Err.log using latest RSP

viewportOffset 23
fix hend
creating fbo 400 320 x 240 fmt 0
Creating depth buffer 400 1024 x 777
creating fbo 38f800 320 x 240 fmt 0
creating fbo 3b5000 320 x 240 fmt 0
fix hend
creating fbo 3da800 320 x 240 fmt 0
fix hend

Z64.log
rglInit()
rglClose()
cache hit 40834 miss 322 0.788559%

[PsyMan]

Hmm... the error logs I get with r4 seem quite the same compared to r3.... here they are anyway.

[ziggy]

No it's not anymore necessary to post logs. I'll tell you when I have a release that will produce more interesting logs.

EDIT : however I'd be insterested to see just a few lines of your monstruous log :)

EMu-LoRd : It's weird. I checked, indeed under windows with Project64 I get this error. However, it works fine with mupen64. It also actually works with Pj64 but through wine under Linux (that's where the screen shot come from by the way). I don't know what the problem is yet.

[ziggy]

Ah, I see the problem, you've setup the RSP plugin in "Interpreter" mode. This mode currently contains debugging code , so it displays a trace of all instructions executed by the RSP, which is very verbose indeed :) Just set it to "Recompiler" instead (you might need to turn on "advanced settings" in Pj64)

[Trotterwatch]

LOL, my bad had it on that for testing another plugin and neglected to set it back :D That explains things.... d'oh

[PsyMan]

LOL, my bad had it on that for testing another plugin and neglected to set it back :D That explains things.... d'oh

Oh, btw. Welcome "back". When did you get yourself unbanned anyway? :P

[ziggy]

Just released version R2 of modified Pj64 RSP plugin, without debugging code in "Interpreter" mode :)

[ShadowFX]

EMu-LoRd : It's weird. I checked, indeed under windows with Project64 I get this error. However, it works fine with mupen64. It also actually works with Pj64 but through wine under Linux (that's where the screen shot come from by the way). I don't know what the problem is yet.
Just to let you know, even Mupen64 (win32) exits unexpectedly at the same point PJ64 gives me the error message. Tried both interpreter and recompiler :bouncy:

[ziggy]

Ah ok, so it's not the same problem I'm having. The problem I get under Windows with Pj64 is that is crash right on the beginning.

I know there's a second problem that is it fails at the end of the Nintendo intro (where conker cut the Nintendo logo) That second problem is going to be easy to fix, should be fixed in next release. Meanwhile, if you have a saved state, you can jump across this part of the intro and get into the game.

[CpU MasteR]

The LLE plugin runs very slowly with my ATI Mobility Xpress 200M as well...

[Sri Narayan]

thank for the plugin. compiles but have problem at the end:


rgl.cpp: In function `void rglRenderChunks(int)':
rgl.cpp:486: error: `GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATT ACHMENT_EXT' was not declared in this scope
rgl.cpp:707: warning: converting to `uint16_t' from `float'
rgl.cpp:709: warning: converting to `uint16_t' from `float'
rgl.cpp:711: warning: converting to `uint16_t' from `float'
rgl.cpp:713: warning: converting to `uint16_t' from `float'
rgl.cpp: In function `void rglDisplayFramebuffers()':
rgl.cpp:788: warning: converting to `int' from `float'
rgl.cpp:789: warning: converting to `int' from `float'
gmake: *** [rgl.o] Error 1


(freebsd 6.2 + debian-testing.)
because i have an athlon-xp +nvidia0: <GeForce FX 5200> the plugin is a little slow .


ciu

[ziggy]

I'm curious, what kind of FPS are you getting Sri Narayan ?

I'm releasing a first benchmark application. For ATI users mainly it requires glew32 dll, just run it and it will produce a file called "zbench64log.txt", it shows timing of a few GLSL sample code.

[PsyMan]

Hmm... Here's how the results look like:


test #0 13.6385
test #1 13.7008
test #2 13.636
test #3 13.6328
test #4 17.0934
test #5 18.8244
test #6 16.885

I ran the testing application about 4 times and the results varied on almost all of the 6 tests. I got results from 13.xxx to even 20.xxx.

[Sri Narayan]

@ ziggy around 15 fps

found a bug in sm64 perhabs only my vid card?

ciu

[ziggy]

Thanks Psyman. Variations are expected because we're under a multithreaded OS so there might be other events interfering with the timing. It's not a problem at all, when we'll have found the problem, we'll get numbers that are at least 10 times bigger for the corresponding test.

I'll add new tests in a new release.

EDIT : Sri Narayan, what kind of bug did you find ?

[Sri Narayan]

the scaling of the video output. only happens in some games. don't know if it is really a bug.

ciu

[ziggy]

the scaling of the video output. only happens in some games. don't know if it is really a bug.

ciu

Funny, you're not using the correct plugin in fact :) The plugin you're using (I guess is called z64.so) is a completely software renderer, it's based on the emulation in Mame/Mess with barely any modifications. It's of course an LLE emulator too, but it's much slower (as it's not using GL), and it lackes many features too.

The plugin you want to use instead is z64gl.so . Because you had a compilation error, it probably wasn't produced. To fix that compilation error, just remove the offending lines , they're just here to check very eveything's ok but aren't mandatory.

[ziggy]

I've updated the benchmark application in the post http://www.emutalk.net/showpost.php?p=378708&postcount=43

[Trotterwatch]

I got results like Psyman in the last one, except for one freak result which gave some values as high as 33.

These are the values with the new app, I take it there should only be 10 results? Program appears to hang after that (I left it a while just in case :D)

test #00 12.3646
test #01 9.83572
test #02 10.3392
test #03 10.0117
test #04 9.83667
test #05 11.4368
test #06 9.96601
test #07 13.5388
test #08 13.4973
test #09 9.84922
test #10 19.687

[Sri Narayan]

are the assert(glGetError() == GL_NO_ERROR); functions important? because mupen doesn't like this and exit.

the output was:


mupen64: rgl_rendermode.cpp:281: void rglSetCombiner(rglRenderChunk_t&, int): the assurance »glGetError() == 0« is not fulfil.

ciu

[PsyMan]

OK, here are the results I get with the new test:

test #00 17.8108
test #01 13.6323
test #02 17.344
test #03 17.4944
test #04 17.3957
test #05 21.7174
test #06 17.7129
test #07 22.8143
test #08 22.7625
test #09 13.637
test #10 38.7659

As TrotterW already stated, the app seems to hang after that.

[ziggy]

Arg, I was expecting to get at least a huge number for test #10. But no ... they're all in the same order of magnitude.

Sorry for the hang at exit, it's a stupid mistake (it's just waiting you press ENTER into the console to exit, but as it's a cygwin console it's not even really working)

I'm starting to doubt the problem is related to fragement shader after all, I'm releasing a version of the plugin that do not use them at all, the drawback is that it won't look correct without them , but it's not the the problem, I'd just like to see if it's still slow even without fragment shaders.

Sri Narayan, can you post the assert error message (it should be in the console) so that I know which one failed.

[Trotterwatch]

No difference at all here, same speed.

Sorry that ATI cards are proving to be such a pain in the arse :D

[PsyMan]

Indeed... It's still as slow as the shader enabled version. :P

[ShadowFX]

Here are my results, if it's still needed:

test #00 5.87552
test #01 4.33165
test #02 4.34695
test #03 4.50605
test #04 4.33314
test #05 4.32943
test #06 4.3392
test #07 4.3447
test #08 4.34535
test #09 4.32048
test #10 4.39261

[ziggy]

Aah, so we made a big step forward , since it proove that the problem as nothing to do whatsoever with fragment shaders :)

The bad new is that I 've absolutely no idea where the problem come from ... Well, if you're not yet tired of playing ginea pigs, we'll make more tests :)

Sri Narayan , bad luck you get the error in a place that is rather generic so I can't really tell what goes wrong. Yes you can try to remove the asserts, but then you'll need to remove all of them (those on glGetError, you can leave the others) But if you get some errors , it probably won't work very well anyway.

[ShadowFX]

ziggy, what do these results actually represent?

[CpU MasteR]

test #00 29.3609
test #01 44.438
test #02 24.6589
test #03 28.1255
test #04 24.7671
test #05 24.8425
test #06 24.8707
test #07 49.3154
test #08 43.7958
test #09 34.5414
test #10 63.4593

[Sri Narayan]

after commenting out of rgl.cpp CHECK_FRAMEBUFFERSTATUS (line:486)
it compiles z64gl.so
after starting a game sm64 for instance I get this:



creating fbo e9d80 292 x 216 fmt 0
Creating depth buffer e9d80 1024 x 778
creating fbo 3d6300 292 x 216 fmt 0
mupen64: rgl.cpp:353: void rglPrepareFramebuffer(rglRenderBuffer_t&): the assurance »glGetError() == 0« is not fulfil.


ciu

[ziggy]

ziggy, what do these results actually represent?

Well I'm testing various GLSL fragment programs, from very basic (test #0) to more complicated, and I time them with the RDTSC instruction. The time scale isn't fixed (because I use RDTSC, it depends on the CPU frequency) but what matters is the variation between test #0 (which is alsmost certainly hardware accelerated) and the other ones. If one of the test was being emulated by CPU, we would get for this test a number at least 10 times bigger, more probably 100 times. This didn't happen so there's no problem with fragment shaders, they're all GPU accelerated even the complicated cases.

EDIT : Sri Narayan, I replied in my previous message, I suggest you now to try to remove these assert on glGetError (you can leave the others) and see what happens. YOu'll need to remove all the asserts on glGetError (there are some in several source files)

[Sri Narayan]

perhabs is this the fault?



file found
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1447
CRC: 30c7ac50 7704072d
name: CONKER BFD
Manufacturer: Nintendo
Cartridge_ID: 5546
Country : United States
size: 4096
PC= 80001000
md5 code:00E2920665F2329B95797A7EAABC2390
eeprom type:1
init timer!
[New Thread -1394934864 (LWP 8032)]
memory initialized
InitiateGFX
INITIATE RSP
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
rglInit()
rglClose() <======================================== ==================

[New Thread -1410761808 (LWP 8033)]
demarrage r4300
dynamic recompiler
sp_reg_r: 00000001
fix hend
creating fbo e9d80 292 x 216 fmt 0
Creating depth buffer e9d80 640 x 486
creating fbo 3d6300 292 x 216 fmt 0
mupen64: rgl.cpp:353: void rglPrepareFramebuffer(rglRenderBuffer_t&): the assurance »glGetError() == 0« is not fulfil.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1394934864 (LWP 8032)]
0xb75a2947 in raise () from /lib/tls/libc.so.6
(gdb) quit

[ziggy]

No, the problem is that the error happened earlier in a too generic place so we cannot really tell what was the original problem. Simply remove all these asserts.

[Doomulation]

No luck with this ATI card either...
Both of the two versions of the LLE plugin runs at <= 1 VI/s.
Benchmark app reports:

test #00 10.8771
test #01 10.5227
test #02 11.3515
test #03 10.5979
test #04 10.8698
test #05 10.4954
test #06 14.4264
test #07 17.5862
test #08 17.4432
test #09 11.582
test #10 14.4253

ATI Radeon Mobility X1600

[Sri Narayan]

after removing all assert(glGetError==GL_NO_ERROR); functions I have a black screen now.
another question may I edit this line in rgl_osdep.cpp 34:
form:
int screen_width = 1024, screen_height = 768;
to
int screen_width = 640, screen_height = 480;
?

[ziggy]

Yes you can enter any resolution you wish here. It control the size of the window as well as the resolution of framebuffer objects, so it might indeed help if you haven't enough video memory.

[ziggy]

Another version to test for ATI users, this one doesn't use Framebuffer objects. Again, it's won't look quite right , but it's only to check if the slowness problem is related to FBOs.

[Trotterwatch]

A lot faster! From 1fps to 30+ ;) So you're getting somewhere with this.

z64.log
rglInit()
rglClose()
cache hit 4753409 miss 33089 0.696111%

[ziggy]

Excellent. Could you show also the content of z64err.txt ?

[PsyMan]

Same here. Too bad the window roughly fits my laptop's screen and i can't check the vi/s counter. :D

Edit: Here are the logs with this version and the z64 RSP.

[Trotterwatch]

z64.err
viewportOffset 23
fix hend
fix hend
fix hend

[ziggy]

Ok, one possibility is that the problem has to do with the use of depth texture as depth buffer. This version doesn't use depth textures, but still use Framebuffer Objects.

It shouldn't make any visual difference because I was not using these depth textures yet.

If it's slow again, then I have another theory, but that's for after :)

About the logs, I'm only interested to see them when you get a crash now. Also can you tell me a bit more in details when you experiences these crashes ? You said in Super Mario, did you try some other games ?

[PsyMan]

Unfortunately this version is slow again...

Also, I tried some games with the previous version (the fast one) and some of them had occasional random pauses for no apparent reason. (ie: Mischief Makers) while some others were very slow while ingame to the point of 2fps (ie: Aerogauge)

[ziggy]

Ok, the second theory is the use of an alpha channel in the framebuffer that might cause a problem on ATI. (EDIT : note that without the alpha channels , dynamic shadows effects in CBFD or Banjo won't work anymore)

[ziggy]

Trotterwatch, you wrote that you had crashing with the modified Pj64 RSP plugin. In Super Mario ? I've never got any crash with it in Mario, in fact it works for most games (Jet Force Gemini is one of the few exceptions). What emulator are you using ? I'm using Mupen64 and Project64 v1.6.

[Trotterwatch]

Just done some testing;

Mario 64 crashes after the intro with the modified RSP'rsp-pj64-ziggy-r2-win32' renamed to rsp.dll

z64err and z64.log are both blank after this.

/I'm going to clear out my PJ64 1.6 directory after this, complete with registry entries to see if it's not just something else amiss. Could even be my drivers so I'll try some other ATIoglxx files.

So disregard this for the moment, I don't want to be making faulty bug reports.

[ziggy]

Another release, this time it uses power of two sized framebuffers. Also I'm using a much lower resolution, in case of it's a video memory problem.

[Trotterwatch]

Ok, cleared everthing out, files, folders and registry and reset everything to defaults.

That plugin works great, the speed is good, and Mario64 is now working :D Yay.

/Just to clarify this version and the non FBO work fine, the rest didn't.

[PsyMan]

The last version seems OK... It's faster than all the previous ones except from the version with the disabled framebuffer (with the old version I was getting almost fullspeed on Mario on almost every place, with the new one speed drops more on "heavy" places).
The speed on some games (including Zelda OOT) still drops to merely 2fps on some cases.
Mario 64 works fine for me even with the modified PJ64 RSP. I successfully started a new game and collected a star. (Edit: TrotterW got me to it :P)

I also attached a couple of screenshots to display gfx and speed issues.

[Doomulation]

I'd love to test but can't switch back to XP right now and it won't work on Vista. I wonder if it's related to the glew32.dll file?

[ziggy]

Ok, we're progressing :) Well done for finding your weird problem Trotterwatch.

Here's two new versions to test to narrow the problem even more. One is still in the ridiculously small resolution , the other back in 1024x768.

EDIT : by the way, places where speed goes to 2fps , I think this time it's really due to fragment shader, we'll need to look at this but later on

[ziggy]

I'd love to test but can't switch back to XP right now and it won't work on Vista. I wonder if it's related to the glew32.dll file?

I don't know really, what happens exactly when you try it under Vista ?

[Trotterwatch]

Z64 - small and normal both run well, very slight if any performance differential between the two.

[PsyMan]

OK. Both the new low and high resolution versions are fast. :D
Z-Buffer seems broken on Mario 64 though. Only the version with the disabled framebuffer looks ok.

Here are two screenshots to compare (left is the old one with FBO disabled, right is the new one with FBO enabled):

[ziggy]

Excellent. I'm posting a new release in the original post (R5), the difference being that RGBA framebuffers are back and thus dynamic shadows in CBFD , Jet force gemini and Banjo will work again.

EDIT : indeed I noticed the depth problem on your earlier screenshot. Not sure but that might be fixed in R5 as well.

[PsyMan]

Just tried R5... Unfortunately the problem is still there... Weird :\

Edit: Switching to fullscreen makes things even worse. Switching back to window mode does not fix this... Check the screenshot below.

[ziggy]

You mean the depth problem or the slowness problem ? If it's the depth problem only, I'm not too surprised actually, it shouldn't be too hard to fix.

[PsyMan]

My apologies... I should make it clear that I meant the depth problem.

[ziggy]

Does it also get worse when switching fullscreen with the z64-normal version ?

[PsyMan]

Yes. It happens on both the normal and R5.
With the version that had disabled framebuffer objects it didn't get worse. It would either switch normally to fullscreen or it would pop up an "assertion failed" error message. (the plugin seems to continue normally after ignoring the message)

[ziggy]

Ok, the depth problem might be less simple than I thought first. Thanks for your help all of you, I think I'll stop for today. The next step (apart of this depth issue) will be to find out what causes the remaining occasional slowdowns. What would be useful would be to find some scenes that show this behaviour, and if possible the exact moment in the scene where it starts to get slow. The best would be scene that run at normal speed and an effect in that scene that is triggered by the player and causes such a slowdown, so that I'll be able to see what in the effect possibly could be the culprit.

[Doomulation]

I don't know really, what happens exactly when you try it under Vista ?
Mupen64 (at least) crashes.

Z64 + Z64 RSP = Crash
Z64 + PJ/Z64 RSP = Crash
Glide64 + Any RSP = Crash
Direct64 + Z64 RSP / PJ/Z64 RSP = No crash, but doesn't work
Direct64 + Azimer/Hacktarux RSP = Works

So it seems related to your plugin.

[ziggy]

Does it have time to produce z64log.txt and z64err.txt files before it crashes ? If it does, could you post the content ?

[Doomulation]

They're created, but they're empty.

[Sri Narayan]

That's my output with z64gl + RSP emulation Plugin v1.4
ciu

[ziggy]

Sri Narayan, could you PM me the output of "glxinfo" ?

Doomulation, could you try the app here : http://www.emuxhaven.net/forums/showpost.php?p=75102&postcount=7 called gltest, it's going to give informations about what your GL driver supports.

[Doomulation]

Doomulation, could you try the app here : http://www.emuxhaven.net/forums/showpost.php?p=75102&postcount=7 called gltest, it's going to give informations about what your GL driver supports.

I guess driver support for OpenGL is still pretty immature:
All tests fail with NO and auxillary buffers is 4.

[ziggy]

There's nothing we can do here. Apparently OpenGL has been seriously downgraded under Vista. I read somewhere, but it was quite some time ago, that Microsoft planned to limit OpenGL to version 1.4 under Vista, it seems they really did it then ?

EDIT : I did a bit of googling, it might be possible that if you deactivate Aero, then things get better. Are you using Aero under Vista ?

[Doomulation]

Yes, I use Aero...
I can try. It doesn't hurt to try...
No... no, it doesn't work (test shows the same). Either it's downgraded or drivers are premature...
Guess we'll have to work with XP for a while yet. Vista really is crippled...

[ray16]

In PJ64 I just get a blank screen no matter what game I load. In 1964 with the z64 RSP I get a black screen and then an exception in the emulation thread. And in 1964 with the other RSP plugin Conker loads, but crashes near the end of the N64/Rare logo animation, and Goldeneye seemed to work fine...but very slowly.

Just sharing my experience with the plugin.

As for Vista and its OpenGL support... I don't think the OS has much to do with the OpenGL problems while running under Vista, I'm fairly certain it's just the drivers lacking in OpenGL support at the moment (with most games being Direct3D, I imagine it has priority, and OpenGL improvements will come later).

[Sri Narayan]

for the linux user here is the diff for r5-release this should also compile on freebsd (if there is no #include <malloc.h> in the sourcecode didn't check this)


ciu

[Doomulation]

I have good news...
I got ahold of newer drivers (for some reason, the latest drivers weren't on the publisher's download page, pfft) and now we got progress!
The test tool reports the 4 first tests succeed, but the last one still fails.
The plugin now works, but I get an ASSERT pretty quick. I tried the "normal" latest version.

A screenie for you:
http://www.imagewoof.com/view_thumb/fc3bf1644/ASSERT.jpg (http://www.imagewoof.com/view_image/fc3bf1644/ASSERT.jpg)

If I keep ignoring, eventually I get a crash. Log files are empty, though.

[ziggy]

Good new, have you tried the version R5 on the first post of this thread ?

The test that fails in gltest , which is it ? Is it non power of two textures ? That would explain the crash you get in z64 ... Also could you test the various versions I posted earlier (z64-p2, nodepthtex, noalpha)

[Flash]

I can't compile r5 :
[flash@stardome z64-r5]$ make
g++ -g -DGCC -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -I/include `freetype-config --cflags` -I/usr/include/FTGL -O2 -mtune=athlon-xp -ffast-math -funroll-loops -m3dnow -mmmx -msse -mfpmath=sse -fomit-frame-pointer rdp-mess.cpp -c -o rdp-mess.o
rdp-mess.cpp:29:1: warning: "rdram" redefined
In file included from rdp-mess.cpp:9:
Gfx #1.3.h:116:1: warning: this is the location of the previous definition
rdp-mess.cpp:31:1: warning: "rsp_imem" redefined
Gfx #1.3.h:117:1: warning: this is the location of the previous definition
rdp-mess.cpp:33:1: warning: "rsp_dmem" redefined
Gfx #1.3.h:118:1: warning: this is the location of the previous definition
rdp-mess.cpp:37:1: warning: "vi_origin" redefined
Gfx #1.3.h:119:1: warning: this is the location of the previous definition
rdp-mess.cpp:39:1: warning: "vi_width" redefined
Gfx #1.3.h:120:1: warning: this is the location of the previous definition
rdp-mess.cpp:41:1: warning: "vi_control" redefined
Gfx #1.3.h:121:1: warning: this is the location of the previous definition
rdp-mess.cpp:44:1: warning: "dp_start" redefined
Gfx #1.3.h:123:1: warning: this is the location of the previous definition
rdp-mess.cpp:46:1: warning: "dp_end" redefined
Gfx #1.3.h:124:1: warning: this is the location of the previous definition
rdp-mess.cpp:48:1: warning: "dp_current" redefined
Gfx #1.3.h:125:1: warning: this is the location of the previous definition
rdp-mess.cpp:50:1: warning: "dp_status" redefined
Gfx #1.3.h:126:1: warning: this is the location of the previous definition
rdp-mess.cpp:1083:1: warning: "TEXTURE_PIPELINE" redefined
rdp-mess.cpp:1025:1: warning: this is the location of the previous definition
g++ -g -DGCC -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -I/include `freetype-config --cflags` -I/usr/include/FTGL -O2 -mtune=athlon-xp -ffast-math -funroll-loops -m3dnow -mmmx -msse -mfpmath=sse -fomit-frame-pointer disasm.cpp -c -o disasm.o
g++ -g -DGCC -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -I/include `freetype-config --cflags` -I/usr/include/FTGL -O2 -mtune=athlon-xp -ffast-math -funroll-loops -m3dnow -mmmx -msse -mfpmath=sse -fomit-frame-pointer main.cpp -c -o main.o
g++ `pkg-config gtk+-2.0 --libs` -o z64.so rdp-mess.o disasm.o main.o -g -rdynamic -lGL -lGLU -L/usr/X11R6/lib -lglui -lglut `freetype-config --libs` -lftgl `sdl-config --libs` -lz -fomit-frame-pointer -shared -Wl,-Bsymbolic
/usr/bin/ld: warning: creating a DT_TEXTREL in a shared object.
g++ -g -DGCC -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -I/include `freetype-config --cflags` -I/usr/include/FTGL -O2 -mtune=athlon-xp -ffast-math -funroll-loops -m3dnow -mmmx -msse -mfpmath=sse -fomit-frame-pointer rsp.cpp -c -o rsp.o
rsp.cpp: In function `UINT32 get_cop0_reg(RSP_REGS&, int)':
rsp.cpp:167: error: `exit' was not declared in this scope
rsp.cpp: In function `void set_cop0_reg(RSP_REGS&, int, UINT32)':
rsp.cpp:183: error: `exit' was not declared in this scope
rsp.cpp: In function `void unimplemented_opcode(UINT32)':
rsp.cpp:227: error: `exit' was not declared in this scope
rsp.cpp: In function `void rsp_init(RSP_INFO)':
rsp.cpp:278: error: `memset' was not declared in this scope
rsp.cpp: In function `void handle_lwc2(RSP_REGS&, UINT32)':
rsp.cpp:535: error: `exit' was not declared in this scope
rsp.cpp:537: error: `exit' was not declared in this scope
rsp.cpp:542: error: `exit' was not declared in this scope
rsp.cpp:566: error: `exit' was not declared in this scope
rsp.cpp:596: error: `exit' was not declared in this scope
rsp.cpp: In function `void handle_swc2(RSP_REGS&, UINT32)':
rsp.cpp:896: error: `exit' was not declared in this scope
rsp.cpp:900: error: `exit' was not declared in this scope
rsp.cpp: In function `void handle_vector_ops(RSP_REGS&, UINT32)':
rsp.cpp:1700: error: `exit' was not declared in this scope
rsp.cpp: In function `void sp_dma(int)':
rsp.cpp:2931: error: `exit' was not declared in this scope
make: *** [rsp.o] Error 1

[Gonetz]

OMG!!! Open-source LLE video plugin!! My dream comes true :D
I haven’t tested it yet, but as I see on screenshots, it really can do some stuff, which HLE plugins currently can’t, e.g. GE sky. I hope it can help me with reverse engineering of these problems. Good luck with your work, ziggy!

[ziggy]

Flash : add this line in rsp.h :

#include <stdlib.h>

Gonetz : hey thanks :) Indeed I think it could be very useful for HLE plugin developpers, what more, there's an embedded debugger. Unfortunatly at the moment it's using SDL so it works only in the linux version , but it should be easy to port to Win32, the SDL part is just to read keyboard and mouse.

[ziggy]

New release R6 that should fix depth issues that I introduced in R5.

[PsyMan]

OK. The depth issue when switching between window and fullscreen is fixed.

However, the depth issue on Mario 64 is still there (same on R6):
http://www.emutalk.net/attachment.php?attachmentid=36133&d=1178030355

Only the version with disabled FBO made Mario 64 look correct. It's wrong on every other "fast" version. I didn't actually have the patience to check if it happened with the "slow" versions.

[Doomulation]

Good new, have you tried the version R5 on the first post of this thread ?

The test that fails in gltest , which is it ? Is it non power of two textures ? That would explain the crash you get in z64 ... Also could you test the various versions I posted earlier (z64-p2, nodepthtex, noalpha)

Yes, the power of two test fails. Also, now I would test Windows XP. Although, initial wrapper tests shows power of two textures are still not supported here either. I will take a moment to make sure all drivers and software are up-to-date, however.

I'll test Vista later.

EDIT: With Windows XP, z64 plugin (R6) & z64 RSP, speed is average 30 VI/s. With PJ64/Z64, it's around 40-45 VI/s.
However, just a little while after the intro in Banjo-Kazooie, speed drops to <= 1 VI/s.

[ziggy]

Another release (R7) that should fix the other depth issue on ATI cards. It was a depth bias issue (similar to the one in the glide wrapper by the way). Now depth bias will be identical for all cards, however it's not yet perfectly tuned.

[firefox]

my video card (ATI x1900GT) fails the "non power-of-two texture support" test, and all the emus i've tried crash with your plugin with all possible combinations.
i'm under win XP

[Sri Narayan]

does anybody have noticed that sm64 us version destroys the emu? (v5,6 linux)

(edit) z64bench:



test #00 17.4144
test #01 36.5143
test #02 36.6146
test #03 36.5487
test #04 36.5705
test #05 36.5797
test #06 36.5371
test #07 37.0084
test #08 36.9962
test #09 17.4388
test #10 91.0377
test #11 36.5445


Not that bad with my stone age video card. :P

ciu

[PsyMan]

Depth issues seem finally fixed on R7. Nice. :)

Regarding the major fps drop on some games... I noticed two occasions of the fps dropping at ~1fps on the same spot (or near the same spot). Here they are:

GoldenEye 007: If you shoot a bullet on a wall (and make a hole) from near distance some smoke comes out from the hole. The smoke results in major slowdown. (check attached pic)
Getting near an enemy also results in major slowdown.

Chameleon Twist: Major slowdowns occur when specific plants are drawn on the screen (check attached pics). This specific spot is from the first stage of the game (at the very beginning).

[SWAT_Marc]

The smoke results in major slowdown. (check attached pic)

I don't know if that's related to the N64 hardware or the code for that smoke, but having lot of smoke in GoldenEye and PerfectDark caused BIG slowdowns in N64 real console playing.

[ziggy]

Thanks PsyMan, that should help a lot to find the problem. I'm having a problem with Mupen64 to boot Chameleon Twise (the game complains about the Rumble Pack malfunctionning), would you have a saved snapshot of the game so that I can skip this check ?

[PsyMan]

ziggy: Just remove the memory pack (from the input plugin configuration). ;)

SWAT_Marc: You're right, but this is smoke from a single bullet (no explosion or or other "heavy" stuff). Plus, the speed drops to less than 1fps as the smoke fades out.

As a side note, my ATi x600 also fails the "non power-of-two texture support" ogl test.

[ziggy]

Ah, my bad, I had removed the memory pack, but only from the first controller, forgot the second one :) Ok, so, the impression I get is that the problem is with non power of two textures. The plants as well as the smoke are using textures of that type (for example the smoke has a texture with 56 as width)

The solution is to use another extension, it's called texture_rectangle, it's more limited and a bit a pain to use, but it's probably supported. Could you check wheither you have this extension ? EDIT : there might be several texture_rectangle extension, the best would be ARB_texture_rectangle, but also tell me if you have other ones.

[PsyMan]

The report says that ARB_texture_rectangle and EXT_texture_rectangle are supported. :)

[ziggy]

Ok, R8 is out , hopefully fix this slowness issue related to non power of two textures and certain use of clamping mode on ATI.

[PsyMan]

Still the same with R8. Both games have no speed changes...

[ziggy]

Still the same with R8. Both games have no speed changes...

Argh, I really though it would be the good one. Well, here are two version to test, they won't look right, but it's just to test the speed again.

[Flash]

Still fails to compile in linux:
rsp.cpp: In function `void rsp_init(RSP_INFO)':
rsp.cpp:278: error: `memset' was not declared in this scope

[ziggy]

Hmmm, add in rsp.cpp :

#include <string.h>

and also in rdp.h.

[PsyMan]

Here are the results I've got with these 2 versions:

The "z64-tp2" version has some (heavy) gfx glitches (as you already said) but it fixes 3 (!) of the issues I had.
- Speed is OK now on all games that suffered major slowdown.
- The random "freezes" I had on some other games are also gone.
- On Shadowgate the screen would turn black at some point during the intro movie (if you let it play) that would stay there until you exit the emulator. This is fixed.

The "z64-clamp" version has less "heavy" gfx glitches but it fixes only the slowdown issues. This means the following:
- The "random" pauses on some games are still there.
- On Shadowgate the screen turns black at some point during the intro that stays there until you restart the emulator.

A weird (probably not related) bug remains on Shadowgate though; if you switch to fullscreen then the screen will be black until you exit the emulator even if you switch back to window mode (this happens with all versions of z64 and it is not fixed yet).

[ziggy]

That's curious. Here's another version to test.

The freezes you mention, how long are they ? one second , more , less ? Also, how often do they happen ?

About the black screen issue in Shadowgate, I'm having it as well. I suspect that the version "tp2" was "fixing" it purely accidentaly (it does it for me too). It's a problem of emulation inacuracy, but it's not hardware dependent so I'll leave this for later.

[PsyMan]

The "freezes" I mentioned are not so random after all... nor they are actually "freezes". It's probably an effect that drops speed dramatically but the games I tried use it just for very few frames (so it seems like a freeze). This actually happens under certain circumstances and affects only the "clamp" versions (end everything except the "tp2" version).

Here are some cases of this happening:

Chameleon Twist: During character selection only if you try to select the green or the yellow (brown) player. (the game freezes for some seconds when trying switching to them)

Castlevania Legacy Of Darkness: Randomly during the menus before you start the game.

Zelda OOT: On places with static images as background there is major slowdown. Speed drops below 1fps. (inside houses, hyrule town, etc)

Nothing of the above happens with the "tp2" version.

Edit: The new "clamp" version has textures fixed.

[Doomulation]

Banjo-Kazooie Intro drops to 0.1 VI/s still with z64-clamp2.zip (http://www.emutalk.net/attachment.php?attachmentid=36155&d=1178130771). Same with z64-clamp.zip (http://www.emutalk.net/attachment.php?attachmentid=36153&d=1178124662).
But I believe you've made progress with z64-tp2.zip. (http://www.emutalk.net/attachment.php?attachmentid=36152&d=1178124652)
Intro now works, at least for as long as I tested, with speeds from 15 to 40 VI/s. CPU use was around 30-40% (one core).

[ziggy]

Screenshots of Last Legion , a game using custom ucode.

EDIT : new release R9 based on the idea in the test tp2, it should fix all slowness issues (that I'm aware of) on ATI, and might even improve the general emulation quality in certain cases.

[ziggy]

Screenshots of framebuffer effects in Mario Tennis

[PsyMan]

Nice. Everything seems right now, almost everything actually:

- Slowdown still occurs on Zelda Ocarina of Time. It happens only on cases where black borders appear on the top and bottom of the screen and the button icons (and hearts) are about to fade in. This does not happen with the tp2 version. (check pic).

- If you let the Shadowgate intro play for a while it'll be messed after some point (unemulated framebuffer effect?). If you do this while in fullscreen it will also result in ingame textures being messed. Switching back to window mode fixes that. Doing that on window mode does not result in texture corruption.

PS: Don't you just love ATi's OpenGL drivers? :P

[ScottJC]

Does the framebuffer in BK work with this plugin with a nvidia card, just tried it on my X1950 (ATI) and its the same as every other plugin, jigsaw not working.

Speed is ok sometimes, gets quite slow though. 60 to 30fps.

Edit: Mario Tennis is showing me a bit more love (attached screenie)

[ziggy]

Good news SpyMan. Yeah I love those ATI drivers :) But we shouldn't put the blame entirely on their shoulder, I believe the problem you report now in Shadowgate isn't ATI's fault this time but rather general emulation problem in z64 :)

ScottJC, what is BK ?

EDIT : another nice transition effect in Mario Tennis' menus

[PsyMan]

Indeed. I was actually referring to the code you have to change because ATi's OGL drivers are far worse than their DirectX counterpart. The hardware is capable of various things... but the driver is the bottleneck.

When it comes to z64 issues... I also noticed that Star Fox 64 is broken on almost all versions. It works only on the builds you posted here (http://www.emutalk.net/showpost.php?p=378735&postcount=67) and here (http://www.emutalk.net/showpost.php?p=378750&postcount=77). All the other versions of the plugin show an "assertion failed" error message.

[ShadowFX]

ScottJC, what is BK ?
Well I saw him posting BK and jigsaw, so it must be Banjo-Kazooie :king:

I take it only parts of the framebuffer usage is emulated? I still get a bit of black around the ball effect (NVIDIA card here).

[ziggy]

Ah, yes indeed it makes sense :) Ok the Jigsaw effect in Banjo Kazoie "works", but not in this version of Z64. It requires the GetFramebufferInfo API that only (to my knowledge) Mupen64 supports. Furthermore, the official version of Mupen64 has a little bug (I wrote to Hacktarux about that already) regarding this API, so it wouln't work even if it was turned on in Z64. Finally, Z64 gets very unstable for certain games when this option is on (Z64's fault this time), so that's why I removed it for now.

[Rice]

I would like to say that frame buffer effects should not be primary focus of the new LLE plugin because it is possible to be done in HLE plugins. The ability to emulate unsupported RSP ucode should be primary focus, shouldn't it?

[ziggy]

Actually Rice, even though I didn't mention it in the project description, another goal for me in developing Z64 was to explore a bit framebuffer effects , simply because it was a problem that interested me. So, I haven't really a difference of priority between these two aspects, it depends a bit on my mood. If I feel I'm stuck on one aspect, then it's likely I'll work on the other one meanwhile. :)

[Rice]

Reason is that frame buffer effects aren't really too much to do with LLE. Approaching the effects with LLE won't give you advantages over HLE.

Frame buffer effects in N64 are actually not that complicate, even though it is not very easy to implement efficiently in modern PC's CPU-GPU architecture.

More inside about N64 frame buffer / rendering mechanism:
In N64, CPU and GPU (RDP + RSP) are sharing the same memory - 4MB/8MB RDRAM. After RDP has rendered some graphics into the RDRAM, it is just content in the memory, CPU, RDP, RSP can all use the content in a way or another. Most N64 frame buffer effects are to use the rendered content in the RDRAM as texture for later rendering. Another common way to use the content is the set the display buffer to a different location, so previous display buffer content is saved (untouched) and ready to be saved as textures (The BK jinsaw effect).

Having said these, you can probably see that LLE or HLE wont matter for these effects.

If a LLE plugin focuses on the LLE aspects, to run more unsupported ucode, it will make more sense and more impressive. You may want to just leave the frame buffer effects for now. It is not difficult to emulate such effects, it is the modern PC CPU-GPU architecture does not fit very well to N64 CPU-RDP-RSP architecture. The issue becomes more complicated if we want to use content in PC's video card frame buffer (high resolution content) instead of content in N64 frame buffer in RDRAM (There is actually no content there, unless you somehow copy the PC video card frame buffer content back to the N64 emulated RDRAM, and this is where COPY-BACK option in some video plugins comes from. And to do such COPY-BACK, we have to deal with screen size (resize), color conversion (PC RGBA8888 format to N64 RGB5551 format), etc.).


Rice

[ziggy]

Look Rice, I know very well LLE emulation has nothing to do with Framebuffer effects. :) It just happens that I'm interested in both problems ; as I'm not going to develop two different plugins at the same time, I'm doing my experiments in the same one project : Z64.

[Gonetz]

The key words here: depends on my mood. Yes, users demands can be taken into account, but let’s don't forget that prime goal of any such project is author's amusement :)

[olivieryuyu]

Very nice work indeed !!!

I am impressed by the speed of this emulator and the fact that some fb effects are handled nicely, as Mario Tennis.

I hope also it will help HLE to be more accurate and support more stuff as sky in PD.

Now there is still some things that are problematic, as Factor 5 or Boss games games and also the stretched textures in so many games. This latter is really something that now is going to be a real mystery as even LLE has this issue. For instance Ready 2 rumble.

Well anyway very happy to see that LLE is now a reality in N64 emulation.

Congrats

[elchhome]

Hi Ziggy,

nice work, but I get a shifted picture in the mario tennis menus. It does not matter which RSP implementation I take. a picture is attached

best regards...

[ziggy]

Yes there are problems with the screen setup sometimes. If you try Mario Party, you'll see it's even much worst for that game. Mario Tennis version US doesn't have that bug however.

Anyway, this is not high priority problem at the moment, I know it's there and I'll look at it sometimes.

[ziggy]

New release R10 that fixes yet again some ATI slowness issues , plus add a new configuration file + some other fixes.

This configuration file called "z64gl.conf" should be copied into the Plugin/ directory, it allow to select some options, in particular the screen resolution.

Sri Narayan, now "assert" statements have been replaced by "rglAssert" statements. To simply remove all the asserts , simply remove the RDP_DEBUG setting into the makefile. The win32 doesn't have any assert anymore either, meaning that people that have a geforce5900 for example might have better luck now.

[rcgamer]

Whoa, this is pretty nice. Using r10 I was playing Mario Tennis and getting fron 35-55 FPS even during the transition and replays. Nice work. Evfen the split screen effect at the beginning of a match looks nice(the vs. split screen).
Oh and I am using ati x800 with 7.4 drivers.

[rcgamer]

I get an unknown x86 opcode error with conkers bad fur day right off the bat.
Edit-that was using pj64. With 1964 conkers does run. Slow movie intro.

[PsyMan]

This configuration thingy made my day, especially the separate FS and Win resolution. :D

[MIO0]

How did you get the format of the hardware G_TRI* commands? gbi.h has the command numbers, but no information on the formant of the parameters.

[ziggy]

Well, I read "somewhere" that these command where the raw commands the RDP handles, the parameters being slopes instead of traditional coordinates. If you've written a software renderer, it will be familiar, usually to render a triangle, you calculate the starting point and from there, you need slopes , or variations, of the different values (colors, edges of the triangle, etc ...) so that you can render your triangle incrementally. On the N64, the RSP calculate the starting point and the slopes, and then the RDP do the actual rendering incrementally.

Then the next step was to find out how these parameters were encoded in the RDP command, and I was very lucky because I didn't have to do it myself :) Ville Linde from the project Mame/Mess had already done it. I only improved a little bit on what he did to get rid of some imprecisions (and there are still some remaining) Reverse engineering these parameters encoding was definitely the most difficult part and all credits for this goes to Ville Linde.

[smcd]

Since you are improving on MAME sources, are you contributing your findings back to the MAME project? That'd be great :) btw, nice work so far!

[ziggy]

I'm not contributing back directly to Mame, however all my source code is available and I'll definitely contact Ville Linde at some point.

Sethmcdoogle : by the way, at the beginning , you mentionned that you were able to view some stuffs in Rogue Squadron, which emulator were you using ? Personally I'm stuck on the expansion pack screen with Mupen64 ...

[smcd]

I used pj64 1.6 with latest rdb, lle rsp plugin and one of the earliest (r1, r2?) z64 editions. I didn't try to get further into the game, but the expansion screen showed then the little space ships flew around in the next screen and I closed the program

[gandalf]

I tried the plug-in, but Pj64 (also Mupen and 1964) crashes everytime when the game tries to render something 3d, it not crash when renders something 2d (like 1080 snowboarding intro, the n64 logo and more stuff)

It´s the same with all z64 video plug-in versions, and with the z64rsp and the pj64rsp modified. :(

Specs of my comp are still there in my profile (6600GT AGP video card 93.71 drivers)


EDIT: And there´s no LOG created :S


EDIT2: Maybe a driver problem? (these drivers are modified, Xg drivers, not oficial ones)
zbench64log:

test #00 7.81904
test #01 7.82096
test #02 7.84882
test #03 7.7991
test #04 7.8238
test #05 7.82314
test #06 7.83111
test #07 8.02833
test #08 8.06206
test #09 7.81409
test #10 15.5993

EDIT3: Yes, there´s LOG created (after tried to play Mario Golf)

z64err:

rom name 'MarioGolf64'
key 'res_x' value 640
key 'res_y' value 480
key 'fs_res_x' value 1024
key 'fs_res_y' value 768
key 'hires_fb' value 1
key 'fb_info' value 0
section 'ZELDA MAJORA'S MASK'
section 'MAJORA'S MASK'
section 'Banjo-Kazooie'
section 'BANJO KAZOOIE 2'
section 'BANJO TOOIE'
section 'MARIOKART64'
section 'ZELDA MASTER QUEST'
section 'THE LEGEND OF ZELDA'
viewportOffset 23
fix hend
creating fbo 400 320 x 240 fmt 0
Creating depth buffer 400 640 x 486
creating fbo 38f800 320 x 240 fmt 0
fix hend
creating fbo 400 320 x 240 fmt 0
Creating depth buffer 400 640 x 482
creating fbo 3b5000 320 x 240 fmt 0
creating fbo 3da800 320 x 240 fmt 0
creating fbo 38f800 320 x 240 fmt 0


z64log:

rglInit()
rglClose()

[ziggy]

This sounds quite strange. Might be driver related, but there shouldn't be any difference between 2d and 3d stuffs, they all go through the same OpenGL code.

Could you try this version ? It might produce better logs.

EDIT : if there's no log, try to redownload the archive, the first version had a mistake in it

[Trotterwatch]

Rogue Squadron works up until the title screen when it crashes - the bits prior to the crash though look superb.

For me if a game doesn't work I set the RSP plugin to process audio lists or vice versa (for some reason that tends to work).

[gandalf]

For me if a game doesn't work I set the RSP plugin to process audio lists or vice versa (for some reason that tends to work).

Well, i tried with the PJ64 RSP, and i did the same thing (send audio list to audio plug-in) and it works! (slooow, but well, it doesn´t matter now)


I think , this plug in has a little time out there, but the emulation it´s great, at least i see a plug in that makes a nice transition, in banjo kazooie, between Rare (when the mosquito crash with it) logo and the intro (when the mosquito fall in the water)!

And the sky in goldeneye, that´s great :)

[ziggy]

What's your CPU Gandalf ? Have you tried my debug version in the previous post ?

[gandalf]

My CPU it´s an AMD Sempron (socket A) 2600 @ 2.1ghz
Motherboard ASUS A7N8X E-Deluxe with Nforce 2 Ultra 400 (soundstorm sound) 1GB ram DDR (1:1 with FSB), Windows XP SP2

I tried with it, but with your RSP and crashes (still no log :S), now i´ll try it, but with PJ64 rsp


I´m so sorry, i´m bad for this things :(

[grand master]

WOW! My first post in prob 4 yrs. I've been waiting for a LLE/software plugin for the 64 for ages (actually found this by randomly entering software plugin in google). I would love to have a plugin that faithfully recreates the n64 in all it's mid 90's crappy-ness. I used to love playing the games at high res but now i have a serious case of nostalgia and would love these games preserved in their original format. In my mind software/LLe emu is what should be undertaken. HLE is not true emulation (but great none the less)
Great work Ziggy. Would love to do some testing but i have so many test at the mo. Keep up the great work!

[grand master]

Just took the plugin for a spin. Very impressed already. Mario Tennis is easily the best i've seen from any other plugin. GoldenEye is sluggish on my comp (x2 4400+ 7800gt Extreme). I'm sure speed will improve when it it optimised and improved. As it stands it's a very good and promising plugin. Hopefully you will develop it further, cause as i said i would love a LLE/software plugin so i can get the most authentic n64 experience.
Great work. Keep it up!.

[olivieryuyu]

Rogue Squadron works up until the title screen when it crashes - the bits prior to the crash though look superb.

For me if a game doesn't work I set the RSP plugin to process audio lists or vice versa (for some reason that tends to work).

Same for Indiana Jones :-) crash when the menu must show up :-(

[Knuckles]

all I know now is that my Ati Radeon M6 32MB doesn't support it :P

instant-crash on 1964 and PJ64 on my laptop....not home right now... can't wait to test it ;)

[da1writer]

How is everyone getting this to work?
What dll's do I need?
I downloaded the Win attachments (extracted them) and put them in the directories I believe they should be in but I keep getting an error whenever I try to open a game like Goldeneye,etc.

Grabbed:
R10
R2
Glew

Specs:
Amd64 X2 4800+
Windows XP Pro
Geforce 7800 GTX

[Doomulation]

Well, glew into windows\system32. RSP & Plugin into plugin directory. Select rsp & plugin with mupen and away you go.
For Pj, you're supposed to rename the rsp to rsp.dll and switch it with pj's default rsp. Then select plugin and it should work.
That's all.

[Knuckles]

It's nice to see sky in Perfect Dark and the blur effect from fists, N-bomb and tranquilizer.

nice :)


But of course... it's slow...

[Flash]

g++ `pkg-config gtk+-2.0 --libs` -o tester rsp_dasm.o tester.o -g -rdynamic -lGL -lGLU -lGLEW -L/usr/X11R6/lib /usr//lib/libglui.a -lglut `freetype-config --libs` -lftgl `sdl-config --libs` -lz -fomit-frame-pointer
tester.o: In function `main':
/usr/tmp/CompileMOO/z64-r10/tester.cpp:172: undefined reference to `dlopen'
/usr/tmp/CompileMOO/z64-r10/tester.cpp:174: undefined reference to `dlopen'
/usr/tmp/CompileMOO/z64-r10/tester.cpp:175: undefined reference to `dlerror'
/usr/tmp/CompileMOO/z64-r10/tester.cpp:177: undefined reference to `dlsym'
/usr/tmp/CompileMOO/z64-r10/tester.cpp:178: undefined reference to `dlsym'
collect2: ld returned 1 exit status
make: *** [tester] Error 1

[ziggy]

Ok, it fails to build a tester application, instead of "make" do "make z64gl.so z64-rsp.so" to build only the plugins.

[ziggy]

Rogue Squadron works up until the title screen when it crashes - the bits prior to the crash though look superb.

For me if a game doesn't work I set the RSP plugin to process audio lists or vice versa (for some reason that tends to work).

I'm still unable to start Rogue Squadron or Indiana Jones. What emulator exactly are you using and which rsp plugin ?

[Trotterwatch]

For Rogue Squadron

rsp-pj64-ziggy-r2-win32 > as RSP
Last version of the plugin
PJ64 1.6 as the emulator
Jabos Dsound 1.6 for audio

Settings for rom, Recompiler mode, protect memory, 4mb, everything else defaults (these may not be optimal, just what works for me)
RSP setting > alists and dlist boxes both unchecked

You can also get it to run with Alists checked but for me that entails settings CF to 5 or above (otherwise it instantly crashes).

[olivieryuyu]

For Indy i used 1964 and it works until menu, crash after.

I got the same result than Trotterwatch for Rogue Squadron, a very nice intro :-)

[ziggy]

Thanks, what is CF ?

EDIT : forget it, found the option :)

EDIT2 : ok, I managed to have Rogue Squadron work somehow, using Pj64 v1.7 and then doing a savestate after the first screen, I then load it up in Pj64 1.6, I'm still stuck with Indy however.

Olivieryuyu, would you be ok to send me a savestate of Indy shortly after is has booted ?

[olivieryuyu]

yes i will do that as soon as i am back at home, in few hours :)

[olivieryuyu]

Sent :-)

Here 2 ss of Indy btw

[Trotterwatch]

One more of Indiana Jones - decided to try and enter the cheat code to see if any levels loaded. Several of them go to the pre-game screen, none seem to go into a playable game (not that I expected that, but just checking for curiosities sake).

[ziggy]

Ok, thanks for the savestate , unfortunatly , I still can't see anything. There must be something wrong in my settings of the emulator but I don't see what (and I'm not very familiar with Project64)

On the other hand, I've managed to go further in Rogue Squadron under Mupen64. The trick was to load a savestate to skip the first screen, because Mupen hangs on this. For that I had to do a pj64 savestate loader in mupen. It works well, so now I get the intro, I enter the menu, and then when I want to start a game , I can go up to the point of the starwar 3D text scroller , but unfortunatly at this point mupen doesn't recognize any input from the controller anymore. The game isn't crashed, it's just I can't go beyond that point since the "start" button is ignored.

That's an annoying very rare bug of mupen64, sometimes the controller inputs don't work anymore (the only other game where I noticed that is Donkey Kong 64, I suspect it's the same bug)

[rcgamer]

This sounds pretty exciting. I've been waiting for some of these games to start coming along. The N64 emu scene has been pretty stale for a while. Thanks for waking it up some ziggy.:bouncy:

[SeymourOmnis]

I get around 80FPS in Super Mario 64 with PJ64 1.7's RSP plugin, and around 45FPS in Goldeneye. Is this normal?

Core 2 Duo 3.5ghz
8800GTX

[Edit: It seems that the speed is variable, in goldeneye sometimes I get full speed in Dam, but also in SM64 it slows down sometimes in the first level. Any cause to this)

Also zbench64 crashes for me, but here are the results:

test #00 1.69842
test #01 1.64458
test #02 1.6395
test #03 1.64033
test #04 1.63949
test #05 1.69431
test #06 2.21903
test #07 2.37986
test #08 2.39267
test #09 1.69452
test #10 3.06304

[ziggy]

You should use the RSP plugin based on Pj64 1.4 I'm providing, it should be much more fast. But you can't use it in Pj64 1.7 (I don't know why yet) so try an earlier version or another emulator.

[mudlord]

You should use the RSP plugin based on Pj64 1.4 I'm providing, it should be much more fast. But you can't use it in Pj64 1.7 (I don't know why yet) so try an earlier version or another emulator.

From what I know, the threading methods in PJ64 1.7 have changed a bit, especially when plugins and games are loaded and executed:

for instance: In 1.6, the plugin is loaded in its own thread and then kills itself, and then the ROM executes in the main emulation thread.

However in 1.7 (current version), the plugin loads in PJ64's GUI thread, and then the ROM is opened in the emu thread.

Maybe that might be a possible answer?

[FloW3184]

Nice to see someone working on N64-Emulation!
Damn... it seems that everyone uses PJ64 1.7 except me ^^...
If i werent that broke, i would spend some money for it ;).
Maybe next month.

[NES_player4LIFE]

man this is goooooood

i just wish i had a vidcard with opengl 2.0:(

[ggab]

great plugin!!

thanks a lot ziggy :)


GAB

[The Siskoo]

Hello all,

Here some tests :

Emulator : 1964 0.9.9
Plugins : Z64Gl, Z64 RSP
Game : Telefoot Soccer 2000 (F)

Your plugin is the first to display some screens with this game :) Congrats

[olivieryuyu]

Hello all,

Here some tests :

Emulator : 1964 0.9.9
Plugins : Z64Gl, Z64 RSP
Game : Telefoot Soccer 2000 (F)

Your plugin is the first to display some screens with this game :) Congrats


In fact it is playable with MESS (very slow ok :-) ).

[olivieryuyu]

Rogue Squadron in game :-)

[mudlord]

Rogue Squadron in game :-)

Wow, olivieryuyu, that looks amazing! (Image quality is definately a improvement over Jabo's LLE)

What ROM settings are you using and how did you get into the game?

[Jelta]

battle for naboo in game.
change jabo to z64 on the way.

[ziggy]

I'm very jealous , apparently I'm the only one who can't make work rogue squadron nor battle of naboo :)

New release (r11) :

- screen setup fixes (Mario Tennis screen isn't shifted any more, huge improvement for Mario Party too, Telefoot doesn't crash anymore)
- new framebuffer effects : see screenshots for Perfect Dark below
- some multitexturing fixes (fixes roads in Zelda OoT for example and some textures in ReVolt, but doesn't fix yet sky in Beetle adventure racing)
- better texture management (improve things in games that use lot of dynamic textures, like Beetle adventure racing and Mystical Ninja)

Some new screenshots of Telefoot and Perfect Dark (for Telefoot, use the z64-rsp plugin, otherwise textures aren't correctly mapped, fortunatly the RSP code in that game is "light" so it still runs reasonbly fast)

I'm also including a win32 version of the plugin with the embeded debugger ; use the following keys :

P : to enter / exit the debugger
keypad +/- : change framebuffer
up/down : scroll the RDP disassembler window
page up/down : same but by half a page step
TAB : move the disassembler window
left mouse click : select a polygon (EDIT : mouse won't probably work correctly unless you're in fullscreen mode)

You need to put LucidaTypewriterRegular.ttf into the emulator top directory to use the debugger.

Note : depending on which emulator you use, you might need to try several time to press 'P' before you see anything useful.

[The Siskoo]

Computer specs :
Processor : AMD Athlon 64 3200 +
Memory : 1 Go DDR Corsair
GFX Cards : Ati Radeon X1950 Pro - Official ATI 7.4
Directx 9.0c 2007 April.


Emulator : 1964 0.9.9
Plugins : Z64G R11l, Z64 RSP R11
Game : Telefoot Soccer 2000 (F)

Olivieryuyu, I never used Mess. So thanks for the info :)

Whoooo, nice improvements, I've got some bugs. Football players losts their feets (Pic 7). Screen shaking (pic 5). Some problem of resizing (pic 1-2-6).

[The Siskoo]

Game : Nintama Rantarou 64 Game Gallery (J) [!]

In game, FPS decrease and the game is slow. Some glitches in game too.

[ziggy]

I'm not entirely certain the player loosing their feet is an emulation bug. The game uses LOD on the player models, so it's possible lower resolution models don't have distinguishable feets.

About the screen shaking, this is indeed a little bug, but I didn't yet find the fix. It should be only a slight shaking however, and only of a part of the screen (especially the text in the lower part). If you are having more shaking than just that then maybe you have a problem ( maybe again ATI related, or win32 related ) EDIT : maybe you should try fullscreen mode too and see if it improve things

[The Siskoo]

Game : Nushi Zuri 64 - Shiokaze Ni Notte (J)
1964 Status : Not working --> Playable :)

Screen shaking (any time - chat, move in game). It's slight.

[The Siskoo]

I'm not entirely certain the player loosing their feet is an emulation bug. The game uses LOD on the player models, so it's possible lower resolution models don't have distinguishable feets.

About the screen shaking, this is indeed a little bug, but I didn't yet find the fix. It should be only a slight shaking however, and only of a part of the screen (especially the text in the lower part). If you are having more shaking than just that then maybe you have a problem ( maybe again ATI related, or win32 related ) EDIT : maybe you should try fullscreen mode too and see if it improve things

About shaking, I've got just with the text. In fullscreen, it's a little bit better, but still present

World Driver Championship (E) [!] and (U) : error message --> 800766BC : Exception in emulation thread.
Stunt Racer 64 (U) [!] : error message --> 8009D2FC : Exception in emulation thread.
Hydro Thunder (E) and (F) : black screen (idle in 1964 : 99%).
Hydro Thunder (U) : works but it's slow and there are some GFX bugs. No sound too.
Nightmare Creatures (U) [!] : Black screen.
Dark Rift (E) [!] : after the second introduction screen (kronos digital......), the emulator close alone.
Dark Rift (U) [!] : after the second introduction screen (kronos digital......), crash with this error message --> 8003B84C : Exception in emulation thread.
Nushi Zuri 64 (J) [!] : very nice, we have the text now. Anyway, the screen have a slight shaking.
Pokemon Snap (all countries) : problem with the text (Pic 1)

[ziggy]

With Mupen64 under linux, I got Nightmare creature working (playable) and Hydro Thunder working partially (it freezes shortly after the game has started, I suspect it's a core issue though)

Nushi Zuri - Shiokaze Ni Notte doesn't work with mupen64 nor project64.

Dark Rift : it works with Mupen64 under linux

[The Siskoo]

With Mupen64 under linux, I got Nightmare creature working (playable) and Hydro Thunder working partially (it freezes shortly after the game has started, I suspect it's a core issue though)

Nushi Zuri - Shiokaze Ni Notte doesn't work with mupen64 nor project64.

Nushi Zuri - Shiokaze Ni Notte - works with Mupen64 0.5.1 under windows ?!? Works properly (no shaking like with 1964)
Hydro Thunder --> crash after the first jump (when you get the boost). -Mupen64 0.5.1 Windows

[ziggy]

Nushi Zuri - Shiokaze Ni Notte - works with Mupen64 0.5.1 under windows ?!? Works properly (no shaking like with 1964)

Very strange, what settings are you using ? I've tried the win32 version of mupen too and I can't get it to run.

About the shaking, if you don't have any in mupen then it's probably an issue with interlaced mode. Could you try with Project64 1.6 and tell me if you have shaking there too ?

[The Siskoo]

Very strange, what settings are you using ? I've tried the win32 version of mupen too and I can't get it to run.

About the shaking, if you don't have any in mupen then it's probably an issue with interlaced mode. Could you try with Project64 1.6 and tell me if you have shaking there too ?

Video plugin : z64gl (r11)
Sound plugin : Azimer's HLE Audio v0.56 WIP 2
Input plugin : Nrage 2.2.00b (rabbidity plugin)
RSP plugin : z64 (r11)

No shaking with PJ 1.6 :)

[ziggy]

By the way, the problem of resizing in pic 1-2-6 you mentionned earlier, did you test in fullscreen mode ? It shouldn't happen, I don't have this bug.

[The Siskoo]

By the way, the problem of resizing in pic 1-2-6 you mentionned earlier, did you test in fullscreen mode ? It shouldn't happen, I don't have this bug.

I just tested in fullscreen mode and no problem of resizing except the second logo (Silicon dreams) move to the center alone. The former tests was in all in windowed mode :)

[olivieryuyu]

To get to Rogue squaron in game i use Rice with normal RSP with Pj 1.6. there is sound so i can know when you are in game. at this time savestate and go in LLE.

Hydro thunder is a timing issue, so core issue. Hacktarux could explain much better than me this.

[Nick_kidid0]

Great work, just wondering if the "bright lights" in perfect dark are emulated? (Corona Fix?)

I'd test myself but my GFX card isn't compatible.

[The Siskoo]

1080 Snowboarding (E) (JU) [!] --> crash with 1964 0.9.9 and project64 1.6(before the menu), and works with mupen64 0.5.1 (fps are slow) We can see some vertical thin line on the logo (pic 1-2).
AI Shogi 3 (J) [!] --> Works with 1964, there is just some lit gfx issue on the main screen (pic 3). Game not playable with Project 64 1.6 and Mupen64 0.5.1 (GFX are messed).
Bakuretsu Muteki Bangaioh (J) [!] --> With the 3 emulators, same GFX issues (pic 4), anyway, there are no slowdowns in game like with Rice plugin (better GFX).

[FloW3184]

i like the progress of your plugin!
Would you like me to test some games and report the eventual gfx bugs?

[ziggy]

i like the progress of your plugin!
Would you like me to test some games and report the eventual gfx bugs?

Thanks for the proposition. Not yet, because there are still too many obvious problems, but later on definitely.

However what would be very useful to me at the moment is that you report any regression you notice when I do a new release. For example I just noticed one regression between r10 and r11 (torch flames and the logo in Zelda MM) and it's easy to let slip some. So , testing that I don't break anything that used to work in new releases would be very helpful.

[Iconoclast]

AI Shogi 3 (J) [!] --> Works with 1964, there is just some lit gfx issue on the main screen (pic 3). Game not playable with Project 64 1.6 and Mupen64 0.5.1 (GFX are messed).This is not a cause of the z64 graphics plugin. This game is known to be unplayable in Project64, Mupen64, Nemu64 and other emulators, regardless of the graphics plugin being used. These graphics issues are caused by the core.

Here's an interesting tidbit: Rice's Daedalus gives better graphics than Rice's Video 6.1.1 for this game. Well, alright, at least till you use 32 bit texture and all that texture enhancement crap, but still, Daedalus obviously is faster on 1964.

Edit: The magic post count # has been reached. :D

[The Siskoo]

This is not a cause of the z64 graphics plugin. This game is known to be unplayable in Project64, Mupen64, Nemu64 and other emulators, regardless of the graphics plugin being used. These graphics issues are caused by the core.

Here's an interesting tidbit: Rice's Daedalus gives better graphics than Rice's Video 6.1.1 for this game. Well, alright, at least till you use 32 bit texture and all that texture enhancement crap, but still, Daedalus obviously is faster on 1964.

Edit: The magic post count # has been reached. :D

Thanks for info. Maybe I could add this (in the comments) to the unofficial 1964 ini !!! If you could give me the full info :) Rice Daedalus or Rice Video ?

[Iconoclast]

These are my notes when testing this game:

There are no known issues for this game.
---
Recommended Emulator: 1964
Recommended Plugins:
Graphics: Glide64 or Rice's Daedalus 5.2.0
Audio: Azimer's HLE v0.56 The only official emulator that can really support this game's graphics is 1964. Since this is a puzzle game, the graphics plugin does not need to support that many things, relatively. Direct64 and glN64, however, emulate the title screen at a wrong resolution. Nemu64's graphics plugin, when used with any emulator, won't even start the game. Four remaining graphics plugins qualify for near-perfect emulation. Rice's Video Plugin also works, once configured properly, but there's no point in using that when Rice's Daedalus, which is even faster, works just fine. Finally, Jabo's Direct3D has some fine texture mapping glitches with the game. RSP emulation is not required for this game, but the sound can be a little glitchy. Only Nemu64's audio plugin can emulate this sound without any crackling whatsoever, and Nemu64's core cannot fully support this game's graphics. The next best thing for 1964, however, is Azimer's HLE.
---
This is my INI configuration for AI Shougi 3 and can be used on either Rice's Video or Rice's Daedalus.

{a682c18cb0cad0c2-4a}
Name=AI¼®³·Þ3
NormalAlphaBlender=1
NormalColorCombiner=1
IncTexRectEdge

[ziggy]

I made some nice progresses in Rogue Squadron : zbuffer issues are fixed and the sky is now properly mapped (EDIT : apparently it fixes also the issue in Bakuretsu Muteki http://www.emutalk.net/attachment.php?attachmentid=36295&stc=1&thumb=1&d=1179402468).

Other improvements soon to come : more combiner/blender fixes so the sky in Beetle Adventure Racing is finally correct, also fixes without nasty hack the roads in Zelda OoT. Better mapping algorithm , which get rid of black border texels in Mishief Makers for example and other 2d mapping.

All these in R12. :)

EDIT : it seems to also fixe texture mapping in Ready 2 Rumble ( the problem was exactly the same as in the sky of Rogue Squadron and Bakuretsu Muteki)
EDIT : another game being improved for the same reason : Neon Genesis Evangelion

[The Siskoo]

Sounds good :)

About Bakuretsou, there still some thin lines when you shoot, but that's really better than before :). Here 3 Pics when you walk with the robot. Small Lines moves. (Tested with Mupen64 0.5.1, 1964 0.9.9 and Project 64 1.6).
Pokemon snap : problem with the text are fixed whit R12 :)
keep up the good work Ziggy, nice plugin :)

[PsyMan]

I can see some improvements here too...
Yoshi's Story is perfect now until you reach ingame (backgrounds are messed). Some of the purple lines around text on Quest 64 are fixed (some are not). Black thin lines during the Shadowgate intro are gone (every other plugin has these for me). Texture errors on Mystical Ninja seem fixed too.

Nice progress ziggy. :)

[Trotterwatch]

The title screen for Indiana Jones + the options screen is perfect now :)

[mudlord]

The title screen for Indiana Jones + the options screen is perfect now

Yep, can confirm. Just tested on the Core 2 Duo I'm currently working on :). Same with the Rogue Squadron fixes.

Great work btw, ziggy :)

[mr_tecnico]

Hi, i was testing R12 with pj64 rsp and mupen64 0.5 linux, and testing pokemon snap, when it comes to the foto selection part, it crashed my X server..

[olivieryuyu]

Ok i did some tests, some amazing things, some bugs.

1) Indy title: uses 1964.

2) Dynamic soccer: nearly correct now, still a small mapping issue i guess

3) NBA hang time: fast but some gfx issues

4) iss64: damn there is a big problem here !

5) pga european tour: still no sky texture

6) extrem g : title is wrong (blue square should not appear): one of the mystery of the N64 emulation

7) south park: the radar is fixed. i don t understand the linkwith mapping but that is good :-)

8) cybertiger is fixed totally, oh nice it is !! :-)

9) madden 2000: wrong ground

[Trotterwatch]

1) Indy title: uses 1964. > Works in PJ64 too

[ziggy]

I just released a new version of the modified pj64 rsp plugin. It should fix most differences with the z64-rsp plugin, for example now Telefoot works with it.

A call to the nice beta testers here :) : If you find any game that are still working differently with z64-rsp plugin and pj64 rsp plugin, I'd like to know which it is. Thanks in advance.

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : z64gl R12, z64-rsp R12

007 - The World is Not Enough (E) (M3) [!] --> the screen shake (no problem of shaking with (U) version), 16 FPS
1080 Snowboarding (E) (M4) and (U)[!] --> 34-38 FPS. Thin line displayed in the game. (Pic 4)
AI Shogi 3 (J) [!] --> menu screen is nice :)
All Star Tennis '99 (U) [!] --> slow, 26 FPS.
Bio Hazard 2 (J) [!] --> gfx are messed. (Pic 5)
Ganbare Goemon - Mononoke Sugoroku (J) [!] --> pink color on texts !!! (Pic 3)
Indiana Jones and the Infernal Machine (U) [!] --> I can go on the second screen after the start menu (Pic 1 and 2)
Nintama Rantarou 64 Game Gallery (J) [!] --> 23 FPS, glitches in game, logo (culture brain) is nice (no more thin line).
Supercross 2000 (E)(U) [!] --> no ground (black ground), no public, very low FPS, sound hangs. (Pic 6)
Tamagotchi World 64 (J) [!] --> thin line. (Pic 7)
Telefoot Soccer 2000 (F) [!] --> problem with the texts and with the legs of players. No more shaking screen ;) (Pic 8 and pic 9)
Zool - Majou Tsukai Densetsu (J) [!] --> slow 40 FPS.

[ziggy]

Again a new release of the modified pj64 rsp plugin (R4). Only a small trivial change to get rid of the annoying popup dialog that appear in certain games (Telefoot was one of them)

Apparently there are still some differences since I cannot use it for Battle of Naboo nor Indy.

[jackschmidt]

I tried the r2 z64 release and it crashes 1964 and mupen on my end. Not sure what was wrong.

At first I tried it on Toukon Road 2, and that did not work. Then I tried it out on other games and I noticed it crashes everytime I use it.

I'm not sure if this is any help, but I just wanted to test it out and have come up empty handed. Sorry.

I'll try the newer releases when I find the time.

Radeon x800 pro 256mb.

[The Siskoo]

Emulator : Project 64 1.6
Plugin : z64gl r12, porject 64 rsp r4

Try this :
- Launch the game what you want.
- End emulation (File --> End emulation)
- Launch another game. Project64 close auto.

[ziggy]

New version (R13) with :

- some texture formats fixes (for example text in Tom Clancy's Rainbow, some double texturing in Conker's Bad Fur Day)

- Some screen setup fixes (Extreme-G doesn't crash anymore)

- A new option for video cards that do not support non power of two size FBOs (for example geforce 5900)

[Trotterwatch]

Most of the graphics bugs in NBA Hangtime have now disappeared, should be fully playable on a fast machine. Runs about half speed with sound here on a lowly P4 2ghz, so anything double that should be good enough :)

[The Siskoo]

Lot crash with this release for me
Ganbare Goemon : Error XXXXXXX : Exception in emulation thread.
Aeorfighter Assault : same
etc...

[ziggy]

What options are you using The Siskoo ? Anyone else had problems with this release ?

[The Siskoo]

I just copy paste new files in the plugin folder. Launch 1964 0.9.9 and tested games :)
btw, Siskoo instead The Siskoo :)

Edit : made a test with R12 and games works. With r13, games don't works...

[ziggy]

Could you try this version, it should produce two log files, hopefully we'll get more informations from these.

[jackschmidt]

Okay, I'm doing these tests primarily on these settings:

Mupen 0.5.1

Windows

Radeon x800 Pro 256 mb.

z64-r13-win32
rsp-pj64-ziggy-r4-win32
nrage-direct-input v2 1.82a
azimers-hle audio 0.56

Toukon Road 2 - Mupen changes resolution and then Windows says Mupen has crashed.

Indiana Jones - Mupen changes resolution again and then crashes.

Star Wars Rogue Squadron - same result.

[ziggy]

Rogue Squadron and Indiana Jones, don't use Mupen it won't work. Instead Pj64 1.6 or 1964. Also for Indiana Jones, use the z64-rsp plugin. In any case, you should try basic games like Mario 64 and Zelda first. These ones should work with any emulator and both rsp plugins.

[The Siskoo]

Here 2 games :
007 The world is not enough (E) --> black screen.
Aerofighter Assault with error exception............

[ziggy]

Does it also crashes with the modified pj64 rsp plugin R4 ? I don't understand what is the problem, the logs don't show anything wrong.

[jackschmidt]

Rogue Squadron and Indiana Jones, don't use Mupen it won't work. Instead Pj64 1.6 or 1964. Also for Indiana Jones, use the z64-rsp plugin. In any case, you should try basic games like Mario 64 and Zelda first. These ones should work with any emulator and both rsp plugins.

Mupen 0.5.1

Windows

Radeon x800 Pro 256 mb.

z64-r13-win32
rsp-pj64-ziggy-r4-win32
nrage-direct-input v2 1.82a
azimers-hle audio 0.56

Super Mario 64 yields the same result. Just changes resolution and crashes.

Did I install this correctly?

I copied RSPcomp-pj64.dll into the mupen folder. I then copied z64gl.dll z64gl.conf and z64-rsp.dll in the plugins folder.

[ziggy]

Was it working with the previous version R12 ?

[jackschmidt]

The last version I tested was r11, which is my first post in this thread. Should I try R12?

Edit:

I copied r12 plugins over and tried Super Mario 64 with not much success.

[ziggy]

Well you could. But if it wasn't working with R11, it probably won't with R12. Apparently it's a problem related to your system.

Could you try the debug version I just released a few posts ago and send the log files that should be generated ?

[jackschmidt]

Will do. Where should I expect the log files be dumped? I presume in the plugin folder?

I'm going to test it as we speak.

Edit: found it. I'm going to attach it now.

[ziggy]

No, above , in the same place as the emulator executable. The files are called z64err.txt and z64log.txt.

[The Siskoo]

Does it also crashes with the modified pj64 rsp plugin R4 ? I don't understand what is the problem, the logs don't show anything wrong.
If i understand, i put pj64 rsp R4 in 1964 plugin folder. Choose this RSP and test ?!?
I just test this and it works except for 007 The world is not enough. Always the same bug. The game don't launch.

[ziggy]

Yes that's the way to use it, as explained on the very first post of this thread.

Ok, so the problem is with the rsp plugin, here's a new version to test it should fix it. Please tell me if the rsp plugin in this version now works.

But you should use the modified pj64 rsp plugin whenever you can, it's much faster. :)


EDIT : this new version fixes more combiner thingies as well, and some very rare case of texture being badly clamped.

EDIT2 : this release is now on the main page.

[jackschmidt]

Yes that's the way to use it, as explained on the very first post of this thread.

Ok, so the problem is with the rsp plugin, here's a new version to test it should fix it. Please tell me if the rsp plugin in this version now works.

But you should use the modified pj64 rsp plugin whenever you can, it's much faster. :)


EDIT : this new version fixes more combiner thingies as well, and some very rare case of texture being badly clamped.

I'm not sure if you were referring to me or Siskoo (probably him). Anyway I gave r14 a try and nothing changes.

[The Siskoo]

Yes that's the way to use it, as explained on the very first post of this thread.

Ok, so the problem is with the rsp plugin, here's a new version to test it should fix it. Please tell me if the rsp plugin in this version now works.

But you should use the modified pj64 rsp plugin whenever you can, it's much faster. :)


EDIT : this new version fixes more combiner thingies as well, and some very rare case of texture being badly clamped.
Ok, error are fixed. 007 - The World is Not Enough (E) (M3) [!] don't boot (works with r12). And I test a quick thing. All Star Tennis was slow. With pj64 rsp, no slowdowns, with z64gl rsp, slowndows :)
More test tomorrow, I'm going to sleep, it's very late :)
Good job mate
Question : with 1964 0.9.9 and your video plugin, can we choose some options (like rice) or not ?

[ziggy]

Yeah , I'm going to sleep as well. Thanks for the help, that was a stupid bug of mine (some debugging code left in the rsp plugin). :)

EDIT : R14 is out on the main page. A screenshot of Mischief Makers showing one of the combiner now working right.


Question : with 1964 0.9.9 and your video plugin, can we choose some options (like rice) or not ?
Yes, just edit with a text editor the file z64gl.conf.

[mudlord]

Just a small suggestion for this:

Why not use a check for the extension dealing with NPOT textures? That way, if a card supports the textures, it will enable it, otherwise framebuffers and other textures will use power of two dimensions.

[ziggy]

I cannot do that, because some cards (i.e. ATI) do not advertise the feature but actually do support it (only partially, but enough for what I'm doing with it). Otherwise, I would have done that of course :)

It's a complicated problem, ATI do support it, but only with certain clamping modes, with other clamping modes it gets slow as hell (that was the problem that took me so much time to sort out in the beginning)

[mudlord]

I cannot do that, because some cards (i.e. ATI) do not advertise the feature but actually do support it (only partially, but enough for what I'm doing with it). Otherwise, I would have done that of course :)

It's a complicated problem, ATI do support it, but only with certain clamping modes, with other clamping modes it gets slow as hell (that was the problem that took me so much time to sort out in the beginning)

Oh alright, it just strikes me as odd at first that this method of detection wasn't implemented earlier...But it makes sense of ATI not exposing the extension when thier cards seem to have the NPOT implementation incomplete, from what your saying. :)

[The Siskoo]

Yes, just edit with a text editor the file z64gl.conf.
Ok, thanks.

Emulator : 1964 0.9.9
Plugins : z64gl r14, project64 rsp r4

007 - The World is Not Enough (E) (M3) [!] --> Don't boot with R14. The game works with R12.
1080 Snowboarding (E) (M4) and (U)[!] --> slight screen shaking on the logo (no problem with (U) version). FPS are good with PJ64 rsp. Some lit' gfx problem with thin lines (Pic 1).
All Star Tennis '99 (U) [!] --> FPS are good with project64 rsp r4.
Bio Hazard 2 (J) [!] --> gfx are messed. After 2 messed screens, 1964 freeze. (Pic 2)
Ganbare Goemon - Mononoke Sugoroku (J) [!] --> pink color around the text !!! (Pic 3)
Indiana Jones and the Infernal Machine (U) [!] --> no more screen menu.
Nintama Rantarou 64 Game Gallery (J) [!] --> 30 FPS, glitches in game, thin line on the menu screen. (Pic 4)
Nushi Tsuri 64 - Shiokaze Ni Notte (J) --> screen shaking when you cvhat or when you walk out.
Nushi Zuri 64 (J) [!] --> screen shaking.
Supercross 2000 (E)(U) [!] --> no ground (black ground), no public, low FPS, sound hangs and crackle. (Pic 5)
Tamagotchi World 64 (J) [!] --> thin line. (Pic 6)

Emulator : Project 64 1.6
Plugin : z64gl r12, porject 64 rsp r4

Try this :
- Launch the game what you want.
- End emulation (File --> End emulation)
- Launch another game. Project64 close auto.
more test to come on this post.

Note : it seems there are speed problem with z64gl rsp rXX

[ziggy]

Ok, thanks.

Emulator : 1964 0.9.9
Plugins : z64gl r14, project64 rsp r4

007 - The World is Not Enough (E) (M3) [!] --> Don't boot with R14. The game works with R12.
That's weird. I tried with mupen and it works fine, can you test with mupen ? Can you test the debug R13 version and see if there are log files generated ?


1080 Snowboarding (E) (M4) and (U)[!] --> slight screen shaking on the logo (no problem with (U) version). FPS are good with PJ64 rsp. Some lit' gfx problem with thin lines (Pic 1).
Ok, this kind of problem, you shouldn't report it because there are too many of them. The only case where you should report it is when it is a regression (i.e. it became worst than in an earlier version)


Bio Hazard 2 (J) [!] --> gfx are messed. After 2 messed screens, 1964 freeze. (Pic 2)
Bio Hazard is broken at the moment and it will remain broken for some time, there's a lot of work to do for that game.


Ganbare Goemon - Mononoke Sugoroku (J) [!] --> pink color around the text !!! (Pic 3)
See comment about 1080 snowboarding.


Indiana Jones and the Infernal Machine (U) [!] --> no more screen menu.
Difficult for me to look into this problem since I've never been able to run India Jones :/


Nintama Rantarou 64 Game Gallery (J) [!] --> 30 FPS, glitches in game, thin line on the menu screen. (Pic 4)
I have a solution for this kind of problem, it will be in next release.


Nushi Tsuri 64 - Shiokaze Ni Notte (J) --> screen shaking when you cvhat or when you walk out. Again a game that never worked for me. :/


Nushi Zuri 64 (J) [!] --> screen shaking.
Supercross 2000 (E)(U) [!] --> no ground (black ground), no public, low FPS, sound hangs and crackle. (Pic 5)
Tamagotchi World 64 (J) [!] --> thin line. (Pic 6)
I never tested these game, I'll have a look.



Emulator : Project 64 1.6
Plugin : z64gl r12, porject 64 rsp r4

Try this :
- Launch the game what you want.
- End emulation (File --> End emulation)
- Launch another game. Project64 close auto.
Can you try to set "threaded = 0" in z64gl.conf file and see if it still happens ? EDIT : oops didn't see, it's pj64 1.6, in this case MAKE SURE you use "threaded = 1". Does it also happen with z64-rsp plugin ?



Note : it seems there are speed problem with z64gl rsp rXX

What do you mean by this ? Which version ? All versions ? In this case it's normal, z64-rsp plugin is much much slower than the modified pj64 rsp plugin. It's more compatible, but it's not a (real) recompiler and doesn't use SSE code, so it's expected to be slow.

[The Siskoo]

007 - The World is Not Enough (E) (M3) [!] --> Don't boot with R14. The game works with R12.
That's weird. I tried with mupen and it works fine, can you test with mupen ? Can you test the debug R13 version and see if there are log files generated ?

Now works, I guess the problem was with the z64gl rsp r13.
About report, I try to describe all what I got :p.
I made an unofficial 1964 ini : http://www.emutalk.net/showthread.php?t=40880 with lot improvements (settings, rename, etc...).

To get Indiana "works" (not playable) :
With 1964 0.9.9 change 2 settings :
- Right click on Indiana Jones and the Infernal Machine (U) [!]
- EEPROM Size : 4 kb EEPROM (defaut)
- Counter Factor : CF 5
- Core interpreter

Test with z64gl r14 + z64gl rsp r14 --> no music (Pic 1, Pic 2, Pic 3, Pic 4, Pic 5)
Test with z64gl r14 + project64 rsp r4 --> choose interpreter in RSP, music, more slow than z64gl rsp r14, lock after the third picture.



Can you try to set "threaded = 0" in z64gl.conf file and see if it still happens ? EDIT : oops didn't see, it's pj64 1.6, in this case MAKE SURE you use "threaded = 1". Does it also happen with z64-rsp plugin ?
Yup same stuff.

[jean945]

I have a question (sorry for my ignorance on tis but Im kind of new): What the hell means "core emulator plugins directory"? Thanks!! :pj64:

[Xing]

I use Project 64 1.6 and Mario Tennis but i don't know how use plugins
i download rsp-pj64-ziggy-r4-win32, z64-r14-win32 and glew32
glew32.dll is in the root of project 64, z64gl.dll is in Plugin and I have change other files --> RSP. how definitely to install with project 64?

My configuration : Processor 1.3 Ghz, 1024MB RAM, Nvidia GeForce 6200(256MB), Realtek AC97 Audio.

thank you for helping me well.

[The Siskoo]

I use Project 64 1.6 and Mario Tennis but i don't know how use plugins
i download rsp-pj64-ziggy-r4-win32, z64-r14-win32 and glew32
glew32.dll is in the root of project 64, z64gl.dll is in Plugin and I have change other files --> RSP. how definitely to install with project 64?

My configuration : Processor 1.3 Ghz, 1024MB RAM, Nvidia GeForce 6200(256MB), Realtek AC97 Audio.

thank you for helping me well.
Launch Project64 --> Options --> Settings. Choose z64gl in Video (graphics) plugin.