wraitii

Exactly. Basically it handles a lot of maps in one go, and JS is not exactly perfect to do that. I'm considering switching some stuffs to c++ as part of improving the AI. I want however to be sure that the added cost of memory transfers are not bigger than the increase in computation speed.

That function should be disregarded when profiling. It does big 2D image manipulations that really shouldn't be done in JS in one turn. I'll try to find a way to even that one out whenever I can.

Tuan kuranes: that's pretty spot on. I'll just add that right now getinrange sorts the unit for no really good reason(in some cases), and a speed up can be obtained from removing that (though that could be linked with returning duplicates, which for rendering might or might not be annoying). One thing though: your idea about frustum culling could lead to trees or tall objects popping up in front of the camera, which is bad.

Should have made myself clearer: I meant a quadtree with a final "top/bottom" branching, for stuffs that are only near the ground. This could be useful for refraction/reflection culling for the water, for example, and in a few odd cases. Not too interesting, I have to admit. Frustum culling is currently done by checking the bounding box of every renderable model against the frustum, afaik.

I wouldn't rule it out. If it's not too expensive (I'm speaking CPU-wise here), we could use it to have better frustrum cullings (such as removing bushes that can't be seen but not big trees or something). It would probably need to be slightly clever, though. And it'd indeed be nice to have. But if it leads to a somewhat significant slowdown, then scrap it.

We do use a basic subdivision system (not a quadtree because we don't navigate nodes, we directly access the right square using a vector, I believe) for notably the range manager and the obstruction/path finding managers. It's somewhat efficient, though there are inefficiencies that Could be fixed. The problem is that each manager keeps his own and the simulation as a whole doesn't, when it really should. I'd advise looking at the obstruction implementation: it keeps static objects (no need to update them) and moving objects (need to be updated at a cost). The game can use events for updates. Overall, a new quadtree/octree ( I'm thinking it wouldnt cost muuuuch to make it an octree, not sure it has a point though) would need to be owned by the simulation (perhaps a manager) and shared for all stuffs that could use it, in particular the renderer for frustum calls.

I think you get artifacts because you consider points and not surfaces, which is what you actually ought to consider. Diagonal points can make a lot of difference in the water flow, and this is probably where your results are wrong. Your current implementation simulates constant raining, which should give a good enough result but would be better if you kept the water map over every frame, I think (twist it though, because given your algorithm it would be much too strong. You'd need to lower the strength). In that case, you need to lose some water (multiply WaterFlow by an arbitrary constant). For the rest, seems good.

The basque words sounds like a Basquization of the roman word, though, so I'd advise using something else.

That's looking pretty good . I'll be on holidays for the rest of the week so I'll give a look at your code this week-end/on monday (public holiday in France).

Some interesting stuff: your line 674 is actually required and does all the work. I tried *0.5 the waterDrain variable: now it did nothing. Setting it to 2 gave odd results. 5 gave the same. Looking at your code, it doesn't seem too sane: first you only move the ground for x+1 and y+1, might want to do it at least for w-1 and y-1 too, if possible all 8 corners. Secondly, the way you calculate the water drain map seems alright, but it has a side effect: it seems to me like in the current implementation this means all water will flow down to the lowest point on the map (locally), with no respect for possible pond formations… You need to take into account the water height when calculating height difference, I think it would alleviate the effect. Furthermore, you should make each square retain a little water (percentage) so you will get some rivers as you can keep track of where water runned before going down. If you then use my method of recreating the water drain using the first water drain distribution, you should get really good results. Otherwise seems fine. edit: or keep adding water each frame uniformly as if it was actually raining, losing a little every turn too to simulate absorption.

FeXoR: I don't think you posted the files. What do you mean by the "resonance"?

I'm not sure you can create riverbeds unless you make rivers remove some amount of ground, and make them remove more stuffs the deeper the water is (linearly, likely) so rivers will tend to dig. Given you avoid multi-step, I can't think of much better. Perhaps try to run a little rain/wind erosion first, to get a better map.

Some better concept for the fishing boat. If this is good, I'll give a definite go at proper UV-ing/texturing (using free textures, could somebody point me to some website for that?) and animating (getting a crash loading the rigged model into the game for some reason). (I'm pretty sure the reed texture I've used is bamboo, so papyrus would probably be a bit less yellow, more like in the first one though). edit: obviously beyond any mesh change that would be required.

I think the fact that the water is flat doesn't help you with not seeing riverbed, which with such a function would be at different heights. I suggest you try this erosion on a tilted plane with minor differences in height level and check how it looks like.

Some comments about the wiki article: I suggest you try to put this in Coding Conventions or Code Quality rather than somewhere else, and try to follow the layout/style from those pages. It would make it easier to read and understand (also, your descriptions of optimizations are a bit under-detailled to my tastes.) Finally, a wiki article stating "I" feels a bit weird to me.

FeXoR: after the fix it should work better. But I'm thinking you should also try to run some water only there to remove terrain, and not actually displace it, as that will probably help in creating rivers.

I think they're going for "Rule of Cool" once more. (achtung: TVTropes link, you can get stuck there.)

Lordgood, your female face (I'm assuming the blue one is one) is still a little odd: it looks like a man. (Having said that, I'm starting to really like those. The archer one in particular is awesome, you can feel the dynamism in that picture.)

I'm thinking it should be blood the the odd post-effect makes it black. That or Thorfinn is right.

Enrique: I likely can, yes. Beyond the need for proper UV/texture, I'm not sure how to handle the rows. Should I keep one similarly to the existing fishing ships, use what appears to be the "historical" way (ie pushing on a pole, but that would look weird on very deep water, wouldn't it?) or use some sort of single-oar sculling (probably the best bet here, but I'd need to give a good go at animation. Can certainly be done, imo)?

I'm raising a slight issue on the fishing boat for the Ptolemies. While from what I read it appears their galleys were basically greek (see Tessarakonteres, though this is probably as mythical as it is real, or the next source which, while really old, is really interesting), and their merchant ships mostly similar to what we could find on the mediterranean at the time, I am unable to find conclusive evidence that their fishing boats had changed much (old source here quotes herodotes, but it doesn't seem to talk about fishing boats). Most sources I've found do not discuss the issue. Given the shapes of the other fishing ships, I'm thinking perhaps we should give them traditional looking papyrus boats (such as here), rather than more generic looking boats. It somebody has some accurate information on their actual fishing ships, I am interested though. (basically, in the style of the generic fishing ship but more "egyptian" looking) edit: basically, something like the attached image (was bored out of my mind this morning)

There are at least 3 coordinate systems: -World position -"Tile" position (usually world position /4 except Y which if I recall correctly doesn't change), which theoretically shouldn't really be used by simulation code. -screen position. Your assumption seems to be right to me (you can see it's multiplied by Terrain_Tile_Size, which is 4, to go from world to "tile" position) Giving a look at the code, it seems to work properly, and detect the action properly (if I "warn(uneval(action))" right after calling determineaction, I get "set-rallypoint". However apparently the DetermineAction thing expects "GetActionInfo" to return position and tooltip information, which it obviously does not. I suggest you fix the bug in GetActionInfo: it should return more information for set-rallypoint. This should make it work, unless something else goes wrong.

I think the best would be a different discussion thread, at this point. What we would need for a discussion on topic X to go somewhere is: -Some breakdown of how system X is currently done in the game (which is what is mostly lacking currently). -some data about how much time it takes per frame/turn, preferably verifiable/reproducible, so we can get data from multiple machines and get the real hotspots and bottlenecks from there. -some concise description of how we could improve on this, with a con/pro list (that obviously would be discussed. We can certainly update it more or less realtime.) The problem of estimating the time needed for the actual changes is a function of those two and of knowledge of the code, but having a good breakdown of what exactly is slow could help by knowing why it was implemented that way and help input from users knowing the code (which could help fix issues that shouldn't be there in the first place, like with CStrIntern.) The memory issue is really quite different from the proposals of switching to Ogre, which is much more problematic in terms of how many changes it would require. Same with changing things in components. The fixed point issue should probably be left alone for now while we optimize the rest (there are also ways to avoid incessant conversions between floats and fixed, so we could gain speed by doing that). If after all the other optimizations, it's still a huge problem, then we'll see how we can tackle it, but I doubt that will be necessary in the end. Truly there are other areas to optimize. So generally I'd recommend one topic per specific issue otherwise the discussion seems to get diluted, particularly on big issues like the ones being discussed here. (the model being the "Design Committee" topics here.)

I'm not sure that's the bug reported... From what I recall in the code, it probably won't try to attack gaia buildings, only units, when those are agressive.

AI won't defend its ally anyway currently. It's not clever enough to do that.