wraitii

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.

Tuan Kuranes: I meant try to avoid as many temporary allocations as we can, and use the existing ones as efficiently as possible. Beyond that, it's probably the only way to go to get a pool. Now, on the other hand, it seems to me this whole debate is quickly getting into the "unconstructive" area. There's a little too much being thrown in the air with numbers flying all over the place. I would suggest a little recap of the points debated here, because based on what is being discussed, it sounds a little too much like the whole game code needs to be rewrote absolutely-or-it's-never-gonna-work, and that's not going to be very constructive.

Looked at your code, Tuan Kuranes. Beyond the ton of const changes (you could have put those in another patch for readability ), it seems mostly sensible. I'd recommend you take a look at the existing patches for the rangeManager, there are some more things there. The fixed issue is not an issue as long as the network cannot deal with smaaaall precision error: we can't afford the change. I would rather optimize the current code to avoid too many memory allocations/deallocations than switch to a pool system though. We need to know how much faster that would be than better use of memory.

I like the third the most, aesthetically. Fortress feels AoM like but that's not a bad thing. Great concepts nonetheless.

That was later in the game. I'm not sure what calls this function, or for the matter how accurate that number is (I'm fairly confident for the main thread, but this was apparently another thread. The JS stuff is kind of exploded in the profiler). Frankly, I'm really not sure what that particular function is. If I investigate it further, it tales me to assembly code which reads "Jaeger trampoline", which is apparently a thing from MethodJIT.

Basically it's Xcode's profiling tool, and that's a % of the time taken by the game to run over about 30 seconds. I'm not sure if that's clear? edit: Apple's guide to the Xcode instruments. it's not really that useful though ^^

Historic_Bruno has a point with the fact that late-game is where the real lag happens. But there are some interesting things to get from early-game extreme situations, because that's when the non-obvious slowdowns are noticeable. Some more random profiling info from starting a game on Peloponnese (according to XCode's profiler). Time spent in "QueryInterface": 2.5% Time spent in "InstancingModelRenderer:RenderModel()": 18.7%. 13.7% of that was system command "glUpdateDispatch" (not sure if that means anything, just shows we can get interesting tidbits of data). To contrast, some info On Median Oasis with 3 very hard Aegis bots at 19 minutes. They had expanded greatly. CheckStackandEntherMethodJIT: 16.9% CGame and CRender took basically the same amount of time, respectively 38 and 28% of the time (at game start it's much more contrasted). Pathfinder::ProcessShortRequest was 7.3% of the time (total pathfinding was 7.9). "BroadcastMessage" took 15% (23% total, but the direct calls were 15%), which went (absolute numbers): -2.3% to VisualActor update (0.9 from calls to CUnit::ReloadObject in CUnit:SetEntitySelection, 1.0% from UpdateVisibility) -2.9% to UnitMotion (1.1% for "TurnTo, 0.7% for "MoveTo", 0.6% for calls to Pathfinder::CheckMovement) -8.2% to the rangeManager, with expectedly 7.8% for ExecuteActiveQueries (about 30% of the time there was SpatialSubdivision::GetInRange.) We have patches that speed this up considerably, I'm thinking it would take less than 2/3% with those, which is non-neglectible. Rendering took 38.4%, 2.5% for the GUI and 4.4% to enumerate objects (which is basically caused by GetWorldBoundsRec and "CModel:ValidatePosition" Some interesting tidbits for the renderer (numbers are now relative to the time it took to complete RenderSubmissions) There was basically no water in my shot, yet waterreflection takes 6.8% of the time, mainly because of RenderPatches. TerrainRenderer::renderpatches takes 11% of the time, mostly for renderblends and renderdecals (5.5 and 3.7%). The shadowmap took basically the same time as rendersilhouette, 17%. Overall InstancingModelRenderer::Rendermodel takes 36.9% of the time spent in RenderSubmission. Now all this doesn't mean much, obviously, but it does show that rendering takes time. But it also shows that the rangeManager is right now one of the biggest slowdowns. BroadcastMessage's overhad was about 3% of the time, which isn't really too much.

About the AI. We should be able to move pathfinding to C++ (perhaps using the main pathfinder with that. The issue is that if it's threaded, it needs to be thread-safe. I'm thinking AIs wouldn't really need much more beyond knowing if something is accessible, a "real distance from there to there" feature and some basic long-range pathfinder (which I have implemented in JS as an oversampled A* (basically I look over every 3 tiles and note very tile, which makes it acceptably fast on my computer), so basically hooking some of the long-range pathfinder features could be enough). The AI also deals a lot with maps, when it really shouldn't. In particular for dropsite placements, it does fairly expensive stuffs. I'm not sure how possible it is to switch this to C++, but there ought to be some way to gain performance there. Finally the entity "collection" system for AIs is still fairly dumb and could be optimized a lot. And then there's the rest. In particular, the GC issue is tougher to deal with. Fixing all AI leaks, if any, wouldn't fix it completely since given the architecture (it gets the simulation state from the JS (maintained by AIProxy), and that's about 40kb each turn) it will OutOfMemory someday.

This is one of those things that seem like they'd improve performance slightly and be generally good, I support it. FYI, XCode has a really interesting profiler too in the instruments, so I could perhaps also get some data from that. (edit: that code does seem crazily inefficient, though) Edit2: ran the game a little in the main menu, Xcode's profiler tells me about 40% of the time was spent walling CGUI: textDraw if I read things correctly.

Excellent post, Yves, I completely agree. I'd add that there are probably a lot of slightly inefficient code bits in quite a few areas of the game, which overall would probably give semi-substantial improvements, but would require probably not too obvious changes (and possibly tedious ones, like caching things, or reinventing slightly better algorithms). I would like to make a case for proper model culling, we currently cull models once per frame, in a not really efficient way (we have to check the world bounds against the frustrum, which is fairly slow, and sometimes recalculate the bounds, which is slower). We would need to do it faster, so we can do it more often (the code for water reflection and refraction fakes culling by flagging unwanted models. But since the rendered recreates the bucket and all, this is not really efficient (and again, the method for culling is slow). This is bad because we can't really do this efficiently, it introduces bugs, and particularly as I'm working on multiple water level (infinite, really), we would really need to be able to better cull models. This is sort of linked to the Ogre and the Octree discussion, but I think it's one of the more important point.

I'd be against a pop-up reminder, I usually find those things more annoying than anything else. I would be all-right with an in-game button though (to trick the player: in the "you won" screen )

I've just committed some fairly extensive behind the door changes to the water code: it no longer uses textures but rather vertex data for rendering the foam. Please report any issue that could arise. It should be faster for rendering but it's most likely unnoticeable.

Similar results in both my Macbook air with GAM 950 and my ≈4 year old iMac: On Gambia river, after lowering the camera as much as possible (using the start camera) and revealing map: Without the patch, full rendering of a frame is according to the profiler 170ms. With it, it's 140 ms. I'm fairly sure we could win another 40 ms if bushes used the no-sort material too. Doesn't seem to be any artifacts but I invite you to test it out. Obviously this only speeds up tree rendering when there are lots of them. For the record, I think we could also use alpha test on a per-material basis, and it could be another speed up for trees without many changes either.

Sure. First screenshot is with sorting, second screenshot is all sorting disabled (couldn't bother to reapply the patch). (fairly big files, didn't want to compress).

Original change talked about in the topic is now in a patch at #1920.