Ykkrosh

Oops, yes, that happens if you use GCC 4.4 (but not 4.3). It's possible to make the error go away by removing the "-fvisibility=hidden" bit from build/premake/premake.lua and running update-workspaces.sh again, but that's not ideal. Or run "make pyrogenesis Collada" so it only builds the game, not the editor. I don't know what the cause of the problem is (maybe GCC bug? or an intentional but undesirable effect of hiding inlined symbols in certain situations?), and it seems hard to debug, and maybe it'll magically go away in the future, so I'm not planning to find a proper solution now Could you give the error message? Might be something that's easy to fix

There's no GL_ARB_fragment_shader in that list, so it looks like your drivers don't support GLSL (though this indicates the hardware does have shader support). Apparently it's work in progress, so maybe future driver versions will handle it. What I meant was $ CONFIG=Release make or $ export CONFIG=Release $ makeso either of those should work better

Bug in the version packaged by Ubuntu. Could you post the file ~/.config/0ad/logs/system_info.txt? That should show what drivers it's detecting. "Low FPS" might be caused by graphics or by CPU - the game compiles in unoptimised debug mode by default so it'll be slow. (It's possible to build with "CONFIG=Release make" to enable optimisations, which should go faster.) No. If you create a file .../binaries/data/config/local.cfg containing the line "fancywater = false" then it shouldn't attempt to load the water shaders at all - does that make it look any different?

Part of the problem is my recent changes to the GUI. Originally, all GUI XML files were loaded at once, and the session GUI files caused the snLeave object hotkey to be registered, so pressing esc would do whatever it did (I can't remember now what it actually did do but it wouldn't give that error message). In the new system, only the main menu XML files are loaded at first, and they don't include the snLeave hotkey, so pressing esc should do nothing; but if you start the game, the session GUI files register snLeave, and if you leave the game then the hotkey registration still exists - there's just a single global hotkey list and nothing can get removed from it. So if you press esc on the main menu (after leaving the game), it complains because the snLeave object (which is in the session GUI) doesn't exist any more. So the relatively important bug is that hotkeys are global, and not limited to the lifetime of the GUI page (CGUI object in the code) that registers them, and that really ought to be fixed. The relatively unimportant bugs are that the keys to exit the game might not be the most obvious ones they could be, but that's easy to fix later.

Should be in SVN now. It's a bit experimental (use at your own risk etc) but seems to work for me. The general idea is: cd .../libraries/spidermonkey-tip/ ./build.sh cd .../build/workspaces/ ./update-workspaces.sh --with-spidermonkey-tipand then run make as normal, and it should use the new SpiderMonkey.

Hmm, I guess you've compiled it successfully in the past but upgraded your system since then? That would cause it to have out-of-date dependency information which would give those errors. In that case, it should be solved if you do cd ../premake/src make cleanand then run update-workspaces as normal. You might also need to run "make clean" inside libraries/fcollada/src, and "make -f Makefile.ref clean" inside libraries/spidermonkey/src/js/src, and "make clean" in build/workspaces/gcc, if you get similar error messages in those places. (Is there a nicer way we could handle this problem?)

Urgh, I've had similar problems when running the game but only in Release configurations. I couldn't work out what the problem was (seemed a bit like it was linking against two different copies of SpiderMonkey or something similar), so I gave up - the longer-term plan is to move to a recent version of SpiderMonkey, which has a new build system and should solve the problems with the old version. I've only used the new version on my experimental Hg branch, not on SVN trunk, but if you're interested then I could try getting all the files onto SVN and fixing it to work there...

That sounds unexpected - I've used lots of versions of GCC (4.1, 4.2, 4.3, 4.4, 4.5, I think, all on Gentoo, and typically with ccache) and not had any PCH-related problems (other than some with wxWidgets in GCC <= 4.1, so our premake.lua disables PCH for that). If you have any details of the errors, it might be good if we could work out what the problem is

Hmm, why did you want to disable PCH? I presume the Atlas problem is the libxml2 thread-safe one, which seems to be a bug in the version Ubuntu provides. Seems like the sound issues are possibly caused by OpenAL/PulseAudio interactions (given what's said here); I'm hoping it's not our fault and it'll get magically fixed in the future . Otherwise I have no idea how to approach the problem myself.

Did you run update-workspaces.sh with the --without-pch flag? If you did, I've committed some change in r7224 that should fix it. If you didn't, something crazy is happening - those compile errors should be fixed now anyway, but it would be good to know what the crazy thing is, since it will cause the build to be extremely slow and may cause other errors. (CStr.h declares both the classes CStr8 (also called CStr) and CStrW, via a load of macros, so it's the right file to include.)

To be specific, it's a Voronoi diagram

wcscasecmp should be fixed now. (Can't test on OS X myself, so let me know if there's any problems!)

I've just committed a few changes to the GUI (r7214). Please let me know if anything broke . I should probably document the changes in some way, so: The old implementation had a single global GUI object (the CGUI class in C++) for the entire game, and loaded all the XML files and scripts into it, and the scripts hid and unhid various parts of it at various times, so it was all a big mess. The new approach is to split the GUI into a series of independent 'pages' - currently there's one for pre-game menus, one for the loading screen, one for the in-game session UI, and one for message boxes. Each page is defined by a new XML file, which just lists the other XML files to load into it. There is a stack of currently-loaded pages. Only the page on the top of the stack is active (it receives keyboard/mouse events etc). Scripts can use the functions pushGuiPage(xmlfilename, initdata) to load a new page onto the stack, popGuiPage() to remove the current active page from the stack, and switchGuiPage(xmlfilename, initdata) to replace the entire stack with a new page. xmlfilename is relative to the binaries/data/mods/*/gui/ directory. initdata is an arbitrary JS value that gets passed to the init() function defined by the new page's scripts. In the current collection of pages (which aren't intended to be a well-designed set, they were just the easiest way to split it) it mostly uses switchGuiPage. Only message boxes make use of the stack - various bits of code can load a new message box page, push it on the stack (it acts like a modal dialog box), and pass some callback functions in initdata to make the buttons do interesting things. It might be good to use the stack in more cases, e.g. split the single-player-game-options screen into a new page (plus maybe extra pages underneath that), at some point in the future. One benefit of this system is that it can now support hotloading: if you edit a GUI XML or JS file, while you're running the game and have that GUI page visible, it will automatically reload the files and reinitialise the page. So you can tweak the layouts and get near-instant visual feedback, which is nice. The other intended benefit is that it should be possible to load the session UI page inside the Atlas editor, so you can interactively playtest the game, but that's not implemented yet. There's still a lot of XML and JS that is loaded into every single page, usually unnecessarily, since I haven't tried hard to split things into pages nicely yet - there's a lot that needs to be cleaned up, but hopefully this will help a bit.

There's a crazy idea which I've had for a while, to replace the game's GUI system with a web browser engine. (WebKit in particular, which is used by Safari and Google Chrome). I've never got further than a very rough prototype, but I still think it's interesting, so I'll dump some ideas here and see if anyone has any relevant thoughts. (Warning: This is mostly quite technical and I'm not explaining it well or in much detail.) The general notion is to write the game's GUI (the pre-game menus, the in-game session UI, etc) with HTML and CSS and JS like a normal web page, rather than using a limited custom C++/XML/JS system. WebKit can be used to execute and render the pages, and the output can be copied on top of the game's OpenGL graphics. (The typical UI of a web browser (toolbars and menus and windows and tabs etc) is not relevant here - we just care about the rectangle that web pages get drawn into.) I think the main benefit is that it would provide a lot of flexibility once it's integrated: we could use full HTML/CSS formatting to write an in-game manual describing the history of all the units; we could have an online in-game service to browse and download new maps, or to find multiplayer matches; we could add videos and fancy graphical transitions and effects. None of those are critical for a working game, but they'd be nice to have. Most are possible without a full browser engine, but they'd be much easier if we had one. You can write pages like this (best viewed in Chrome or Safari; hover and click the 'single player' bit for effects) - view source to see that the layout and dynamic behaviour are reasonably straightforward. (Well, straightforward once you understand HTML and CSS and JS and JQuery...) Also it's easy to test using normal web browsers and web development tools (Firebug, WebKit's Inspector, etc). Cross-platformness is a non-trivial requirement. There are lots of ports of WebKit - the original OS X one (for Safari), and a Windows one (for Safari), and Gtk (mainly Linux, sort of works on other platforms), and Qt (presumably works on all platforms), and Chromium (works on all platforms to varying extents; used by Google Chrome), and some others. We want to run on all platforms (by which I mean Windows/Linux/OS X), and don't want to write lots of platform-specific code, so we'd have to use the Qt or Chromium ports. I don't know how well the Qt port works, and I don't especially like the idea of having a dependency on Qt, so Chromium might be more interesting. (There's already a library for embedding Chromium in (primarily) 3D games, and it's used by EVE Online, but it's no longer open source and it's not targeting Linux.) Obvious drawbacks are that it's complex (particularly it makes the build process more painful), and might be slow, and might use lots of video memory, and adds ~20MB to the binary distribution, and maybe it's not really that useful. But I'll ignore those issues for now. General idea for implementation: Create a shared library (.so / .dll / etc) which exposes a plain C interface, somewhat similar to the webkit_web_view_* functions in the Gtk port (which I used in my rough prototype) - create a view, navigate it to a URL, and also send mouse/keyboard events to it, and render it to a plain char* buffer (at least for the simplest initial version). The game engine would set up a view, pass events to it, then render it and copy the output into a GL texture. And it'd have some way to pass events from web page scripts back to the game engine (for "start game" and so on). The library would be a fairly thin wrapper around Chromium's WebView and related classes. The test_shell (particularly test_shell.cc, and web{widget,view}_host_*.cc) has bits of code that use WebView, and could be informative. A better solution would involve running the WebKit code in a separate thread, using callbacks to notify the engine when it needs to repaint or respond to unhandled input events, and only repainting (and uploading to the GPU) the parts that have changed, which might result in more acceptable runtime performance. So I think this could be useful and feasible. But it'd involve quite a bit of complex technical work, and I have enough other things to work on myself, and ought to focus on things that are really necessary for the game, so I can't look into this as much as I'd like . But it'd be pretty neat if it worked, so I'm just throwing this idea out there

"hg diff" should give suitable output, if you're using the command-line client. (I'm not familiar with other clients so I'm not sure how they'd do it.)

Currently it's not in SVN, it's in a separate branch I've been working on using Mercurial, which is at http://svn.wildfiregames.com/hg-source/ (CParamNode is here). I've been intending to merge the changes back into SVN at some point, but haven't got around to it yet. (I've been rewriting most of the simulation system, and want to wait until it's mostly functional enough to replace the old one). So currently it's only accessible through Mercurial, and the build process isn't documented for that. What's roughly required is: * Install Mercurial (Hg) * Use it to clone http://svn.wildfiregames.com/hg-source/ * Check out SVN as normal (in a different directory) * Copy (or symlink) the libraries/ and binaries/data/mods/public/art/ and binaries/data/mods/public/audio/ directories from SVN into the Hg tree. (That's needed because I wanted to keep the Hg repository small by excluding the big binary data files.) Then it should work as normal, I think. Sorry this is a bit messy at the moment!

I added it there. But then I changed my mind since the custom field messes things up a bit (it causes spurious change messages when updating old tickets, and it causes the wrong fields to show in certain query results), so I've removed the checkbox and changed that wiki page to say to use a "review" keyword. Hopefully that'll work better

It'd be technically possible to implement any game with the Unreal Engine, by first deleting all its code and then writing your own - the question is how much its existing features help you. If you're making something like Rome Total War then I guess you'd need a whole new AI system, a new rendering LOD system, maybe a new networking system, probably new map editing tools, etc, so you wouldn't benefit so much from the engine and it may not be worth the complexity and cost (the previous generation engine is $350K plus 3% of revenue). (The free/cheap UDK doesn't give you the engine source code (only the editing tools and UnrealScript), which seems likely to limit its flexibility for these different kinds of games.)

I agree automatic translation isn't much good - I was just thinking of tools in the sense of programs that help humans write translations (showing the English string, giving them a space to type in the translation, presumably including some comments about the context and whatever). I've never looked into this area enough to know what tools actually exist and are good, though - does anyone have recommendations?

Just thought of another option: we only use libxml2 across threads for the map editor, so if you just run "make pyrogenesis Collada" then it'll skip the editor (AtlasUI) and the game ought to work okay. That's not ideal either, but it might be better than nothing.

Thanks, just wanted to check . Looks like it's a newly introduced problem in 9.10, given that nobody has hit that error before. I can't find any indication of why it changed, though. We use libxml2 across multiple threads, so it really needs to be compiled with thread support. I'm not particularly familiar with how these things work on Ubuntu - I guess the options are to wait for them to fix the bug, or to use their source package and tweak it to configure with --with-threads, or to download and install the normal upstream version, or for us to bundle the upstream version and compile it automatically. None of those seem ideal

Hmm, sounds similar to this on OS X. (People have built successfully on Ubuntu before, but maybe an older version (perhaps this changed in 9.10?), and also our code has changed some threading stuff recently.) Could you look in /usr/include/libxml2/libxml/xmlversion.h for the block of code that sets LIBXML_THREAD_ENABLED? Also, could you run echo '_REENTRANT' | g++ -E -pthread -and copy the output? Hopefully one of those should show why it's not working.

The engine currently has a non-standard custom translation system, which is not really finished or usable, and I think the design is unnecessarily complex and weird. (I wrote it myself but I've changed my mind since then ). We should probably replace it with something based on gettext so that it works with standard tools. But that's not a high priority at the moment - as Erik says, we don't even have much English text finalised yet, so it'll be a while before it's important to focus on fixing the i18n system, and we can't do any useful translation work before that.(But since it's open source I'd be happy if anyone with relevant programming experience wanted to sort out i18n sooner (and I'd be happy to discuss the design requirements) ) I believe we could (and probably should) start doing translations long before being ready for release - the tools keep track of new/deleted strings, so we can do some early translations and then do a much quicker second pass when we're nearer release to fill in the gaps. But I agree it's too early now.

Thanks, I've committed the change to jsotypes.h now so hopefully that'll work without manual patching. wcscasecmp just needs somebody to fix it . I won't have time to write it and test it myself in the next few days - if someone writes a patch for it then that'd be great, otherwise I could look at it soonish.

Thanks, I've finally got around to adding your name to the list now, though I've omitted your email address (since putting it in plain text would attract spam, and putting it in obfuscated form would be ugly). I've also added a review request checkbox to tickets, which should make them show up on this list - it's a fairly simplistic approach but it might be enough to help us keep track of things.