Alien vs Predator Port


They're prepaing different drivers for the 1GHz units. Right now, those drivers don't work. Notaz is investigating it.
Yeah, I read the previous replies that had not appeared while I was typing that, and updated that post. I feel a bit silly now.
 
Well, the highest profiling function is this:

Code:
__int64 aa = (__int64) a;
__int64 bb = (__int64) b;


__int64 cc = aa * bb;


return (int) ((cc >> 16) & 0xffffffff);
 
I've checked and the compiler is already generating optimal code for this, but because it's an external function, you get a function call overhead, plus at least 5 stall cycles because the compiler has nothing useful to insert after smull instruction. Just move this function to ./src/win95/inline.h and make it static so that it can be inlined (maybe do this for other math stuff too).
 
Last edited by a moderator:
This driver crap really needs to be sorted out. I understand not wanting to break drivers in the older units, but the alternative that the new units have to have broken drivers is ridiculous.

Edit: Okay, I had written this message very slowly and sporadically due to constant interruptions at work, and have now seen Notaz's response. My post's tone was rather unpleasant, and is not intended to disparage anyone's efforts. Also, I assisted in thread derailment. My apologies.   ...but I wanna play AvPeeeeeeeee!
The 1Ghz has some problems in a few conditions. Otherwise they've done a great job getting the unit functional... ;)


but, there is lots of work being done behind the scenes.
 
Other than the graphical problems, which are NOT your fault Stephen, the game runs perfectly! I look forward to seeing the graphical problems being fixed, so I may actually play it!
 
I'm pretty sure I remember graphical artifacts like those on my 1ghz when testing misc stuff in libGL.
 
On preliminary profiler run I can see lots of time spent in OpanAL lib, where did this lib/libopenal.so.1 come from? it seems to be horribly slow and desperately needs optimization.

FloatToInt() is an abomination, kill it with fire! They were doing real horrible workarounds for that WATCOM compiler. Just change f2i macro to this:

#define f2i(a, b ) a = (int)b

Something is generating alignment faults (23167777 faults after 30s test), this is real bad, needs to be tracked down and fixed.

Then there is this TranslatePoint() which could be NEONized.

Quite a lot of optimization potential for this game.
 
Last edited by a moderator:
On preliminary profiler run I can see lots of time spent in OpanAL lib, where did this lib/libopenal.so.1 come from? it seems to be horribly slow and desperately needs optimization.


FloatToInt() is an abomination, kill it with fire! They were doing real horrible workarounds for that WATCOM compiler. Just change f2i macro to this:


#define f2i(a, b ) a = (int)b


Something is generating alignment faults (23167777 faults after 30s test), this is real bad, needs to be tracked down and fixed.


Then there is this TranslatePoint() which could be NEONized.


Quite a lot of optimization potential for this game.
Odd, the only problems I had with it was the graphical glitches. Other than that the game ran great!
 
It really is strange, that a game runs like this on the Pandora even if it ran at 50 fps on my P2 266MHz with riva tnt 2 graphicscard...

it's not optimized yet

The team first ran a benchmark of Left 4 Dead 2 under Windows' Direct3D renderer, and managed to achieve a baseline performance of 270.6 FPS. Next, Valve tested the same game under Linux using OpenGL, and obtained an initial result of 6FPS. This is hardly an impressive figure, but it's not unreasonable that a newly-ported engine would have a few hiccups. The breakthrough came after a few performance tweaks and with some direct help from hardware manufacturers, after which the team recorded a staggering 315 FPS.
Quite a lot of optimization potential for this game.
 
Graphical glitches are caused by drivers, it's completely separate problem..
I know. I was trying to say, the game itself doesn't seem like it has any problems.
If it runs good on the GHz units, this might be because of the faster graphics chip and the additional MHz.

Keep in mind, that we tested it on CC/Rebirth units.

Do you want to say, that no optimisations need to be done, because YOU can run it flawlessly on YOUR GHz unit?
 
On preliminary profiler run I can see lots of time spent in OpanAL lib, where did this lib/libopenal.so.1 come from? it seems to be horribly slow and desperately needs optimization.
I don't recall, I didn't build it myself, grabbed it from somewhere on the internet. Is anyone able to link me to a libopenal.so that is properly optimized for Pandora?

FloatToInt() is an abomination, kill it with fire! They were doing real horrible workarounds for that WATCOM compiler. Just change f2i macro to this:


#define f2i(a, b ) a = (int)b
Done.

Something is generating alignment faults (23167777 faults after 30s test), this is real bad, needs to be tracked down and fixed.
I need to look up how to do this; presumably either via a breakpoint directly within GDB, or by installing an exception handler globally for alignment faults and then putting a breakpoint in there?

Once I have a new version of the OpenAL lib I will package a new build up to see if there are any improvements with these changes, will probably inline a bunch of the maths functions too.
 
You can make alignment faults to crash the program (so you can watch it on debugger) with (as root):

echo 4 > /proc/cpu/alignment

to get back back to kernel fixup of faults:

echo 2 > /proc/cpu/alignment
 
You can build openal on the Pandora or in any toolchain pretty easily.

If you want a precompiled version with all Pandora flags, have a look here:

http://mcobit.openpandora.org/openal-pandora.tar.bz2

Tested the new build and it crashes at the loadingscreen of the level. Here is the pnd_run.out:

=======================================================================================
PND             : /media/PANDORA_SD2/pandora/menu/avp.pnd
PND_FSTYPE      : ISO
APPDATADIR      : /media/PANDORA_SD2/pandora/appdata/com.pawprintgames.avp
APPDD_FSTYPE    : vfat
PND_CPUSPEED    : <unset>
EXENAME         : ./AvpMP
ARGUMENTS       : <unset>
=======================================================================================
[ START ]--- Mount the PND ----------
Mounting : mount -o ro "/dev/loop1" "/mnt/utmp/com.pawprintgames.avp"
Mounting the Union FS : mount -t aufs -o exec,noplink,dirs="/media/PANDORA_SD2/pandora/appdata/com.pawprintgames.avp=rw+nolwh":"/mnt/pnd/com.pawprintgames.avp=rr" none "/mnt/utmp/com.pawprintgames.avp"
[sUCCESS]--- Mount the PND ----------
[ START ]--- Starting the application (./AvpMP ) ----------
/usr/pandora/scripts/pnd_run.sh: line 519:  2937 Bus error               "$EXENAME" $ARGUMENTS
[ FAILED]--- Starting the application (./AvpMP ) ----------
[ START ]--- Restoring the frame buffer status ----------
[sUCCESS]--- Restoring the frame buffer status ----------
[ START ]--- uMount the PND ----------
[ START ]--- Waiting the Union to be available ----------
[sUCCESS]--- Waiting the Union to be available ----------
auplink:plink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
rmdir: failed to remove `/mnt/utmp/com.pawprintgames.avp': Device or resource busy
[ START ]--- Waiting the PND mount dir to be free ----------
[sUCCESS]--- Waiting the PND mount dir to be free ----------
cleanup done
[sUCCESS]--- uMount the PND ----------
=======================================================================================
Return code is : 3

Might be a problem with your new macros.
 
Last edited by a moderator:
Thanks, I have put up a new build, with the provided OpenAL. I have had to revert the other optimizations as they are causing the crash (seems only -O0 works at the moment, -01, -02, -03 seem to cause problems). At this stage I am not sure how tricky it is going to be to track down the cause of this.
 
Back
Top