historic_bruno

Thanks for the report I don't know what the story behind this is, maybe it's left there as a reminder that it needs fixing Are you referring to Alpha 6 by chance? This problem should be fixed in SVN (r10064 was the relevant change).

How about CSIDL_PERSONAL aka My Documents? I think that's the best location for games to store data because it's easily accessible from several locations (start menu, any explorer window, etc.)

I don't know anything about git, but no - it needs one patch to be fixed first

And now the much improved Atlas on OS X...

I agree, the user data should be more accessible than it currently is

Is it possible to get XCode to switch the active target when changing build configuration? Like when I switch between Release and Debug, it doesn't seem to switch "pyrogenesis" and "pyrogenesis_dbg" (this doesn't seem to affect the build target, only the run and debug). I don't know if it's a premake4 problem or an XCode problem.

Just an FYI, I committed the latest patch to our new build system (r10154). So "--without-pch" should no longer be necessary for building with Xcode, please test if you can

Your link mentions the fix (Alpha 6 didn't support building against Boost 1.47). So you'll want to either: downgrade your boost lib to 1.46, or probably better, try compiling from the latest SVN source.

What version of the game are you using?

The GL canvas isn't being updated properly when the size changes, it stays stuck at the initial resolution (which happens to be 320x240 - thus the ugliness). I've got a fix for this but it causes the game view to flicker when the window is resized or moved

The UI alignment is all broken, but I think that's because it's forcing a minimum size for wxButtons, maybe that can be set to (1,1) and expanded evenly. The toolbar is missing entirely, or maybe hidden under the title bar? The game view is more broken, it's all pixelated as theShadow pointed out (wrong resolution?) and the coordinate system is different than we expect so mouse events behave differently.

To put it another way, the location where you run the binary becomes the working directory and the game only supports binaries/system (because all the game data paths are relative to that, not just the libraries)

Yeah, people get that on both Windows and Linux. If I understand correctly, it's not a serious error but gives us some additional debugging info for Jan to work with, and so it could be disabled if we can't solve the underlying issue by Alpha 7. Jan would know more about it though

Atlas on OS X, it's not pretty but it works.. somewhat

It looks like you're running the binary from the binaries directory instead of system, where it expects to find all the libraries.

I think getting Atlas to compile on OS X with wxWidgets 2.8 is a lost cause, it appears the Mac Ports devs have also given up on this and are suggesting people migrate to 2.9 instead. There are other issues than this, namely the Carbon implementation (which doesn't support all 64-bit APIs) has different constructors for wxGLCanvas, so I thought maybe we could add macros for that, but this would only help older 32-bit Intel Macs building with wxWidgets 2.8, I think they could just as easily upgrade to 2.9 instead - in the very unlikely event that anyone tries. I uninstalled the wxWidgets stable (2.8.12) port and installed wxWidgets-devel (2.9.1) and it seems to build fine for me in OS X 10.6, with a few changes (r10095). Philip also made some earlier updates to get us 2.9-compatible, so I think we can focus on that.

My guess is that it was http://trac.wildfiregames.com/ticket/898, which has been fixed for Alpha 7.

Pie or bar charts, they can either be for all samples or averaged over fixed periods: OS (Windows/Linux/OS X) Windows version (2000, XP, ME, Vista, 7, ?) Linux distro, and maybe kernel if it matters? OS X release (10.5, 10.6, 10.7, etc.) [*]Graphics card maker (ATI/AMD/nVidia/Intel: possibly subchart for each?) [*]CPU vendor (AMD/Intel: possibly subchart for each vendor to show important distinctions, not just clockrate?) [*]System architecture (32/64 bit and/or 32-bit userspace on 64-bit) [*]RAM (under 512MB, 512-1GB, 1-2GB, 2-4GB, 4+ GB) [*]Supported OpenGL version Graphs: Release adoption (does anyone still play A3?) Avg. framerate by release Avg. framerate by graphics card (and maybe other criteria, like OS) Some moving averages (maybe 1 month window) of above data to show adoption of new technologies

Ask yourself: are those games tailored for Linux or Windows? Also commercial games will obviously have many resources at their disposal, so they can optimize and tweak every little thing to gain another 1fps increase. Since we're open source, anybody with the knowledge and time required could join and help us optimize the game, but it's not feasible for us to focus on only Windows or Intel (by comparison we plan to support Windows XP+, Linux, OS X on Intel or AMD with Nvidia/ATI/AMD/Intel graphics, oh and 32 or 64-bit builds).

Even the newest Intel HD 2000/3000 graphics are the equivalent of a low end discrete GPU, from what I've heard. Here's a snapshot of performance (it's a few months old). Ah, I thought it was in A6 for some reason. Hopefully that will help to try

Mythos: You're mad as hell and not going to take it anymore? Also there's a ticket: http://trac.wildfiregames.com/ticket/886

Oh right, I misinterpreted your comments Think the PCH support is still broken for Xcode, we haven't applied the patch for it yet. Try adding the --without-pch flag when running update-workspaces-new.

What's the call stack like when it crashes?

Hmm, I think this is worth looking into as I'm seeing more reports of mouse lag and general slowness on Linux. By the way, that was just standard debug output you saw, nothing abnormal there

Use Run > Debugger (for me in Xcode 3) > Build and Run, seems to work fine