Leaderboard

Modified versions with your feedback:

I think some folks are putting too much stock into the religious motivations of pagans of this time. Sure, some believed that glorious death in battle guaranteed a better afterlife, but I don't think this was the main basis for great deeds and warlike-spirit. Most Roman soldiers during the 2nd Punic Wars were likely fighting because they were defending their city and homes from a foreign invader (Hannibal). Persian soldiers fought at Thermopylae because they were conscripted to. As far as I know, Ahura Mazda blessed truth and justice and things like that, not reckless battlefield heroics. Carthaginians in the 3rd Punic War fought to prevent their own enslavements and slaughter. Alexander fought for everlasting fame and glory, not to gain some kind of comfortable afterlife. The men beneath him fought for riches and plunder. The Teutones fought the Romans under Marius in order to secure a new homeland (and lost badly). I think it would be cool to have some kind of tech at the temple that boosts your units, but base it on religious rites or rituals. These were very important to superstitious soldiers and helped curry the favor of the gods for their cause, or so they believed. Alexander sacrificed with his army's priests every morning. Priests from many cultures ritually slaughtered goats, chickens, and cattle prior to battle (Greek: "Sphagia") for favorable omens. Ritual feasts accompanied religious and civic festivals, with burnt offerings "given to the gods." Spoils of war were dedicated to temples in honor of the gods and to gain their favor. Religious oracles were consulted by private citizens, governments, and kings for guidance.

This is only somewhat related to Android development, but just for laughs I tried to get 0 A.D. to run on a Raspberry Pi. It's really far too low-end of a platform to be practical for actually playing 0 A.D., but it's still fun to see the game running on unusual platforms, especially one so cheap and low power as a Pi. My Pi is a Model B with ARM CPU, 512 MB shared RAM, 16 GB SD card, connected to 1920x1080 monitor via HDMI, and running fully updated Raspbian OS. Pictures will come once (if) it's running stably. In theory this is all possible, because the Pi is an ARM device and Josh, Philip and others have worked to get ARM support working nicely for 0 A.D. (originally for the Android port) and most of the game's dependencies are already available as ARM packages in Debian, which at least the Raspbian OS is based on. The Pi also has an integrated GPU with OpenGL ES 2.0 support, which is partially working in 0 A.D. SVN. I fixed up some of our rendering code that was broken on GLES, available on my Github repo here, and updated our SDL2 support here. Note that SDL2 is required for supporting GLES and has vastly improved support for mobile devices. The changes in these branches will eventually make their way to SVN, but for now, they can be pulled for anyone wanting a somewhat working Android/GLES build My approach for getting the game to work on the Pi was to begin with a custom cross-compiling GCC toolchain, using distcc to distribute the bulk of the compiler processing burden onto an Ubuntu VM providing 4 cores, to avoid the Pi's incredibly slow CPU and disk I/O. crosstool-NG was used to build the actual cross-compiler toolchain, vaguely as described here. This proved to be quite a headache, not least of all getting my network configuration set up so the Pi could communicate with the Ubuntu distcc "slave". Next I had to check that all dependencies of the game were available as ARM packages through Raspbian or if they could be built separately. Surprisingly, most of them were already available, though a few had different names than on Debian/Ubuntu. SDL2 was not available, so I had to download the source and compile without X support. That's important because GLX, which SDL typically uses on *nix, is not supported by the Pi's proprietary GLES drivers, but SDL2 defaults to using X when available. Instead, rendering has to use the EGL backend on the Pi, luckily SDL 2.0.1 has basic Raspberry Pi support that does all the Pi-specific initialization required. The only other dependency that was missing was NVTT, our bundled copy in SVN has patches to build on ARM. Compiling software on the Pi is incredibly slow, with distcc and decently powerful slave devices, it becomes bearable, but it will still be slow during e.g. preprocessing and linking. If you can get a cross-compiling environment working on desktop Linux, that might be the way to go, and I might try that next. Once I found the right combination of options for SDL2 and premake, the process went smoothly, but there are a lot of problems to get that far. I would say it takes at least 45 minutes for a clean build of the game using distcc with my Ubuntu VM, compared to less than 3 minutes to build the game normally on the same VM. SDL2 clean build takes maybe 5-10 minutes additional time, the same for NVTT and FCollada (neither are really needed though as will be seen below). After getting the game to build on the Pi, the next challenge was making it run. Once I figured how to build SDL2 with udev (required for keyboard and mouse) and EGL support, the next hurdle was that texture conversion was impossibly slow. I was staring at a mostly gray main menu screen with about 2 textures loaded for quite some time, before I realized it wasn't frozen but busy converting textures! It's also possible NVTT wasn't working 100% correctly as there were a lot of GL errors being logged. So I chose to create a public.zip archive like we use for releases, with all the textures, models, and XML precached, and copy it onto the Pi in place of the SVN mod data. In the end, I got the game to load the main menu a few times (buggy as usual on low end hardware, maybe due to the massive scrolling background textures with transparency?) Using autostart, I even got a game to load once before textures were working, but it typically fails pretty hard during loading. There are either some software bugs, it runs out of memory, or the hardware/power supply is being overstressed. It's hard to troubleshoot because whatever is going wrong kills the network connection (so I can't SSH into it) and locks up input, so I can't close the game window. It could even be an assertion in our code, and it's unable to minimize the window and release input like it normally would (Pi support in SDL2 only allows creating a full screen window, not changing mode to e.g. windowed). I'm satisfied that the game can be built for, and run on, a Raspberry Pi, but it's not yet to the point I can demonstrate it working reliably, if it ever will. Hopefully it will work again and I can get some quality photos and screenshots, because I think it's a pretty cool demonstration of 0 A.D's versatility and the capability of low power ARM devices like the Pi Sadly I don't have a smartphone with nice CPU and GPU, that would be a much better test platform, but the nice thing is I can develop, test and debug much of the same code on a $50 Pi, that would be reused by a $400 smartphone or tablet.