historic_bruno

I'm updating the bundled Boost libs to 1.51, using the binaries from BoostPro which is much more convenient than properly setting up Boost.Build myself I don't think we even use the static libs, but they are included anyway for convenience/completeness.

Why? It's not taking much effort to "support" it, in fact I can't think of anything we've done recently on that front Though I did look into updating some of our bundled libs a few months ago, some of them only include VC2010 projects now, but I'm sure we could get around that with a little effort. If it makes updating the libs or maintaining the game too difficult, then I'd say dropping Win2K support is something to consider. Another factor would be our dropping the fixed renderpath which should greatly reduce the number of Win2K-compatible graphics cards that work with the game.

Hmm, so as long as the main thread updates at least once during the period of the buffer there should be no problem? So far the only case I can reproduce the sound stoppage is loading the map XML for the first time (uncached) which takes about 25-30 seconds on my system. Using a stopwatch it looks like about 28 seconds after music starts playing, it stops during the map loading, and the log would seem to explain that: ERROR: Loaded data of audio/music/Honor_Bound.ogg for 27.863958 seconds ERROR: Loaded data of audio/music/Honor_Bound.ogg for 0.557279 seconds Both of these lines occurring immediately at startup, the next one occurs after the map list is loaded, by that time music is already broken. This is probably a worst case scenario because releases have map data already cached and most users will have faster computers. But it does make me think we need to optimize the map XML loading because the number of maps will only grow over time and users might have hundreds of their own maps. We could use a thread or progressive loading for that instead of expecting it all to load instantly in the main thread. I'll look for other cases of music stopping, I remember it happened sometimes in game as well.

We should just upgrade the Windows boost libs, but build them with VC2008 rather than a newer edition, as that's what the autobuild utility uses and we're still officially supporting Windows 2000 and maybe pre-SP2 XP?

I made a ticket for this: http://trac.wildfiregames.com/ticket/1802

The good news is with the patch, the game loads again on my laptop, the bad news is music stops playing even while loading the maps list and doesn't continue (back where we started on that). There has to be a sensible solution as I've never played another game with music issues like that.

Does every game have this problem or is this something specific to 0 A.D.? If the latter, we need to look into using the best available graphics card.

It wasn't a bug in the sound manager, but the new threaded design calls the timer code much more frequently, which exposed the actual bug. I'll try the proposed patch on my laptop and see if the game starts and hopefully sound will still play smoothly.

This is the only outdated link of the ones you posted Probably the first and most important part of an RPG mod would be having a single playable character and locking camera / movement onto them.

Great idea. Here's a bunch of them http://www.wildfiregames.com/forum/index.php?showtopic=15553&st=20#entry249621

It could be triggering race conditions elsewhere, I suspect #1729 was one of them.

Have you tried the COLLADA Wiki? That should have plenty of info, though it may be best to ask on the forum if you have a specific question. Another valuable resource is the COLLADA spec. If you're converting one format to another, then you need a good understanding of both (I'm not the least bit familiar with "pssg").

I wonder if these threading issues could also be responsible for #1763.

Hi, can you attach the system_info.txt created in the game's log folder? That will give us some more info about your system. I wonder if there's not an error that is being missed since it starts in fullscreen mode. Try setting windowed=true in the game's config file as described in the manual. This will take some troubleshooting, but there's a few other things we can look at. If you can, download and run Microsoft's free DebugView utility, then try running the game. DebugView should log some output from the game that might show us what goes wrong, paste that here. I haven't heard of the game running successfully on a netbook, unfortunately I don't have one to test. I don't know a reason (yet) that it wouldn't work, there could just be a small problem we need to fix. This is the only other report I've seen of the game failing on a netbook, also Windows 7.

I don't know that it should be implemented in C++. For comparison, technologies (including template loading) were implemented entirely in JS. The advantage of using JS is it's much more convenient to access simulation and UI state (IMO) rather than passing it back through C++. It's also much more cumbersome to work with JSON on the C++ side of things -- assuming we'd want to use JSON to define triggers/conditions/effects. For how this might work, we already parse and store the JSON map settings when reading a map, the same could be done with triggers (in a separate object I think) and then it would call some JS init function that initializes the "trigger manager" and parses the triggers object. Accessing them in Atlas will be messy either way, because AtlasUI runs in a separate thread and uses message passing to communicate with the engine, however it does have a script interface and the ability to parse JSON objects (it does this for map and player settings).

I split the trigger discussion to its own topic here, so it's easier to find

Yeah pure "red" and "green" are probably not suitable, it would need some tweaking to find a good color. However, I think we should be careful about how we use color to distinguish things in the UI, and especially careful about using color as the only difference to make e.g. text stand out. There's almost always a better way to do it. Someone has already proposed using color for failed tech and resource training/building requirements, so there would potentially be a lot of color used in the tooltips. It also makes it more difficult to find useful information, because the player's eye will be attracted to the red text, when all they really care about is costs, or health, or something.

It has been demonstrated as a proof-of-concept that the game can "work" on Android. We don't have any plans to purse it beyond that though. If the community is interested, they can work on it, but judging by the lack of progress/updates, I'd say it's not anyone's priority...

^ This would be great on a Trac wiki page Maybe you could expand http://trac.wildfiregames.com/wiki/EngineProfiling and make it more "friendly".

Indeed, thanks for looking into that. In some cases it actually prevents the game from loading on single core systems and can lead to an error in the WMI code on Windows (presumably it times out or something, since the sound worker thread begins very early in init). If you get a fix, please commit it ASAP.

You're not installing it to the default location, which is in the user's home directory (you should have permission to do so unless something is very wrong). That is actually where Microsoft prefers applications install themselves, though most ignore that and use Program Files instead. If you need to install somewhere that requires admin permission, simply right click on the installer and choose "Run as administrator", but most users won't have that problem and I haven't seen it reported very often.

Right, I think there's already a ticket for the technical issue. However, I didn't notice zoot already made a ticket, so I'll close mine as a duplicate.

Made ticket for this: http://trac.wildfiregames.com/ticket/1784

Glad the problems are fixed anyway

Good to know, probably the compiler changed and wasn't compatible with the previously built SpiderMonkey libs, etc. I would suggest Geek also try cleaning workspaces.