Ykkrosh

Hmm, I'd probably expect the opposite - the look of low-poly models will be dominated by their silhouettes, which no kind of mapping can help with. (Especially units, which are very small during normal gameplay, so there's not enough pixels to represent any fancy lighting effects, and the silhouette and broad texture detail is all you'll notice). It'd probably be more effective to increase the polygon budget by 10x or more (plus some kind of LOD system) so the silhouettes can contain more detail. (And even more effective to simply stop using the same mesh and animations for pretty much every single unit )

It'd be useful to know where it's crashing (since it shouldn't) - can you start it like "gdb --args binaries/system/pyrogenesis -archivebuild..." then do "r" to run, then it should crash, then do "bt full"? One possibility: Does the "temp" directory exist? (If not, does it work better if it does?)

Hmm, I don't know where that file comes from - some part of the Android SDK generates it (maybe ant), but I have no idea how to trigger it. The .apk won't be created correctly without that - you'll need to run "make clean" then "make" inside sdl-project/ to rebuild properly once the keystore file is in place. (None of the rest of the build process will be affected by that, though.)

The code is all here (the files with "Pathfinder" in their names). My current perspective is that users with very fast PCs are the least important when optimising the game - in general it's best to focus on optimising the bottlenecks, so users with very slow PCs are the much more interesting problem . We want the gameplay to work well for every player; and to support multiplayer and replays (and to preserve sanity when debugging problematic behaviour) we really need the pathfinder to give identical results for every player; so performance is constrained by the slowest player we want to bother supporting (which nowadays is probably still (just about) single-core CPU and middling Intel GPU, i.e. not much opportunity for parallel computing). I've seen some interesting demos like ATI's Froblins of doing pathfinding on the GPU (just using D3D10 in that case) - that's more like the Continuum Crowds paper than SupCom2 is, in that it uses the crowd density when computing the potential field (and has to update it each time everyone moves). I don't know how practical it'd be for a game though - their demo seems to have few distinct pathfinding goals ("go to any gold" and "go to any temple" and not much else), and a uniform unit size and no formations etc, which cuts down the need for many distinct potential fields, so it'd be interesting to know if there are other clever parallelisable ways to do pathfinding that could work well in practice.

I don't like the default font size for posts (testing on both Opera and Firefox, and Linux and Windows) - it's now 14px, which seems annoyingly large when trying to read or write any non-trivial-length posts, and it looks inconsistent with the rest of the text in the UI. I think 13px looks much better. The font in the non-WYSIWYG post editor (Courier New, small) is almost unreadable for me on Linux (it's alright on Windows). "font-family: monospace; font-size: medium" would work better.

Looks like I accidentally removed the NDK build instructions. I added that back which will hopefully help

It's probably too slow, and we don't want crowds anyway (we want units to move in relatively rigid formations), as well as it being complicated, so it's not very suitable at all

I assume you've put the game in a path that contains non-ASCII characters. r11839 should fix that now.

The Continuum Crowds research seems to be all about using a 'dynamic potential field' that represents both global navigation (planning routes around static obstacles) and moving obstacles (avoiding running into other people). It's an expensive computation since the potential field needs to be a large high-resolution grid, and the whole grid needs to be updated several times per second to cope with moving obstacles, but it can result in nice congestion-avoidance behaviour (forming lanes and vortexes). SupCom2's behaviour (based on observing the gameplay and its debug visualisations) can be understood without any of that - its global navigation is fundamentally just standard RTS static A* (but run backwards, with the results shared between multiple units), and it deals with moving obstacles largely by having them run into each other and then slide around and hope they eventually slip past each other. If you tell two groups of units to cross each other at 90 degrees, there's no lane formation - they turn into a giant mess. (You do get lanes if the two groups are moving directly towards each other, but that's the only case where it works nicely, and that's just a consequence of groups being box formations with wide separation between units.) So they're, like, totally different, and claiming that one is based on the other (as anything more than just a vague inspiration) is therefore nonsense

The most useful screenshot would probably be with the camera looking vertically downwards, with obstruction overlay enabled. I guess the problem is that you've got so many builders that one is standing inside the foundation (preventing the builders from making progress), and is completely surrounded by other units and is therefore unable to get out. I have no idea how we can avoid that problem, without letting units push each other out of the way so they'll never be permanently stuck when surrounded.

As I understand it (which is not very well), removing the effect from units would be unlikely to make it much faster - SSAO is a screen-space algorithm, i.e. you render the whole scene to colour+depth+normal+other buffers (or some subset of that) and then run SSAO over the relevant buffers. It doesn't care about the number of objects or triangles being drawn - only the number of pixels matters. Units typically cover very few pixels so their cost would be negligible. I guess removing the effect from terrain could improve performance (the shaders can do an early exit and skip some processing for large areas of terrain), but then it'd presumably need an extra buffer to distinguish terrain from non-terrain which could make it slower again.

Since I happened to play Supreme Commander 2 recently, I thought it'd be interesting to reverse-engineer its pathfinding algorithm (as with Age of Mythology, though SupCom2 is entirely different). Their promotional material ( etc) talks about it being based on crowd continuum pathfinding, but as far as I can tell that's basically nonsense (though I could certainly be mistaken; it'd be good if anyone had more precise technical details) - it doesn't appear to do any kind of dynamic potential field, it just does a basic static vector field plus local steering behaviour (with perhaps a little bit of lookahead to discourage units walking straight into each other).I don't think this is of much direct relevance to 0 A.D., since we have very different requirements and constraints, but it's interesting as a point for comparison. So, this is my current poorly-organised understanding of how it really works (with a few links to pictures hidden in the text, for people who don't like reading): Units have an EPathMoveType, which is one of a hardcoded list: * PMT_Land_Small_Water_Surface * PMT_Land_Medium * PMT_Land_Large_Water_Abyss * PMT_Land_Large_Water_Floor * PMT_Land_Medium_Water_Surface * PMT_Air determining what kind of terrain it can move over. Terrain rendering is not tile-based - the world is just a collection of meshes (one for ground plus separate meshes for walls and custom scenery etc) - but it's converted to a 2D tile-based heightmap for pathfinding and for computing heights of units. Tiles are about the same size as a small unit. The world is about 1024x1024 tiles on the 2-player map I tested. Buildings are aligned to the tile grid (they can't be rotated or fractionally offset). Buildings have a square outline, and you're not allowed to build so that it overlaps any other building's outline. Also you're not allowed to construct too close to an impassable terrain tile. Buildings block tiles in an arbitrary pattern (typically a square, but factories have holes cut out the middle so units can walk out of them). There is always a one-tile-wide border inside the outline that is not blocked. The consequence is that it's impossible to block off any areas - there's always a gap for units to squeeze between buildings, or between buildings and blocked terrain. That means it can't support defensive walls that keep enemies out. (Also you can't accidentally set up factories where there's no space for units to spawn.) To be more specific about impassability, see two screenshots: small unit, large unit. The red tiles are impassable due to terrain, and the purple tile are impassable due to buildings. Red tiles block off roughly 2 tiles around the steep walls for small units, and an extra 4 tiles for large units. (The red tiles gives an octagonal pattern around sharp corners.) But buildings take precedence - if a tile within a building's outline is defined to be passable by that building (e.g. the one-tile border), then it will never be marked as red. (That means even the huge units can squeeze between buildings and blocked terrain. (Or they can try, at least - sometimes they get permanently jammed for some reason.)) Given that passability grid, a unit can pathfind to a single goal tile, using a flowfield algorithm. That algorithm computes a vector for every tile, such that a unit can follow the vectors and will end up at the goal. See another screenshot which makes it clearer (the goal is the bottom-centre of the screen). It starts with the goal tile. For any tile within about 64 tiles of the goal, if there is a straight line to the goal that doesn't cross any impassable tiles, then the flowfield vector points directly at the goal. Those vectors are drawn in light blue. Beyond that, it expands outwards in 45/90 degree angles (like normal A* pathfinding), and the vectors (drawn in green) point in 45/90 degree angles towards the predecessor tile. (In a few cases it gets some intermediate (presumably 22.5/67.5 degree) vectors too as a shortcut, but it seems pretty random in when it decides to do that (probably a bug).) It stops generating the vector field a little bit after it's reached the source unit. (I don't know why some of the vectors in the earlier screenshots are dark blue; it only seems to happen for short paths. Maybe a visualisation bug?) The point of doing that work is that multiple units with the same goal can use the same flowfield - moving a group of 100 units has the same flowfield-generation cost as moving 1 unit, and the units can still move independently of each other (so they move as a swarm, not as a formation). Each tile will either have one of 16 directions (rendered green), or will be pointing directly at the goal (rendered light blue), or will be unexplored and have no vector, so it needs to be stored with 5 bits per tile. It needs to be memory-efficient since each flowfield is stored for as long as any unit is still using it. Given a flowfield, each unit does some kind of steering behaviour: try to move in the direction of the vector of the tile you're currently on; if you hit a unit bigger than you, or an equally-sized unit that's also moving, then try to wobble left or right a bit until you get around it (or get stuck); if you hit a stationary equally-sized or a smaller unit then shove it out of the way and carry on straight. When you tell a group to move to a goal, they try to spread out in a grid formation around some target (i.e. some position and direction). It computes the desired formation offset for each unit, then casts a ray out from the target to each of those offsets, and stops when the ray hits an impassable tile and puts the real formation offset there. (That means if you move a group to a tile adjacent to a cliff, the units on one side of the formation will get jammed up against the inside edge of the cliff, instead of letting the formation get split across the cliff.) It then computes a single flowfield for the entire group of units. Each unit follows that flowfield, until they reach a point where there's an unobstructed straight line to their own formation offset, and then they head straight towards that new position. The target for a group of units is determined in some unknown way; it seems to depend mainly on the average position of the units, and jumps around a lot every sim turn. At some point it snaps to the goal tile and stays there forever. (That means the units often don't remain in any kind of formation - they squash up into a narrow snaking column until they get in sight of the goal and spread out again.) I think that's about it.

#741 (toggling fullscreen causes the OpenGL context to be reinitialised, but we retain reference to data from the old context and reuse them, so it breaks in random ways). (We ought to support reinitialisation on Windows and Linux too, so we can change monitor resolution and antialiasing etc at runtime without restarting the whole engine, but they don't need reinitialisation when toggling fullscreen so it's not a problem there yet.)

"InternalError: recursive object" is emitted by SpiderMonkey's structured clone operation, which is what Engine.PostCommand uses to safely copy its argument data from the AI thread to the engine thread. The cloned data mustn't have any objects that include references to themselves (e.g. "var x = {}; x.foo = x;"), so you get the error message in that case. (I think newer versions of the HTML5 structured clone algorithm, implemented in newer versions of SpiderMonkey, don't have that restriction.) In this particular piece of code you were probably accidentally passing some complex recursive object instead of an entity ID.

Does this help? (Our code was arguably incorrect, though I can't tell what the C++ standard says about whether it should have worked anyway.)

Capturing video inherently requires a lot of hardware resources - FRAPS seems about as good as anything. The Evolve client also seems to work reasonably well for capturing game video (and is free).

Building for Android will only ever be possible on Linux. (I updated the instructions here recently to use the various build scripts that I added some time ago, but it's still far from step-by-step instructions and is only suitable for people who are comfortable with debugging the build process and code themselves.)

What about paying £26 to upgrade your Mac so that it's not running an out-of-support OS with known actively-exploited unfixed security vulnerabilities? (e.g. there's no update to fix Flashback on 10.5, only advice to disable Java in all your web browsers.) I don't think we want to actively refuse to support old OSes just because they're old (I think it's valuable to be widely compatible, especially for an open source game which relies on inclusiveness and community support and which should appeal to people without modern gaming PCs), but in this case it's been hard to get any OS X support at all (due to lack of interest and/or capability) so it makes sense to limit the scope in order to minimise technical difficulties - PPC vs Intel, 32-bit vs 64-bit, Carbon vs Cocoa (in particular the Atlas editor uses wxWidgets which supports only Carbon on 32-bit and only Cocoa on 64-bit, if I remember correctly). Maybe a reasonable approach would be to continue doing 64-bit 10.6+ builds as the primarily supported version, and also distribute a 32-bit Intel 10.5-only non-Atlas build for broader compatibility (with no guarantees it will get continued 'official' support from WFG) if someone is willing to set up and maintain and test the build environment for that?

I think GF210 should be fine for 0 A.D. (even at highish resolutions), since we don't do anything graphically demanding - most slowdowns are due to the CPU, which will be fixed as we optimise the code. You probably need to make sure you're using the proprietary NVIDIA Linux drivers though, not the open source Nouveau drivers (which have various performance problems and general bugginess). I have a GF560Ti, which is nice (it runs any modern game at nearly-highest settings without much trouble) and benchmarks seem to indicate it's about 10x as fast as the GF210, but I don't think it's cheap and it doesn't really have "good energy saving capabilities" (it's apparently >100W more than the GF210 when loaded), and it's certainly overkill for 0 A.D.

In the old and currently-being-worked-on designs, we don't recalculate paths for units. Once they've started to move and have picked a path, they'll carry on using that path forever, unless they crash into an obstacle and have to stop and pick a new path. That's maybe not ideal behaviour, but it works okay for now

No - you'll almost always need a new version of the compiled executable, not just the new data files and scripts. This got fixed.

I'd worry that that might be a bit too dangerous in general - checkrefs.pl isn't perfectly accurate (e.g. it can't detect filename strings generated by scripts (especially GUI textures), or filenames that are hardcoded in the C++) so we might end up removing files that are actually used, and nobody tests the alpha releases very thoroughly so we probably wouldn't notice the errors. It could be safe enough for some subdirectories though - if there are non-music .ogg files that aren't referenced by any sound group XML, we could probably exclude those without much problem.

GL_MODELVIEW_MATRIX might not always be set up correctly - the current version of the renderer tries to do everything with local per-shader transform matrices instead of the global GL state. Better to use g_Renderer.GetViewCamera().GetOrientation().GetTranslation() to get the world-space camera position (or use the g_Renderer.GetViewCamera().GetOrientation() matrix in other ways).

The first load of a texture from SVN will be slow since the game has to compress it, but that's only a temporary issue. When running in Release mode from the debugger, you also have to add "_NO_DEBUG_HEAP=1" to the environment variables (somewhere in the project properties), otherwise memory allocations will be abnormally slow.

I'm fairly sure printf should work when on Linux. debug_printf(L"message", ...) should work too (and also works on Windows, via Visual Studio's debug output window). There's also LOGWARNING(L"message", ...) which displays the messages in the game window.