On Fri, Feb 15, 2013 at 10:11:10PM +1300, Ralph Versteegen wrote:
> On 15 February 2013 10:22, James Paige <[email protected]> wrote:
> > So I found https://github.com/pelya/commandergenius which is a port of
> > SDL 1.2 to Android. It looks pretty actively maintained, although the
> > build system seems a little peculiar.
>
> Ah, neat!
>
> I tried out some of .pkg files available using this port of SDL
> available from http://libsdl-android.sourceforge.net/
> Nearly all of these need to download data files from the internet, but
> finally I found one that doesn't: MilkyTracker. Although that failed
> to run because it assumed I had an SD card, on borrowing someone
> else's it runs great on my old phone. And reading the log with adb, I
> see that SDL is actually using an OpenGL context:
Ah, cool!
I know what you mean about the downloading of files. That seems to be a
built-in feature of this port of SDL to android. You can have your data
files in a zip somwhere, and the apk will download them on the first
run.
> > I followed the instructions in the readme, got the demo compiled and
> > successfully loaded onto my android device, and then I dug into trying
> > to compile the OHRRPGCE using it.
> >
> > I ran
> >
> > scons fbc=~/misc/usr-local/bin/fbc gengcc=1 asm=1 game
> >
> > And then I copied over
> >
> > *.c *.h *.cpp fb/*
> >
> > Into my android project directory. Then I removed Jay's experimental gui
> > code and the code that only matters for scons raster=1
> >
> > I made my best guess at AndroidAppSettings.cfg settings using
> > commandergenius's changeAppSettings.sh tool and tried to compile.
> >
> > Results were not successful, but still somewhat encouraging. Some
> > modules do compile, but the NDK's gcc chokes on a whole bunch of errors
> > like this:
> >
> > /tmp/cc2PJ0en.s: Assembler messages:
> > /tmp/cc2PJ0en.s:5539: Error: bad instruction `fldl [fp,#-36]'
> > /tmp/cc2PJ0en.s:5539: Error: bad instruction `fistpl [fp,#-40]'
> > /tmp/cc2PJ0en.s:5807: Error: bad instruction `fldl [fp,#-92]'
> > /tmp/cc2PJ0en.s:5807: Error: bad instruction `fistpl [fp,#-96]'
> > /tmp/cc2PJ0en.s:5841: Error: bad instruction `fldl [fp,#-92]'
> > /tmp/cc2PJ0en.s:5841: Error: bad instruction `fistpl [fp,#-96]'
> > /tmp/cc2PJ0en.s:5942: Error: selected processor does not support ARM
> > mode `flds [fp,#-96]'
> > /tmp/cc2PJ0en.s:5942: Error: bad instruction `fistpl [fp,#-92]'
> > /tmp/cc2PJ0en.s:6199: Error: selected processor does not support ARM
> > mode `flds [fp,#-96]'
> > /tmp/cc2PJ0en.s:6199: Error: bad instruction `fistpl [fp,#-92]'
> > /tmp/cc2PJ0en.s:7854: Error: selected processor does not support ARM
> > mode `flds [fp,#-96]'
> > /tmp/cc2PJ0en.s:7854: Error: bad instruction `fistpl [fp,#-92]'
> > /tmp/cc2PJ0en.s:7896: Error: bad instruction `fldl [fp,#-92]'
> > /tmp/cc2PJ0en.s:7896: Error: bad instruction `fistpl [fp,#-96]'
> > /tmp/cc2PJ0en.s:8388: Error: bad instruction `fldl [fp,#-92]'
> >
> > It seems that freebasic's gcc backend is still writing asm code in some
> > situations. For example, taken from bmod.rbas.c
> >
> > static inline integer fb_dtosi( double value )
> > {
> > volatile integer result;
> > __asm__(
> > "fldl %1;"
> > "fistpl %0;"
> > :"=m" (result)
> > :"m" (value)
> > );
> > return result;
> > }
>
> I hadn't noticed that.
>
> This is a very simple function; it rounds a double to an int. In C,
> doubles are cast to ints by truncation. FreeBasic instead rounds. In
> fact FB's approach is far more efficient on x86, where truncation is
> more complicated if the FPU is normally in rounding mode (as it needs
> to be for most other operations).
>
> I'm quite surprised that FB emits this function instead of just using
> the C99 function that does the same thing: lrint.
>
> Replacing the function with the following lines should do the job (it
> compiles, at least)
>
> long int lrint(double value);
> #define fb_dtosi lrint
>
> Similarly, fb_ftosi should be replaced with
>
> long int lrintf(float value);
> #define fb_ftosi lrintf
>
> (The C files FB creates don't include math.h or anything else at
> all... wonder whether there's a good reason for that)
Spiffy! Fixing those got me a little further, but I found just one more
block of asm code. Seems to be the same deal as the other, but I am not
sure what the C99 equivalent would be
static inline longint fb_dtosl( double value )
{
volatile longint result;
__asm__(
"fldl %1;"
"fistpq %0;"
:"=m" (result)
:"m" (value)
);
return result;
}
---
James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
