Hi,
I have a silly question ! Currently the plugins rely on nvidia cg language. Technically speaking would it be possible to use pure openGL (GLSL) ? GLSL only support opengl (not directx) but I m not sure it would be ok on windows side (but not sure neither if this plugins is still used on windows anyway).
I know it would requiere rewriting lots of code. The major gains is licence "freeness" under linux (or at least in debian). But I just want to know.
Thanks
(06-07-2010, 12:27 AM)udx6bs Wrote: [ -> ]Having problems running any Game under Linux.
Gives me always segmentation error after a minute or so.
It runs just fine when I disable GS in the configuration panel or use the nullGS plugin, (except no video output:-) ).
Tried with 210, 211, 212 all the same.
OS: Ubuntu 10.04 32bit
Driver: NVidia 195.36.15.
PCSX2: 0.9.7.0 (svn) 01. june 2010.
Hard specs: Q6600 2gig ram 220GT
Unfortunately pcsx2 won't run on Ubuntu, it's a known bug/incompatibility =/ Technicaly it runs but segfaults after a few minutes of gameplay.
@gregory: ZZOgl dropped the directx section of ZeroGS, so that wouldn't be a concern anyways. Technically, it'd probably possible, but it'd probably be a pain, and since I don't know nvidia's cg language, and don't really know that much OpenGL, would be better done by someone else.
@wingnux: A few people have reported issues. It's a bit early to say that it won't run on Ubuntu whatsoever.
Though I would recommend anyone running on Ubuntu use the version of wxwidgets here: (technically, I think you only need this if you are on a lower version then 2.8.8, because that's the release "ReserveSpaceEvenIfHidden" was introduced in. Hardy is on 2.8.7, though, as is Debian Lenny.)
http://wiki.wxpython.org/InstallingOnUbuntuOrDebian
and use the version of the binary in
this attachment (since the original binary is linked against a newer version of zlib then Ubuntu usually has).
I'm hoping the next beta will be more Ubuntu friendly, anyways, since now that I know about the zlib issues, I can work around them...
Well, GLSL is nice and I looking at possibility of rewriting shaders section under it, but such work is pretty hard and several new bugs are definitly would appear.
Yes, it is not an easy jobs. It was just for my curiosity. There are enough work in plenty of others area
First, I will be honest I do not understand anythings in the code ^^
Trying to understand why zz crash (on my system) in debug mode !!! (and not in Release).
-> ZZoglVB.cpp:282: int ZeroGS::VB::CheckFrameResolveDepth(int): Assertion `pnewdepth->fbh == prndr->fbh' failed.
I maybe found something, here what I have done.
Code:
--- pcsx2.snapshot-3203.orig/plugins/zzogl-pg/opengl/targets.cpp 2010-06-11 22:14:07.917884135 +0200
+++ pcsx2.snapshot-3203/plugins/zzogl-pg/opengl/targets.cpp 2010-06-11 22:14:30.242018949 +0200
@@ -1523,6 +1523,7 @@
ptarg->psm = frame.psm;
ptarg->fbm = frame.fbm;
ptarg->fbp = frame.fbp;
+ ptarg->fbh = frame.fbh;
GetRectMemAddress(ptarg->start, ptarg->end, frame.psm, 0, 0, frame.fbw, frame.fbh, frame.fbp, frame.fbw);
I have an assertion failure later (in a _DEBUG ifdef). I disable _DEBUG for the moment (one issue at a time) and it seems to work (well grandia3 intro is ok). Any opinion ?
Target height should be calculated, not inherited from frame data. Such inheritance lead to big onscreen distortion. So better remove assertion.
Well, ZZOgl's based on ZeroGS, which was written by Zerofrog, so that's understandable. Zerofrog's code can be pretty difficult to understand.
That's why I've got Onepad going as a rewrite of Zeropad, and why a lot of my work on ZZOgl-pg is rewriting pieces of code so that they are understandable.
I seem to recall that Debug mode didn't work particularly well on ZZOgl any more, which is one reason why I've been tending to stick to Devel and Release.
As far as that change goes, I notice a bunch of warnings about mismatched dimensions start cropping up in the log file if we do that, and the assertion failure later is because of incomplete dimensions in the framebuffer. Since I'm assuming frame.fbh == frame buffer height, I'm not sure that's the right way to go about fixing that assertion.
(I'm not sure I'd trust the opening movie of Grandia III not to have edge cases in it, btw, just simply because I managed to break that opening movie a half dozen times when working on Sif. ^_^)
Here's my own suggestion for resolving the issue, after playing with the code a bit:
--- plugins/zzogl-pg/opengl/targets.cpp 2010-06-11 16:10:38.000000000 -0700
+++ ../pcsx2-1/plugins/zzogl-pg/opengl/targets.cpp 2010-06-11 16:10:10.000000000 -0700
@@ -1501,7 +1501,7 @@
it = mapDummyTargs.find(GetFrameKeyDummy(frame));
- if (it != mapDummyTargs.end())
+ if ((it != mapDummyTargs.end()) && ((it->second->fbh == frame.fbh) || !(opts & TO_StrictHeight)))
{
#ifdef DEBUG
printf("A %x %x %x %x\n", frame.fbw, frame.fbh, frame.psm, frame.fbp);
This code is wrong, you could miss correct dummy if correct oneis not the first with the same Dummy Key. Only correct way is to change Dummy Key function, if you miss correct dummy it lead to flickering.