Jump to content

Crynux

Community Members
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    1

Crynux last won the day on May 21

Crynux had the most liked content!

Community Reputation

19 Good

About Crynux

  • Rank
    Discens

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Interests
    Programming, Software Development, Performance

Recent Profile Visitors

82 profile views
  1. Hello! Thank you for the detailed response. I understand the concerns with an abstraction possibly introducing slowdown, but I do think if done right that slowdown could be minimal to none. Rather than creating an abstraction that forces Vulkan, OpenGL, or whatever else, to conform to it. It'd be best to create the abstraction "conforming" to our 2 or so favorable APIs. So, for example, It'd be created with Vulkan and OpenGL implementations in mind - minimizing the need to create workarounds in each. Where differences exist, some compromises may need to be made. But I think the benefit would be that even with this OpenGL/Vulkan abstraction, anyone else who comes along and would like to develop an implementation of it for some other graphics api, can then just conform to the abstraction spec - and not have to necessarily deal with how to build it into the game engine. If they satisfy the abstraction, then it should work. Either way, I do think some layer between whatever graphics APIs that will be used, and the engine, is important. For one, if we have a standardized interface, with that interface, unittests or function/feature-based performance benchmarks could be possible. So then technically, it would be possible to create a small separate application, that would for example, test one of the implementations in areas such as - rendering 500 units. Or testing the FPS impacts of effects. With these benchmarks you could actually see were each API struggles. In addition, it may provide an opportunity to add some kind of option to the game graphics menu, where it could choose the 'optimal api' for your machine, based on a series of small real-time performance tests (even if just a FPS comparison of a minute or to of each running a similar complex scene). Almost like a benchmark that determines your graphics settings. But with that being said, I do agree that 1a or 1b would be best. Relying on a 3rd party has more risks, even if it may be 'easier' (although sometimes it isn't, because then there's learning that 3rd party api). I also agree that an initial refactor would help greatly. As you say, if we get all the GL code in one spot - then that'll make replacing it simpler. Thanks! -Crynux
  2. Yeah that's fair - "a bit more work", is more like "a lot more work" ... either way though, I think it could be done in steps. The first being making it an abstraction, then once we have a 'concrete' interface or whatever, other implementations would be simpler, as there'd be a better idea of what we need to create. With that being said, there'd need to be some thought into the inputs and outputs of the renderer to some degree (thinking somewhat abstractly here), like building some standard for objects to be passed to the Renderer. That way no matter the implementation - we can provide the same thing and it should be happy. My initial idea was that the renderer implementations could be their own separate thing eventually (maybe thinking too far ahead here). Having for example 'opengl_renderer.so' or 'vulkan_renderer.so', maybe with some version numbers in there as needed. Then the engine could look for the shared objects/dlls/whatever mac uses somehow and load them as-needed, providing a renderer option in the settings (possibly?). I've seen this in other games before... not sure how it was done though... but it's possible lol. I'm always aware of dependencies ... tbh even not knowing too much about the rendering code here, I think we have a really good base. It'd be a waste in my opinion to move away from it. From how it sounds, it just needs a little TLC. Interesting ... I may have to send a message, thanks for the heads-up! Thanks again! Crynux
  3. Hmmm yeah that's true, instancing would help it seems in a lot of cases. I was just thinking that in the meantime, if we could reduce anything to increase render speed, it would help. On that note (models), are there any kind of stats on how many triangles we have per model 'class'? Like is there an average polygon or triangle count for 'normal' units like slingers, or one for 'houses', 'civic-centers', etc? It might be something valuable to have - then we could keep the counts within a certain range based on classification... a 3d resolution for lack of a better term. Yeah lol the case I was looking at specifically were a few archers that just seemed to fling the arrows wherever, they didn't even try... just a pile of arrows on the ground. As for justification - I think it's less the actual decaying, and more the implications of having the decay there. So like, having 230 units, and then killing all 230 units... it's the same amount of polys/tris when alive vs decaying, so there isn't much to be saved there. It's when you have 4 minutes of n units hiding underground, with the next wave of units fighting on top of it - then you get the performance decrease. I guess that could be called replacement rate? The units are replaced faster than they can decay, so it steadily increases unless battle stops entirely ... which usually never happens late game, unless someone gets destroyed. I mean, I like seeing the corpses there ... it makes the game feel more realistic, but I'd rather see no corpses than be playing a slideshow. If anything - I think the idea of having a slider in the Graphics menu or something - to multiply the decay by some factor, manually set the duration, or just disable it entirely, would be of value. On a side note, I just had another thought. Does anyone remember playing older shooters, where you'd shoot a wall for example, and the bullet holes would only 'trail' so far? Maybe we could do something like that - if your unit cap is 200 units, then you should only really be allowed to have 200 or so decaying. Along the same lines, I remember in those shooters as well, when you turned away, and looked back, sometimes the decals on the wall for the bullet holes would disappear. I guess it's a more harsh approach - as you'd only see corpses in-view, but if anything it's a possible (probably not favorable) solution. Thanks again! -Crynux
  4. Hmmm, so there seems to be a bit of an improvement, there's still the usual unit stutter every now and then, but that might be the pathfinding lag. Overall I get a better fps that before it seems, spikes of 100fps, and lower-end values of 40 or so fps in 'populated' areas. I'll have to give it a try tomorrow in an actual game. I haven't taken a look at that mod yet ... I'll do that soon after. On a side note, I noticed in-game there's quite a few arrows on the ground (due to archers and such); so I figured I'd take a look at an arrow mesh to see how many triangles were in it; looking at props/weap_arrow_front.dae in blender, it looks like it has 62 triangles. I'm not a 3d modeling person by any means, but is that high for such a small prop? It just gets me thinking - these slowdowns I'd imagine are a result of the renderer being somewhat outdated, so any triangles we can trim would help. My concern with the arrow is that if you get a good few archers in some area, they can spawn triangles quite quickly. Very interesting. Thanks for the links, skimmed there quickly while writing this response ... but it looks like more justification is needed? Maybe I'll come up with some tests of sorts. Thanks again, Crynux
  5. Interesting, I'll have to give that a try. At the moment I'm testing with the decay rates turned up a bit, and all the same... will see how it performs; large map, 4 AI's, unlimited units.
  6. It does add some degree of lag - mainly in the form of rendering. In my tests, I could be on one side of the map getting 75fps, and on the other where there's a bunch of dead units, I'd get 20fps. So even if pathfinding does contribute to lag in late game, the increased render load due to having to render so many corpses (even when underground?) seems to have a negative effect.
  7. Hi all, so lag has been a topic for a bit. I noticed in my rounds that in the beginning, I usually get around 60fps, with everything maxed. Late game can dip to about 15-20 fps (my most recent game did so; 'normal' map, 2 player vs 2 AI). Anyways, I decided to look into this. First, I went into the scenario editor, and spammed a bunch of houses and units on the map. Opened it up in-game, and there was very little difference. So then, I heard you can 'pit' AI's against each other. So I setup a tiny map, 4 AI's, and let'r rip on 20x. For the most part it was "OK". Then ... I slowed it down, because I noticed the performance dipping. To figure out what was doing this, I zoomed in as far as possible, and moved around the map. I quickly noticed that in the main city-centers of the AI's that weren't attacked, they were getting ~75fps (unlocked). However in the battleground ... it dipped to below 20fps. That made me think - maybe there's something we're not seeing... and that's the unit decay. So after some testing, it looks like the unit decay rate (at least for Slingers [I tested with those units only]) may be too low. The defaults that I can see in the template_unit.xml are as follows: <DelayTime>30.0</DelayTime> <SinkRate>0.01</SinkRate> <SinkAccel>0.0</SinkAccel> In game, a depth is calculated based on some bounding box (I assume unit height? This may be inaccurate as when a unit is 'dead' they're shorter than when standing - not sure if it accounts for that). That number happens to be 3.877156. With that, at a rate of 0.01, and 60fps, it'll take ~3.87 minutes for the unit to decay and be removed (not including the 30 second delay). Taking that into account, for the unit I tested with, to re-create one of them it takes 10 seconds. To create a batch of 5, it takes 30 seconds. So potentially in the time it takes 1 unit to decay, you could have replaced it with 38 - that's if you used only one barracks. With 2+ players and multiple barracks/unit types ... this can become a problem quickly. So my thinking is - in late game, part of the lag is due to all of these 'decaying' units all over the ground, which seems to only increase as time passes. Anyways, is there a reason for such a long decay time? I'm thinking to speed things up - it'd be good to either increase the SinkAccel value, or increase the SinkRate in general. Another option would be to have some code that could dynamically increase the SinkAccel or SinkRate values based on how many units are on the field. On a side note, it may be useful to have a setting in the UI as well, since if it does slow so much as I've seen - then it'd be good to turn it off in some cases, or at least have a manual throttle for it. Thoughts? Thanks in advance, Crynux
  8. Hmmm interesting, thanks for the video link, etc. On the topic of graphics - I did a quick search thru the code for basically gl_ , and there were quite a few hits in many files. There were a ton in Renderer.cpp (as expected), but also a good few elsewhere. With that in mind, looking at Renderer.cpp, there's a lot of direct OpenGL calls; this makes me thing that maybe a first step in 'resolving' the issue of updating the renderer, would be to abstract it. Instead of having the current OpenGL calls directly in Renderer.cpp and friends, the Renderer should be an abstraction or interface, that is then implemented in OpenGL, Vulkan, or whatever else. The benefit to this - is that we'd have one 'set' of functions/calls that we'd have to satisfy whenever it came to supporting a new API. So for example, the existing code could be reworked into a Renderer interface (IRenderer, following the same convention as everything else [tbh I'm just assuming the I there means interface ... please let me know if otherwise]). Then the current OpenGL code could be implemented as OpenGLRenderer or something, and whatever else in their own implementation. The benefits of doing it this way would be: Requirements for the Renderer (thru the interface) would be clear. OpenGL, Vulkan, and whatever else code would be contained in a single location. In theory we could package it so that Renderers are easily changeable. We still have control over the rendering part of the engine. Downsides would be: It's a good bit of work With that in mind, I do see the value in using some other third party rendering stuff - but I think for every third-party dependency added, it provides opportunity for the project to be stuck with no alternative. Say we pick up some library to use for rendering, if that is no longer maintained, then we'd either have to find another, or maintain it ourselves. Which really, only brings us back to the same position. So in my view, I think keeping as much as possible within the project is best - even if a bit more work. Plus we already have a working renderer - even if a little outdated technology-wise. Those are my thoughts anyway... open to counter-arguments/agreements! Thanks, -Crynux
  9. Hello! Thank you for the detailed overview! After digging a bit thru the code today, I did notice the hierarchical pathfinder, and wondered a bit about its use; your post clears that up a bit! I haven't looked much at the AI stuff yet ... but since I'm already into the pathing, maybe I'll stick with that for a bit. I did notice some issue where units would continually try to go somewhere when they can't (for example, having a large group of workers go to an area without formation). They'll just continually pace around trying different angles to get there. I have some ideas on how to fix this ... just haven't gotten to it yet, since I've been working on / getting familiar with path-finding in relation to the extended corner idea. With that, I do recognize those concerns there, more vertices would slow it down, but it maybe a case where having those few extras are better - since if a 'successful' path can be found faster, then overall there 'may' be less computation. That bug you mention seems like it's the same thing I noticed (where they can't get somewhere, but keep trying). Maybe I'll give that a shot next. Aside from that, the OpenGL instancing thing mentioned ... is that just with regard to supporting older versions rather than updating?
  10. Ah, ok cool! I started playing around with VertexPathfinder.cpp ... and came up with this: It's a little modified from the concept above, just extending the corners out, and adding those as extra vertices to be considered in pathfinding. The result, seems to be that units can get to their target a little faster, and actually seem to have access to more sides (that last lady there got a little confused, given she was on the other side of the building to begin with, that's ok I guess... but overall the rest were better I think). I might play around with these changes a little more ... just to see how it affects a long-term game. But from what I can see it looks to be some sort of improvement! What do you guys/gals think? EDIT: I changed how the new points are created, basing it off of the existing buffer based on unit clearance, and a constant. Also created a Diff for it (hopefully it's created decently well) https://code.wildfiregames.com/D1911. Thanks again, Crynux
  11. Hmmm, thanks to everyone for the posts/pointers! I started poking the code, seeing what I can observe that 'may' contribute to slowdown. At first I enabled some code to draw paths - these are commented out by default, so I just commented them and enabled the overlay. From there, I started testing moving units around, and started playing with some 'usual' cases. What I found is that if you have a good few units tasked to an area (say 20 or so workers), and a building is parallel (with respect to it's bounding polygon thing [the blue lines on the overlay]), in some cases you'll get a "unit bounce", where they'll continually bounce around, looking for paths, since there's never a space within the 4 points available (the right two corners of the stone grid polygon, and the left two corners of the storehouse grid polygon). This can be seen here: By contrast if you rotate the building 90 degrees (excuse the rubble, had to try a second time since the first angle wasn't great), the points now being outside of the vertical (relatively) min/max of the right points of the stone, helps the units resolve their paths more quickly, since they can now access the bottom and top sides of the stone. As seen here: This may not cover every case of unit pathing ... but in cases where you get a good few units tasked to an area, and they just happen to line up, I could see how this could cause some slowdown. (sorry if the video too blurry... I made them small clips, and I'm not sure how to make them use their original size on here). With that in mind, I'm thinking a solution to this would be to add some "satellite points" of which the pathfinder could use to resolve the paths more easily around corners; maybe something like this (orange areas are where units would be expected to 'bounce' if no other point of path finding was available): Not sure how 'possible' that would be ... well, I guess anything is possible. But I'm not sure how well that would fit into the existing setup. Just an idea anyways. Thoughts on this? Thanks, Crynux
  12. Thanks for the replies! I just read into 5422, interesting problem there. I haven't looked into the GUI code yet, besides just looking at the session.xml... but, am I correct in the assumption that there isn't any kind of 'caching', or 'GUI State'? My initial thoughts would be that a GUI would be built using layers. So for example, all the panel backgrounds would be one layer - then other objects (buttons, text, etc) could be rendered on top of that. A jump from 3500 calls to 12000 is quite a few. On a side note - maybe the GUI is best done on a separate thread? I read elsewhere that the simulation is supposed to be deterministic ... but the GUI can act in response to the simulation. So instead of having it lag everything when there's a selection, it could just have a 'Update' message (for lack of a better term) posted to it, making it update independently of everything else. Tooltips (in my very non-familiar-limited view), could be on a separate layer, since they seem to be the most 'dynamic' of the GUI renderings. So for example in a unit selection, you draw all the UI bits once, save the result to a buffer somewhere, where on each tick that buffer is drawn to screen, and the tooltop layer could be rendered on top of that, without having to redo the whole thing. So the result would be: Background layer; containing any panel backgrounds Display layer; containing buttons, text, etc Tooltop layer; containing only the tooltop Again, I apologize if this is all obvious (or already done), I'm just kind-of thinking out-loud here. One last thought -- is there a reason for using OpenGL to render the 2d GUI? My thought would be that something geared toward 2d rendering may be a better solution; like using Cairo or something for offscreen GUI rendering, and then OpenGL could just take the result and plop it in-view. Thanks!
  13. Hello! Thank you for the response! I had seen your post there, I hadn't looked at it closely as I was mainly focused on the AI at the time, however I'll take a look there as well.
  14. Every time I go to upgrade these, I click the wrong icon because the stone looks like metal, and the metal icon looks like the stone icon. Perhaps these are mismatched? Just thought I'd make a post, in case it's not actually supposed to be this way; Playing as Ptolemies, not sure if that makes a difference. (you can't see the cursor, but on the top one, I'm hovering the 3rd icon, and on the bottom image, the 2nd icon.
  15. Hello! I recently started playing 0AD again, and I must say, it's looking good! One thing I noticed is that during game-play, in the late game, everything slows down (2 humans vs 2ai; 300 pop cap). I haven't looked at any performance metrics yet (I may here in my next game), but I'm interested in looking into and possibly working on some stuff to help speed this up. From what I've gathered, there are 2 issues (please correct me if I'm wrong): 1. The Renderer is somewhat bound by simulation. 2. In late game specifically, the AI is the main slowdown; partly due to pathfinding, and use of a single thread. With that in mind, I've looked thru some of the code, specifically the code here : https://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/components/CCmpAIManager.cpp It looks like it has been partly setup to use threads, but doesn't yet? I've also read that there's some concept of moving some of the AI related JS code to C++. Anyways (I apologize if this seems a little scattered), I was wondering what the current plan is for this. I noticed there are a few performance related tickets open, and some have been worked on. Really, I'm just looking for maybe some clarification of where to go from here (specifically, if there are known problem-areas, I'd like to be aware of them before-hand, knowledge sharing on these things is important). I have some time that I could dedicate to this ... and I'm very interested in performance improvements. On a side note, with conversion of some of the JS ai code to C++, has any design or some other outline of what 'needs' to be in JS vs C++ been outlined? I think it'd be valuable to set some rules or guidelines as to how much should be available in JS. To be honest, I don't have very much experience with AI programming, but at a glance, I believe any of the heavier computations should be strictly implemented in C++. An AI should really only contain decision logic... (I haven't looked thru the Petra code yet so if this is already the case, that's awesome!). I think that's it for now. I really appreciate any pointers on this, or clarification. If anything above is dumb or obvious, please point it out ... I really only started looking into this in the past few hours ... but figured it may be worth-while to make a post, in case there's some info out there that I'm missing. Thanks in advance! Crynux
×
×
  • Create New...