Leaderboard

You should really try playing the game

Trying to define the structures direction with the first concepts like we did with mauryan ones and gather some feedback. These are WIP concept structures, nothing is finished or final. First some CC concepts: And these are the old ones, which I think the only one that could be used is the fortress concept (temple would be probably greek) Non-fancy structures concepts coming soon. I would like to base some of them in LordGood concepts, he made several good ones in a screenshot somewhere in the forum.

Hey guys, haven't been active for a few years, but I've been tweaking around with the pyrogenesis source lately and made some performance improvements: Removed CFixed<> and replaced it with float. All fixed::IsZero checks replaced with ::IsEpsilon(float). This accounts for float imprecision in some cases and removes thousands of conversions from CFixed -> float and float -> CFixed. Improves overall performance by ~20%. Replaced boost::unordered_map<key, value> with std::unordered_map<key, value>. Implemented std::hash<> for the required keys. This gave only a small performance increase of ~5%, but it was worth the shot, since unordered_map is a part of the C++ standard. Most notably, the bad performance was due to unimplemented hash functors (!) . Right now performance can be further improved if all std::map<> instances have a proper hash method implemented. As it turns out however, most of these maps can be removed overall. Result: before 37fps, after 48fps on my i7-720QM and Radeon HD5650 laptop. It took some 250 files to modify and some minor redesign of the math library, but the benefit was worth it: faster game, more maintainable code. Right now the engine has a lot of inefficiencies that are mostly caused by naive implementations: 1. Inefficient Renderer: Problem: Currently the rendering system constructs a sorted map of models and their shaders Every Frame. Not only is this bad that such a large map and vector is created every frame, it could be redesigned to achieve the same effect with no maps or vectors recreated. Solution: the models can be sorted beforehand, during context initialization (!) and grouped under specified shaders and materials. Result: This should give a huge (I'm not kidding) performance boost, so this will be the next thing I'll implement. 2. Entity/Actor/Prop XMLs: Problem: Not only is XML inefficient to parse, it's also much harder to actually read and edit. To make it worse, the filesystem overhead for these hundreds of files is huge (!). Loading times for weaker filesystems can be very long. Solution: use a simplified text parser for entity/actor/prop parsing to increase speed. Group common actors/entities into single text files (e.g. - units_athenian.txt) while still retaining the 'modability' of the game. All current data can be easily converted from XML to the desired (custom) format. Result: Loading times and memory usage will decrease dramatically (which is a pretty awesome thing I might add). 3. String Translation: Problem: It would seem as if this had no effect for performance or memory, but you should think again. Creating a translation (multilingual) system offers us a cheap ability to group all the strings together into a huge memory block. Solution: Load game/unit strings into a large memory block and simply share out const pointers to the strings. Something like this: "unit_javelinist\0Generic Peltast\0unit_javelinist_descr\0Peltasts are light infantry...\0". Result: Every heap allocation costs some memory for the system heap bookkeeping and on Win32 platform it's around ~24 bytes. If you have 1000 strings of size 24, that will add up to 24KB and totaling at 48KB used. With the translation system this would remain ~24KB. Of course, there are much more strings in the game, so the result would be noticeable. 4. Entity-Component System is inefficient: Problem: While some would say its having a map<int, map<int, *>> shouldn't have any real effect on performance (since the profiler(?) says so), I would recommend to reconsider and rethink the algorithm of the entire system. Maps are very memory intensive and too many vectors are created/destroyed constantly while the look-up of Components remains slow. Solution: Give the good old ECS pattern a slight Object-Oriented overhaul. Create an IEntity interface, give concrete implementations like UnitEntity : IEntity a strong reference to a Component in its class definition. This will remove the need for component look-up. The message system can also be redesigned to be more direct. And finally, Managers can be divided into frame slots across frames, since a lot of the data can be asynchronous. Result: This will give a huge overhaul and streamline the simulation engine; making it more maintainable, easier to program and much much faster and memory efficient. 5. Naive Pathfinder: Problem: The current implementation runs a very time consuming algorithm over the entire span of the region, making it very inefficient. Solution: Redesign the pathfinder to include a long-distance inaccurate path and a short-distance accurate path. The accurate path is only updated incrementally and for very short distances, making this method suitable for an RTS. Result: A huge performance improvement for moving units. 6. Naive Collision/Range/Obstruction detection: Problem: Currently a very naive subdivision scheme is used for collision, range and obstruction. Even worse is that all of these modules are decoupled, duplicating a lot of data and wasting time on multiple updates of the same kind. Solution: A proper Quadtree embedded into the Entity Component System would help keep track of all the entities in a single place (!) and the Quadtree structure itself would make ANY(!) range testing trivial and very fast. Result: Performance would increase by at least 10 times for the Collision/Range/Obstruction detection components. 7. AI is a script: Problem: I can't begin to describe my bafflement when I saw UnitAI.js. AI is something that should be streamlined into the engine as a decoupled yet maintainable module - a component of ECS, yet in a little world of its own. Solution: Translate UnitAI to C++ and redesign it. In a FSM case (such as UnitAI.js), the controller pattern would be used to decouple actions from the FSM logic and make it maintainable. Result: AI performance would increase drastically and an overhauled system wouldbe far more maintainable in the future, leaving room for improvements. -------------------------------------------------------------------------------------------------------------------- This is not exactly a duplicate of the old Performance Optimisations thread - I've made these observations and conclusions based on the current source and my past experience as a C++ developer. Furthermore, the reason why I'm bringing out all these problems, is because I intend to solve all of them and I also have the required time and skills to do it. Michael as the Project Leader has invited me to take up as a full-time developer for 0AD after my mandatory service in the Defense Forces finishes in May, so right now I'll be focusing on small changes and getting fully acquainted with the source. As for me, my name is Jorma Rebane, I'm a 22 year old Software Developer of real-time systems. My weapon of choice is C++, though often C and assembler is required. I've worked with several proprietary and open-source 3D engines in past projects as a graphics and gui programmer, so I'm very comfortable around DirectX and OpenGL. ----- Hopefully these points will bring out a constructive discussion regarding 0AD performance and improvements. Cheers!

Sorry to stray off topic, but perhaps this should be put in a different sub-forum like off-topic discussions. It isn't really a whole lot about in game material and would be more appropriate I think.

That's not what CStrIntern is for - it's just for fast string comparisons and copies, since string equality is simply pointer equality. In particular it's for cases where you might expect to use enums, but you want to let data files define new values too and don't want the hassle of maintaining some centralised definition of every possible value, so you use strings and convert them at load-time into some unique identifier (which happens to point to the character data). Memory usage is not a concern at all, since it's only used for a few short strings. (It should certainly never be used for UI text.) (But I think quite a bit of the code is silly in that it converts a string literal into a CStrIntern many times per frame, which isn't cheap - the CStrInterns ought to be constructed once and cached in the appropriate places, and then there should be no extra runtime cost compared to enums. So that'd be nice to fix. And with that fixed, we should never look at the contents of the strings at runtime, so they're not going to be pulled into cache.) The game's current network architecture is client-server: every player sends their list of commands to the server, and the server sends those commands back to every player, then the server tells each player when it's safe to start the next turn. (The server doesn't know anything about the simulation state - it's just blindly forwarding packets and counting turns). So if nobody is doing anything, each client will just receive one packet from the server per turn, and the server will just send one per player per turn.

I'd like to be able to turn all graphically irritating and distracting stuff off to get the most possible space for information and interactive UI. Don't get me wrong, I like the style! But for me this projects value is the game and it's usability. Focusing more on graphics means focusing less on playability and usability.

I don't think you understand why this topic was locked in the first place... but, besides that, this a very good example of biased opinion! Let the others decide who the barbarian is amongst us. Anyway, call me a barbarian if you wish. I'll gladly be one, if the credit for building the Gothic Cathedrals came to me

Er... did you just say you're great and thus people hate you? Not to mention insulting Amish at the same time. At least your derogatory isn't undercurrent, it's right out there in the open.... Anyway, I'd say the most influential civilization was Israel. They affected the histories of the Egyptians, Persians, and Seleucids, as well as being a great nation of their own for a while. But probably the most important part was that Judaism is the basis of Christianity (Jesus was Jewish, after all). Christian monks preserved knowledge during the (not quite so) "Dark Ages", Christian scientists like Newton and Pascal discovered all sorts of interesting things (motivated by trying to understand the world from a theistic worldview), and currently it's the most popular religion in the world (although that doesn't really mean much). Just my 2¢. I'm not a historian by any means.

I was curious about this. Actually, the code of the pathfinder points to the "points of visibility" article in GPG. As I had that lying around I had a look, and the article specifically says that POV is a reasonable choice if you have 3D with few dynamic obstacles. For RTS it suggests a rectangular Grid approach. I think its also meant to have the edges precomputed instead of on the fly? If I look at the code, seeing edges between passability classes, edges between obstruction squares, a sort for every open vertex etc. I'm wondering if this is actually much faster than simply searching the squares with heuristic directly?

I haven't prepared anything that's worthy of a progress update, however here's a small over-the-top graphic made for fun -

Yes, though MyGUI for Ogre3D is a very good implementation and I doubt we should use our own. Those folders would probably disappear entirely, replaced by Ogre3D. Ogre3D has a collada plugin. So no changes there. Yes, this is the main part where the integration would occur. This is the brigdge between modules: [simulation] <-> [ps engine] <-> [ps graphics]. Luckily it means that graphics can be replaced with changes to [ps engine]. Ogre3D has a very mature maths library. I already replaced the ps maths vectors with: Vector2, Vector3 and Vector4 (had to roll my custom implementations). But Ogre3D has a much more mature version with maths for interpolation and optimized ray intersection. Now that is cool. I think you are right. A lot of these arguments should put into a list, describing the benefits and amount of code required to change. I'll get right at it.

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.