Jump to content

Mercury

Community Members
  • Posts

    9
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mercury's Achievements

Tiro

Tiro (1/14)

3

Reputation

  1. Is there something wrong with the windows build pipeline? It's saying the diff failed unit tests but the error is : E:\Jenkins\workspace\vs2015-differential\cxxtest_debug.xml was length 0
  2. Hi Stan Reduction in the sum of the 'total' metric for a replay when comparing two sets of 10 runs, each set being averaged. Profile data and commands.txt are attached to the diff.
  3. @wraitiiThanks for all that info! I made a patch based on your suggestions about memory layout and iteration. 12.3% improvement in my testing. https://code.wildfiregames.com/D4718
  4. @Stan`We will need it eventually: the World of 0AD MMO is gonna be Webscaletm!
  5. @smiley@wraitii Thanks for those links. Reading through those threads gave me the impression that this was abandoned due to memory 'leaking' because of temporary entities. But maybe temporary entities aren't really a problem? An empty vector in 32 bit is only 16 bytes. 1,000,000 entities would be 16MB. If a game had 10,000 units spawned and every unit averaged 100 projectiles in it's lifetime the cost is 16mb. That seems safe.
  6. @wraitiiDefinitely related optimizations but ultimately I think they are parallel. This data structure proposal is agnostic about actual storage location, but providing an iterator yielding a series of sequential pointers should be quite fast. Maybe this stuff should be grouped together in a ComponentDataManager class which is responsible for both allocator and pointer look-up data structures? It could have an interface like addComponentToEntitiy, removeComponentFromEntitiy, componentsByType, componenetsByInterface, componentByEntityAndInterface, etc. Just my personal bias against long files, feel free to ignore
  7. @nani~~entitiy_id_t is used as the index of the vector in the second case.~~ Disregard that, I was thinking of the first case. in the second case entity id would have to be stored in the linked list i guess. So a custom linked list instead of std:list? Or a tuple holding entity IID and *IComponent? Hmm, but in that case there is no performance gain to be had vs. std:map. Maybe Ill just try m_ComponentsByEntity then and leave m_ComponentsByInterface alone. Maybe entity_id could be added to IComponent?
  8. I have been thinking lately about how to optimize the component manager system. I have an idea that seems worth trying and wanted to get any feedback possible from people who are more familiar with the code base then I am. std::vector<std::unordered_map<entity_id_t, IComponent*> > m_ComponentsByInterface; // indexed by InterfaceId This data structure seems to be doing two things at once, and because of that could be optimized more. This structure serves two logic paths which seem to me are pretty hot: QueryInterface and getEntitiesWithInterface/getEntitiesWithInterfaceUnordered. (These are all functions within ComponentManager.cpp). if we create a new data structure like: std::vector<std::vector<iComponent*>> m_ComponenentsByEntity; //entity(outer) and component(inner) indexed by InterfaceID to serve QueryInterface we could remove the relatively expensive std::map.find call it contains and replace with fast vector de-reference. getEntitiesWithInterface could continue to use the existing data structure or the std::map could become a std::list. This would give marginal performance gains but also allow the minor logical gain of replacing calls to getEntitiesWithInterfaceUnordered with getEntitiesWithInterface, since the insertion order is preserved automatically. Also some significant performance gain for the ordered variety, but I think that one isn't used much anyway? There is some minimal cost when units are created and a more significant cost when units die. Still it seems very much worth it. Also some RAM cost, pretty negligible. Maybe 17mb per 1000 units in a worst case scenario with 256 components? After doing this maybe an experiment with using a naked array of component pointers in m_ComponentsByEntity to save the vector overhead is worth trying as a further upgrade. Thank you for your time reading this and for any feedback you might have.
  9. Hello, this is my first post here. I have been poking around in the relevant bits of code. Have not found a fix yet. I did find out however that this bug is not specific to water units but rather to units which die in the water and have blood. I saw the same behavior by killing infantry and cavalry on the beach at the surf line in Corinthian Isthmus. https://imgur.com/a/rbzfMwF I did not see the behavior killing a battering ram. In a25 blood is drawn under the water for land units. No blood that I can see for whales / fishing boats etc. In a26 blood is drawn at the water level height, this seems to be the origin of the regression. One problem I am having is understanding the conventions of the C++ side. Can anyone tell me how to find where AddEntity is defined? I tried interacting with Engine.AddEntity through the in game console. Engine exists in that environment but AddEntity does not. Any solutions? Hopefully these notes help point someone in the right direction.
×
×
  • Create New...