wraitii

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.

There are no such mods now. It can definitely be modded in using the experience though. This reminds me of "rpg" maps in AoE 2 multiplayer.

That along with different water levels would be nice. it would require changes to atlas tough for support, I'm not too sure how (i was thinking keeping a 2d map of water height, some basic info for running water. I think changing the texture could then be handled automatically: if the water plane is flat/enclosed, it's a lake, I it's big enough, an ocean, and of it's of different heights, it's a river (possibly switching in the middle). The rest of what you describe ought to be doable. Biggest slowdown right now is refraction/reflection rendering tough and there's not much currently to do to speed that up (need to speed the rznderer up...)

Current water rendering is not exceedingly satisfactory, so some changes are definitely in order. I'm not sure how doable a system like red alert would be, it's obviously fairly advanced, but we should be able to do better than what we have.

From what I know of the code, implementing ogre fully means changing the entirety o the GUI folder and perhaps also converting GUI files(to use ogre. If we actually switch the GuI its a full change) It means a complete change of the renderer folder. It means tons of updates in the graphics folder, but that actually shouldnt be too much of a problem. Might require some changes to collada(can't recall if ogre handles collada natively). Ps/ probably has files that would need to be changed as its the core of pyro genesis, but that also shouldn't be a problem with your experience The issue is maths/. If you use the ogre provided versions of matrices, vectors, it Ould require changing things everywhere in the code. Perhaps a simpler solution would be to typedefs those types (which would maintain the usage of CWhatever for class names) The rest should be mostly left as is. However ogre was not chosen before, and we need to know why to check if the reasoning still applies. I suggest you start a new topic explaining what we would gain (in terms of speed, flexibility, features) and how much time you think it'll take after assessing the necessary changes. Then well be able to take a sensible decision

It's definitely a very interesting long term perspective, particuarly as the renderer is quite limited. On the topic of floats vs fixed, unless serialization and OOS checks can be efficiently changed to disregard all roundin errors, this is something that needs to be kept. Perhaps however it can be optimized a little (20% seems fairly big). Anyway, there are other areas where optimizations are interesting so that's nothing too important. Edit: this is probably impossible, but another solution would be SP to have floats and Mp to have cFixed. Might require two apps though, à la CoD and perhaps some other games.

Even for fairly small areas it's very computationally intensive. There's a reason if hardcore realistic water is really rare in video games

I think that having the basics down is the necessity. If some stuffs require behind the door changes later, it's less of a problem. This is so the work done on components afte the ECS will be there for good, such as optimizations or new features. The renderer is a big Change that has the advantage of being very long term and really good FPS-wise, so that's why I think it's the second highest priority (particulalrly as theres really noone else to do it). Of course, that's only my opinion, and others should weigh in on this.

It's fairly simple, really. If its too long to refactor the ECS, then it'll stall development and while in alpha with not all features implemented, that's really undesirable. Unless it can be done fully and then one day committed in one go, it should not be done now. That's true of the renderer too, but to a lesser extent, and wouldn't prevt adding new things. It's however probably not quite as long (depends. You might well be fast if you know Ogre). The problem with focusing on the renderer is that changes to the components are "lost" in that many things will change, so it might also prevent work on thy, whoch we do not want. My vote would be for the ECS, but it needs to be in one go, with full support of existing functionality, which means it needs git. Then the focus should probably be the rznderer. Other things can likely be done by other people anyway if the architecture is there (slower, but that doesn't really matter)

From what I know of ogre, switching to I would almost allow to keep every file as is. Might require rewriting shaders to cg, but that's close enough from glsl. We wouldn't really lose much. I'd agree that it would be more urgent to, say, rewrite the component system: this would probably stall development for a while, but allow it to resume faster later (c++ side anyway). The renderer is "not quite slow enough", I find. It's an area where absurd optimizations could be done, but generally I think it'd be best to have the final component/simulation architecture down first.

Basically the current implementation seems fine: only "pack" the files for releases. The engine already for that, just need to change the way it packs.

It's most likely some variation on the best way to go for a moddable game. I think civilization IV uses some sort of similar system ("loose" or readable files are cached into binary files for later uses). 0 AD should definitely allow something like that. Given the architecture of the "mods" folder, I'm thinking keeping a separate "pack" cached for each mod. The engine would need to be able to handle either the original files and cache them, or the packs, or a combination of both. Keeps moddability, readability, and efficiency. (obviously takes more time to do but or the sake of argument, ill assume your time is infinite )

I think rewriting the pyrogenesis renderer would still be faster than implementing ogre through and throughout. But in the long run, it's not. It really depends on how you feel in terms of time. Working full-time, with your experience, I hardly doubt you'll manage it "fairly" fast. It is however true that working full time on the engine is much more efficient than on and off, though.

Sound generally good. I have nothing against changing XML to something else as long as readability is kept (and thus modability too), and most/all features are too. Redesigning the way components are handled seems fair, the use of maps and intertwined calls to other components slows th thing down and makes it awkward to understand. Again, as log as moddability is kept, sounds good. The pathfinder is a permanent WIP that stalled a year ago. I recommend you check out Philip's work, he had basically done what you describe (still has to give away the code though). I'll add that this should, as much as possible, use functions the eventually could be called by the AI to obtain paths (even of that implies having to wait for the next turn), as that is a serious slowdown for AIs. If at all possible, a proper quadtree for entity positions should probably be linked with the renderer to speed up frustum culling for models, though that might link rendering and simulation a bit too much. UnitAI is slow. However, I believe it's wanted to remain mostly JS to allow it to be modded fairl extensively. Moving it to C++ would imper that completely. (same deal with the actual opponent AIs code) (also: we need to be sure that removing cFixed won't cause OOS errors in MP, but I'm sure you have that in mind) (edit: btw, as the kind of guy that makes crap code that need to be fixed (do NOT look at water manager.cpp right now. I can't believe how ugly it is, and I made it), glad to have you on board )

Based I my (smallish) experience with Ogre, I'd agree that it's really flexible enough to integrate properly without bloating the engine. One concern about the updating would be the GUI (is it worth recoding from scratch? Use an existing ogre one? Adapt it?). Basically the renderer is pretty much there and mildly efficient. There are 4 things that have to be worked on: optimizing the rendering (eG by having better instancing (I think we're pseudo instancing non-animated objects, currently)), work on some sort of LoD(I think it's worth it), fix the silhouettes rendering(waaay too slow. Check "combat demo huge" for an example), and the water refraction/reflection, which is not too efficient, but is really tied with the other points. There are few bugs, nothing too important. Making it efficient enough would require some rewriting, but I believe we could get good enough performance without too much work. Updating to ogre has one huge advantage long term: no need to worry about maintaining the rendering and updating to the latest technologies. It's also more flexible for the engine itself, for potential other games using it. It will probably allow to do fancier stuffs too, so that's a win-win. So basically deciding is simple enough: will it take too long to update to Ogre for part 1? If no, I'd say it's an interesting project. If yes, then we're better off without it. Working full-time on it, with experience, I think it's possible to finish the update before part 1 (by doing it properly, I mean.). Perhaps even for beta. Obviously, this would be made easier by using a separate branch in Git, whenever that day comes.

I tend to agree. While ogre is an excellent engine, in the current state, the cost of migrating things seems a little high. The current renderer can probably be improved enough to be acceptable for release. It could be a task for part 2 though, as it seems to me that Ogre could be fitted pretty nicely in pyrogenesis, but it basically requires rewriting a ton of stuffs.

I've been working on adding relative-to-prop velocity for particles so your jet effects should be improvable fairly easily in the next few days (need to get back home, get it reviewed and committed). (I'm doing mundane tasks that could be useful to the engine while on holidays. Also slightly changed the ship decay anim to make it slightly better looking.)

Putting this here: I've added the ability to select items in dropdown menus by typing stuff with the keyboard (open the map menu, type "lorr", it gives you Lorraine plains"). I feel like it'd be nice to have, I'll post a patch when I get back home.

Gave a look at the code... It's actually sort of the same thing, but not really. Alha testing means textures are either fully opaque or fully transparent, which is a fair approximation for our models but does give artifacts on their borders. It's faster because openGL doesnt really have transparency to do. Now when rendering transparent mOdels such as trees, we sort them by distance to avoid transparency artifacts such as these: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-10-transparency/ (sorry typing on the phone). However that's not really useful for us since we don't really have tons of actually transparent models (which is why alpha testing is not too ugly), except the water which is a special case anyway. So I think not sorting our models by distance would be a good optimization. Note that this can be done mostly on a case by case basis, which is nice. It not only speeds up by not actually sorting, but it helps a lot with batching, which makes it faster (I'm not sure to what extent we actually batch rendering though. It can only help but it might be much more noticeable on some systems). Edit: note that we can combine these techniques. To me, trees on gambia river look basically the same with alpha testing, and then not sorting them is logical, and the the rendering is faster. This can be done on a case-by-case basis, I think we ought to look into it strongly. Might want to add a "alpha testing" option in materials instead of alpha blending, which would prevent models from being distance sorted. That could seriously speed up maps with lots of trees. NB: I'm assuming transparent models are sorted by distance. I'm not 100% sure we actually do that. Edit: if trees use model_transparent, he we do.

Historic Bruno, mythos and zoot are right. Basically to improve on this would be a lot less efficient: we'd need te water manager to know about all the floating objects, and then either update the mesh real time, or use some sort of hack to store in a texture that water should not be rendered. There are ways to do that, but I think they would pretty much all be inefficient on slower systems, which means boats would look ugly on those, which means I think they should be avoided. Basically the fix is to have boats with a slightly upscaled height, so that the can both appear floating and look nice. Works fine for the others. Edit: we could do it easily f we rendered every boat twice, though.