Ykkrosh

Yes, same as what's currently implemented (and same as in AoM/AoE3 etc). (The 3D model only rotates at a constant slow rate, which makes the instant turns much less noticeable, but it's still instant as far as the simulation code is concerned.) Maybe with some simple hack (like apply an attack bonus if the unit was moving recently), or maybe a special movement mode that's not based on pathfinding and just moves in a straight line until it hits something (which is fine as long as we can fall back on proper pathfinding when the unit has to navigate a tricky environment without getting stuck).

There isn't. (Wouldn't be hard to implement, but it's not implemented currenty.)

Yeah, it would probably be a bit nicer to do rounded corners, though it shouldn't affect the correctness of the pathfinding (it just might look a bit visually nicer when units move in smoother paths around corners). Currently I'm effectively doing a convolution with a box shape over the terrain passability grid; convolution with a circle would give rounded corners around the terrain (though I guess it'd be a bit slower since the circle isn't a separable filter; need to measure it to see whether it matters). Static obstruction passability is done by rasterising a square (after adding clearance radius to width/height), and could be fairly easily changed to rasterise a rounded square instead No. It's not really axis-aligned anyway, since it's sort of a circle (though sometimes sort of a square, and it gets rendered as an axis-aligned square) - the pathfinder and unit-movement code assumes units can turn on the spot instantly, and won't get stuck when turning, so orientation is ignored entirely. (This should only really matter for things like ships, which are long and narrow and slow, and they probably need a largely separate implementation of the movement code anyway to deal sensibly with momentum and ramming and turning circles etc.)

Filenames are case-sensitive now, so you need "-autostart=Latium" (not "-autostart=latium") and "-autostart-ai=2:scaredybot" etc.

While on the subject of performance, I grabbed some profiles showing where time is spent during the processing of a typical frame (in the default view on Oasis, with no AI etc). Top row: PC (Intel Core i5-2500K, 3.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$, 6MB L3$), MSVC. Vertical grey lines are 0.1ms. Bottom row: Samsung Galaxy S II (Exynos 4210 / ARM Cortex-A9, 1.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$), GCC (-mthumb -mcpu=cortex-a9 -mfpu=neon). Vertical grey lines are 1ms. In both cases it seems to be primarily CPU-limited, not GPU-limited. "sim interpolate" is purely on the CPU (computing model transform matrices, fog-of-war status, etc), and is about 12x slower on ARM than on Intel, which sounds plausible as the general CPU performance difference for branch-heavy code; it would probably benefit from high-level optimisations that would work the same on all platforms. "prepare models" is more like 100x slower on ARM, which I guess is because it's mostly computing skinned meshes, which is SSE-optimised on Intel; ARM would probably benefit from similar low-level optimisations (using NEON) (or using vertex shaders, maybe). So there seems to be plenty of scope for improving performance significantly, and modern Android devices could probably sustain ~30fps on more complex maps. (Improvements to pathfinding, AI, multi-core support, etc would all be needed too, but they're important for PCs anyway.)

Yeah, the problem is the decals' clamp-to-border textures (the border should be transparent, not that greyish colour), which I assume is a driver bug. What driver version are you currently using? ("glxinfo|grep OpenGL" should say.)

Everything is in public.zip, except for .exe/.dll/etc files on Windows, and except for binaries/data/tools/ and binaries/data/config/.

Sounds like they deserve it and have no justification for complaining The networking code currently doesn't provide any way to kick players. I suppose the easiest way to add it (if you have some C++ experience) is to add a new script-callable function to source/gui/scripting/ScriptFunctions.cpp that does "if (g_NetServer) g_NetServer->KickPlayer(playerId)" then add KickPlayer to source/network/NetServer.cpp (you need a CNetServer::KickPlayer that pushes the command onto a new queue in the CNetServerWorker m_Worker object, then CNetServerWorker::RunStep can read the command and find the session associated with that player ID and call session->Disconnect(...)). Then whichever player is hosting can run "Engine.KickPlayer(4)" etc in the in-game console to forcibly disconnect a player. For it to be a more robust solution, it would have to stop the player from immediately reconnecting, and some kind of GUI interface would be nice, but those probably aren't critical features. I'd be happy to add a basic solution to the source if someone writes a patch for it

(I don't think it should - if we add other OS X platforms later, they should probably be added to the same build script (to avoid redundancy) inside libraries/osx/, and they don't need a new top-level directory. Platform-specific compiled output could perhaps go in libraries/osx/x86_64/ if there's a real desire to support multiple platforms in parallel in a single checkout, but that sounds quite a theoretical concern to me.) That doesn't sound right - it needs to contain the source for (if I remember correctly) nvtt, fcollada, spidermonkey, enet, and probably valgrind (only headers), and shouldn't contain anything else. It would be nice if we didn't duplicate the forked source in both libraries/osx/ and libraries/linux/ - maybe put them into a single libraries/sources/ (along with any shared-by-Linux-and-OSX custom build scripts for each). Could it be made part of the existing update-workspaces.{sh,bat} step? That can automatically do a "svn co" to get or update the appropriate libraries/{linux,osx} (and libraries/sources/{nvtt,...}), and then (on Linux/OSX) automatically run the library build script, so we don't need to worry about users getting it wrong or forgetting to update when we change the libraries. (In that case, update-workspaces should probably specify an explicit SVN revision of the libraries that it wants, and we should update that specification when updating the libraries, so that people can still build old versions of the game successfully with the contemporary libraries, instead of it always requesting the latest versions. Also, need some alternative for Linux release downloads so that they bundle everything necessary, since package build scripts shouldn't perform their own network access.) (update-workspaces should quite possibly be moved and/or renamed, perhaps to "build-setup" in the root directory or something like that, since currently it's weirdly hidden away.) Linux packagers generally insist on dynamic linking for various reasons, but OS X development never seems to bother with anything like that, so static linking on OS X sounds reasonable and least problematic. (Static linking also means bigger executables (which I wouldn't like on Windows since it would probably make the autobuilds much bigger), and seemingly much worse linking times (which I wouldn't like on Linux since I compile the game myself on Linux and am impatient) ((unless I'm misinterpreting the cause of the slow linking of Android builds)), but those don't seem particularly important on OS X.)

Vectors are ugly if they don't have antialiasing (and antialiasing often hurts performance significantly, so we can't rely on it). They're also harder to implement in an artist-controllable way - we'd need a vector graphics editor, a vector file format, code for loading and rendering those vector files, etc, to support any shapes much more complex than plain circles. Textured quads will generally look prettier (assuming they're high enough resolution that you don't see the pixels, which should be possible), and perform better, and are much easier for artists to control (they can just paint a .png of whatever they want it to look like).

Thanks, it did

The technologies are pretty similar (C++, OpenGL ES, ARM, etc, with SDL doing most of the platform integration work) so it should be feasible if anyone cared to do it. Porting to Windows for ARM would probably be a bit more technically interesting - I guess you'd have to use ANGLE to translate GLES into DX9, but otherwise it still shouldn't be much different. The biggest problem is that the current RTS gameplay design seems like an awful fit for phone-sized devices (since it requires presenting too much information to the player, and requires too much precision of input, and requires concentration for long periods), and not much good for tablet-sized devices either, so someone would have to solve that too (To clarify my current interest in this: I don't care about making a proper playable game on Android, and I'm not intending to spend any time trying to achieve that. I'm just personally interested in learning about the technical aspects of the platform, and porting the game engine as a tech demo seems a better approach than spending the time on some throwaway toy project instead, since it encounters more interesting issues and produces a more impressive result, and it also indirectly helps the game on the proper desktop platforms (by cleaning up some of the rendering code (avoiding global GL state), and by adding GLSL support which will simplify new graphical features and may improve performance or driver compatibility, and by dealing with some portability problems, etc).)

Short answer: No The main benefit of the navcell-grid-related changes is that it should eliminate a class of problems where units currently get stuck, especially with large units moving through forests or other dense environments. That won't help performance, but pathfinding needs to be correct before making it fast. Using the navcell grid with a higher resolution than the terrain tile grid will make performance much worse, but using the JPS pathfinder optimisations should make it much better again. The reachability testing should help performance massively in certain cases (like a formation walking beside a lake), but it will make other cases a bit slower, but if necessary it could be adapted to make those other cases faster too. There's still the opportunity for multithreading the pathfinder, which would make things faster for most users. I can't really predict how all the factors will balance out, or how much extra work will be needed until it's acceptably fast, but I'm reasonably confident this is at least moving in the right direction.

If you're able to edit the source code before compiling, then applying this patch should make it give a bit more information about exactly what it's trying and failing to create. Incorrect owner or permissions for the directories leper mentioned are probably the most likely causes.

The current approach (public.zip with no internal compression, then everything packed together and compressed with LZMA by the installer) minimises the initial download size - any other combination will make it larger. Most people will probably only play the game once, so I think it makes sense to optimise for initial download size, rather than doing a tradeoff of worse initial size for better incremental update ability. (And trying to reuse off-the-shelf tools probably wouldn't be any easier than developing a custom updater that incrementally updates the installed public.zip files, which would allow the best initial download size plus efficient updates.)

Found a better camera (and fixed text rendering and landscape mode etc): (You can get to the match setup screen by touching buttons, but the GUI isn't designed for such a low screen resolution so you can't click the button to start the game, which wouldn't work anyway because it's missing shaders and doesn't have the Collada importer.)

I think I've committed the right code now. It's not at all elegant or robust, but seems to be enough to start testing and iterating. Rough usage instructions: "hg clone http://hg.libsdl.org/SDL" into build/android/sdl-project/jni/ (or clone elsewhere and symlink it there, or whatever). Until this bug is fixed, apply the patch from there. In build/android/sdl-project/, run "make". That should compile SDL and the .apk file. (Dependency checking is probably broken, so run "make clean" if you need to rebuild after changing stuff.) In build/android/, run "./setup-libs.sh". The script hardcodes the expected locations of NDK and SDK, so put them there or adjust the script, and it will output to ~/android/toolchain-0ad. That should download and compile loads of stuff. Build the game like ./update-workspaces.sh --gles --android --without-fam --without-audio --disable-atlas --with-system-mozjs185 --with-system-enet --with-system-nvtt --without-nvtt and TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/ -I../../android/files/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug Then attach a device, and in build/android/sdl-project/ run "make push-apk" and "make push-so". Run /sdcard/0ad.apk on the device to install. Then you need to build a public.zip containing all the data files, kind of like what source/tools/dist/build.sh does, and preferably unzip+zip it so that it's compressed properly (to save bandwidth and space), and push to /sdcard/0ad/data/mods/public/public.zip, then run the app. (The .apk is basically just the standard SDL android-project, and it loads /data/local/libpyrogenesis_dbg.so which contains all the engine code. That means you can recompile and then upload the engine code (via "make push-so") on the host PC, and don't have to manually reinstall the app after each change.)

(Apologies for poor image quality - using a phone to take a photo of itself is seemingly not a good idea.)

After a load of disgusting hacks, and after giving up on the emulator since it seems to complain when executing certain instructions (blx) in the Crystax NDK, I can get the code to start running on the real device. Currently the only data file is the hwdetect.js script which lets it report some hardware details like { "os_unix": 1, "os_linux": 1, "os_macosx": 0, "os_win": 0, "arch_ia32": 0, "arch_amd64": 0, "build_debug": 1, "build_opengles": 1, "build_datetime": "Feb 15 2012 01:13:30", "build_revision": "custom build", "build_msc": 0, "build_icc": 0, "build_gcc": 404, "gfx_card": "ARM Mali-400 MP", "gfx_drv_ver": "OpenGL OpenGL ES 2.0", "gfx_mem": 0, "snd_card": "", "snd_drv_ver": "", "GL_VERSION": "OpenGL ES 2.0", "GL_VENDOR": "ARM", "GL_RENDERER": "Mali-400 MP", "GL_EXTENSIONS": "GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil ", "GL_SUBPIXEL_BITS": 4, "GL_MAX_TEXTURE_SIZE": 4096, "GL_MAX_CUBE_MAP_TEXTURE_SIZE": 1024, "GL_MAX_VIEWPORT_DIMS[0]": 4096, "GL_MAX_VIEWPORT_DIMS[1]": 4096, "GL_ALIASED_POINT_SIZE_RANGE[0]": 0.25, "GL_ALIASED_POINT_SIZE_RANGE[1]": 100, "GL_ALIASED_LINE_WIDTH_RANGE[0]": 0.25, "GL_ALIASED_LINE_WIDTH_RANGE[1]": 100, "GL_SAMPLE_BUFFERS": 0, "GL_SAMPLES": 0, "GL_RED_BITS": 5, "GL_GREEN_BITS": 6, "GL_BLUE_BITS": 5, "GL_ALPHA_BITS": 0, "GL_DEPTH_BITS": 0, "GL_STENCIL_BITS": 0, "GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 1.00", "GL_MAX_VERTEX_ATTRIBS": 16, "GL_MAX_VERTEX_UNIFORM_VECTORS": 128, "GL_MAX_VARYING_VECTORS": 12, "GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS": 8, "GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS": 0, "GL_MAX_FRAGMENT_UNIFORM_VECTORS": 1024, "GL_MAX_TEXTURE_IMAGE_UNITS": 8, "GL_MAX_RENDERBUFFER_SIZE": 4096, "video_xres": 320, "video_yres": 483, "video_bpp": 32, "video_desktop_xres": 800, "video_desktop_yres": 480, "video_desktop_bpp": 32, "video_desktop_freq": 0, "uname_sysname": "Linux", "uname_release": "2.6.35.7-I9100XWKJ1-CL647431", "uname_version": "#2 SMP PREEMPT Tue Oct 11 16:42:43 KST 2011", "uname_machine": "armv7l", "cpu_identifier": "unknown", "cpu_frequency": -1, "cpu_pagesize": 4096, "cpu_largepagesize": 0, "cpu_numprocs": 1, "numa_numnodes": 1, "numa_factor": 1, "numa_interleaved": false, "ram_total": 836, "ram_total_os": 836, "ram_free": 20, "timer_resolution": 1e-9 } and then it dies because it can't find the rest of the data files. Need to make the hacks less disgusting, then I'll try uploading my changes, and then need to get it to load all the other data files to display the GUI screen, and see what else breaks.

I patched the Boost build script with --- MysticTreeGames-Boost-for-Android-70838fc/build-android.sh 2011-10-16 14:34:17.000000000 +0100 +++ MysticTreeGames-Boost-for-Android-70838fc/build-android.sh 2012-01-29 13:06:37.289820841 +0000 @@ -104,19 +104,19 @@ ;; windows|cygwin) Platfrom=windows-x86 ;; *) # let's play safe here Platfrom=linux-x86 esac -CXXPATH=$AndroidNDKRoot/build/prebuilt/$Platfrom/arm-eabi-4.4.0/bin/arm-eabi-g++ -CXXFLAGS=-I$AndroidNDKRoot/build/platforms/android-8/arch-arm/usr/include -TOOLSET=gcc-androidR4 +CXXPATH=$AndroidNDKRoot/bin/arm-linux-androideabi-g++ +CXXFLAGS=-I$AndroidNDKRoot/sysroot/usr/include +TOOLSET=gcc-androidR5 if [ -n "$NDK_R5" ]; then CXXPATH=$AndroidNDKRoot/toolchains/arm-linux-androideabi-4.4.3/prebuilt/$Platfrom/bin/arm-linux-androideabi-g++ CXXFLAGS="-I$AndroidNDKRoot/platforms/android-8/arch-arm/usr/include \ -I$AndroidNDKRoot/sources/cxx-stl/gnu-libstdc++/include \ -I$AndroidNDKRoot/sources/cxx-stl/gnu-libstdc++/libs/armeabi/include \ -I$AndroidNDKRoot/sources/wchar-support/include" TOOLSET=gcc-androidR5 fi then passed it the toolchain path instead of NDK path when running it, which seemed to be enough to get it building with the latest NDK.

r11068 fixes some. With the GL errors: What version of the NDK are you using? I'm testing with android-ndk-r7-crystax-4 and those symbols (GL_BGRA_EXT etc) are defined in platforms/*/*/usr/include/GLES2/gl2ext.h. After some fiddling with libraries and Premake and environment variables etc, I can get it to compile against the NDK and get far enough for the linker to complain about mostly-legitimate missing symbols. I've been writing a script to automatically build all the libraries based on the steps in the wiki, so I'll try to get that working and upload it some time tomorrow.

As of r11065, I can build and start the game with Mesa's GLESv2 implementation - there's no text on the menu screen, and it crashes when you start a match, but that should be enough to test the Android port.

See http://zsync.moria.org.uk/paper/ch03s02.html: The Windows installer uses the LZMA compression algorithm (plus whatever headers NSIS adds), which is even less likely to work. The installed game's public.zip is uncompressed so something like normal rsync/zsync would work for that.

We compute bounding boxes of particle emitters correctly (I think), and treat them like any other prop on the model. The problem might be that we ignore the bounding boxes of all props when deciding to cull a unit during rendering (and if the unit is culled then no props are drawn). That should be fixed to either use the correct bounding box, or to cull and submit each prop model independently.

An auto-updated Git mirror would be handy so it's always in sync - it's easy to get the SVN server run a script after every commit to do whatever extra updates are needed. I've been continuing to commit various GLES compatibility fixes, mostly trying to fix things in a permanent way (not just disabling code temporarily). The basic strategy is that any fixed-function multitexture setup code (glTexEnvi etc) should be moved to ShaderProgramFFP.cpp, and the rendering code should load it via g_Renderer.GetShaderManager().LoadEffect(...), so that we can easily add a GLSL-based implementation of the shader later. Then the rendering code should replace calls to glVertexPointer(...) etc with shader->VertexPointer(...) (which translates the fixed-function arrays into generic vertex attributes for GLES-compatible GLSL). Then replace all glBegin/glVertex3f/etc drawing with vertex arrays and glDrawArrays. Then replace the GL global matrix stuff with client-side computation of the model-view-projection matrix, and pass it to the shader with shader->Uniform("transform", m). I think the shader API provides everything that's needed for this now, so the remaining work is mostly just mechanical translation.