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

[Seth Hetu]

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?).

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.
   * 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...
   * 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
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.

-->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