Leaderboard

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

@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.

Meanwhile ...

Can be like a treasure that attacks. Fake treasure like Trojan Horse.

the academy attacking.

Oh okay. Isn't cheating though to know everybody's scores ?

The renderer isn't bad, it's actually fairly well designed (except for the GUI). It's just quite coupled with OGL2, which isn't the best coupling for 2019 . Also agreed pithing pinging Vlad' on this, he's probably more knowledgeable than I am about the renderer.

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.

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.

@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)

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.

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

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.

Mimic

It would be a good unit

Hi @seantenk & welcome to the forums. You could try locating & posting your crash logs (before you start the game again). Most popular tip around here: disable glsl and post proc in the graphics options. hth

Agrianes have been confused by ancient authors as Thracians, so maybe some thracian cape for the basic version could be useful. Moreover, Agrianes are Paeonians, and it seems that Paeonians used some illyrian helmets according to their coins: https://www.cgbfr.com/peonie-royaume-de-peonie-patraos-tetradrachme-sup-ttb-,bgr_469398,a.html So why not a mixture of pilos, thracian and illyrian helmets for the elite version?

not in AoE.

In vanilla you can only see your own summary (and those of allies, if you have any and researched cartography) until you end the game, I believe.

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

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

I think that is exactly what @vladislavbelov is planning. Maybe he can need some help?

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.

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.

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.

i swear we are playing different game

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.

why? i just wanted to spec @Pudim

fair but when I'm not productive I don't get that sweet sweet dopamine

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.

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.

as wraitii said before plus look at this video http://mirroronet.pl/pub/mirrors/video.fosdem.org/2019/K.4.401/0ad_graphics.mp4

Unit Motion is rather subtle to be honest because it ties the actual pathfinders, the unitMotion component and UnitAI together to work. Mostly if we want to keep supporting old versions and new versions we first need to clean up the code to support different renderers, and that's not too easy, and then actually code the new one, which isn't easy either. We don't have a lot of graphics programmer, and it's getting increasingly hard to do graphics correctly. I've been somewhat convinced, for a few years now, that we need to change our strategy of doing most things in-house and just use a rendering engine, but I haven't really found a very satisfactory one so far.

Very nice work ! Add some flags and banners maybe ? Also maybe some props

Little update on development progress.