wraitii

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.

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