[Ohrrpgce] GAME compiles on the RPi, but needs serious debugging.

Wed Jun 26 07:04:47 PDT 2013

The RPi runs at 700 MHz; I'm kind of amazed that all that software
rendering doesn't slow it down. Amusingly enough, valgrind doesn't
want to touch it (complaining about "unknown instructions"), so I'll
probably have to gprof it.

sysroot seems to be the way to go; it'll fix those "/" libraries for
sure. I've got most of the OHR to compile by changing the sysroot;
however, the RPi's rootfs has libraries in "/lib/arm-linux-gnueabihf"
as well as "/lib"  ---the "arm-linux-gnueabihf" is confusing the
linker. This should be simple to fix, once I can wrap my head around
how linkers work.

Also, I have no idea how much patching went into timidity on the Pi.
One blog post explains that Timidity is too processor-intensive for
the Pi to handle reliably, so maybe it is the audio after all? I might
try using the "silence" audio backend and seeing how that affects
stuttering. Is it possible to disable (or hack-disable) *only* midi
playback and not any other audio?

-->Seth

On Tue, Jun 25, 2013 at 10:00 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 26 June 2013 03:57, Seth Hetu <seth.hetu at gmail.com> wrote:
>> I'll try modifying fbrt0.c later tonight. In terms of fbgfx and
>> gfx_fb, I honestly don't have much interest in it  ---SDL performs
>> fairly well, even on fades, and I can't imagine Free Basic's default
>> renderer outperforming this (it's soft-rendering, right?).
>
> Both SDL and FB's gfxlib can use OpenGL or DirectX, however in both
> cases all drawing is done by the OHR, in software.
>
>> Now, the laundry list:
>>    * Audio works (through HDMI to my TV). Music is much quieter than
>> sound effects.
>>    * The volume slider doesn't seem to affect the volume, but I
>> haven't 100% verified this.
>
> Ah, so the default RPi (Debian?) dsitrib comes with Timidity patches?
> MIDI playing quietly is normal, and with music_sdl the volume slider
> should affect only music (all formats) but not sound effects (which is
> a bug).
>
>>    * Graphics over VNC or ssh -X are very slow, esp. fades. Over
>> direct HDMI output, though, games are quite playable.
>>    * Some (~4) Alsa messages pop up in the console complaining of an
>> "underrun". Doesn't seem to affect anything, but...
>
> I see those messages on Linux quite often.
>
>>    * The game will seize up occasionally. Waiting 30 seconds will
>> usually resolve this. Input is still buffered during this time. This
>> almost always happens when selecting "Quit" on Wandering Hamster. It
>> *may* correspond to the Alsa underruns, but it also happened to me
>
> Yikes. I saw long pauses when quitting the game on Android, apparently
> because of all the file operations it does; although around 5 seconds,
> not 30. But I have nothing to explain long pauses in the middle of the
> game. I would suggest breaking with a debugger to see what's going on
> when this happens.
>
> How fast is the RPi's ARM?
>
>> randomly inside the Plip Tamer's house.
>>    * Wandering Hamster is still, unfortunately, not finished. ;)
>>
>> My main concerns now are:
>>    * Figuring out how to make the $RPI_HOME/ directories known to the
>> linker. I figure there's probably an option in crosstools-ng for
>> including these paths by default.
>>    * Figuring out why "/lib/" and "/usr/lib" are linked directly in 4
>> or 5 cases. This is probably also fixable at the toolchain level.
>
> Have a look at gcc's --sysroot
>
>> -->Seth
>>
>>
>> On Tue, Jun 25, 2013 at 4:49 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>> Hurrah!
>>>
>>> Are you going to try modifying fbrt0.c? Does audio and everything seem to work?
>>>
>>> Come to think of it, fbgfx should compile for Raspberry Pi and gfx_fb
>>> should work, since it's just GNU/Linux with X11. Not that we would
>>> want to use gfx_fb, but I'd be interested in testing fbgfx. I guess I
>>> could try compiling it myself. Oh, wait, I think it does contain a
>>> bunch of x86 for accelerated blitting, but I've no idea whether that's
>>> optional. So don't bother mucking around with that for now.
>>>
>>> On 25 June 2013 13:51, Seth Hetu <seth.hetu at gmail.com> wrote:
>>>> And here's a binary:
>>>> https://docs.google.com/file/d/0B1P7NepPcOslTW84MEhxRUpCbk0/edit
>>>>
>>>> If you apt-get all of the dependencies (on the Pi, of course), this
>>>> will work as-is.
>>>>
>>>> -->Seth
>>>>
>>>> On Mon, Jun 24, 2013 at 9:47 PM, Seth Hetu <seth.hetu at gmail.com> wrote:
>>>>> MAGIC!
>>>>>
>>>>> (I used -lfb instead of -lfbmt).
>>>>>
>>>>> -->Seth
>>>>>
>>>>> On Mon, Jun 24, 2013 at 8:33 PM, Seth Hetu <seth.hetu at gmail.com> wrote:
>>>>>> Ah, thanks for the futex advice; that looks like it might be the
>>>>>> culprit. More details to follow!
>>>>>>
>>>>>> -->Seth
>>>>>>
>>>>>> On Mon, Jun 24, 2013 at 8:27 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>>>>>> On 25 June 2013 09:57, Seth Hetu <seth.hetu at gmail.com> wrote:
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>>    I got GAME to cross-compile for the Raspberry Pi, and cataloged my
>>>>>>>> approach here:
>>>>>>>>    http://rpg.hamsterrepublic.com/ohrrpgce/Talk:Compiling_for_Android#First_Successful_Build_with_RPi
>>>>>>>>
>>>>>>>>    Unfortunately, after loading a few libraries and making a few
>>>>>>>> function calls it just hangs forever. Strace and ltrace here:
>>>>>>>>     http://pastebin.com/bp8nND16
>>>>>>>>     http://pastebin.com/N1GjRt0E
>>>>>>>>
>>>>>>>>     I will now be going through these traces and trying to debug this,
>>>>>>>> but I thought a few more pairs of eyes wouldn't hurt. Also, if
>>>>>>>> anything in my build steps looks suspicious, please let me know.
>>>>>>>> Finally, if any of you encountered a similar "stalling" bug while
>>>>>>>> porting to Android, do provide some insight.
>>>>>>>>
>>>>>>>>     Let's hope we're only a short debug away from a working copy of
>>>>>>>> GAME on the RPi!
>>>>>>>
>>>>>>> Yes, in fact this freeze is probably the same as what I experienced on
>>>>>>> Android (though I looked at a backtrace, not an strace, so I don't
>>>>>>> know if it's identical). The problem was that a futex lock froze
>>>>>>> because the futex was never properly initialised by rtlib, because
>>>>>>> rtlib's initialisation routine wasn't run. Have a look in
>>>>>>> fbc/src/rtlib/static/fbrt0.c. The defined(HOST_ANDROID) ||
>>>>>>> defined(HOST_DARWIN) constructor declaration is the portable version,
>>>>>>> and should be used on all ARM too. I have no idea why the FB devs
>>>>>>> opted to use a nonportable __attribute__((section)) method.
>>>>>>>
>>>>>>> Another way to diagnose this to try replacing -lfbmt in CXXLINKFLAGS
>>>>>>> with -lfb. This will link with the non-multithreading build of rtlib,
>>>>>>> which doesn't use futexs. In fact, we only use a thread when using
>>>>>>> gfx_fb or gfx_alleg backends, so this should be safe to use (but
>>>>>>> obviously should be fixed anyway).
>>>>>>>
>>>>>>>> -->Seth
>>>>>>>> PS: For those of you wondering, a chroot (or kvm) install won't work
>>>>>>>> solely because fbc can't be compiled as a native ARM app (to my
>>>>>>>> knowledge). So cross-compiling seems the only way to go.
>>>>>>>
>>>>>>> To compile fbc as an ARM app you need to use -gen gcc (the C emitter).
>>>>>>> I haven't tried this myself. Last I heard (a couple months ago), this
>>>>>>> either didn't work or didn't produce a working fbc. At least back then
>>>>>>> there were still lots of bugs in FB's C emitter (I simply worked
>>>>>>> around them).
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org