historic_bruno

Would it be possible to display a different error message if the crash dumps weren't generated for whatever reason, and give the path to them otherwise since surely that will be known?

Yes

Wouldn't you need to set the environment variables before running the script? The way you're invoking it, I think they will be passed as parameters to the script and discarded.

I also get the QuickTime warning but it doesn't seem to cause any problems. The OpenAL warnings are bad, what's the result of running uname -a?

OK, in that case can you try using DebugView to view the debug output of the game when it loads and paste the output here?

Unfortunately 0 A.D. doesn't really take advantage of multicore systems yet, this could improve with multithreaded AIs and pathfinding.

Have you tried ./clean-workspaces.sh?

I believe there is: http://www.wildfiregames.com/forum/index.php?showtopic=15427

Right, it looks like the driver wasn't installed/configured properly in the case of the above posts. I would try uninstalling the driver(s), then reinstalling, following which method is supposed to be used on Ubuntu.

This is an important step, because we need more information for troubleshooting Please find the crash dump files in %appdata%\0ad\logs, if they exist, and attach them to a new Trac ticket.

Is it reproducible? Would you be willing to create a Trac ticket for this? Forum topics tend to get buried, and this way people will get emails when the ticket is updated

Don't forget NVTT, Spidermonkey, Enet and fcollada, which are bundled with the source and typically built along with the game. Though depending on how much modification is required, some dependencies could change (for instance, Fam/Gamin is used for monitoring file hotloading which doesn't seem as useful on an Android device).

I've had a problem like this and maybe worse on an old laptop I have with integrated graphics, the background sort of flickers. Obviously some graphics cards and drivers handle this better than others Do you have the latest available drivers? I'm not sure about the audio problem, but you could try running the game with the -nosound option, as a workaround. Also, we're hoping to totally rework the audio system due to various other glitches.

Glad you like the progress we've made There are some economic features like trade that are planned and we don't have true diplomacy yet, and of course our only game type is conquest, but anyway I think warfare will be unavoidable in 0 A.D. Really... most people find it cumbersome to place wall segments one at a time, I think we will actually implement an automatic system of wall placement, hopefully intuitive and working correctly. Something like click-and-drag and it will place wall segments in a connected line between the end points. There are several disadvantages to using walls right now. We could do this with GUI styles, which are supported by the engine but not really used yet. Or we could implement some method of scaling the GUI up/down to user preference. Setting the resolution in full screen mode would work, but there should be a separate GUI setting, in my opinion. I don't experience readability problems, but I think the GUI should adjust nicely for wide screens. My preference would be English names only or English in a large font with native names in a smaller, less visible font. Most of the time I have no idea what a unit or building is

You mean 12/31 I probably won't be there.

Seems like a driver problem? What version of Ubuntu are you using, what graphics card, and which driver?

Do you mean the main menu background is scrolling? That's an intentional effect

Based on your screenshot, I would say it's some weirdness with the camera position or input, because the UI and minimap are there, but there's no orange camera box in the minimap. It's probably offworld, which is why you see nothing, I've had a problem like this before on Windows. Try clicking on the minimap or scrolling, see if your camera comes back, and check that your mouse is not accidentally scrolling the map before the game loads. Either way I think this can be considered a bug.

I've played a 4 player multiplayer game (with 4 humans) and there wasn't serious lag, your best bet would be using few or no AIs, also the map size and features have a big impact. Some maps are prone to poor pathfinding performance right now.

That's interesing, can you run the glxinfo tool and paste the output here?

I don't believe you could keep the same gameplay mechanics or art, because it wouldn't be an effective mobile game IMO. Mobile games require a different paradigm, or at least the successful mobile games I can think of are very different. There are physical limits, the smaller screen limits what you can see with a glance and how big the "world" can be, and many of our models assume you can easily zoom in and out, rotate the camera, and that you're using a 1024x768 resolution or higher screen that's at least 15-17". We also assume you can read small text for tooltips and UI buttons, but if you remove those, you have to remove certain functionality that they represent. You could try for voice command and use the accelerometer control of the device (for camera movement), assuming those worked intuitively, there would still be visual limits. I believe the direction a mobile 0 A.D. would inevitably take is toward a quicker, less historically accurate, goofier, simpler game - at which point it's no longer 0 A.D. I just feel that even if I could play 0 A.D. today on a tablet, smartphone, or whatever, I wouldn't enjoy it. Still I'd be interested to see where such a project went.

I don't see what a mobile version of 0 A.D. would actually share with the standard desktop/laptop version. I mean the UI, gameplay, and art would need widespread changes to be practical for a mobile device (think bigger, "cuter", simpler, gimmicky) with totally different controls, obviously no keyboard shortcuts or mouse click selection. That means multiplayer between mobile and non-mobile devices wouldn't make sense either, so this idea doesn't make any sense to me at all. A first person shooter is not even remotely comparable, because let's face it, all you have to do is run around, point a gun at your enemies and shoot

The problem that affects all versions of OS X with SDL 1.2 is switching between fullscreen and windowed modes or changing resolution, if you want windowed mode, you can just change the game's config file to always start in windowed mode and choose a default resolution. This works fine for me, just don't stretch the window or it will break What about changing resolution or toggling fullscreen/windowed mode? As far as I know, we need to reload our GL state (though I did also see a few 1.2 patches attempting to preserve the GL context in some situations - I don't know if that has been perfected, I still think it's a worthy goal to be able to reload the state).

I've successfully built the game on Lion using GCC 4.2 (though it's very noisy), so it's unlikely to be the problem. As far as using gcc_select, see this article

Here's the SDL 1.2 patch I mentioned. It would be nice if we could make a script to get all OS X dependencies (for developers of course, not the average user), then it could apply that patch to SDL before building it. Hmm I haven't noticed this at all, though I only have a VM for testing. Can you post a screenshot of what you are seeing?