historic_bruno

Looks like it can't find the game data for whatever reason, did you install the 0ad-data package (if applicable)? If so, how did you launch the game?

Right, I just wish there were Trac tickets for that, to clarify what is needed and what work has been done so far Otherwise I don't expect any progress on fonts, there are plenty of other things that need doing. Did you have to modify fontbuilder to add new effects/settings, if so can you make a git branch or attach a patch somewhere?

In fact, it's good to have a clear license for any content added to the game, even community content about the game, because the question will inevitably arise when someone else wants to modify or use your work, whether or not that's allowed and under what conditions

You could be seeing bugs in the debugger (heh), to be sure, try adding some manual debug output using one of our JS logging functions. All I know about the JS debugger is that it runs, I'm not sure how often it's tested or if the output is ever validated.

Most of the progress/discussion occurred on IRC, such as here. Basically, rewriting the font system would have inevitably resulted in a lot of bugs and limitations but not a lot of new features. It's kind of weird to go through all that trouble and just omit complex text layout, for example, especially when the existing font engine already has Unicode support and supports as many effects as we can think of by modifying Python scripts rather than C++. All that's needed for prettier fonts (short of a redesign adding far more than the above approach) is for artists to request new fonts or effects somewhere like Trac, and a programmer to generate the textures or walk them through the steps for doing so. I haven't seen that in the last 3 years, so if someone is unhappy with our fonts, they aren't documenting it well, if at all.

You're certainly not the only one having problems with Mavericks, but they are all slightly different. I may have to get a Mavericks install locally and spend some time working through this. Thanks Apple...

I don't believe FCollada is actively maintained, so any changes will have to come from us (#562 is relevant if anyone is interested) I would prefer to ignore the warnings, unless they cause noticeable bugs in the game - nobody here understands all of FCollada, or what could break on one platform by "fixing" harmless warnings on another.

Are you having permissions issues? If you simply copied files from one computer to another, that is something that comes to mind. Make sure your account has read/write permissions on all the 0 AD sub-directories. Indeed that's a bug in the build script, it should remove .already-built when --force-rebuild is used.

According to the call stack, the failing function is ChangeDisplaySettings. There are numerous error conditions but without the error code, it's hard to debug, the way we handle the error now is rather useless I'll try to improve the error handling in these cases to display some useful debugging info.

Do you mean the bundle build? The lib build script doesn't have an SDK hardcoded, you would need to set the SYSROOT env variable, which shouldn't happen by accident (and it's not necessary unless you want the binaries to run on multiple computers). Which version of Xcode? Which version of the command line tools? (the results of gcc --version could be informative) Have you upgraded Xcode/command line tools recently? Premake doesn't generate Xcode workspaces the way it should be done (using the "new" 4.x+ schemes concept), that is a known problem and one reason why I never use Xcode to build the game BTW I don't know if it's documented anywhere or not, but it's not a good idea to mix the command line build scripts with SDK and Xcode, since Xcode has its own ways of doing SDK / targeting that might conflict. That's a completely untested scenario but I know there are many ways it could go wrong.

Today there was an avalanche of OS X related commits, the SDL-Mavericks build error should be fixed. gloox has been added to the lib build script, so the lobby can be built and tested. Kieran (k776) has reported the build currently fails on Mavericks, if anyone else has upgraded, I would be interested in hearing if the game builds successfully or not using latest SVN. Building against 10.9 SDK on Mountain Lion works for me now. Please note: OS X devs will need to run ./build-osx-libs.sh again to build the new dependencies, and if you've recently upgraded to Mavericks, it is advised that you run ./build-osx-libs.sh --force-rebuild, and later ./clean-workspaces.sh to perform a clean build.

I tried a clean build against 10.9 SDK starting with build-osx-libs.sh, the first error I encountered was related to "CGDirectPaletteRef" in SDL. That type was deprecated and has now been removed, it has already been reported and fixed upstream. I don't know if there will be another SDL 1.2 release, so we may have to apply the patch until we're using SDL 2.0 It seems like there are Boost problems as well, both in the build and (with other build options) at runtime, but I haven't found the cause yet.

Every MB is precious when you only have 512 for both CPU and GPU The way our game is now, I wouldn't try to run it with less than 128 MB video memory either - ideally we would have better control over which and what size textures we're loading. So yeah, any fat that can be trimmed from the OS would help a little, I've thought about other possible distros. I don't think it will help performance much, but it should let the game run longer before it runs out of memory and dies

Also mention what you were doing when you used Alt+Enter, was it main menu, loading screen or during a game?

Photos of 0 A.D. running on Raspberry Pi You can see it's quite a simple setup: just the Pi, an LCD monitor (a TV works too), and a USB nano receiver for keyboard and mouse. I'd be happy with controlling the fullscreen resolution through standard SDL API Windowed mode isn't critical but it's kinda nice for testing and debugging.

You're right about that, they were invalid enum (0x0500) errors and unrelated to the other problems. Thanks, I was wondering which commands could tell me this. A few times malloc failed somewhere in the engine and it crashed, I've also seen GL out of memory errors (0x0505) before a crash. Another thing I suspect is there are problems with disk access, I couldn't get the main menu to load at all until I switched from the public.zip to SVN data, then I moved them back and it worked with no other changes. I tested the zip separately and it seems to be OK. Last night I got a bit farther by decreasing desktop resolution to 1024x768, the main menu background loaded and the game seemed more stable. The Pi platform code in SDL2 only creates a fullscreen window at full resolution, so I have to change the desktop resolution. I autostarted the blank default map and it loaded OK, the text rendering and LOS were correct. I have not yet been able to fully load a real game, but at least I can take some photos and screenshots now Performance varies, the menus are very slow to respond of course and game loading takes a long time, but the menu framerate hovers between 4-20 fps so it's usable. Next I would like to experiment with smaller, lower quality textures, perhaps by hacking the texture loading code as you mentioned in IRC. If I have time, I might look into improving Pi support in SDL2, so I can use arbitrary resolutions, toggle fullscreen mode, etc.

This is only somewhat related to Android development, but just for laughs I tried to get 0 A.D. to run on a Raspberry Pi. It's really far too low-end of a platform to be practical for actually playing 0 A.D., but it's still fun to see the game running on unusual platforms, especially one so cheap and low power as a Pi. My Pi is a Model B with ARM CPU, 512 MB shared RAM, 16 GB SD card, connected to 1920x1080 monitor via HDMI, and running fully updated Raspbian OS. Pictures will come once (if) it's running stably. In theory this is all possible, because the Pi is an ARM device and Josh, Philip and others have worked to get ARM support working nicely for 0 A.D. (originally for the Android port) and most of the game's dependencies are already available as ARM packages in Debian, which at least the Raspbian OS is based on. The Pi also has an integrated GPU with OpenGL ES 2.0 support, which is partially working in 0 A.D. SVN. I fixed up some of our rendering code that was broken on GLES, available on my Github repo here, and updated our SDL2 support here. Note that SDL2 is required for supporting GLES and has vastly improved support for mobile devices. The changes in these branches will eventually make their way to SVN, but for now, they can be pulled for anyone wanting a somewhat working Android/GLES build My approach for getting the game to work on the Pi was to begin with a custom cross-compiling GCC toolchain, using distcc to distribute the bulk of the compiler processing burden onto an Ubuntu VM providing 4 cores, to avoid the Pi's incredibly slow CPU and disk I/O. crosstool-NG was used to build the actual cross-compiler toolchain, vaguely as described here. This proved to be quite a headache, not least of all getting my network configuration set up so the Pi could communicate with the Ubuntu distcc "slave". Next I had to check that all dependencies of the game were available as ARM packages through Raspbian or if they could be built separately. Surprisingly, most of them were already available, though a few had different names than on Debian/Ubuntu. SDL2 was not available, so I had to download the source and compile without X support. That's important because GLX, which SDL typically uses on *nix, is not supported by the Pi's proprietary GLES drivers, but SDL2 defaults to using X when available. Instead, rendering has to use the EGL backend on the Pi, luckily SDL 2.0.1 has basic Raspberry Pi support that does all the Pi-specific initialization required. The only other dependency that was missing was NVTT, our bundled copy in SVN has patches to build on ARM. Compiling software on the Pi is incredibly slow, with distcc and decently powerful slave devices, it becomes bearable, but it will still be slow during e.g. preprocessing and linking. If you can get a cross-compiling environment working on desktop Linux, that might be the way to go, and I might try that next. Once I found the right combination of options for SDL2 and premake, the process went smoothly, but there are a lot of problems to get that far. I would say it takes at least 45 minutes for a clean build of the game using distcc with my Ubuntu VM, compared to less than 3 minutes to build the game normally on the same VM. SDL2 clean build takes maybe 5-10 minutes additional time, the same for NVTT and FCollada (neither are really needed though as will be seen below). After getting the game to build on the Pi, the next challenge was making it run. Once I figured how to build SDL2 with udev (required for keyboard and mouse) and EGL support, the next hurdle was that texture conversion was impossibly slow. I was staring at a mostly gray main menu screen with about 2 textures loaded for quite some time, before I realized it wasn't frozen but busy converting textures! It's also possible NVTT wasn't working 100% correctly as there were a lot of GL errors being logged. So I chose to create a public.zip archive like we use for releases, with all the textures, models, and XML precached, and copy it onto the Pi in place of the SVN mod data. In the end, I got the game to load the main menu a few times (buggy as usual on low end hardware, maybe due to the massive scrolling background textures with transparency?) Using autostart, I even got a game to load once before textures were working, but it typically fails pretty hard during loading. There are either some software bugs, it runs out of memory, or the hardware/power supply is being overstressed. It's hard to troubleshoot because whatever is going wrong kills the network connection (so I can't SSH into it) and locks up input, so I can't close the game window. It could even be an assertion in our code, and it's unable to minimize the window and release input like it normally would (Pi support in SDL2 only allows creating a full screen window, not changing mode to e.g. windowed). I'm satisfied that the game can be built for, and run on, a Raspberry Pi, but it's not yet to the point I can demonstrate it working reliably, if it ever will. Hopefully it will work again and I can get some quality photos and screenshots, because I think it's a pretty cool demonstration of 0 A.D's versatility and the capability of low power ARM devices like the Pi Sadly I don't have a smartphone with nice CPU and GPU, that would be a much better test platform, but the nice thing is I can develop, test and debug much of the same code on a $50 Pi, that would be reused by a $400 smartphone or tablet.

Interesting note for Retina users: SDL 2.0.1 now has SDL_WINDOW_ALLOW_HIGHDPI as an option for SDL_CreateWindow, which seems specially included for Retina displays.

Interesting, so you were able to play the game and the entire UI worked in fullscreen? How does it compare to the old A14 bundle: http://trac.wildfiregames.com/wiki/LatestReleaseMac

Maybe we should wait until their translations are included in the game before crediting them? I would imagine that is how most projects handle it.

That's disappointing, I guess it will have to wait for SDL2 support to test the next possible solution. Jagst3r21 in IRC tried it on 32-bit 10.6.8 with Nvidia graphics and it worked. Also sent it to someone with 10.8 and no issues were reported. So at this point I think it must be an issue particular to Fabio's setup. At least everyone else has reported that it works, even if it doesn't fix anything that was broken.

I know you won't have time to change it, but that statue looks really bizarre for a monument to conquest. It seems like an old scholar or something, which I'm guessing is not the impression that would have been desired I would imagine something more aggressive and imperial.

Nobody wants to try it? Fabio did and reported weird graphical glitches that I don't see on my test sytems. I made a Github repo with the SDK-related changes, if anyone wants to test, though it seems even less likely: https://github.com/historicbruno/0ad/tree/osx-sdk-fixes

What resolution is the TV? If it's less than 1024x768 (our minimum supported size), then the UI will be messed up. So for example 720p HD will be a little smashed, 1080p should work fine, and anything much less than HD won't work very well at all.

What does this mean? Are you reporting a bug, can you be specific about what it is?