Sonarpulse

Sure, GC-induced stalls are horrible with real-time systems, and thus I don't advocate them during gameplay. But does it make sense to treat the loading stage before the match begins as a real-time system? I'm saying for the loading stage maybe use some GC library (not switch languages) for temporary objects which will be deallocated before the match actually starts, because nobody cares whether GC cycles stall the loading process if it's still faster overall. Of course, if you can get rid of little allocations cleanly enough, as it looks like you have done, that great. But judicious use of GC could potentially both be easier and make for cleaner code than such manual methods.

Switching the spikes from manual memory management to garbage collection could also speed things up. GC alloc is typically much faster, and since GC'ing itself has a time complexity with respect the number of live objects, garbage collection can actually be much faster when you have lots of short-lived objects, as seems to be the case hear. Any stalling from GCing (the price of more throughput) is also more appropriate during initial map loading than game play.

Us Haskellers are slowly becoming more prevalent!

Well if you are going for a big donation push, now's the best time to seek these things, as some things might merit rewriting anyways. Also if enough new code needs to be rewritten vs just maintaining old stuff, the new code can be in the new language and the old stuff kept in the old. Even if something were rewritten, and in the short term the rewriting slowed things down, you may be glad you did it. It's like the US switching to metric, it's annoying, it's painful, but it's only going to get more difficult in the future. Better incremental changes now than a complete engine rewrite for the sequel. Last I heard (about a year ago), much of 0ad's performance woes could be traced to the fact that it wasn't very parallel. Haskell provide very per formant lightweight (implicitly preemptive) concurrency http://benchmarksgame.alioth.debian.org/u32q/performance.php?test=threadring and unlike, let's say node.js, distributes those threads across multiple OS threads/cores. Additionally transaction memory, and/or immutability means deadlock and the other normal concurrency woes are out of the picture. Rust also supports similar lightweight concurrency, though I am not sure if it's implementation is as mature. It doesn't support transaction memory for safe shared state, but also allows rigorous use of immutable data structures and additionally offers unique pointers / notions of ownership to tackle the same problem. Additionally it's probably easier to interface with the existing C++ code. Javascript doesn't support parallelism, so there is little you can do to tackle that problem while staying with it. Even with existing code, I wouldn't say rewriting in C++ is going to be less painful than one of these languages, and without a good preemptive concurrency library you may still not reap all the performance benefits.

You guys should consider something besides C++ and Javascript. Haskell, Rust maybe.

Maybe give the user a warning when a the lowest alternative is higher than their configuration asked for?

I'd hate to deprecate perfectly good models, but do we really need separate wall towers and stand alone towers? Maybe just like with gates we can make it so a wall tower is upgradable to a standard tower (for added range or something).

I think I have said this before, but horses and ships, since they both accelerate slowly, can use the same motion/path-finding.

One suggestion, is there any tool that can smooth vertex normals horizontally but keep them as is vertically? i think that would make them look less geometric, yet still rough and wind-hewed, with no performance penalty whatsoever.

Excellent work on the dock and theatron! My only criticism is scale. I think the size of the seats/steps don't quite correspond to the main building. More importantly the center stage should be much bigger (even if their are less rows of seats/steps). But it is only a WIP as you say, and these things are easy to fix. Keep up the good work!

On a related note, what if you have have multiple "bases" that are either a certain distance apart, or separated by water, they have separate stockpiles and you'll need to shuffle resources between them (with traders or something similar)? You could always build a string of cheep buildings in between to make the two bases one contiguous base ...but that would be much harder to defend. I imagine this would probably entail overall big changes in the engine, but it would add a whole new dynamic to the game.

Ow, my brain. That emoticon really fits

looks like inverted normals to me. Excellent fortress!

you know, honestly the best whitewater I was was the little creeks in Skyrim. And a swear it was just a couple layers of animated textures with only specular highlights as an effect. This only applies to splashes and rapids, not waterfalls proper or any bigger waterway, but it's a start. Look about minute 8

I think your first orange was in fact perfect for leaf-litter, though the existing leaf litter texture can do too. As to the grass, it depends an what you are looking for. Grass doesn't change color like deciduous trees, it can however brown due to a lack of rain, as in the South African pick. If this is supposed to be a like a New England (or England for that matter), I think their is enough rain so the grass wouldn't change color at all (it would just be covered with leaves, and in a clearing or meadow there wouldn't be less leaves for that matter. In the steppes of Asia, western United States, that place in South Africa I guess (If that counts as Savannah probably other Savannahs too), the grass would dry out (what ever season that might be). AFAIK, the dry grass is tends to be less orange and more brown-yellow like the grass in the foreground of the South African picture. Not really sure what's making the grass so orange in the middle of the valley though, never seen grass like that before.

I believe you don't need to squash your history to make a patch. I just searched and it seems their are a number of ways to convert a git patch to a svn patch.

I think I would prefer a grid, you may want even spacing between buildings too. Maybe pressing a hotkey while you are placing the building would highlight a grid (made up of game tiles, I think they are about the right resolution), and the building would snap to that.

That would please many OCD RTS fans, i think.

Eh, don't worry about it. You've got better things to do than research that. Foam isn't wrong at all. (in fact, I'd also say the white that is left over after the wave breaks is more correctly called foam that whitecaps). I picked the most distorted on the crude analogy that distortion was proportional to wave height (which is probably more true for breaking waves than normal ones, if ever true at all.) Anyways though, in this case i think realism is less important than finding a metric that somehow makes the whitecaps in look related to the distortion effect (which I believe is realistic), even if that relation is bogus.

Here is an idea for waves and whitecaps ('whitecaps' probably being a better term than 'foam' for what we are trying to achieve): Looking at the (gorgeous I might add) screenshots of the tower, it looks like you guys are using dynamic distorting (for both refraction and reflection)? In that case I would say a wave texture isn't needed. Likewise, if possible you guys could scale the distorting near the shore (using the depth texture), you would get bigger waves near the shore (somewhat realistic, especially with bigger waves like tsunamis). Lastly, if the amount of distortion exceeds a threshold (per pixel), the pixel can be tinted white to simulate whitecaps.

OK. Hopefully he comes back soon.

I don't know any relevant fluid dynamics, but I'd imagine what you'd really want is the gradient vector field based off the height map. https://en.wikipedia.org/wiki/Gradient

regarding murkiness: Yay! i guessed right! @historic_bruno Do you mean have blender use the gpu? or use the gpu for the lower alternative? I don't know blender, but if you can give it a script from the command line, this seems the type of thing that would easily be added to the build system. Even a straight up makefile would probably work.

So at the point where multiple materials meet, are multiple tiles overlayed?

Haha, is that http://www.digitalartform.com/archives/2006/05/faking_simple_v.html from page 8 of this thread? Also, for ultra-realism wouldn't what you are saying need the light-ray-in-water distance computed from the camera's perspective and the light source's?