On Sat, Feb 16, 2013 at 03:47:54PM +1300, Ralph Versteegen wrote:
> On 16 February 2013 05:58, James Paige <[email protected]> wrote:
> > 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.
>
> Is there any good reason for not putting the data files in the .apk
> (other than the packages for open source reimplementations of
> commercial game engines)?
No, I can't think of any other reason.
> This port seems to have a lot of builtin functionality that I had
> expected that we would have to implement ourselves. I assume we will
> fork and modify it, the same way SDL's Mac port has a template
> SDL_main.m file.
Yes, I suppose so. I'm still feeling slightly lost among all this
porting business :)
> The readme for that port mentions that SDL 1.3's official Android port
> is far more barebones. I definitely want to write an SDL1.3
> graphics backend, especially for multiple window support. I
> have been using SDL 1.3 for a pure-programmed game lately. So that
> will give us another option on Android. Also, SDL 1.3's distinction
> between (software) surfaces and (hardware) textures maps well onto
> Jay's new graphics API (which I would like to start adopting after
> Beelzebufo), though maybe it is problematic on devices without actual
> hardware acceleration.
That sounds nifty. That is the gfx_newRenderPlan stuff?
> >> > 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;
> > }
>
> Oh, missed those when I grepped the output.
>
> long long int llrint(double value);
> #define fb_dtosl llrint
>
> and (not actually used)
>
> long long int llrintf(float value);
> #define fb_ftosl llrintf
Cool! Thanks!
That got me all the way through the compiling phase and into the linking
phase, and then I got so many "undefined reference" errors that it
filled up my consol'es buffer and I could not even scroll back and see
them all. They all seem to be the FreeBasic runtime library, so I guess
the next step is figuring out how to cross-compile that.
---
James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
