Leaderboard

To start off you generally start from scratch, maybe import a model from the base game for comparison to get the scaling correct. Afterwards I tend to keep like buildings in the same blender file so I can borrow elements off of it, it aids in set cohesion when you can compare things side by side All the my flora is in one file as well, but the only things to borrow between those are leaf planes, tree trunks to edit slightly. its better to start from scratch so you have a deep familiarity with the meshes, as a project space can get quite hectic even with that in mind cheers, and good luck

I was doing different refactorings of our engine for last 1.5 years. It's allowed me to add a new backend (graphics API) - Vulkan. It's relatively new API (as D3D12) which allows us to have a more predictable and stable performance. And in some cases even better performance. But not always as we use it in a single thread yet. Vulkan drivers from different vendors are usually much lighter than GL ones. That's the way to have less driver bugs and crashes. But we still need testing how it works on different hardware. So everyone who has a Vulkan compatible device please try to enable it in options (along with feedback). If you're able to run SVN then you already can test it. Else wait for the next RC. Note: to run the game you'd need to download and install a separate mod with precompiled shaders (it'll be bundled in RCs and the Release): https://releases.wildfiregames.com/rc/0ad-spirv.zip. Vulkan can't run pure GLSL shaders (which we use for GL), it uses a special binary format for shaders: SPIR-V. Vulkan allows us to use different interesting features. For example it allows to select the most appropriate GPU to use. It means no more crashes because of wrong GPU, I hope Also Vulkan supports multithreading. If you still have some time you could run the game with validation enabled. It makes the game slower but validates a lot more different internal things. It should help to make Vulkan stable for the release. To enable validation you need to add the following lines to your usef.cfg: renderer.backend.debugcontext = "true" renderer.backend.debuglabels = "true" renderer.backend.debugmessages = "true" renderer.backend.debugscopedlabels = "true" Known issues: Screenshots aren't implemented yet, but going to be during Feature Freeze rP27552 Some precompiled shaders are missing, please report if the game says so macOS isn't supported yet, but we have plans to do so via MoltenVk rP27488 Missing silhouettes rP27418 Unsupported depth formats cause an assertion rP27421 Stretching on window resize after fullscreen switch rP27422

Do you start from scratch? Or is there a base mesh that you start off with?

Adjust your workflow as you see fit, however the amount of effort needed to create your own 'building blocks' is minimal in a lower poly setting and worth doing to prevent blatant repetition in most cases.

I don't think you understand what is trying to be achieved. Think about actions per minute (APM). If you have to have units on deck and then use APM for those units, you now have to have a small number of ships because APM is limited by the human player. By getting rid of the entire "garrisoning units on deck" aspect, APM can be freed up and more ships can be allowed. If you want lots of ships in a battle, then you have to remove things like units on deck and multiple roles etc etc. If you want ships to be multi-roled and fully featured with on-deck garrisons you have to micro, etc., then you have to lower the number of ships. The proposed design in the first post is opting for more ships with a single role per ship. And for pathing reasons it is desired that ship models be decreased in size, which makes soldiers on deck even more awkward from a visual and gameplay standpoint.

Well sadly all the posts are gone now (GDPR) but somebody went through great lengths to create hero portraits using make human.

The idea is to make ships that are dedicated to a purpose so that a countering system can be devise, kind of like a video game.

I think warships equipped with catapults should not participate in naval battles, because catapults are difficult to hit other ships in rough seas, and their operators are also a fixed number, and adding other soldiers on a warship will not improve the catapult power and work efficiency. Catapult ships should be dedicated to destroying structures along the enemy's coast, they don't need to be large or heavy, and they can't match those ships with shooters in naval battles.

any balancers want to give their two cents on phabricator? https://code.wildfiregames.com/D4914

It depends. If it's for an existing civilization we try to reuse some elements. Since they are gonna share the same texture space anyway.

I don't really see anything in your post that supports the position to not use multithreading? Yes, obviously more efficient computations is better than doing less efficient computations faster, but given the same level of optimisation, a well designed multi-threaded CPU-bound program will almost always be faster (by how much depends on Amdahl's Law). In most architectures the cores have some levels of independent caches, so increasing number of threads also increase the effective memory bandwidth (for things that are in cache, taking into account cache invalidation, etc, etc). Cores also have their own prefetchers. Modern memory systems are quite well optimised for concurrent access. It's definitely not a case of all cores having to go through the same narrow pipe. For another example, if two cores require data from two different memory banks (last level cache miss, on the order of 100 cycles), the memory controller can issue read requests for both, and wait for both at the same time. Most of what you described are basic optimisation concepts that anyone who cares about performance should be familiar with. However, I think there's one big idea that took me much longer to REALLY understand and get onboard with - always profile first. Humans are absolutely terrible at estimating where the performance hotspots are, and if left with our guesses, we will spend all our time optimising things that just don't matter. Now when I program, I never do any non-trivial optimisations ahead of time. Strictly only after profiling. Of course, that doesn't mean I pessimise unnecessarily. I still try to not make unnecessary copies of data, etc. Just nothing that requires spending more time. Just a few notes about the specific things you mentioned: * Manual prefetching helps in theory, but is extremely hard to do it usefully in practice. You have to make sure you prefetch far enough ahead that it makes a difference (if you do it just 10 cycles ahead of when you need it, that's not going to make any difference, and you are paying the instruction decoding cost, etc), but not so far that it gets retired before you need it (in which case you wasted memory bandwidth that maybe could have been used by another thread). Also, in your example of a linked list, if you traverse the list on every frame, the hardware prefetcher is probably already doing it for you, because it would have recognised the data access pattern. I have been working on performance-critical stuff for about 10 years now, and have only seen one instance of manual prefetching that's actually helpful (and only marginally). Many have tried. If I'm trying to optimise a program, this is going to be one of the very last things I look into. Yes, using a vector over a list where possible is a good idea. Mostly because continuous access means each cacheline fetch can pick up more elements, and for a very long vector, DRAM has burst mode that is more efficient. * Virtual functions are fine in reality. The v-table is almost always going to be in L1i cache, so those fetches are essentially free with good instruction scheduling. Also, in many cases, the actual function called can be proven at compile time, and the compiler can de-virtualise it, in which case it's absolutely free. Virtual functions offer a lot of readability and maintainability benefits. I would need very concrete evidence showing that they are a significant bottleneck before taking them out. Again, profiling first is important. I have not encountered a single case where this makes a difference.

Its a good idea, but there is one thing that should be talked about here: In other RTS games, using macros is considered cheating. That being said, if it is implemented into the game, it's definitely not cheating. The question is then are the repeated actions that these macros take care of an important part of the skill gap in 0ad? Are they important for player experience? I would personally say most of them are important, save for very basic things like autoqueue (which can be thought of as a macro no?) So my thoughts are that this might be good as a mod, but not as an addition to the main game.