Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. It's even worse if you have bad archers as all the projectiles will remain on the ground if they "miss" their (or a) target. Yes! iirc they did that before alpha23 release so it was a bit done on the fire.
  3. With things like arrows, I think triangles are a lesser concern than draw calls. 60 polygons is nothing in 2019, but 60 draw calls is something. Reducing the # of polygons would help, possibly after instancing of some kind, but it won't fundamentally speed things up right now imo.
  4. I think that is exactly what @vladislavbelov is planning. Maybe he can need some help?
  5. 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
  6. @Crynux: see https://code.wildfiregames.com/rP21732 (I didn't find the related diff proposal) https://code.wildfiregames.com/rP21783 (see https://code.wildfiregames.com/D1467 for the work before)
  7. Those are definitely the pros and con... "Bit more work" is I feel a bit of an understatement though. Modern graphics are complex affairs, and we already don't have much workforce. I don't think we can make an AAA level RTS graphics engine - and that's kinda what we're talking about here. The dependency problem is a big issue because most "probably won't fail" projects have grown a bit too big. Things like godot or Ogre are complete and modern, but we can't really easily adapt our current code to them. Smaller projects have a more uncertain future, or don't support all of our three platforms, and such. Regardless, the renderer abstraction is probably something we'll need to do anyways, so it's a good first step.
  8. 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.
  9. Today
  10. @Crynux There is no real justification for the number itself. The only part where it may be important is to know there has been a battle. To see potentially which of your enemies is the weakest. One of the reason of the lag might be the blood decals which alpha transparency which will have a performance hit. To test that theory just download the no blood mod.
  11. 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.
  12. Also apparently a lot of players are playing with GLSL off to improve stability and FPS. But yeah some work could be done as @(-_-) says to just tweak values on maps. I don't if we can do in RMG. I guess there is no reason one wouldn't be able to.
  13. I haven't played AoE 2 that much so maybe a screenshot would help. However my answer is probably not gonna change. There is currently no mod that changes the interface to be that of AoE 2 but I'm sure someone with a little patience could do it.
  14. Interesting analysis , but I really doubt lag comes from decaying dead units. It's most likely that it's pathfinding. Late game has tons of units, so pathfinding calculations grow exponentially.
  15. 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
  16. Hey, I’m a new player but I used to play Age of Empires 2... Can anyone tell me that 0 A.D. has any mod which contain in-game score system as in AoE2? I would realy apriciate any help.
  17. Just a concept for a Macedonian officer. This could be used by mods who use banner carriers and offcers since I could not find a suitable unit in the game which could use it
  18. Yesterday
  19. why? i just wanted to spec @Pudim
  20. 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
  21. fair but when I'm not productive I don't get that sweet sweet dopamine
  22. Well, most of the maps are created with the assumption that post-processing or environmental settings such as sun elevation, sun color etc do not exist.
  23. Looks like a very nice tool indeed. Don't hesitate to add it on the wiki! The bottom of the EngineProfiling page is probably the best place for it.
  1. Load more activity
×
×
  • Create New...