historic_bruno

Which graphics card are you using, and do you know which drivers? I don't know if it makes any difference, but it could help in reproducing the issue. Also which version of the game?

It worked perfectly, so I committed a variation of your patch (r12834) Please test and see how it goes

I agree that we probably want a better/new animation system. If you look at GameplayFeatureStatus, "dynamic ship animations" is listed as a desired feature. As far as I know, that requires more precise control of animations. It's not a small task, but doable. Gate animations would also be simplified and improved.

This is why I said offer the videos for download, for people who don't want to use online viewers. This is no problem as long as we have the original AVI videos. It's no more difficult than putting them on our web server somewhere and linking them from the release download page(s), or something. We can bundle them if we do physical CD/DVD or thumb-drive releases at some point.

I like this idea. For one thing, using XML would eliminate the need for having our own custom parser, and it's a fairly flexible format. The tradeoff would be slightly less readability for people who don't understand XML, but an in-games options menu would mostly negate that concern.

Also use the in-game profiler by pressing F11. If "render" is taking the most time, then it may well be your graphics card or lack of optimizations in our code, but if you see "sim update" taking much more time, then it's likely nothing to do with your graphics card. FWIW, I think a 7600GT should work well enough with 0 A.D., at least with basic settings.

I don't think there's a way to import .psa files, those are what our engine uses internally. Worse is that it's a lossy format (discards bone hierarchy, for instance), and in many cases there's no way to recover the original data. Hopefully we will replace them all with DAEs at some point. If there's a specific file you need, we might be able to provide the original .max file, depending on availability.

From IRC: One thing to keep in mind is that the password reset doesn't actually work, despite it sending emails to the contrary.

I like tutorial videos as an option, but the game data is already growing quite large, so I wouldn't bundle them. We could simply link from within the game to YouTube/Vimeo/whatever. Even if we had downloadable tutorials as a modular option, we wouldn't really be able to compete with the options and quality of established streaming services like YouTube. Plus, nobody wants to wait for a full HD video to download before watching their tutorial, and compromising on quality or resolution seems like a bad idea So we could offer the original videos for people who want that, otherwise direct people to YouTube/Vimeo/wherever - the best of both worlds.

Confirmed the bug. I will let Philip know about your Trac issue, is your username there also "zoot"?

Create a Trac ticket and assign it to stwf.

Tested Polynesia map @ 1920x1080 fullscreen, map revealed and zoomed out. Both fancy and super fancy are about 60-62 fps, very little difference when switching between the two. Win 7 64-bit, Radeon HD 6850

Ah thanks! So the cwd isn't always binaries/system! I did some testing and noticed that if I open the game from Finder, the cwd is /Users/Ben, so indeed Atlas and Collada loading are broken (this problem doesn't occur on the official bundles because it uses an absolute path with the bundle's framework directory). 99.99% of the time I use terminal to run the game, and in that case the cwd is binaries/system, so it just happens to work by relying on dlopen's cwd path searching Wraitii's solution looks like it may be the least evil (another option would be setting the current directory), so I'll test it some more and commit to SVN, then merge it into my github osx-build branch.

Hi, welcome and please see our known problems list, which answers your question and offers tips for avoiding performance problems.

Hmm but that still doesn't explain why it works for me and not you. I've made some local changes for OS X building, but I'm pretty sure the path for loading libraries is untouched for non-bundles: DllLoader.cpp (I'm testing by running a loose binary, not a bundle). I'd really like to get to the bottom of this annoying problem

About Atlas and super fancy water, I did an experiment and it's actually quite simple to do away with the g_GameRestarted hack, because the simulation sends MT_TerrainChanged messages whenever terrain changes including when a map is loaded. CCmpWaterManager can handle this in a similar way to how CCmpTerritoryManager does. When terrain is not being modified, it works quite smoothly as expected and the foam/waves look correct. The problem is when terrain is modified (or the water height adjusted - don't forget that case), the update is so slow, there is a noticeable delay in the rendering. It would be very annoying if this happened in Atlas. At the same time, it's not easy to preview how the environment settings will affect the super fancy water in-game, so I think this problem should be solved. Is it possible to optimize the update code, or can it be split into multiple steps and stretched across frames, or moved into a thread, instead of forcing it into a single frame?

More info would help, can you attach system_info.txt from the game's log directory?

The game has to be running when you use that command. For me it shows: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pyrogenes 207 Ben cwd DIR 14,2 3672 324263 /Users/Ben/0ad/binaries/system so dlopen should be finding libAtlasUI and libCollada, and indeed it works without any @executable_path hack. Maybe for you and wraitii it's something different?

Great news! It looks like the argument was made that whether we call the game "Alpha" or not is irrelevant and can't be used to justify deleting the article, if 0 A.D. is noteworthy enough for an encyclopedia, and they feel it is Thanks to all who participated in the discussion and got the article restored.

It prevents the game from using OpenGL's vertex buffer objects, so some of the rendering data is stored in system memory instead. Otherwise VBOs are enabled by default, if the driver claims to support them. Hmm, it would be nice if we could detect that and handle it gracefully (ommitting features that exceed the limits), but I don't know how much time we can/should put into that? That crash or similar, has been around long before any changes you've made. IIRC changing novbo didn't always solve the problem. My laptop was able to reproduce the crash, so I might be able to test, if I know how to debug it (I don't really like blaming it on drivers since it occurs with different brands).

Please attach crashlog.dmp as well. You can zip it. Also see this if you're interested in debugging. But even crashlog.dmp would help.

Well it's reasonable that it works with AOE3 since that game uses DirectX, not OpenGL, the drivers would be completely different. Also your card is literally on or below our minimum requirements (OpenGL 1.3), so it might not work perfectly. Perhaps myconid (our current graphics expert) would have some ideas.

Can you try that lsof command and see what pyrogenesis' working directory is?

Have you read the modding guide? We don't have anything so specific yet, but that's as good a place to start as any. Keep in mind, since 0 A.D. is still in Alpha and under heavy development, any gameplay mods you work on will need to be updated as we progress. Mostly to create a new faction you need to first create a new mod (after reading about how they work) and add a new civ "JSON" file like hele.json. Then start adding entity templates and art for your new faction There shouldn't much gameplay logic that has hard-coded civs, other than AIs, some technologies, and a few random maps.

Does Atlas work without that change? If Atlas works, then I don't see why Collada wouldn't work, since they are in the same location. Of course if Atlas fails to open too, then that may be the best solution. If one works and one doesn't, it sounds more like an issue with our Premake script (but what?). According to Apple's documentation for dlopen: The working directory should be binaries/system? You might be able to use lsof to find out the cwd, like "lsof -a -d cwd -c pyrogenesis".