Well, I'm happy to report mixed results
I've got a somewhat working daphne.bin built with only tweaking of the makefiles to suit the Cell architecture and the VLDP compiled statically. I can post the makefiles later, but for now the rough procedure goes something like this:
- Copy ${sourceroot}/src/Makefile.vars.linux_x86 to Makefile.vars.linux_ps3; symlink the latter to Makefile.vars
- Remove any references to MMX, OpenGL, or x86-specific optimizations from Makefile.vars
- cd to ${sourceroot}/src/vldp2; copy Makefile.linux to Makefile.ps3
- Remove any references to MMX or x86-specific optimizations from Makefile.ps3
- ./configure && make -f Makefile.ps3
- cd ..
- make
Assuming all the correct libraries, etc. are installed, this should ultimately leave a daphne.bin with statically-linked VLDP capable of running on a PS3-based Linux in ${sourceroot}.
Quick notes:
Build was with gcc 4.1.1 under Yellowdog 6. SDL, Ogg, Vorbis, etc. libraries were whatever was pulled down via yum.
OpenGL support was disabled since there's currently neither full nor supported access to the PS3's RSX. Linux graphics are currently framebuffer-only on the PS3, so SDL it is.
Video mode is 1080p at 60Hz.
Status:
- 'lair': runs and plays. Audio seems to be restricted to only the samples; sound from the MPEG doesn't play at all. Need to pull error log.
- 'mach3': gets past video parsing, but exits with a blank screen. Textmode video is not restored after this point; I have to shell into the PS3 and reboot it to get video back (no daphne.bin process is showing). Same thing seems to happen if -fullscreen is specified with other games. Need to pull error log.
I haven't tried much else at this point since it's late and I really need some sleep. I did catch a couple of missed x86-specific options in places, so will remove those tomorrow and see how it goes.
For some reason if daphne is built with the VLDP as a dynamic library, it's never found at runtime. Not sure what's going on with that; I've tried repositioning the library in relation to the binary, putting it in different places, etc. For some reason only statically linking it seems to be consistent in terms of allowing the binary to run.