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

Tue Jun 25 19:00:06 PDT 2013

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