wraitii

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.

Not sure what you mean, but I don't think it's related. Basically what I suggest here is making rough approximations when rendering trees because it doesn't really matter what order they're rendered in, despite being transparent. Thoug TBH I'm not sure to what extent we actually batch anything and if rendering is really optimized. In particular I'm not sure the profiler draw calls are accurate.

Let me introduce this topic by stating that 0 ad's rendering is also fairly slow, right now. A big part of that is trees: since the use transparent materials, they are currently distance-sorted (a usual technique to avoid blending artifacts). However this makes batch sorting basically impossible. Now, I've done some tastings and it seems to me that alpha on trees is basically used mostly as a "1-bit" method: either transparent or opaque. With such a technique, distance sorting is formally not too necessary, so we could speed up rendering a lot by having not all materials sort by distance, particulalrly with trees. On Gambia river, I basically get it to render twice as fast 180 to 100 ms for "Render" in the profiler. Its my MB air which is slow, and I lowered the camera to have lots of trees. But still. So basically I'm saying we should probably experiment with this, we might get a really really similar rendering for basically a much lower cost. By not distance-sorting trees, we could batch them much more efficiently. (if you want to see for yourself, go to line 482 of modelrenderer.cpp and add " && 0 " to the if statement, then recompile)

Works pretty great, I must say. Obviously the buttons would need a rework too but I guess that's part of the WIP I really like the marble aspect of the background, though I think making it slightly less white, combined with making windows slightly less black would be easier on the eyes. I find the bottom bar to be a bit too prominent, particularly on small windows. Still, solid work!

Still, I'm not too sure about completely inverting the color scheme. But if everything gets reworked.

That's something I always was interested in in RTS, because allowing units with 1 HP to perform like a fresh one basically means that it's better to aim all your units on one enemy than spread the shots, thus favoring micro players. I've always felt it was perhaps a little gamey, as a mechanic. This should be reasonably easy to mod in, if you want to give it a try. Something like attack * ( (HP/max HP)/2 + .5) could work. It does seem like it would favor healing, and it would tie in nicely with how formations will probably work. Perhaps units in the case of formations would either use their health or the formation average health (depending on which is higher), thus giving another bonus to using formations.

I'm a little bored this afternoon (exams start tomorrow so I'm resting ). Did some sort of a fishing ship. I'm leaving the .blend in case it's a good direction. (the un-decimated mesh is 1000 tris, decimated is 600, there's a version on layer 3 where subsurf has not been applied that's 250 tris.) Untextured. Default unwrap, probably bad. If it's a good direction, I can probably work on it a little this week. (it's been a while since I last used Blender…) Egyptian fishing boat.blend.zip

It would probably imply changing the rest of the game's look too, though, so it fits. Aiming for an off-white/cream color could work.

About work: a method I've found fairly efficient to start working efficiently is doing 30 minutes of something, 5 minute break, rinse, repeat until it's over. Working for school takes willpower, it's boring, no-one really wants to do it. And willpower is fairly limited, particularly if you don't have the habit of working. Don't start too big. Learn to only work efficiently, by focusing 100% on what you do. Then you'll slowly be able to do more and more. But I stress this, taking breaks are very important. Not too long, but often enough so that you don't fall into a spiral of inefficient "lemme check Facebook every second" work phase. Find at what time you find working easiest, and then begin planning your work for the day. It sorts itself out. What Ludo say is very true. But I find you don't even really have to like what you work on. The simple satisfaction of having worked "right" and knowing the material can compensate a little for doing things you dislike.

I agree with that. Those are default modes, interesting but not requiring complete change of the game. More fancy modes would be fun (a PVE builder mode for example could be really interesting) but that'll be for later.

I believe this is the same error as the one you've already posted. If I recall correctly historic_bruno is giving a look at AI serialization right now, I'm not too sure, though.

I think [13357] counts as a minor gameplay improvement: ability to garrison in your allies' buildings.

The diff is pretty huge, which is kind of surprising (in the former case too). You seem to imply this always happened on Alpine Lakes 2v2? Have you tried a specific seed or does it simply always happen?

Yeah. That worked fine.