Yves

I think that the time for GC more or less proportionally depends on the amount of memory to collect. At least this sentence from the blog post I linked above gives that impression: I'm not sure how much further it can be divided, though. Probably there's an overhead somewhere that doesn't allow us to divide it further. Anyway, as you can see it takes more than 40 ms which is more time than the whole frame should take (someday... ). 40 ms per frame would be only 25 FPS! And you can also see that it happens three times in four frames on the first screenshot, which is already quite regularly (we can't call it more often).

Historic_bruno has created a patch that uses JS_SetGCCallback to profile how long garbage collection takes and when it happens (patch is attached). We figured out that Aegis (old/svn version) has a lot more problems than Qbot and that this is the main factor that makes it slower. The new version in this thread is a bit better but garbage collection is still a major performance problem. I've attached some screenshots from profiling (new version with your patch). This is the command I used for starting the test-game: ./pyrogenesis -quickstart -autostart="Oasis 04" -autostart-ai=1:qbot-wc -autostart-ai=2:qbot-wc -autostart-ai=3:qbot-wc -autostart-ai=4:qbot-wc I did the profiling when all players had between 180 and 190 population. Do you think it's possible to reduce the amount memory that needs to be garbage collected in each frame/sim update? If we upgrade Spidermonkey it should be possible to use incremental GC, but that doesn't help when the garbage collection takes that long and happens as often as it does now. If it's not possible to reduce the amount of memory that needs to be garbage collected, the only other solution is to move the AI to another thread completely, which we should probably do at some point anyway. jsgc_profiling.diff

That should be possible. The API supports hooks for exceptions.

Thank you, I'll fix it for the next patch. I've uploaded a new patch (v0.9). Changelog: Fixes the problem that functions could fail because StringifyJSON returned an exception. Credits go to historicbruno for figuring it out. Fixes an assertion failure when loading random maps because they don't initialize the profiler but try to use it now through the debugger.

Thank you, this makes clear where to put the information about licensing that we have. @mmayfield45 Just to be sure: Could you please confirm that you agree to release your own work under "GPL version 2 (or later)" like most of the game's code?

Very good. I'll wait with committing the code until the server side is ready to commit too and until everything related to licensing is clear. @all Checking LICENSE.TXT, everything in source/ should be "GPL version 2 (or later)", but the web-GUI will most likely go into /source/tools which is listed seperately and uses "Various (unspecified)" licenses. I think we should make it clear somehow which licenses the web-GUI uses. Should we put a seperate license.txt or something into that directory or how should we do that?

Oh my god this is so awesome! I hope you don't mind if I post a screenshot: I've only tested it a few minutes so far but it already looks very polished and the GUI works as I dreamed it could... someday. I never expected this to happen so quickly! Now I have to fix the remaining problems on the serverside and it will be a very useful tool. About the licensing: Do you agree that your code will be committed to the project repository and that it will be licensed under the GPL v2 (or later)? I guess there are also some other options if you prefer. What 3th party libraries and code did you use and how are they licensed? I see "jquery.easyui" which contains a license file but what about "ace"?

I'm repeating myself but: Usually raiding doesn't lead to victory immediately. It just slows down the economy so much that the other player will never be able to catch up again. Even if you are really lucky as an Iberian player and you have a lot of resources inside your wall, it won't last for very long.

I think we shouldn't use the same behaviour for this debugger because stopping other threads only works if they execute Javascript at the moment. Stepping to the next line in one thread could continue the execution of a lot of C++ code in another thread. I decided to allow continuing for all threads but send "step", "step in" and "step out" only to one thread.

It will just continue the execution until the next line is reached. It should do exactly the same as normally.

A new version is ready. You can get it from the wiki article together with the updated documentation. http://trac.wildfire...scriptDebugging Changelog Fixes/Adds Step command to step single lines of code Adds StepInto command to step into functions Adds StepOut command to step out of function Adds setting for stopping threads relatively simultaneously (check the wiki) Adds the ability to continue all threads with one command by passing threadDebuggerID=0 Adds the ability to break in parent scripts that aren't enclosed by a function Fixes the output of GetThreadDebuggerStatus to return a JSON array instead of just multiple objects Fixes possible crash with null-functions Fixes threading issues with static hook-functions Fixes setting breakpoints in the current function Fixes issues with function definitions inside functions which could cause the debugger to break on the wrong line ... maybe I forgot something I had to use a different approach (described in the post above) to solve certain problems. I hope I didn't introduce too many new problems. I've tested a few hours on Windows and on Linux, but testing is very cumbersome without a GUI that supports all the features. Kieran's current version of the GUI was already very helpful, and I hope he'll be able to continue the work and add some of the other features.

We are aware that there's lag: http://www.wildfiregames.com/forum/index.php?showtopic=16991 There was also a problem with the soundmanager's threading implementation that should be fixed now. This had quite an impact on singlecore systems and maybe also some others.

If I remember correctly, this is already implemented for building.

I used the NewScriptHook to fill such a structure with information: struct trapLocation { jsbytecode* pBytecode; JSScript* pScript; }; std::map<std::string, std::map<uint, trapLocation> > m_LineToPCMap; I was able to toggle an example breakpoint correctly that was set on the wrong line with the last version. I think this should be clean if I delete invalid entries in a DestroyScriptHook, but I'm a bit too tired now, maybe I have forgotten something important. I'll check it in depth tomorrow.

I've found a problem that seems quite difficult to solve. Maybe someone has an idea. Some explanation of the terms first: Script: Is a script or a function, but it does not include any child functions. In a normal script-file you usually have multiple functions and therefor multiple scripts. jsbytecode: It's some bytecode which (as far as I can tell) represents a single line of sourcecode. A jsbytecode belongs to a specific script. I'm using a call hook set with JS_SetCallHook to get informed about each script that runs. I check each script if it is associated to a filename for which a breakpoint should be set and if the line number specified by the user is between start- and end-line of the script. Now the problem is that if there are multiple nested functions, there will be more than one script where this condition applies. I'm using JS_LineNumberToPC to get the bytecode associated with the line specified by the user. This function takes a script as argument. I only get the right jsbytecode if this script represents the innermost function. Otherwise it could be a completely different line because JS_LineNumberToPC doesn't count lines of scripts/functions definied inside the current script. Some things I've tried or thought about: If I call JS_LineNumberToPC first and then pass the resulting jsbytecode to JS_PCToLineNumber, I get the line number on which the breakpoint will be exactly set. Unfortunately that doesn't really help to find out if it's the innermost script/function. If for example the user has specified a line with comments or an empty line, the returned line number can be different too. I could check all the breakpoints that are already set in each call hook. If they are more nested (start- line is greater than the last one and end-line is smaller than the last one), I could replace the breakpoint. The problem here is that a wrong breakpoint could be triggered before the right call hook is executed that would correct it. Here's the API documentation (unfortunately not much more than a list of functions): https://developer.mozilla.org/en-US/docs/JSDBGAPI_Reference I hope there's another solution than parsing the JS code.

I agree that the speed becomes much faster quickly after a certain stage. That's bad for people who prefer slower gameplay and also for those who prefer faster gameplay and should be improved. That's true and I think the Idea isn't bad. Another solution would be increasing the strength of the champion units. I think they are too expensive and too weak at the moment if you take into account that they can't gather resources and therefore are a loss the whole time they are waiting somewhere for an attack compared to citizen soldiers who can gather resources at that time. That's true, but I think the point brought up by Pureon has much more impact on the game's speed difference in early and in late-game. Reducing build-time for the buildings required early has some limits.

There are people who like competitive gaming where a game is over after 20 minutes, but others prefer to play together with friends for hours, build up a base slowly and have some battles. I'd prefer a generally slower game too with as little advantage for super-fast clickers as possible. Strategy should have a greater value than developing an automatism for getting your economy up as fast as possible and having the best micro managing skills. This also allows us to have greater differences between the civilizations. The discussion about (sort of) removing the the Iberian walls is a perfect example. This and other special buildings, bonuses, techs, units and abilities make the game harder to balance and less attractive for professional gaming. On the other hand they bring more variety for the average player. Having some adjustable options is probably a good idea for things like those you mentioned. However it's not a solution for everything and we'll have to make a basic decision what kind of gameplay we want. That's the same thing I've tried to express in TheMista's balancing thread. Making little adjustments here and there will not be enough to achieve a coherent balancing and gameplay. We need a plan first! Another argument in favour of varieties is that we have a lot of artists and programmers who are capable of creating this variety and like to do it. In contrast, for a professional game development company the other approach is probably more interesting. It means they get access to the pro-gaming market and they don't have to spend too much money creating the variety.

Raiding is still possible even with the towers and the gates because you need resources from outside of the walls soon. If you can keep the Iberian player inside his castle you are going to win the game. What's the point of walls with gaps and no towers? Maybe we could remove the towers so that the workers close to the wall can't easily be protected from attacks without running far away from the resources, but I think we shouldn't remove the gates.

I know that it's cross platform, but we don't generate projects files for eclipse with premake at the moment. Premake doesn't even support it unfortunately. I've thought about something like that too. For example it should also be possible to debug the game's startup. I'm not sure yet if I will read breakpoint definitions or if it will just be an option that stops the execution as soon as any JS-Code is triggered. You could then add all the breakpoints you want using the normal ToggleBreakpoint command. Could the Web-GUI somehow save the breakpoint definitions and load them? I'd prefer if as much as possible would be done with the Web-GUI because that's cleanly separated from the engine and the game.

I've uploaded a new version that fixes some more crashes to the wiki. There were some problems with rooting Javascript values and some parts with threading problems. I didn't use it for JS yet and I don't know if there are any JS plugins. I wanted to develop a Codeblocks plugin first because it's the only supported IDE that runs on all systems at the moment and because I know it.

Looks good! Do you mean the ground? No grass should grow where elefants walk!

There were some discussions because he posted very very often and many posts were not of high quality. But as far as I know the consensus was that he likes the game and the project very much and he is trying to contribute (and already did). Also ohne part of the problem is that english isn't his native language, which is not his fault (not a fault at all ). He should be encouraged to value quality a bit more more than quantity. I don't know what happened then, but I think he's allright and we don't have to worry that anything bad happend.

I think we can get a lot of performance out of JS. I've seen that we have already enabled JIT (Just In Time compiling) for release builds. Why do we even need to do it "Just in Time" when we (opposed to Firefox) know all scripts before we run them? In addition to that, there were a lot of improvements in Firefox's Javascript engine (Spidermonkey) which we are using. The latest versions of Firefox has come with many significant performance improvements and introduced a new JIT compiler called Ion Monkey. This compiler should further improve the optimization for compiled JS code. Here's an interesting blog-post about that topic (also other topics are interesting on that blog): https://blog.mozilla...-in-firefox-18/ One difficulty about using a newer version of Spidermonkey is that Mozilla doesn't seem to be interested in doing the work required to release a new standalone (not part of Firefox) version. This means also that documentation is lacking. https://bugzilla.moz...g.cgi?id=735599 Another difficulty is that the API of 1.8.5 isn't compatible with the newer versions. I don't know yet how much work it would be to integrate a new version of Spidermonkey into the game. Last but not least I assume that garbage collection and memory allocation could be a major bottleneck for certain parts of JS code that update a lot of data very often. I don't have any proof for that yet. Maybe we can optimize something or if that fails we could still fall back to C++ code. I'm very interested in doing more research about that matter, but I'd like to complete my current work first.

I agree with Jonathan on that point. Arguing about what is closer to real life doesn't help us here. We are not implementing a battle simulator (which would require a lot more variables, research and adjustments). The important factors are if it is flexible to achieve what we want and how easy it is to balance. I haven't spent enough time thinking about both options, so I don't have a clear opinion about what is more flexible and easier to balance.

Hello TheMista, welcome to the forums! I'm a surprised to get suggestions for balance changing so quickly. You said you first downloaded the game about four days ago... how much did you play 0 A.D. since then? What I expected (or hoped to get) was a proposal for a general direction/plan of balancing in the next weeks or months. For me it's important to underline that there's not just one good solution for balancing a game. There are a lot of different directions that can be chosen and each of these directions will affect how the game plays and feels in the end. I'd say you shouldn't start suggesting specific changes before you are able to describe an outline or a concept of your balancing efforts. I'm a bit concerned that you are trying to apply a pattern you know from other games without thinking too much about alternatives and without knowing 0 A.D. very well. Your fast and in my opinion not very founded proposal seems to confirm that concern. You should not only look at how the game is at the moment, but also check our planned features (but they are re prioritized at the moment) . Please don't take my critical answer personal. I think we can benefit a lot of your experience and I'm glad you are here to help!