What's new

Z64 - a LLE graphics plugin

OP
Z

ziggy

New member
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

New member
perhabs is this the fault?

Code:
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()
[COLOR="Red"]rglClose()  <==========================================================
[/COLOR]
[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
 
OP
Z

ziggy

New member
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

New member
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;
?
 
OP
Z

ziggy

New member
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.
 
OP
Z

ziggy

New member
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

New member
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%
 
Last edited:

PsyMan

Just Another Wacko ;)
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.
 
Last edited:
OP
Z

ziggy

New member
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

Just Another Wacko ;)
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)
 
OP
Z

ziggy

New member
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)
 
Last edited:
OP
Z

ziggy

New member
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

New member
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.
 
OP
Z

ziggy

New member
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

New member
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.
 
Last edited:

PsyMan

Just Another Wacko ;)
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.
 
Last edited:

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?
 

Top