Leaderboard

I started modeling this, so, here is a WIP. I might have to redo some fo the parts to get the polycount down, but I'm going to make it as I first intended, and I'll see how much detail I have to cut back. Right now, I'd estimate that it end up being around 2700 triangles + statue on top, so it's a bit heavy.

Hi! I slowdown the development a little bit because of the GLES errors, and I focused on an easy way to "debug" the GPU on Android. I tried different tools (which none of them worked as I expected) and I end up using apitrace. But even with apitrace it wasn't perfect because it does the retrace on desktop and the GLES implementations are quite different, and I didn't get the same errors on Desktop. So I had to find a way to do the retrace on Android .... This way I end up working on an apitrace retracer for Android . The good new are that I managed to finish the retracer and also I integrate it in the UI . Last night I created the pull request ( https://github.com/apitrace/apitrace/pull/311 ). I need someone who knows GL(ES), to help me to fix these errors and also to check/debug the trace(s) to see why it eats that much memory (+1Gb), the problem is that when the game starts, it eats more and more memory until its killed by the OS . At the beginning I suspect the engine has some leaks, that why it continuously eats memory, but I've seen the same thing happens with the retracer on Android, so now I suspect that the GL(ES) commands, somehow are responsible for the leaks. Even more, having an application that can replay the trace directly on Android, its great because I could run also benchmarks and it seems that not the CPU is the (main) bottleneck for the slowness, but the GPU. There are frames that have +10k of GL commands, which it seems is a little bit too much for an android tablet Anyway, I hope this weekend to have time to update the Android wiki page, this way anybody will be able to build, run & debug pyrogenesis on Android. Also I need to check what are the steps to upstream my 0 A.D. work ;-). Apart that someone needs to make the UI touch friendly, the only "major" task that *I* need to do, is to bundle game data in an OBB, make sure that OBB is downloaded together with the game, mount it, set the game data paths to the mount location, and then we can start publishing it on Google Play! BTW does wildfiregames have an official Google Play account?

Stupid Question : Are you trying to make it smart or realistic ? High level Unit in bataillon killed(ie : Hero, E variant, champion unit) implies units split in every senses trying to find someone to kill ? Or change formation/stay in line, and try to adapt to the enemy they are dealing with ?

1GB isn't that much, depending on the map and game settings - if I run on desktop Linux with nos3tc=true (to mirror the lack of working texture compression on Android), on "Greek Acropolis (4)" with default settings, I see resident memory usage ~1.3GB. With S3TC enabled it's ~0.6GB. I think that indicates there's a huge volume of textures, and we don't (yet) have any options to decrease the texture quality or variety, so you just need a load of RAM. (Texture compression is kind of critical for Android, but ETC1 is rubbish and doesn't support alpha channels, and nothing else is universally available. It would probably be most useful to support ASTC, since that's going to become the most widely available in the future, and has good quality and features.) The problem with having a very large number of GL calls is usually the CPU cost of those calls, so the bottleneck might still not be the GPU

A lot of work, impressive! You may want to contact Philips on IRC for some tips about opengl. Also historic_bruno ported it to iPhone simulator and did some work on gles iirc, no idea if his changes got committed in a public repository, however. Did you try it on at least a couple of different devices? Maybe the graphic driver is bugged and responsible for the memory usage, since the pyrogenesis engine is not used in other projects it may trigger some driver problem on some devices (Linux mesa drivers required a lot of fixes before being able to properly run 0 A.D.). For submitting patches, you should read http://trac.wildfiregames.com/wiki/SubmittingPatches and ask on irc.

To see how it (the textures) looks in your editor I think you need to have the actual meshes that can be found here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/meshes/skeletal/new And for the head(s): http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/meshes/props/new

Don't worry, i'm just knowing and getting used to the model. These definitely are not finished animations, So if you make a change I can make them again, i just did this for you to watch what can i do. First of all i'll have to know every unit in the game, how do they work, about what make them similar or different from each other and a little of historical references for every single one of them. You can make a new armature with no worries, i'll keep searching for nice "moves" in the meantime. I would like to know about how the thing's goes from the exported COLLADA files until the game itself, so if there's any compatibily problem fix it before i start making real animations. You can send me info here jbv.diseno@gmail.com (I can read english or spanish, the talk is my problem ) I already saw your video and i can take references from there, Don't worry and nice work by the way