218 replies to this topic

[Sonarpulse]

That's weird. How mature is the android port, it might be an idiosyncrasy of the developers, maybe it's this way to allow easy testing of multiple versions of SDL.

[historic_bruno]

afeder, on 11 January 2012 - 03:00 AM, said:

So far, I've been able to get ndk-build to compile the game with SDL, Boost and SpiderMonkey. I am now down to this error output:

http://pastebin.ca/2102027

You don't have std::wstring, quick research led to conflicting suggestions as to whether it's possible to use wstring with NDK.

[Ykkrosh]

I committed some changes to allow building with SDL 1.3 (at least on Linux), though it doesn't actually run correctly (the window size is bogus). Also you can run "SDL_CONFIG=$HOME/local/bin/sdl-config ./update-workspaces.sh" etc if you want to point it to a locally-installed copy of SDL, instead of using whatever the default sdl-config points to.

About OpenGL ES: Don't remember whether I've mentioned this before, but if not: I think the best approach is to extend graphics/ShaderProgram.cpp to support GLSL shaders (it was designed with that in mind, but I don't know if it'll actually work without some interface changes); then move all the renderer's existing fixed-function texture-environment setup code into ShaderProgramFFP.cpp and implement GLSL-based equivalents, so that most of the rest of the renderer code doesn't have to care whether it's using FFP or GLSL (it just uses the CShaderProgram interface). Also, change all immediate-mode drawing (glVertex3f etc) to vertex arrays. I think that should deal with the most serious problems, and the code would all be shared between GLES and desktop GL modes (no need for forking or #ifdefs etc) and can be tested with desktop GL. Then there's probably just lots of little issues remaining, which can be addressed as they occur.

[Ykkrosh]

About OpenGL ES: On Linux you can compile Mesa with GLES support (on Gentoo you just do "USE=gles emerge mesa"), and I added some stuff so you can run "./update-workspaces.sh --gles" and build the game and get a zillion errors. I fixed errors in lib/ (except for ogl_shader.cpp which should be deleted once CShaderManager supports GLSL), mostly by #if'ing out the problematic things (since the rest of the game still depends on things that GLES doesn't support - should fix that later). Then I got bored - I'm not planning to make this actually work properly in practice, but hopefully it's a step in the right direction

[Ykkrosh]

The assert things just look like warnings, not errors, so they shouldn't be a problem and can be safely ignored.

If you're not running 'make' with the '-k' flag, you should probably add it (e.g. "make -k pyrogenesis config=debug" is probably the best thing for initial testing) and then you should get zillions more errors

[historic_bruno]

afeder, on 16 January 2012 - 06:04 AM, said:

Very good I am now down to this error output, using Crystax NDK and the CONFIG2_GLES flag with the latest source.

I guess NDK doesn't provide POSIX asynchronous I/O either, maybe look into using Boost.Asio? If you look at posix_aio.h, we already emulate it on Windows (waio.h/cpp), so perhaps you could use Boost to provide the same interface? Doesn't sound trivial to me :/ Maybe AIO can be avoided in your case. I'm guessing Jan wrote all that code, maybe you could ask him for advice.

[Ykkrosh]

I think we don't use async IO on Linux anyway (because a kernel bug broke it, and it provides little benefit) - sync IO works well enough. I expect we can get rid of the build errors by possibly moving some code into "#if CONFIG2_FILE_ENABLE_AIO" blocks, and possibly by defining some macros (LIO_READ etc) and structs (aiocb etc) ourselves when the platform doesn't provide them.

[historic_bruno]

Good to know, that simplifies things a bit

[Ykkrosh]

You should do this . Also, it looks like you're setting up ndk-build to only build main.cpp and none of the rest of the game - it'd probably be better to build with Premake as normal, like here (though that'll need lots of fixes to support cross-compilation before it'll work for real; but at least it gets far enough to highlight lots of build fixes that will need fixing first).

[Ykkrosh]

You should run update-workspaces.sh after setting HOSTTYPE, but before setting PATH or CXX or anything else. That will build the bundled libraries (SpiderMonkey etc) like in a normal non-Android build with the standard x86/amd64 version of GCC - those libraries won't be usable by an Android version of the game but we can deal with that problem later once the game's compile errors are fixed.

Then set PATH and CXX, and run the 'make' command from inside workspaces/gcc/ (like in a normal build of the game, except now it's using the Android compiler).