Ykkrosh

I expect that's just because there was no good reason to disable PCH on Windows, and supporting it would mean more build configurations to test and fix, so it's easier to consistently require PCH. (GCC PCH can cause problems, at least with old versions or certain external tools, so it was worth supporting without-pch for GCC.)

Yeah, and impossible locations are bad because the algorithm searches the entire visibility graph before realising it's impossible . Maybe the pathfinder could do something like test if the target is inside an obstruction and the unit is outside it, in which case it'll definitely be impossible and it should pick a better target, e.g. change the goal to a CCmpPathfinder::Goal::SQUARE matching the obstruction. That sounds like it should work for buildings, though maybe not for large overlapping groups of obstructions (e.g. tightly-packed ranks of enemy units, or impassable terrain). Hmm, that looks like 64-bit multiplication - all my testing so far has been on 64-bit Linux, where a 64-bit multiply is just a single instruction, and I haven't worried much about 32-bit builds. The CheckVisibility functions do a lot of CFixedVector2D::Dot then compare with 0. Dot does 32-by-32-to-64 multiplications (a bit like the mul32by32returnHi but shifting by 16 instead of 32 and hoping the result won't overflow). Maybe it'd be possible to add a specialised DotAndCompareToZero function which uses some trick to multiply more cheaply on 32-bit x86? (It could skip the >>fract_bits too since that's just throwing away precision before the comparison with 0.)

That sounds sensible in terms of static decision-making, but when should units switch to a new target? Assuming no human is overriding the behaviour: If a unit is attacking a building, then an enemy archer comes near (into their vision range? into their attack range? into some other range?), should they immediately switch to target the archer? or should they wait until the archer attacks them? When they chase the archer (who will run away), if they run into a line of enemy melee units who surround them and start killing them, should they switch to attack their new attackers, or continue chasing the archer futilely forever? If they'll continue chasing forever, it seems you could trick an enemy's whole army into chasing a single fast unit and then trap and slaughter them without them ever fighting back. If they should switch when attacked, then if they're chasing the archer but get shot by a second archer, should they switch to the second archer, and potentially keep alternating? (I don't have answers to any of this - I think I'm mostly uncertain about how to make units responsive to their environment (i.e. visible enemies and attackers) without making them so indecisive that they never follow a target long enough to kill it, and I don't know how to precisely define the right balance.)

Sounds like great progress In the long term, it'd be nice if the changes we need were merged into the standard Premake distribution - the main developer has seemed interested in extending Premake based on real use cases, so hopefully that should be possible. But our main priority is just to have it work for us, and if we have to distribute a customised version of Premake then that's fine for now (and better than waiting months for a new upstream release). I don't think we really need to keep VS2005 compatibility, but we should support 2008 and 2010. But I think the 2005 format is almost identical to 2008, so if it's easy to support both then that'd be worthwhile. If you need help with testing, I have access to various environments and other people here can probably help too, so you could upload your code somewhere (attach here or on a Trac ticket or whatever) for people to try out. (Also it'd be nice for us to have a copy of the work-in-progress in case you discover later that you don't have time to complete it, so someone else could finish it off - hopefully that won't happen but it's good to be safe )

That's odd, there should be one like this in mods/public. Is your copy of that file missing or something? Also, what map were you loading?(r8888 should stop it crashing in this situation (at least after whenever the next autobuild is) but I'm not sure why you're experiencing this situation at all...)

Thanks, done.

Hmm, could you upload mainlog.html (from the same place as the crashlogs) too? (This looks like it's failing with a null pointer returned by tile->GetTextureEntry()->GetProperties() in CTerrain::GetMovementClass, but I don't think that should happen unless some data files are broken.)

That doesn't sound very recent . Are you running the latest version from SVN? Where are you looking for crashlog.txt? (It should be in %appdata%\0ad\logs\ now (or run OpenLogsFolder.bat from the SVN checkout directory).)

r8887 fixes that, by making tiles near the edge impassable to all units. (Didn't seem worth re-autobuilding just for that, though.)

Done that. (Actually made it a bit more complex - the solid black sides hang down from the terrain (or the water if it's higher), so you should never be able to see anything through the edge. With this it'd be easy to do AoM-style terrain where there's a visible rocky texture all around the outside of the map, but that doesn't make sense for circular maps and I think I prefer the fade-to-black-at-edge look.)

Hmm, I don't think that should be possible . It should be doing pretty much exactly what AoE3 does. It was (though not hugely) . I still don't really like doing graphics work, but I suppose I understand it a little better now. Yeah, our handling of map edges still isn't ideal. I could just add a big black vertical rectangle covering each side of the map from the water plane down to the bottom of the terrain, to quickly fix this bug, so I'll probably do that. (We've discussed better ways to handle edges but I don't want to bother with that yet.)

(From IRC discussion it sounds like this was fixed by moving local.cfg into the right place.)

It won't, it's a separate issue - units have a minimum attack range, and if they're too close then they'll automatically pick the nearest point at that distance from the target and move to it (which takes some time) then will stop and prepare to attack (which takes some more time), and by then the enemy will have moved closer than the minimum range again.It'd be possible to make the attacker move to a point further away, to compensate for the amount the target might move, but that sounds either complex (if we compute the distance dynamically based on the units' speeds (which can depend on terrain) and attack-preparation times) or fragile (if we hard-code a larger-than-minimum distance they should aim for). Not sure how best to deal with it.

I've played with its unit models a bit . Never really played its games, though. Its engine design seems less advanced than 0 A.D.'s in various ways (e.g. it appears to rely on the old-fashioned 2D approach of buildings being aligned to grid squares (which makes environments look more artificial), and it seems to have a monolithic simulation architecture rather than being modular and flexible and scripted) so I think it's good that we're designing our own, though they currently have the significant advantage of actually having playable games

I think it can never be perfectly smooth, since the input data is limited to one value per tile (since that's what the visibility computations provide). That's converted a texture with one pixel per tile, then blurred - I suppose it'd be technically possible to use a higher-resolution texture so the blurring can partially mask the tile edges but that sounds like a significant extra cost for little benefit (since the texture can already be 512x512). And I think AoE3 has exactly the same edgy behaviour, and nobody seems to mind their fog Yeah, I just don't really like telling people they can't play our game . Our stated minimum requirements are GeForce 3, and have been since about 2003, which is already very low (and prevents us from e.g. relying on shaders) - but someone over here had a Radeon 7500 which is lower than that, so it seems there's still some practical value in continuing support. But disabling shadows in those cases seems fine, and means there's no longer a problem.

The most annoying thing about implementing this fog is that one part of it wants the graphics hardware/drivers to support 3 texture units, and OpenGL only guarantees 2. Currently our rendering code only requires 2 (it can make use of 3 or 4 but has fallbacks). In practice, I've only seen really ancient devices with 2 (except some modern mobile ones but they only support OpenGL ES so they won't work anyway) - it looks like GeForce4 MX has 2; GeForce 3 / 4 Ti has 4; Radeon 7500 has 3; Intel GMA 900 has 8; etc. This page indicates similar numbers. It wouldn't be particularly complex to continue supporting 2-TU hardware in this case - it just needs an extra render pass, but that'll make it even slower (and these are presumably extremely old devices), and it's another codepath to test and maintain. And actually this case is only when shadows are enabled, which are going to be terribly slow on old hardware anyway. So I think we should say that if you only have 2 texture units then you have to disable shadows - that'll simplify the code a bit and it shouldn't affect any real users.

I tried a blur. Does that look like what people want? (Should it be more/less blurry? Darker/lighter shade for the previously-explored areas?) (This is done by creating a bitmap with one pixel per map tile, then doing a single 5x5 box blur on it, then uploading as a GL texture, then multiplying the terrain by that texture. My current implementation is inefficient and buggy and needs to be rewritten but the basic idea seems to work.)

Hmm, if I remember correctly most games have separate "move" and "attack move" commands, where "move" is the default and "attack move" is ctrl+click or something like that. Does "move" mean they should never attack, even in self-defence if they run into an enemy unit who is blocking their path and slaughtering them? Does "attack move" mean they should only attack in self-defence, or should they attack anything that enters their line of sight? Should we support both commands, or just have one command that's context-/time-sensitive? I don't play RTS games enough to know what behaviour would be helpful/irritating for players, but if someone can say precisely how it should work then I could probably implement it easily.

It's not really feasible to reroute immediately - we can't tell which units could now have a shorter path, except by recomputing every unit's path every time a building is destroyed/created (or locked/unlocked for gates) and seeing if it's much different, which would not be great for performance. Maybe we could do something like recompute paths every ~10 seconds (staggered across all the units) so they'll reroute eventually, but we probably need to make pathfinding as fast as possible before deciding how much more to use it. Hmph, we've spent a lot of effort trying to make the game load as quickly as possible, and now you're complaining it's too quick What OS? In Win Vista/7, is alt-tab doing the Aero Flip 3D effect, or an old-fashioned 2D switcher? (When I try in Vista, alt-tab is the 2D thing and works, but win-tab is the 3D thing and doesn't work; maybe you have something similar but slightly different.) I think the problem is they always fight back when they get hit (e.g. by an enemy who is chasing them). What's a good way to let players order units to retreat, without units abandoning all attempts at self-preservation while walking? (Maybe they should ignore attacks for 5 seconds after a direct order from the player, before enabling self-defense counterattacks, or something like that?) If you shift-click to make a single unit build multiple buildings, they should do so. The shift-click order queuing is broken for groups of units though (since the units split out of the group when reaching the first building and then the group's order queue is no longer tied to those units), and needs to be fixed, so I'd guess that's what you're experiencing.

The code I used for that screenshot is awfully inefficient and slightly broken so it'd need to be entirely redesigned, and that would probably be about as much work as doing the AoE3-style blur, so in that case it sounds like it'd be better to just implement the blur instead. (I'm assuming the blur basically consists of a map-sized dynamically-generated greyscale texture that's stuck on top of the terrain, since that sounds like it'd work and I don't know how else it could be done.)

Hmm, I'm not quite sure what you mean. Premake3 doesn't output .d files by itself, so it has to get GCC to do it via -MF (so that incremental rebuilds work correctly). Do you mean Premake4 is different for C++ and computes all the inter-file dependencies by itself? (I'd be surprised since I don't really see how it's possible to do that correctly, and incremental rebuilds would fail if you added an #include to a file (which is very common) and then rebuilt without running update-workspaces again.) About .asm files: Good catch! (Though is it one % too much or too few? The line for .c files says "$(<F:%%.c=%%.d)" but I don't know if that's right or wrong). The .asm files are edited very rarely, which is probably why nobody noticed, but it would be nice to do it correctly and generate the .d files if it's not much extra work.

Hmm, isn't this kind of an insensitive time to announce the addition of Egypt to a war game?

I don't expect there'd be any significant difference in performance, and I'd prefer us not to have to implement and maintain and test more options than is really necessary, so I think we should stick with just one (whichever matches the look we want).

I think what we've got now is awfully ugly . Diagonal lines in one direction are smooth but in the other direction are very jagged (which is unavoidable since it depends on the direction of triangulation of tiles), so it needs some new method (though not urgently).

My skills are mostly limited to randomly applying the clone brush and dodge/burn tool, so I wouldn't really use the term "artist" . Sharper blends seem okay for things like roads which are usually high contrast against the background, whereas natural terrain usually has much softer contrasts, but there's some terrain where it's probably not great. Needs art input, probably . (It should be straightforward to test new blends - look in art/textures/terrain/alphamaps/standard/, change the corner and edge images to whatever you want (making sure they tile and mirror correctly), then combine them to form all the other images and edit as desired. The engine should hotload changes to the blend textures, in theory.)