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

Wed Jun 26 21:15:12 PDT 2013

On 27 June 2013 02:04, Seth Hetu <seth.hetu at gmail.com> wrote:
> 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.

I've found that gprof isn't any use for tracking down delays when the
time is spent in IO/kernel, or sometimes even in libc. That's why I
suggested gdb.

700MHz seems somewhat slow for an ARM(11). But my ARM11 cellphone is
only 530MHz. I wonder how comparable clockspeeds are between different
ARMs.

Uh oh, I just noticed that the ARM11 supports unaligned memory access
(for 4, 2 and 1 byte sized data aside from floating point). That means
that we could be doing unaligned memory access somewhere and not know
it; breaking on older ARMs, or if the data types change, and anyway
running slower than aligned access. So we may want to look into that.
Apparently you can set a flag to cause alighned access to throw an
exception, but you can't do that on Android without rooting the phone.

This page provides lots of information:
http://jsolano.net/2012/09/06/arm-unaligned-data-access-and-floating-point-in-linux/

> 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

What do you mean by "may it is the audio after all"?
Timidity has heaps of options you can tweak to decrease the cpu usage,
so I imagine that they just changed the defaults instead.
Also, what shuttering? You didn't mention that before.

To disable midi, you could add
if songtype = FORMAT_BAM or songtype = FORMAT_MIDI then exit sub
to loadsong in allmodex.bas. (Though that won't stop the previous
music when trying to play a midi.)

> 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
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org