Yes you need to test it before. Sorry, I forgot to tell you that you can dump a "video", press both control and shift (don't remember if you need to hold control, shift or toggle it again to stop the recording). Be aware that the dump can become pretty large very quickly.
Otherwise, there is another possibility. Download (build) apitrace and generate a trace, it only contains the GL call so it is much more lighter but it have less information. However, If you use apitrace you will need to trace both shader backend (use same config and try as much as possible to have a similar trace)
Hi Gregory,
I am sorry I gave up capturing video dumps. I will give it another go sometime later.
My hobby in the meantime is to try to make the rpm suitable for the rpmfusion repository. Rpmfusion is very specific about what is acceptable >< (for fun read
https://lists.rpmfusion.org/pipermail/rp...13436.html)
I am downloading the rpm from googlecode, using your script and -branch 1.0; they would prefer a static location for the download. I note that this is available on
http://pcsx2.net/download/releases/sourc...-code.html but I cannot wget from this location; do you know what the stable url is for pcsx2-1.0.0-r5350-sources.7z?
ok. Don't have free time at the moment anyway.
Honestly I didn t even know there was a source package somewhere:-P First link leads to 404. Anyway if you have some licence issue, don t hesitate to ask me. I already clean lots of stuff for debian (that the main reason of the glsl port)
Ah - I included a close bracket ) at the end of the url... But it doesn't really matter. Thanks anyway, I'll work something out
Ok. Actually it is very interesting.
1/ Be sure to use latest 1.0.0 I fix a gsdx bug few days ago (well migh be yesterday actually)
2/ copyrigth info is already complicated enough so reuse debian-unstable-upstream/copyright
3/ If needed you can drop cg and replaced by glsl. There still 1 or 2 bugs as you know
and it might be a little slower. I really need to find some time to finish that...
4/ for 3rdparty just remove the dir, it is useless and it will take system lib by default.
5/ I change a bit the script to build the tarball (the one in branch), it might be better for you, feel free to update it otherwise.
6/
Quote:A comment specifying why it cannot be compiled and run on other architectures
must be written.
=> In short pcsx2 is a virtual machine, full details here:
http://code.google.com/p/pcsx2/wiki/Chro...tatusLinux
7/
Quote:The flags used while compiling are not only the one passed by %cmake (ie the
ones specified in CFLAGS) but there are others that conflict with them ("-m32
-msse -msse2 -march=i686"). You must patch pcsx2 to remove them.
The debuginfo package is too small. The binary files have been stripped. Change
CMAKE_BUILD_TYPE to -DCMAKE_BUILD_TYPE=Debug.
Why it want to remove proved flags by upstream. PCSX2 won't compile without sse2 and m32 won't have any impact on a 32 bits system...
Debug don't have any impact on stripping, use that "-DCMAKE_BUILD_STRIP=FALSE" instead.
8/ "incorrect-fsf-address"... Yes I know... One day...
Hope it helps. I would finish to read later
Just for your information. If I remember correctly there is a runtime check to check the support of sse2. If the cpu doesn't support it a nice message will be printed but it won't crash at startup badly. However never test if it work, you need a 10 years old cpu...
Don't use -DCMAKE_BUILD_TYPE=RelWithDebInfo use Release => Allow value are "Debug|Devel|Release" others will fallback to devel...
edit: don't use curent upstream tarball (it still have the GSdx issue). I will try to post a targz somewhere (created by my script...)
No I mean a real runtime check. PCXS2 know the CPU capabilities, it print them in the log file at startup.
Code:
static void CpuCheckSSE2()
{
if( x86caps.hasStreamingSIMD2Extensions ) return;
// Only check once per process session:
static bool checked = false;
if( checked ) return;
checked = true;
wxDialogWithHelpers exconf( NULL, _("PCSX2 - SSE2 Recommended") );
exconf += exconf.Heading( pxE( L"Warning: Your computer does not support SSE2, which is required by many PCSX2 recompilers and plugins. Your options will be limited and emulation will be *very* slow." )
);
pxIssueConfirmation( exconf, MsgButtons().OK(), L"Error.Startup.NoSSE2" );
// Auto-disable anything that needs SSE2:
g_Conf->EmuOptions.Cpu.Recompiler.EnableEE = false;
g_Conf->EmuOptions.Cpu.Recompiler.EnableVU0 = false;
g_Conf->EmuOptions.Cpu.Recompiler.EnableVU1 = false;
}
Edit: don't know, if you can still run the program or if it only print a warning.
Yes the bugfix on gsdx is actually very good. Fixes Katamari games and that improves my quality of life no end
Interesting to hear about the SSE check. I think they want rpm to (theoretically) compile on non SSE machine. But maybe an upstream check on the machine and stop the rpm building will be enough that it is acceptable. I'll let them know and then wait for the feedback from bugzilla, but this is very helpful input for me. Thanks guys
- can I ask, is there any way to build with debug symbols - otherwise it seems that only a Debug build will suffice - which will be slow....
Well, I m sure they don t build package on 10 years old machine. And the guy that could download the rpm source, it won t work in any case. Anyway let s wait their feedback.
For debug, you need to use CMAKE_BUILD_STRIP option (control the stripping of debug symbol). It is orthogonal with the build mode. Cmake will set it to true by default in release mode, just set it to false.