Yves

Great news! Welcome back, Ben! Of course I remember you. You helped me with my first patch (premake upgrade) and I joined the project after that!

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:

As I've mentioned a few days ago on IRC, I'm also working on a battalion system. We might be able to share ideas and code, if you don't mind. I've only had a brief look at your code on github. I might want to copy parts of it, especially the battalion selection code. Is that OK for you? I've uploaded the current state to github: https://github.com/Yves-G/0ad/tree/BattalionSystem Feel free to copy if you find anything you can use. It's still very experimental and unfinished in the current state. There's a demo map included with (currently) just two melee battalions that can attack eachother.

Between Spidermonkey 1.8.5 and 38 there have been many profound API changes and it took us countless hours to adapt the code to these changes. The GUI was especially difficult because it used a wider range of different API functions for the object oriented aspects. During the upgrade we have reduced the complexity of this interaction, which helped streamline the upgrade process in the future. You have valid points for the object oriented approach and I'm not against it, in principle. I just advise to keep the upgrades in mind an avoid adding too much complexity and diversity to the C++ <-> JS interaction. I don't know how much the Spidermonkey API keeps changing nowadays, but given how much Javascript is still changing, I suspect that's still an issue.

I had loading times of 40-50 seconds for a few days and now I'm getting http 503 too. I'd guess there's a performance issue with the forum database because files load quickly and other parts of the forum are also relatively slow (like around 10 seconds loading time).

You answered my question only partially. So far you have identified most issues with the current gameplay and you have outlined some possible ways for fixing them. That's a good start, but it's still quite far away from a concept that can be implemented. Decision have to be made where multiple alternative solutions have been suggested, dependencies between features have to be identified and clarified, detailed descriptions have to be written per feature etc. If developers want to help, they need very specific and detailed information how a feature should work. Do you think it's realistic to design such a concept, write it down and then also implement it in roughly 6 months (I guess 3-6 is too ambitious)? As I said, it would not be complete yet, but it should be complete enough to give a good impression of the final gameplay. If you don't know how long it would take to implement something, that's fine. you could still estimate how long it would take until the first parts of the concept are finalized enough so that someone can start with the implementation and how long you'd need for the whole concept.

Do you think it would be possible to implement your suggested changes in a proof of concept mod/branch in relatively short time of around 3-6 months? The scope would have to be limited as much as possible without leaving out anything that is crucial for the gameplay as a whole. For example, it could only focus on one civ, placeholders could be used instead of new artwork and workarounds or hacks for difficult features are OK. What tasks would have to be done exactly and how much help would you need from the team? We are still discussing your application in the team and I can't give you an official answer yet, but such a proof of concept implementation seems to be well supported. The tasks required for it (further work on the concept, setting priorities, defining tasks) are the next step anyway, so it should be ok to get started with it.

I'm looking forward to reading that document! The lack of a coherent gameplay design is the main issue that prevents us from going to the beta stage and eventually releasing a 1.0 version in my opinion. We need someone with dedication for this task! I've been working on game design for several weeks but then got stuck with a problem I haven't been able to resolve yet. There has to be a plan who could implement missing features in a reasonable timeframe, otherwise it's not going to work. As soon as your design includes some very though technical requirements, this becomes an issue. In my case, I felt that fighting mechanics in this game are quite dull at the moment and I wanted to include some formation fighting mechanics (see: http://trac.wildfiregames.com/wiki/FormationsWip). When looking at the technical aspects, I realised that all our pathfinding code is currently designed around single unit pathfinding. The formation system we have is basically a hack that works more or less OK in most cases, but it would require a major overhaul to meet the quality requirements for such a formation fighting system. Because the fighting system has such a strong impact on other aspects of gameplay, I stopped working on the design and started looking into pathfinding. How would you handle such issues? It's always a possibility to work around such technical problems with the design (drop formations, reduce population cap). You actually see that a lot in commercial games. One part of me thinks that perfectionism is misplaced here (if large companies with big budgets do it, why shouldn't we?). On the other hand, I'd like to strive for more than just another generic RTS that copies the same mechanics we have seen in commercial titles for years or even decades now. Maybe both is possible with a very clever design...

Hello and welcome! I like it, that's a nice addition to the hawks which already fly around in some maps. I'm a programmer and not really qualified to give feedback about art, so I leave that for one of the artists. Yes, you can. Have you already taken a look at the existing hawk actor xml here?

Looks like the perfect testcase for the instancing I'm working on.

I don't had anything specific in mind for multiplayer. It's maybe just because I think that multiplayer games are way more interesting than single-player games. They are more dynamic, more surprising and more challenging (even though wraitii, mimo and the others did a very good job with the AI ) . My comment about tutorial videos was just my personal preference. If you have something in mind, go ahead and give it a try.

In my opinion, tutorials how to play the game aren't particularly interesting. There are some around already and even though I've enjoyed watching some let's plays on Youtube, I've never watched a pure tutorial video about a game on Youtube. In addition, gameplay is still changing quite a bit and tutorials could be outdated soon. Traditional let's plays don't seem to work very well for 0 A.D. either. We don't have a single player campaign yet and only some multiplayer videos were really interesting to watch for me. What really sets us apart from other games is how our development works. There's regularly new content to showcase and gameplay frequently changes because of new features or balancing changes. Something like the development reports, but in a video format, could work and could also attract new developers. You can search in the Announcements and News forum for these development reports. I'd say some well commented multiplayer matches would also work and modding or creation of a custom map in our map editor, but I don't know how well the modding and mapping suits you. EDIT: These guys do it pretty well with development reports in video form: wolfire.com

A problem with writing to the config file could be. It would be user.cfg, not local cfg and for the Mac it's in "~/Library/Application\ Support/0ad/" according to the wiki.

I didn't know we take Bitcoin donations. Everything about donating is described here: http://play0ad.com/community/donate/ EDIT: I misunderstood your question. I thought you wanted to donate but don't want to use Bitcoin but it appears you meant the opposite.

Part of what you describe seems normal. The Javascript engine, for example, schedules a Garbage Collection (GC) regularly. During GC, it reclaims unused memory, but it only gives it back to the operating system from time to time. If I remember correctly, it should not go beyond 400 MB, though. But there are other parts of the game that do similar things like the VFS (virtual filesystem). The VFS keeps some data in the cache because it takes longer to load it from the disk than loading it from memory. So it doesn't work to look at memory usage in the first few minutes after the game is started and then calculate a memory growth rate based on that. But... This must not happen and is a bug. When did this happen? Was it in the menu, in the multiplayer lobby or during a game? If it was a game, was it paused?

These ideas look interesting and I also don't like how the current system encourages to have so many traders. However, in my opinion the system should be somewhat self-explaining and it should be possible to understand how it works without looking at number too much and certainly without making calculations. Facts like these are hard to figure out for players: -Markets generate income based on "connections" with other markets. -Traders increase this "connection". -You can only build one market per CC. The basic idea isn't that hard to get, but how can you influence the number of connections exactly, how much benefit do you get from an increased number of connections and is there a difference between own markets and allied markets? It's hard to explain these things to players in a mathematical formula. Restricting the number of markets by CC seems to be a bit arbitrary, especially considering that some civs just have these smaller military settlements. I liked the separate "trading good" resource because it's something which is easier to understand by players. What about having different trading goods as a less abstract way of explaining these "connections"? You'd get more profit if more different types of trading resources are connected to your market. These trading resources could be placed by the map designer and whoever owns the resource could build a market close to (or on) it and trade it (kind of like in Riese of Nations).Or it could be that each player can trade one or more predefined types of these resources and the only way to get more different types is to trade with allies. In this case we'd have to find a solution for how the distance between markets affects the system. It could require more traders to operate a short trade route (less profits if you sell the resource close to where it's being produced).Or these two approaches could be combined and there would just be some generic "trading camps" on the map where the players could build their markets and trade their own trading resource(s).This is just some brainstorming and it would still require quite a bit of work to get to a solid concept. In any case I'd probably reduce the maximum number of markets to a very low number. Generating profit there should be more about setting up an efficient trade network and not just about building more markets and more traders.

The development version is for developers and modders. If you just switch to SVN because you want to download only the differences between Alpha releases, then you end up downloading much more.

At the moment we are limited on the CPU side by the number of objects and not the polygon count of these objects. At least that's true for dedicated graphics cards. In my OpenGL 4 branch, I'm working on reducing driver overhead with OpenGL 4 functionality such as glMultiDrawElementsIndirect. So far, I've only worked on the aspect of uniforms and don't even do real instancing yet. Still, this has already improved performance quite a bit. I hope and expect to see some more improvements by introducing bindless texture management, which should then allow real instancing. In my opinion, it doesn't make much sense to work on a LOD system, before we overcome these limitations.

Hello Mikita and welcome! As Stan already said, programmers usually just pick a task and submit one or more patches before they eventually get invited to join the team. You may want to pick a simple task (link) or fix a bug to start with. If you are interested in a specific task, you may also work on that. Is there anything you are particularly interested in (AI development, GUI programming, network code, rendering etc.)?

Currently we have a Jenkins master server and one Windows slave. We just use it for the Windows autobuilds so far, but there are some more ideas how it could be used in the future. Some tasks like installing a Linux slave, building and running the tests is on my todo list, but not quite on top.

Thanks for testing, I've committed the fix in r17067.

Hello Etzard Thank you for reporting! You are right, it's a bug. Would you mind testing the attached patch? Please make sure to revert your fix before applying the patch and run build-osx-libs.sh with --force-rebuild. I don't have a Mac and can't test, unfortunately. apply_spidermonkey_patches_on_osx_v1.0.diff

I recently found this paper (around 100 pages) from Ulrich Drepper named "What every programmer should know about memory". It was very interesting and I red most of it in three days. It's not specifically about memory pools, but covers many performance aspects of memory and I learned a lot from it. Online-Version: http://lwn.net/Articles/250967/ PDF Download: http://lwn.net/Articles/259710/ I'm sure that improving memory efficiency can help us a lot to improve performance. However, I would first try to pick some spots where you can prove that memory is the bottleneck and then try to resolve the problems there. Just adding a whole memory pooling system for everything sounds like a lot of work with possibly little effect on performance. To cover everything, a solution has to be generic and the real problems might need more specific solutions.

The first example in the codeprojects article is quite strange. Doesn't it just change from heap to stack allocated memory? It does avoid searching for free memory on the heap because it can just add sizeof(CTestClass) to the stack pointer, but I wouldn't call this a memory pool, not even a "simple memory pool".

I don't think this is supported at the moment. You share the same public IP address when you use the same internet connection. If you want to play LAN games, you should do it this way: One player hosts using "Multiplayer->Host Game" from the main menu The others connect to his internal IP address using "Multiplayer->Join Game" from the main menuThe internal IP is something like 192.168.1.5 (4 numbers between 0 and 255 separated by dots). You can get it with the ipconfig command on Windows or ifconfig on the Mac (if I remember correctly). This is different from the public IP address which you can get if you browse to this website for example (you don't need this address in your case): http://whatismyip.org/