Menu
What's new
By:
Filters

Z64 - a LLE graphics plugin

S

Sri Narayan

New member
thank for the plugin. compiles but have problem at the end:
Code: 
rgl.cpp: In function `void rglRenderChunks(int)':
rgl.cpp:486: error: `GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_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
 
OP
Z

ziggy

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

PsyMan

Just Another Wacko ;)
Hmm... Here's how the results look like:

Code: 
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.
 
Last edited:
OP
Z

ziggy

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

ziggy

New member
Sri Narayan said:
the scaling of the video output. only happens in some games. don't know if it is really a bug.

ciu
Click to expand...

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.
 
T

Trotterwatch

Active member
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
 
S

Sri Narayan

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

the output was:
Code: 
mupen64: rgl_rendermode.cpp:281: void rglSetCombiner(rglRenderChunk_t&, int): the assurance »glGetError() == 0« is not fulfil.
ciu
 
Last edited:
PsyMan

PsyMan

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

ziggy

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

ShadowFX

Guardian
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
 
OP
Z

ziggy

New member
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.
 
CpU MasteR

CpU MasteR

omg h4x
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
 
S

Sri Narayan

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

Code: 
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
 
You must log in or register to reply here.

Top