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

[HatCat]

Okay, I've made some progress with building z64gl LLE RDP in the same way that ziggy has been doing it (GCC on Linux/Win32), so I have the MAKEFILE setup as he recommended here:

http://www.emutalk.net/threads/40640...004#post384004
I found his post suggesting some last-minute amendments to the makefile.

I am still getting an error from GNU MAKE.EXE:

C:\MinGW\bin>make --makefile=../z64/MAKEFILE
process_begin: CreateProcess(NULL, grep GTK2 config.h, ...) failed.
make: *** No rule to make target `rsp-mess.o`, needed by `z64.so`.  Stop.

The same is when I have applied this change:
http://www.emutalk.net/threads/40640...l=1#post384021

I will try more tomorrow to figure out what is missing.
Time for bed.

[HatCat]

Slowly coming along lol.

I must have screwed up my Windows environment variables a long time ago or something.
WIN32 environment was not detected ... this variable was set to 0.

So I had to add this line at the beginning of the MAKEFILE:

WIN32 = 1

Now the error with make renders just slightly differently:

C:\MinGW\bin>make --makefile=../z64/MAKEFILE
make: *** No rule to make target `rdp-mess.ow32`, needed by `z64.dll`.  Stop.

z64.dll is not the same as z64gl.dll however.
So I could probably rip out a bunch of the MAKEFILE contents just to get the actual graphics plugin itself to compile.

It would be nice tho if I could get it going with minimal interventions....

[HatCat]

YES.
IT.
WOOORKS.

After spending the past 12 hours of my awake time in frustration (either at the failed makefile GNU-style z64gl build or at repetitive chess to take my mind off the process), traveling between Hell and back, I got the plugin to build AND it is faster / no more RDP crashing I had with the failed Microsoft Visual Studio builds I kept trying to fix months ago.

IDK where to begin explaining how I fixed it since I had to read a crap load of manuals and pages, but my last issue I had was just that the makefile was not being invoked natively with respect to the source. (I targeted it externally from the MinGW binutils compiler invocation subdirectory which somehow was resetting the source properties....)

Now, as far as stuff with gfx I dunno how much I can talk about that in this thread.
Won't be able to do much in the way of public releases for that until I am certain of myself of improving its accuracy somehow, beginning from the point of knowing nothing about the RDP.

Would rather stick to RSP in this topic, but, nobody seems to be able to find any more bugs?

[the_randomizer]

Originally Posted by FatCat

YES.
IT.
WOOORKS.

After spending the past 12 hours of my awake time in frustration (either at the failed makefile GNU-style z64gl build or at repetitive chess to take my mind off the process), traveling between Hell and back, I got the plugin to build AND it is faster / no more RDP crashing I had with the failed Microsoft Visual Studio builds I kept trying to fix months ago.

IDK where to begin explaining how I fixed it since I had to read a crap load of manuals and pages, but my last issue I had was just that the makefile was not being invoked natively with respect to the source. (I targeted it externally from the MinGW binutils compiler invocation subdirectory which somehow was resetting the source properties....)

Now, as far as stuff with gfx I dunno how much I can talk about that in this thread.
Won't be able to do much in the way of public releases for that until I am certain of myself of improving its accuracy somehow, beginning from the point of knowing nothing about the RDP.

Would rather stick to RSP in this topic, but, nobody seems to be able to find any more bugs?

I need to get back to testing those plugins, I figured out the ROMs were getting corrupted graphics, but I can go and do it.

[et500]

Unfortunately, I cannot get Waverace 64 to run in LLE graphics or interpreter mode with RSP 1.7.0.3 or 1.7.0.9 using PJ64 1.7.0.50 because PJ64 always freezes or crashes.

But the water grid definitely should not be there and is not shown in Jabo with HLE emulation in Recompiler mode when using Zilmar RSP.

[HatCat]

LLE gfx in software RGB using SDL library.

It fixes the luminosity / hardware T&L lightening bugs with Gauntlet Legends black textures, but the lack of hardware rendering introduces a few new but less severe pixilation bugs such as the rainbow static flickering at the bottom.

Hopefully I'll have a chance to pull the upgraded MESS RDP datuum that angrylion implemented after ziggy did the z64 pull to the zilmar plugin specs.

Also, has some stupid bug in ChangeWindow() that makes the game hang when I leave the SDL drawing window, need to fix that.

[HatCat]

Originally Posted by nintendo1889

I need to get back to testing those plugins, I figured out the ROMs were getting corrupted graphics, but I can go and do it.

Cool story! Let me know how it goes.

Originally Posted by et500

Unfortunately, I cannot get Waverace 64 to run in LLE graphics or interpreter mode with RSP 1.7.0.3 or 1.7.0.9 using PJ64 1.7.0.50 because PJ64 always freezes or crashes.

But the water grid definitely should not be there and is not shown in Jabo with HLE emulation in Recompiler mode when using Zilmar RSP.

Well it looks like this on my RSP.


So I guess I don't have that issue.
I would recommend testing not only just Jabo's triangle renderer LLE in Direct3D as that has a few issues that the ziggy OpenGL renderer doesn't.

However, it is necessary to test Jabo's LLE, because it is more stable than z64 and supports special fx like CFB in software, texture T&L overrides etc. that are not currently implemented in the other plugin.

[shunyuan]

I think you should apply angrylion's z64-r17-zerolodfrac patch to z64gl, that disable lod emulation.

[HatCat]

Originally Posted by suanyuan

I think you should apply angrylion's z64-r17-zerolodfrac patch to z64gl, that disable lod emulation.

He only did that because of a texture bug in World Driver Championship.
He later realized that completely disabling the (albeit, incomplete/inaccurate) LOD emulation altogether introduced a different texture glitch.

Either way, OpenGL is way out of my experience to take the time to work on z64gl straight away.
I'm working on the pure software renderer LLE RDP plugin instead, which is more pixel-accurate but slower obviously as it does not take advantage of hardware accelerations of modern graphics hardware (but, faster on older PCs with no video hardware ... hm take your pick).

Once I know enough about the RDP maybe I can concentrate on learning OpenGL and vectorizing it into the less accurate z64gl plugin.

[HatCat]

I'm really impressed though.

The SDL interface on Windows is such a pain in the ass.

* Moving the SDL video window is almost impossible.
* You can't position the drawings screen programmatically in a standard/portable way.
* Lots of missing functions in the simple, portable SDL library for doing some Win32 stability things.

And yet, it has an extremely simple set of functions to do things straight away, like taking BMP screenshots, which does not directly exist in OpenGL based on my findings....

It's a mixed blessing, but either way we need a software plugin.