Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. 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.
  3. @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.
  4. 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.
  5. 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.
  6. 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.
  7. Today
  8. 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.
  9. 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
  10. 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.
  11. 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
  12. Yesterday
  13. why? i just wanted to spec @Pudim
  14. 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
  15. fair but when I'm not productive I don't get that sweet sweet dopamine
  16. 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.
  17. 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.
  18. Thanks. I had been looking for something similar.
  19. I did indeed try RenderDoc first, The OpenGL context wasn't created in the way it expected, so I poked around trying to find something similar to a GLFW start function I could modify. I thought I could just pretend the game was OGL3 compatibility profile and trick RenderDoc, but I failed. Also just to be clear: We I write '$number calls' I don't mean only drawcalls, I'm including all OpenGL functions in there.
  20. It's a good tool. I'm using it for a while. But it still misses some good features from RenderDoc, which doesn't support our GL unfortunately. We mostly use 1 draw call per each GUI element. It'd be good to refactor it and to use only 1-2 draw call per all GUI.
  21. I used a tool called ApiTrace (https://github.com/apitrace/apitrace). If you're using Linux, your distro might have a package for it. What takes about ~3500 calls is the GUI when the game hasn't started (the lobby, main menu, settings screen, etc), so I misremembered. Acropolis Bay (2) map needs about ~14500 calls (before any user input of any kind, so default camera, units and GUI elements) After selecting a Citizen Soldier (because they have the most complex GUI) calls go up to ~21500 If I disable the GUI, Only about 11500 calls are needed. Frames with a citizen soldier selected in red. Frames with a disabled GUI (Alt + G) in green. The .trace file weights 240MB, I can upload it somewhere if you want to have a look at this specific file. There is also this: https://trac.wildfiregames.com/attachment/ticket/5422/out.svg It is a interactive flamegraph, but trac's preview isn't interactive at all. Click 'Download in other formats: Original Format' and then open the local file with an internet browser. After that is done, click elements to zoom in, hover to obtain aditional info.
  1. Load more activity
×
×
  • Create New...