The Pandora Port Request Thread


Hi all,

Linux Air Combat:

Lac05p01P38BehindZekeOverIslandSmall.jpg


http://askmisterwizard.com/FlightSimMovies/LAC/LacIntroFullPage.htm

Based on GL-117, already ported to the Pandora by @ptitSeb ;)

Cheers, Magic Sam
 
Hi all,

Chocolate Duke 3D compiled effortessly thanks to @ptitSeb 's Code::Blocks :)

I'll push the PND to the Repo ASAP !

Cheers, Magic Sam
[doublepost=1508704164,1508695657][/doublepost]Hi again,

Chocolate Duke 3D seems to be working fine with the 1.3D shareware files (I don't own the full game yet):

ftp://ftp.3drealms.com/share/3dduke13.zip

Framerate is good (~30 FPS @ 600MHz).

Known issues so far:

- the game always start in windowed mode, even with fullscreen set to 1 in the configuration file... (@notaz ' improved SDL solves this issue though)
- changing the controls can be tricky (menus are prone to freezes).
- saving the game makes Chocolate Duke 3D crash (bus error). The save file is in the appdata folder, but the game doesn't recognize it...

I'll work some more on the PND and push it to the Repo ASAP.

Cheers, Magic Sam

EDIT: I sent a mail to the author
 
Last edited:
Hi all !

I had a look at the issues on github, and Chocolate Duke 3D seems to be picky when it comes to compilation optimizations... So I decided to recompile it without any CFLAGS (thus defaulting to -O0 AFAIK).

-Good news: it solved the saving / loading issue :)
-Bad news: the game is now too slow (~10 FPS) @ 600MHz to be fun to play :(

I guess I'll just have to find the right balance between speed and usability...

EDIT: the menus are still prone to crashes, and the game still refuses to start in fullscreen mode (but this can be easily fixed with @notaz ' improved SDL).

Cheers, Magic Sam
 
Last edited:
Hi all :)

Some good news regarding Chocolate Duke 3D:

- I recompiled it yesterday with -O3 only in the CFLAGS. Speed is fine, and saving / loading works correctly. I wonder which optimization made it crash though... (it's not fast-math, I checked...)

- @notaz' improved SDL with VSYNC and direct buffering solves the freeze issue in the menus (I think).

I'll work some more on the PND (previews, license, default key mapping) and push it to the Repo ASAP (tomorrow or this week-end, I don't know yet).

Cheers, Magic Sam
 
Hi again,

I just recompiled Chocolate Duke 3D with the following CFLAGS:

-ffast-math -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fsigned-char -mneon-for-64bits -mvectorize-with-neon-double

Sound no longer stutters, but the game still crashes when saving with a "bus error"...

Cheers, Magic Sam
 
Last edited:
Hi all,

I recompiled (once again) Chocolate Duke 3D, this time with the following CFLAGS:

-ffast-math -O3 -mcpu=cortex-a8

The saving bug is gone, but the game is a bit too slow @600 MHz... It looks like floating point maths and / or NEON have something to do with this issue. I'll add some other CFLAGS back to check this theory. I'll also open a new issue on github.

On a side note, I should really learn how to use gdb... It should be much more efficient than this trial and error stuff...

Cheers, Magic Sam
 
@Magic Sam : the BUSERROR is caused by NEON. It's an unaligned access. So the save probably save a bunch of int32 in an unaligned address (probably tightly packed data using some char* pointer). You need to gdb to found the place of error.
So build with "-g" to have debug info.
Launch your program with gdb (you may need to "gdb --args" if chocolate duke need arguments to run).
Then press "r" to run the program.
It should just run. Then at the BUSERROR, the program will interupt at the place of the error.
You should have a better view at where it's crashing.
You can use "bt" to have a Backtrace the may help you.
And "q" to quit the debugger. (other usefull command are "c" to continue execution, ctr-c to break execution, "l" to list current sources, "p blabla" to print variable blabla).

Now, you'll probably see nothing special at the BUSERROR point. Somethign like "*(int32*)p = blabla;". But if p is an unaligned address (not an adress%4==0), you may BUSERROR. Easier way is to change the assignement by a memcpy (something like "memcpy(p, &blabla, sizeof(int32));"). You can see my "forsaken/projectX" github for example of that...

Good luck.
 
Last edited:
Hi all,

@ptitSeb : I recompiled Chocolate Duke 3D yesterday with all the CFLAGS from your Code::Blocks package, plus "-g" for the debugging symbols.

I tried to run this binary through gdb twice this afternoon, but with little luck so far :( Instead of crashing as usual when saving, the Pandora just froze before I could have a look at gdb's output, and I had to hard reset it.

Would it be possible to plug gdb on an already running application ? This way I could ssh in from a different computer, and avoid the system-wide freeze when the application crashes...

EDIT: gdb's man page mentions such a possibility...
EDIT 2: maybe there are too many optimizations involved ? Should I recompile the application with only the CFLAGS known to make saving crash ?
EDIT 3: I managed to gdb --pid= from a different computer, but then gdb behaves differently (i.e typing "r" on an already running application is not a good idea...)

Cheers, Magic Sam
 
Last edited:
Hi all,

@ptitSeb : I recompiled Chocolate Duke 3D yesterday with all the CFLAGS from your Code::Blocks package, plus "-g" for the debugging symbols.

I tried to run this binary through gdb twice this afternoon, but with little luck so far :( Instead of crashing as usual when saving, the Pandora just froze before I could have a look at gdb's output, and I had to hard reset it.

Would it be possible to plug gdb on an already running application ? This way I could ssh in from a different computer, and avoid the system-wide freeze when the application crashes...

EDIT: gdb's man page mentions such a possibility...

Cheers, Magic Sam
Yes it's possible.
Launch the game
Get it's PID using "ps -A"
then launch gdb and use "attach PID" with that PID number.
Better to use gdb from an SSH terminal, if you are using omapdss SDL driver, it will certainly interfer with gdb if launch from the Pandora itself.
 
Hi @ptitSeb :)

Thanks for your help !
Loaded symbols for /usr/lib/libXfixes.so.3
0x00090a04 in hlineasm4 ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x000b5004 in clearbuf ()
(gdb) bt
#0 0x000b5004 in clearbuf ()
#1 0x000b41a8 in compress ()
#2 0x000b4de4 in dfwrite ()
#3 0x00038344 in saveplayer ()
#4 0x00043cb4 in menus ()
#5 0x0001e2c8 in displayrest () at game.c:2865
#6 0x0000aba8 in main () at game.c:8561

As far as I understand, the issue is in the "clearbuf ()" function in game.c.

Is this correct ?

EDIT: I think the relevant piece of code is in menues.c. I had a quick look at it, but didn't understand much unfortunately... Wouldn't it be easier for me (not a developer) just to tell GCC to leave this menues.c file alone (with "#pragma GCC optimize 0" for example) ?

Cheers, Magic Sam
 
Last edited:
Yeah, maybe. But "-g" is not really there. If it was, you would have the name of source file and the line number of the error. Check that "-g" flags is taken into account, and also check that the binary is not stripped and/or there is no "-s" in the link command (as it would strip the result too).
 
@ptitSeb : OK. thanks

pandora:/media/Pandora1/dev/install/chocolate_duke3D-magicsam/bin$ file chocolate-duke3d
chocolate-duke3d: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped

I'll check the link command ASAP.

Cheers, Magic Sam
 
The exe is not stripped, ok, but the static libraries it use may not have debug info.
The backtrace shows 2 entry point with details and all other without...

Yes, of course you can put "#pragma GCC optimize 0" in some files, and it may works.
 
Hi all :)

@ptitSeb : I added "#pragma GCC optimize 0" to menues.c, but to no avail: the game crashed again with a bus error...

I'll try to make "-g" work throughout the code to pinpoint the location of this issue. I'm done with the "trial and error" way of debugging things :p

Cheers, Magic Sam
 
Back
Top