Yves

I wanted to test the new Spidermonkey in the profiler a first time. And guess what... it's currently even a little bit slower than the old version. This is from the non-visual replay on Oasis4 with 4 AI players (so no rendering, no GUI etc...). V185 is the old version and the other two lines are both from the new spidermonkey (I ran it twice to be sure). I'll try to figure out why it's slower this weekend. I have some ideas and I don't think it will stay like that.

I don't think that's possible with the current approach of converting parameters to native c++ types. That would require direct access to Spidermonkey's memory and knowledge of the internal structure of jsvals (which could change from one Spidermonkey release to another). Also as far as I know spidermonkey's GC could theoretically move the storage location of values. I think it works without copying memory when registring JSNative functions directly and accessing the argv array using the JSAPI. But being able to register functions with a fixed number of arguments and native C++ types is worth the additional overhead in most cases IMO. Also keep in mind that this approach is currently only used for relatively simple argument types like integers or strings and not for passing large objects. I know strings are only "relatively" simple but simplicity of code and the additional automatic validation of the number of arguments and their type is also valuable and not just the performance. In my opinion we should only worry about this performance loss if we can prove that it's significant enough using the profiler. In this case we can find a specific solution. Which ones do you mean? This? It was created using Profiler2. Check source/tools/profiler2 and I've written a short howto here. Unfortunately there's no wiki article explaining it. It's on my todo-list since quite a while...

I like these!

No problem, I didn't have time to work on 0ad in the past three days anyway. It's awesome how you made these changes so quickly to help with the Spidermonkey upgrade! I've applied the changes and it works well. I can hear music, the music continues playing across multiple GUI pages, there are ambient sounds after a game starts and it starts playing another piece of music in game after the first is over. I haven't found any issues yet. Your implementation has a few minor differences compared to the other scripting implementations I "ported" like for GameView or for the Renderer. We should try to eliminate these differences just for consistency. These are the main differences I noticed: I'm using a directory called "scripting" for the js stuff, which is the same naming that the simulation and the GUI already use. The file containing the global functions which are regsitered to javascript is called "JSInterface_Renderer" or "JSInterface_GameView" respectively. I suggest you also follow this convention just for consistency. Remember to change Premake4.lua if you change the directory name. I've put all the global scripting functions in a namespace called JSI_Renderer or JSI_GameView respectively. I think this makes sense, you could also add your global functions in a namespace "JSI_Sound" or similar. Currently we use three different ways to make the ScriptingInit/RegisterScriptFunctions function available. I'm using a public non-static class memberfunction for GameView and a public static class memberfunction for the renderer and you use a public non-static global function. Basically I think your approach could be combined with a namespace (point 1) so that we could omit the "Sound" prefix and just name the function "ScriptingInit" or "RegisterScriptFunctions". I prefer the second term because it describes clearer what it actually does. I don't see any advantage of a static class memberfunction at the moment so I'll change that in my code. Another closely related question is... What do we do when functions are only available at certain stages in game? "GameView" for example can only be used when a GameView instance is available which currenty means when a match is running. My hacky workaround is only registring the function in the case of "if(g_Game && g_Game->GetView())". That's not very good because this check runs when the GUI page is initialized and in the future it could be required to access GameView's function from a page that was initialized before the game started. I've noticed that you check for "if ( g_SoundManager )" in each function and simply do nothing if it's false. In the soundmanager's case that's probably good enough because it gets initialized quite early and stays active until the game ends. I'm wondering if I should try to implement a common solution for this problem like a check that can be added when registring the function so that the ScriptInterface itself would react sensible and the C++ code providing the functions doesn't need to worry about that in each individual function. This way I could also use the same approach for registring the functions of GameView and they could be used in all pages when GameView is available no matter when the page was initialized.

I also think that having one tech available in multiple buildings breaks our concept. Of course you have to do that because you need to show their relation in the gui (only one of them can be researched). Why don't we use the blacksmith to solve this problem? I don't think it's a problem there when it affects another building because it is clearly meant to be a "tech-research building".

Hi Patjuh an welcome! When you search other players you best check out the irc channel #0ad. At the moment some people are working on balancing even though there are still some important features missing. Maybe you can help with that once you know the game better.

Very good, thanks! I should be able to get the diff from the GIT branch myself and this way I can always get the newest version. Please post the link. Unfortunately I haven't come as far as I wanted in these two weeks of holidays and the progress will slow down when I start working again next week. But anyway, I'm able to start the game and navigate through the menus with sound disabled. At the moment it crashes when I try starting a match because of some issues with the Javascript context's lifetime. Some more issues could come up with the AI because it uses Javascript intensively. I would like to have a quick look at your sound code now to make sure it is what I need and then wait with the integration in my Spidermonkey working copy until I get a normal match running.

I don't really know what the output of "top" could help. Since the performance is getting worse later in game it seems to be a known Problem which is mainly pathfinding and AI related. We don't need more information on that, it just needs to be improved. Things you can do in the meantime to get better performance: Play with less units (low population cap, low number of players) Disable some graphics settings. Play on small maps with few trees Play multiplayer without AI players

It looks like the same problem as here. Does that fix it for you too? Please post system_info.txt from the log folder: C:\Users\UserName\AppData\Roaming\0ad\ You can use the %appdata% variable as a shortcut: %appdata%\0ad\ This could maybe help us figuring out why the game doesn't recognize the resolution correctly on your system.

Port forwarding usually isn't related to Linux or Windows. You just need a web browser, type the address of your router/modem and then you need to find the right menu where you can set it to forward UDP port 20595 to your computer. Here's a little video from youtube that explains it. Where he types "ipconfig" to get his computer's ip-address you need to use "ifconfig" on Linux instead.

The patch wasn't really meant to be applied directly. It was more a general idea how it could work. I've changed the implementation approach again. Adding a separate file with some global functions in a namespace instead of adding static functions to the class itself seems to be cleaner. When class members become static a lot more in the class may have to become static too, which isn't good. But again, this patch isn't meant to work directly and without other changes. New patch here.

I like the LordGood's fortress concept better. The other one looks a bit too compact, a bit like a very large block of stone.

Nice concepts! Was such roundish architecture like in the 3th concept really used? It looks... unexpected to me.

I don't know anything about animation, but I've found this: http://trac.wildfiregames.com/wiki/ArtDesignDocument#a3dsMax EDIT: Also a bit later in that wiki article: http://trac.wildfiregames.com/wiki/ArtDesignDocument#Animation

I haven't looked into this in detail so I can't say if that approach is good. I wondered if it's possible to simply render as many frames as possible while the sim update is running. The important functions already have profile macros. That's how profiler1 and profiler2 work. That was in a match with 4 AIs and 4 players where I got the 32 GB profile.txt. I think the text format of profiler1 was a bad choice, it has way too much overhead. I have never used it before but it looks quite good. Is it part of the express edition? I have found this feature comparison but the Express edition isn't listed there. What I need at the moment is something to measure the performance difference before and after doing some changes. For the Spidermonkey upgrade for example I need to know how much faster version 18 is compared to version 17. Basically if I run an AI VS AI match without changing the camera and generate a graph like in the image I posted above, that should be ok for a first comparison (with the limitations I mentioned and it doesn't actually work because of the bug). Of course it would be much better to have a real benchmark mode that can do something similar and with predefined camera movement each time. It should be possible to lay one graph over the other and compare them. I would prefer the benchmark mode and it isn't one of the problems that really hurt, but it seems to make sense. Your choice.

That's what I mean. If you set "Match Type" to random you can select the faction/civilization. And as I said we also plan to add another match type where you can set the civilization for scenario maps and the location where the players start on the map.

I hope this won't happen and wish you the best! I liked that. It's one of the things that made this game different than other games. I'm not sure if I understand correctly, but we also plan to have an additional mode to scenarios and random maps with a map created by hand but configurable sports where the players can select their starting location and things like their civilization just like in random maps.

Hi and welcome! The models and also the textures look nice! There's another team creating a mod for 0 A.D. and they got a lot of technical help. I'm sure your questions will be answered too. Here are some of their first questions, so you might find some answers there too. As zoot said there are some concerns that there could be problems with intellectual property when creating a game in the Tolkien universe. I've heard that they are very strict in that matter and send you hordes of orcs ... I mean lawyers.

Unfortunately quantumstate is right. But if you still try to find where this is defined, try doing a full-text search on the directory. It's probably in these civilization definition files in the "civs" folder. If you translate it now and upload a patch somewhere it should at least be possible to add the french translation without knowing french once the system is in place. A lot of text could change until then, though.

Does the AI still delete the walls and leaves the wall-towers when it starts with a wall around its base? That would explain it.

I decided to open a thread about the Spidermonkey upgrade. There are some design decisions to take and it's good to have a place to write down the pros and contras. This is meant for discussions to take place and for work in progress designs and ideas that aren't final yet. I intend to use ticket 1886 for documenting more "final" decisions and information. Each GUI page in its own compartment The first major change is having each GUI Page (CGUI Object) in its own compartment using its own ScriptInterface instance. Currently the GUI uses two global objects. One is a page global for each GUI page which should separate global variables between the pages. The other global is used for all pages and contains engine function definitions and such. The new Spidermonkey associates a compartment with each global object and this design doesn't work anymore. At least I didn't find a way to make it work with minor changes. Cross compartment calls and wrapper objects could provide a solution here but I decided the other approach looks more promising. At the moment the plan is to register all GUI functions for all pages. I don't think registering maybe 100 functions for each GUI page should be a performance problem or memory problem. If it becomes a problem we can still implement something that lets GUI pages include functions they need. I figured out that the music code passes information across pages by using the global object called "global" (for example "global.curr_music"). A grep for "global\." returned only music related code, so it doesn't seem to be an often used pattern and could be replaced by a state stored in the music manager itself that could be accessed by a function. Concerning the JS console, the idea is that it should always use the currently active GUI page. Getting rid of g_ScriptingHost We are still using the old ScriptingHost that had been created before ScriptInterface was developed. That's unneeded duplication and should be replaced by ScriptInterface. It's sometimes a bit tricky because a lot of code simply accesses this global object and some thoughts are required that this code uses the right context/ScriptInterface/compartment in the future. Standardizing scripting access It's possible to access and use the JSAPI in a lot of different ways and we use too many of them in my opinion. That's probably because it grew that way and partially because different code has different requirements. I don't want to do too much at the moment but after thinking about it a lot and after discussing it with Philip I think we should remove CJSObject and the associated classes. It's currently used by the CRenderer, CGameView and the Soundmanager and I'd try to apply the same new pattern also for the JS console. The general approach would be providing global functions to scripts instead of custom C++ objects with GetProperty and SetProperty overloads, custom properties and custom methods. That's more or less the same approach Philip has chosen for the Simulation code and it seems to work quite well there. Object oriented design is good, but I think it's enough to have an object oriented scripting language and an object oriented engine. The interface between JS and the engine benefits more from a clean separation than from OOP. If there are global functions that can be called like "Engine.DoWhatEver()" it's clear that it is an engine function. Properties on the other hand can be script properties or native properties with custom getter- and setter functions that do potentially unexpected things. It's not obvious when using an object if it's a JS object or a C++ object with some custom functionality. The deprecated interface itself (CJSObject) required some quite hacky bits of code to create a relatively smooth transition between global/static callback functions and the objects. It stores some pointers in private data fields of JS objects and has to take care of some rooting to avoid garbage collection. I have to admit that this is hidden pretty well from the class users but what it does is still quite ugly (necessarily for that approach). I thought about either extending or removing the CJSObject-approach and my conclusion was that the additional flexibility is not really needed and the simplicity of global functions is the better deal. Here are some pros and cons I listed if you're interested (+ for pro, - for contra, ? for unknown or to-be-analyzed): Changing CGameView from the old pattern with CJSObject to the new one with global functions was very straight forward. Here is a reference implementation of CGameView @stwf I asked you about changing the Soundmanager code. What I had in mind was something like the example above plus the required changes in JS-Code and something as a replacement for passing data across GUI pages using "global.". For the moment you could use g_ScriptingHost for calling RegisterFunction instead of passing the ScriptInterface as an argument like in the attached example. I can easily change that in my code without causing merging conflicts later. Some additional thoughts about a configuration system Especially the renderer makes a lot of properties available to scripts that are essentially settings. When an options-screen eventually will be implemented a lot more settings will have to be accessible to scripts. I didn't want to develop such a system for settings because it's actually quite complex and requires some more time thinking about it. That should basically also be possible with global functions or the JSAPI could be used directly (something like the GUI does). In the worst case it would still be possible to reintroduce CJSObject if there are good reasons. Edit: Leper and I discussed that on IRC and came to the conclusion that functions are probably better anyway for the settings because they can provide a return value if for example the setting can't be enabled because the hardware doesn't support it. Is anyone against any of these changes or do you have additional inputs to consider? I've spent a lot of time thinking about it and I'm sure enough to write that post, but I still don't understand everything in detail and could be wrong about some aspects.

I guess it's nothing we should worry about now since it will most likely change with the new spidermonkey. It would be good to check it again when that's ready though.

If it's right after starting the game this probably explains these 16.9%. If it's later in game that would probably be because the JIT-ed code gets thrown away by the garbage collector, but there's a solution for that if the information about js::NotifyAnimationActivity is correct. Still I think 16.9% is quite a lot.

Where does that come from and what are these 16.9%? I'm just asking because it could be related to my current work on Spidermonkey.

We do some quite costly computations in Javascript. Most of it is hopefully just temporary because a pathfinder interface is missing. Another issue is garbage collection.