Leaderboard

I updated the wiki up to r27528. I left quite a few of diffs about the Vulkan renderer and other art changes / fixes out. If you think some should be included just let me know and I will update them. Also, since A27 starts at r27104 I may take a look also from there to complete if needed.

by logic alone, a men on horse can do anything a men on foot can do, because a man on horse can dismount whenever he wants. so cavalry should be able to gather any resource infatry gathers. the choice to limit cavalry to hunting has more sense if you think of them being of higher social status, so they couldn't be bothered farming or gathering berries, but only hunting because that was more common among warriors and aristocracy of all ages. I think the game is fine now, by this regard.

Still too many questions for any choice. common problem. fear of enjoying too much later.

"Fischernetze" ist der Name der I Tech für Fischerboote. Hellgrüne Punkte auf der Minimap sind Nahrungsressourcen, sprich: Beeren und Fisch. Ingame kenntlich gemacht durch Möwen, die darüber kreisen.

I agree. Besides Vulcan refers to an underlying technical item and not something in the game itself. And it has the ST association which sounds a bit weird to me.

0AD Hephaestus would sound cool. Perhaps we want to follow the old naming system and go for AArdvark Or AAchen, where your Linux mirror is located; Aachener mirror is often the default for many Linux distributions if you downloaded your ISO from an European hosting server, which means you probably curled your 0ad program files from Aachen - so it definitely deserves some credit. In addition, located on the border between Germany and Belgium, it is a nice city to visit.

Hello everyone, As some of you may know we maintain a list of all the changes for an alpha on the wiki. The page for Alpha 27 is this one. You can also find all the information you need to update your mod here. Unfortunately we sometimes forget to update it and some commits go missing. Would anyone be so kind as to backlog from r27399 and update the page if needed? This page is really useful to write the release announcement. Thanks in advance

Thank you so much! Sure go ahead

First Makehuman was never designed for creating finished characters it is a starting point only not the end point this was stated with our very first release years ago and as a small team FOSS project we have never had the resources for anything else. Enjoy the Choice

I'm working with a school in rennes for a Sci-fi mod. They are making some progress yeah, but no planet mapping.

@TerryF first, try "booming" with only women and soldiers gathering food and wood only. Any new units you train should also go on food and wood. The main thing is to gather the resources you need (food and wood only for the first 10 or so minutes), and immediately spend those resources to get more units gathering. Get upgrades or additional barracks if you have excess wood. If you find that you have 1000 or 2000 food or wood, it probably means you are not spending it appropriately. You should avoid having to "save up" resources for something. Don't move to get stone or metal until you need absolutely need it. You can practice by yourself without any AI once or twice, and if you can manage to get to 200 population by 15:00 minutes of game time, this is a great start.

Don't take the title seriously. What i am writing is my view and not that from the WFG-team. I try to speed up the engine and make it less stuttery. First I was locking at multi-threading. Since "if one core is to slow multiple will be faster" right... In the most recently uploaded CppCon-presentations about Hardware Efficiency and General Optimizations this statements were made: "Computationaly-bound algorithms can be speeded up by using multiple threads" and "On modern hardware applications are mostly memory-bound". It seems impossible or hard to speed up an application using multiple threads. But step by step: Computationaly bound is when the speed of an application is bound by the speed of computation. Faster computation does not always mean faster application. A webbrowser is likely network bound: A faster CPU does not improve the application speed by much but improfing the network speed does (It can also split up in latency-bound and throuput-bound). An application can be bound by many other things: GPU-bound, storage-bound, memory-bound, user-bound An application is fast if no bound does outweight the others. In the last decades CPUs got smaller (smaller is important since that reducec latency) and faster. -> Computationaly bound application became faster. Memory also got faster but is spatially still "far" away from the CPU. -> Memory bound application became not so much faster. There is some logic that can help us: We have to bring the data (normaly inside the memory) spatially near to the CPU or inside it. That's a cache. If the CPU requests data from the memory the data will also be stored inside the cache. The next time it is requested we do not request it from the memory. Exploit: Use data from the cache as much as possible. More practicaly: Visit the data only once per <something>. Lets say you develop a game every entity has to update their position and health every turn. You should visit every entity once: "for each entity {update position and update health}" When you update health the data of entity is already in cache. If you do "for each entity {update position} for each entity {update health}" at the start of the second for-loop the first entity will not be in cache anymore (if the cache is not big enough to store all entitys) and another (slow) load/fetch from memory is required. If the CPU fetches data from the memory most of the times it needs an "object" which is bigger than a byte. So the memory sends not only a byte to the cache but also tha data around it. That's called a cacheline. A cacheline is typicaly 64 bytes. Exploit: Place data which is accessed together in the same cache line. If multiple entitys are packed inside the same cacheline you have to do only one fetch to get all entitys in a their. Optimaly the entitys are stored consecutive. If that is not possible an allocator can be used. The yob of an allocator is to place data(entitys) in some smart spot (the same cache line). Allocator can yield gread speed improvement: D4718. Adding "consecutivenes" to an already allocator aware container does also yield a small speed improvement: D4843 Now and then data has to be fetched from the memory. But it would be ideal if the fetch can be started asyncronosly the CPU would invoke the "fetcher"; run some other stuff and the access the prefetched data. Exploit: The compiler should know which data it has to fetch "long" before it is accessed. In an "std::list" one element does store the pointer to the next element. The first element can be prefetched but to get the second element prefetch can not be used. Which data to load can not be determined bevore the frist fetch. Creating a fetch-chain were each fetch depend on a previous fetch. Thus iterating a "std::list" is slower than an "std::vector". Exploit2: Don't use virtual functions they involve a fetch-chain of three fetches. A normal function call does only involve one fetch which can be prefetched and might even be inlined. Back to threading In a single threaded application you might get away with the memory-boundnes. Since big parts of the application fit in to the cache. Using multiple threads each accecing a different part they still have to share the cache and the fetcher-logic(I didn't verify that with measure). The pathfinder is not memory bound (that i did measur) so it yields an improvement. Sometimes i read pyrogenesis is not fast because it is mostly single thraded. I don't think that is true. Yes, threading more part of the engine will yieald a speed up but in the long run reducing memory bound should have bigger priority than using multiple threads. There also might be some synergy between them.