Leaderboard

Hi folk from 0.A.D, This is the surpirse: Proudly present the Retexture (Also remesh) of the horses in 0.A.D. Introducing more colors variety and the alpha channel hair for manes and tails done by @Sundiata: The update comes with a video tutorial of modeling and soon sculpting process for how it was done. Also the update comes with another blend file for allow blender users to bake their own horse textures, (including neon green, red orange any color they desire) Blend File: Blend file will be 2.80, but also 2.79 users could benefit from it anexing the objects and making little adjust to the nodes Baking nodes: color is managed in by a simple slider with multiple tones, or just two if desired, The body color is handed such way by the Vertex painting colors, i have defined a body paint with RGB allowing to move by another 3 sliders the way the colors are influenced by such vertex paint. There is already some predefined colors, once it finished. i would share another video of the process of baking but sadly my pc wouldn't resist such thing and could loose it since my AMD 145 enough battles has won from around 7+ years of life, and so it is my Nvidia GT520 wich already loosed his fan around 5 years ago and had to adapt another one. Some preview of the cavalry updated: Horse mesh comes with little updates to adjust more to the quality of animations, this means better knees and shoulders (meshing speaking) for a better transition of bones when rotating or moving (ie: galloping, promoting) Animations remains the same, just trot, walking and galloping were changed to move legs movements more centered as mentioned before. Blankets and body armors seems to adapt better to the new mesh due to the way the vertex are placed, making a smoother view, yet theres still some props to adapt, and more to do: Also including some distintive genetic details (not everything but at least the most noticeable) for horse fauna variation: Lusitano colors Indian Marwari Ears: Persian - Arabian contexture: Celtic breed face shape: Why suddendly horses? because i was working on updates for Mythology A.D. And realized i will need better textures for a fluid transition when making pegasus and sleipnir. Comparisson from a gameplay distance of a cavalry army Hope you all enjoy it.

I've worked on an OpenGL4 renderer that uses more modern features like instancing and bindless textures in 2016. My conclusion was also that the renderer is a bottleneck and it's mainly memory bound. I've even tried Intel VTune Amplifier, but switched back to Perf later. By changing how we pass data to our shaders and reducing the number of draw calls, I was able to reduce that overhead by a lot. Unfortunately my work never got beyond the experimental stage. I've written a small blog in the staff forums. I've copied the two most recent post here, if you're interested (still from 2016). The code from the experimental OGL 4 branch is still around on github: https://github.com/Yves-G/0ad/tree/OGL4 Post10: January – Profiling, profiling and ... profiling: Post 11: 10th of July - Bindless textures and instancing:

Getting closer to being done with the final cinematic and going back to adding in more factions, hurray. Just a few more weeks of relentless animating to go.

.

Thanks @nani! I'll definitely look into using larger test cases - but just for the record, the stated "115 units" is just the size of the army I'm directly controlling/moving. I have other units going about their business back in my city and no idea how many the other faction has running around (I'll have to pause the game in combat and see if I can count just how many Iberian units come rushing out to fend me off when I attack). I suppose I should also mention that earlier (using a different VTune Amplifier result collected under different conditions), I did actually find CCMPPathfinder::ComputeShortPath as a hotspot! The cause of the bottlenecking, according to my analysis, was that this function was bound by branch misprediction. Unfortunately, after looking into the code for some time I was forced to conclude that there was nothing that could be done to mitigate the misprediction rate. I have not yet seen other parts of the path finder become hotspots but I'll try building a new test case on an 8-player map tomorrow. Honestly I was sticking to 2 player so far to allow myself time to actually build up a decent test case - I never said I was good at this game! In other news, I was able to run a tighter analysis (with a sample rate of 0.1ms) on the slow startup portion. In that part, SkinPoint is definitely the main hotspot, followed by BlendBoneMatrices. SkinPoint is 49.9% back end bound, almost entirely core bound. None of that was attributed to the divider, though, so it's just plain port overuse. I'm currently investigating whether it might be possible to vectorize the offending loop, as that can dramatically cut down on the port traffic, but ultimately it comes down to whether the nature of the loop is vector-friendly.

For the sake of keeping track of things, and for easy access by the developers helping me out, I figure I should recap all my findings so far. I started with the code as of February 1st, to which I added some VTune Amplifier ITT API calls to mark frames as well as place user events marking the durations of actual gameplay and the loading screen on the CPU timeline. This was the only initial change made. My designated test case is a save file from a medium sized random Lake map featuring the Romans (myself) versus the Iberians (CPU). My standard test procedure is to select my army of 115 units, march them westward along the southern edge of the lake, and engage the Iberian forces. On filtering down the Microarchitecture Analysis result that I'm currently working from to only the actual gameplay portion, I found three general regions of interest: a slow portion immediately after the loading screen ends, normal gameplay, and a bizarre "gap" where no frames were processed at all. Long version: Short version: I've written the dead section off as a fluke (and I don't think it could be optimized anyway). The slow part at the beginning needs further analysis to see if I can get meaningful data. I've concluded that CModelDef::BlendBoneMatrices and ShaderModelRenderer::Render are the primary functions to investigate. Analysis of Functions: BlendBoneMatrices assessment: Render assessment: Render is more complicated. It's overwhelmingly back-end bound (89.8% of pipeline slots) and almost all of this is memory bound (81.4%). Digging deeper into the numbers it's 74.6% DRAM bound, which essentially means that it's slowed down mainly by missing the last level cache quite often. Even more abstractly, it's not accessing data in an efficient way. It's a fairly long function and it had several hotspots in it. Hotspot #1, line 446 I haven't dived so deeply into the other hotspots of note in this function. So that's pretty much what I've got as of right now.

Here you go: Consonants: β, π, φ, ψ are pronounced b, p, pʰ, ps γ, κ, χ, ξ are pronounced g, k, kʰ, ks, exception: γ before {γ, κ, χ, ξ, μ, ν} is ŋ δ, τ, θ, ζ are pronounced d, t, tʰ, dz/zd (ζ is debated, there are decent arguments for and against both options) σ/ς is s λ, μ, ν, ρ are l, m, n, rʰ Vowels, monophthongs, and diphthongs: α, αι, ᾳ, αυ are a/aː, ai̯, aːi̯, au̯/aːu̯ (yes, αι and ᾳ are different) ε, ει are e, eː η, ῃ, ηυ are ɛː, ɛːi̯, ɛːu̯ ι is i or iː ο, ου, οι are o, oː, oi̯ υ, υι are y/yː, yi̯ ω, ῳ are ɔː, ɔːi̯ Basically, α, ι and υ can be long or short (dictionaries distinguish between ᾱ, ῑ, ῡ and ᾰ, ῐ, ῠ, text editions don't), ε and ο are always short (ει and ου are their long counterparts), η and ω are always long (no short equivalents). Word-initial vowels: ἀ (lenis): no aspiration ἁ (asper): aspiration, i.e. h+vowel Accentuation: ά (acute): rising tone ᾶ (circumflex): rising then falling tone ὰ (grave): falling tone

.

Hello, 0 A.D. community! I'm a Technical Consulting Engineer at Intel Corporation, and I need your help. In short, I'm reaching out to you in the hopes of finding 1-3 developers familiar with the 0 A.D. code base to work with me on optimizing your game using Intel's software analysis tools, specifically Intel® VTune™ Amplifier. While I won't be contributing any patches personally, and do not intend to be a long term developer, you are more than welcome to keep and submit any optimizations we make as part of this project, free of charge. In particular I'm interested in optimizing the functions BlendBoneMatrices, Render, and possibly also SkinPoint. A little bit of background for you. Intel® VTune™ Amplifier is a sampling-based analysis tool used to measure performance and locate/diagnose bottlenecks in code. Unfortunately, Intel has a bit of a deficiency in documentation for using this tool on graphical applications like video games (a problem in and of itself already), which in turn leads to the additional problem of a lack of familiarity with this use case in the employees tasked with supporting the product. Currently I am attempting to remedy the second problem by creating an Intel internal training demo for using Intel® VTune™ Amplifier on video games. In theory it should be simple: find a suitable game, run the analyzer, optimize appropriately, show off the results. After some searching around I settled on 0 A.D. as a good candidate for this purpose, and I've been collecting plenty of data on it (it's also a great excuse to play a really fun RTS at work ). I've been able to identify some bottlenecks worth investigation and I've diagnosed the causes to varying degrees. But this game is a... very big project, and that's where I got stuck. I'm brand new to this code base and while I know (or at least suspect) what needs to be fixed, I don't know how to do it. This is where you come in. With your assistance, I hope to understand how to implement these optimizations, since you know the code much better than I do. Again, you're perfectly welcome to keep whatever optimizations we come up with. While the current goal is to create an internal training demo, ideally I hope to create official public documentation on the Intel Developer Zone website as well, such as a tutorial or video, using 0 A.D. as the example application. Assuming Legal gives me the go-ahead after reviewing the game's licensing conditions, I would be more than happy to give you credit for your assistance (should you request it) in this context as well. Please let me know if you're interested in assisting. I would be happy to provide more detailed information about the bottlenecks I've identified, as well as access to Intel® VTune™ Amplifier, my analysis result files, and the 0 A.D. save file I've been testing on. *I'd like to make it clear that I am acting here as an individual employee of Intel Corporation pursuing a work-related task, but I should certainly not be taken as an official representative of the company as a whole. I am "Alex from Intel", not just "Intel"!

Made a new tech portrait, free to use by core game and/or mods. Topic can be used for folks to post any new tech portraits they make or find (cc0 or cc-by-sa). Trade_Routes (made by me, from 0ad assets) Geometric_Masonry (made by me) Aqueducts (fixed by me to have the standard background) "mace_argyraspides" (combine some 0ad icons) Immortals (from 0 ad concept art) Falcata (made by me) Feminine_Mystique (from 0ad concept art) Diaspora (background fixed by me) Some Elephant tech portraits, from 0ad concept art Mining_Pickax (from 0ad assets) Monumental_Architecture (from 0ad concept art)

It's best to avoid English when approximating sounds, because English orthography is horrible and because English phonology varies greatly between different dialects. The classical pronunciatition of ω is /ɔː/; if you do want English equivalents, I'd say it's the sound as in more or saw (Received Pronunciation), not slow /sloʊ/. Unless otherwise stated, Classical Greek means 4th C BC Attic prose, the language of Lysias, Plato, and Xenophon. There were quite a few sound shifts later in Hellenistic times: α, ᾳ → /a/ ε → /e/ ει, η, ῃ, ι, οι, υ, υι → /i/ ο, ω, ῳ → /o/ ου → /u/ β → /v/ It is important to realize e-psilon, o-micron, u-psilon, and o-mega are modern names; in Classical times they were called εἶ, οὖ, ὖ, and ὦ, respectively (other letters already had their current names); e.g.: [EDIT]: In short, ε was /e/, ει was /eː/, η was /ɛː/, ο was /o/, ου was /oː/, and ω was /ɔː/ in Classical Greek.

Thanks for the feedback. It may well be that the pathfinder occasionally bottlenecks the application under certain circumstances - but so far we've located a few functions that are consistently eating up the CPU time, so focusing optimizations on them is likely to bring better speedup overall. This is especially true since what I've seen from both of the pathfinding functions, they mostly suffer from branch mispredictions, which aren't really something you can optimize in most circumstances. Unfortunately we have only 56% of players who support the GL4+. @Yves Thank you for this gold mine of a post! I'll have to dive into what you've provided. Depending on the amount of work needed to complete your experiment (as I do unfortunately have a deadline for producing training material from this effort), it might be extremely helpful to me, even if it's not necessarily something that can be turned around and merged back into the actual game.

I took your advice and started a very large 8 player map and built up to a population just shy of 300 units. Unfortunately by then several other factions had killed each other off but there were still a sizable number of units from various factions (I know one of my allies had 200+ units from switching perspectives). I then marched a very large force through some trees and buildings and I could actually see the game struggling along at ~5 FPS under the strain of the computations, even without VTune Amplifier running on it. (Also I might have a cavalry obsession) But surprisingly... it doesn't look like the pathfinder is the problem (unless the problematic part of the algorithm is showing up through something else that it's calling - could it have something to do with the std::_Tree activity going on here?). Once again, the biggest identifiable hotspot is BlendBoneMatrices. Render is up there again too. This time I see Bind in the top hotspots as well (it's memory bound). For the record, both the pathfinder functions I see here are listed as being bad-speculation bound, so that would make them rather hard to optimize (a lot of the time branch misprediction is unavoidable).

Reduced a bit, however it always look's better with gpuskinning enabled: Also, color diferentiation between rank is no longer used, now every horse (depending on breed) uses the same color by variants; The variant reduce the amount of lines by also calling two props depending on the color, they will call a color range predefined by another variant with the tail and mane:

@feneur Can you lift the post restriction of @Super_player0AD, please ?

W.W-ptl vs s0loooy0-britons 2019-01-07_0001 WW vs S0loooy0.zip W.W very and good eco and full pop, my pop in the frist attack is low and stop my production for defense,

trying : Magna @#$% laude

Tutorial Videos: Modeling: Sculpting:

.

.

You mention your test case uses 135 units. Usually games are played with a maximum total of 1200 units aprox. (8 players 150 population each). From what I know then the pathfinder becomes the most time consuming task for the CPU. Might be worth looking at it with VTune.

Looks like they fixed the preview! Thanks for taking care of that.

In fact, looking at the structree code, i've the impression it can work only if all civs have the same phase sequence.

I want the Thalamegos!!! Joke aside, if it can help you : THE LOST PALACE: Hellenistic Palace of Alexandria https://www.academia.edu/6703691/THE_LOST_PALACE_Hellenistic_Palace_of_Alexandria_Julia_Gruhot_ARTH_302 reconstruction of the palace area in Alexandria https://www.academia.edu/4662183/reconstruction_of_the_palace_area_in_Alexandria

Hmmm, So you consider this laughable non-sense of an abject quality? Again, seems a bit harsh (especially considering that guy reconstructed the actual city of Ephesus for Nat Geo, not just those two buildings) I'm actually quite enjoying his website http://virtualreconstruction.com/wp/?paged=1 True, the color schemes might not be historically attested, as indicated by the artist himself, but I think those renders look really great, regardless. Historians and most self respecting history enthusiasts know that many details, especially things like color schemes, finishings and props in artist renditions are something to be cautious about. Where this particular artist didn't get the colors exactly right, he made up for in 3 dimensional awesomeness. But I guess that's just my opinion. Don't get me wrong, we should always strive for the highest level of accuracy, colors included. I just don't think artists and even researchers should be derided for not getting every single color exactly perfect. Constructive criticisms are better. Explaining exactly which colors are wrong, and how they should be improved in future iterations is far more valuable for artists. Historical reconstructions including artists renditions are often works in progress, that are revised (or redone), or can serve as inspiration for improvements by future artists as more information becomes available.

@Anaxandridas ho Skandiates Yes, I noticed that they glossed over the lacquer finishing, pun intended... But to say that they are useless and fake is a bit harsh, don't you think? They put an incredible amount of work into it, which I'm yet to see repeated, let alone improved by other teams of experts. I don't think they're too far off, perhaps not a mythical "100%", but nothing a little "varnish" can't fix... I mean, it's nothing like the Spanish Jesus fiasco: It's like making out Outlaw King to be Braveheart. They tried... The final result wasn't too shabby.

.

.

@Anaxandridas ho Skandiates, I do understand where you are coming from, and it's difficult to argue about obscurities. It is in the absence of plentiful literary sources that I turn to the archaeological record. Being most familiar with Ai Khanoum, it is clear from that site that the Greco Bactrians did things differently. Most of the structures in this newly built city have strong Achaemenid features, with Greek finishings. Architecture says a lot about a culture, and purely Greek structures are very rare, which is strange for a capital city (Hellenistic remains at Bactra being too scattered to make any conclusions, but considering it's ancient history and importance to Zoroastrianism, which many of the Greeks embraced, it seems unlikely that this city was totally transformed into a "Greek" city the way Alexandria in Egypt was). This is to be expected considering their geographical context. All the other Hellenistic states were surrounded by other Hellenistic states, or states that were (being) heavily influenced by the Greeks. The Greco-Bactrians were surrounded by powerful non-Greek polities, except for their border with the Seleucid empire, which was a peripheral territory for the Seleucids. Their intense contact with the nomadic Scythians (and other steppe people) as well as Maurya India, both radically different from Greeks, and exceedingly powerful in their own right, as well as probably having to contend with local (tribal) rulers and Iranian elites within their territory meant that political manoeuvrings would have been much more important to maintain stability in a potentially volatile cocktail of cultures. The documented conversion of groups of Greeks to entirely non-Greek religions, their occasional service to Indian rulers and the role that Greeks played in the dissemination of Buddhism is also quite noteworthy. Remember that this is where Alexander the Great himself married Roxana of Bactria, and where Alexander himself sanctioned mixed marriages (unlike the ones at Susa, there is little to go on to say that Macedonian-Bactrian marriages ended in failure). It is hard to imagine that either of these events weren't enduring symbols of the multicultural nature of the Greco Bactrian Kingdom. Neither can it be ignored that the first generation of Bactrian born Greeks in all likelihood already included people of mixed parentage. I'm honestly not trying to romanticize it. It's just obvious that Greek culture fused with the local Bactrian traditions, more so than in other Hellenistic states. The centuries old presence of deported Greeks and the relative isolation/distance from the greater Hellenistic world would have only facilitated a more speedy integration of Greeks into a much larger regional system. I'm genuinely curious about the sources saying that the Greeks went "home"? Basically what I'm saying is yes, their ruling class was Greek, but if they ever get developed for 0AD, and the archaeological references are used correctly, their structures are going to end up looking quite different from the other Hellenistic civs. In terms of units, you'd have the basic Hellenistic roster (with some minor unique elements), in addition to Hellenized Persians, Bactrians, Sogdians, Scythians and Mauryan elephants. They'd look and feel quite unique.

.

.

This is where I believe the Greco-Bactrian Kingdom differs. Probably on account of the 2 century old presence of Greeks as subject populations deported by the Persians as early as Darius I, prior to the Macedonian conquest. Hellenistic influences in Bactria are all over the place, and remixed, with each other as well as Iranian (and even some indirect Mesopotamian influences, in architecture at least). The conversion of a decent number of Greeks to Buddhism, as well as Zoroastrianism, and the worship of gods like Zeus-Zoroaster. Some mixed marriages seem to have occurred. The architectural layout of sites like Ai Khanoum also demonstrate a departure from Greek norms, using Hellenistic elements as a decorative veneer, but using Achaemenid principles in layout and function, alongside purely Greek structures like the theatre. Being hopelessly outnumbered by a mixed "native" population of Persians, Bactrians, Sogdians, Scythians and Indians, at such a great distance from the Greek homelands, as well as being largely cut off from new Greek settlers necessitated a more delicate approach to ruling their subjects, causing a much stronger and more genuine mixing of cultures. They are easily one of the most divergent Hellenistic civs, which makes them especially interesting in my opinion. Alexanders dream seems to have come to fruition, to a degree at least, in the furthest reaches of his empire. Ironically, one of the most obscure Hellenistic states, the Indo Greek Kingdom was one of the last (if not the last) independent Hellenistic Kingdom.

.

.

.

.

Nice to get some historians interested into the game. It does not happen often though I wish we had more visibility in the academic world because we can give more life to academic studies. Even if it's 100% perfect we not are professionals after all but striving to achieve levels like what we did for the Kushites is great IMHO. So thanks for anything you will bring us.

.

Hello and welcome! 0 A.D. is a project that has been (and still is) in development for years; what we have right now is the result of numerous volunteers contributing in their free time, which is great. People come and go, though, and not everyone has the same standards or is fully aware of what has been done before; as a consequence the game is full of inconsistencies (the game is still in alpha stage and is not perfect); e.g. at least three different transcriptions of Greek are currently used, e.g. η is sometimes written as e, sometimes ē, sometimes i. I believe the idea is to have two sets of Greek: Attic for the Classical factions and Koine for the Hellenistic states. However, Greek text strings currently in game appear a mixture of Modern, Hellenistic, and Classical, and voice recordings are very much a work in progress. Anyway, if you're interested in actively contributing to the development version of 0 A.D., you probably should register at https://code.wildfiregames.com/ and https://trac.wildfiregames.com/ as well.

Hi, Thank you for your proposal and your help. Yup, we know and your help could be useful in these threads:

.

.