janwas

Yes, we appreciate the good intentions of creating an installer, but I'm not sure it's a good idea, either. At this point the game is unlikely to work out of the box on platforms where we haven't tested as extensively as on Win32 (witness the above problem on Vista). What would help is for interested developers to take it for a spin and hopefully we can work out any remaining issues together. However, if non-developers give it a try, it's likely that the only outcome will be frustration for them (it doesn't work immediately) and also ourselves (because they almost certainly don't have a debugger and probably don't send in the crashdumps, without which it's basically impossible to debug exceptions).

Ooh, that would be a mammoth undertaking, see LICENSE.txt for a breakdown of the licenses in use. Wouldn't it be OK to say the licenses are all GPL-compatible?

Greetings! Having read the google translated version of the contest page, Erik aka feneur (the producer) and myself wish you the best of luck for the contest and our blessing to build upon 0 A.D. in order to do so. What specifically do you mean by "change the proprietary work" - are there any non-free dependencies you are worried about, or did you mean replacing the appropriate units by their equivalents from the 12th century? We are always happy to see programmers interested in helping to finish the game and look forward to fruitful cooperation in this area Jan

He mentioned errors related to #pragma pack - GCC was saying that they would be ignored, and our code had some compile-time safety checks that indicated that they were indeed not being honored. Strange, since #pragma pack is mentioned in the GCC docs and I can't imagine that it was added as late as 4.2. Could it be that Apple has some "enable language extensions" switches that are flipped on dev systems but not normally?

Well yeah, but I think pointer arithmetic/casts are even worse Thanks for the writeup!

Caution, that only suppresses the compile error and risks stack corruption. I've now changed the type of "size" to intptr_t to fix this. Correct, my bad. Simon has fixed this in the meantime.

The other thread has been updated

I've been exchanging PMs with arn34. The problem appears to be in OpenAL's header: - the offending function declaration is similar to others except for the use of ALCvoid; - C allows parameters typedefed to void, C++ does not; - GCC >=4.2 are now strict about the error. Using GCC 4.1 appears to be a no-go since it (surprisingly) doesn't honor #pragma pack. The GCC documentation indicates it to be supported, but not when it was added. We need such a feature for various byte-oriented stuff like Zip archive headers, and supporting GCC's insane syntax and the widespread #pragma pack is definitely not desirable. Until the OpenAL header is fixed (which could be quite a while on OSX), I'd recommend manually replacing all instances of ALCvoid with void except for the very first occurence (a typedef).

Ooh, edge of insanity sounds somewhat unhealthy Hope it works better on the new system.

hm. Did you deselect the Platform SDK during VC2005 installation? Have you changed its include path?

Curses, this issue again It is indeed a problem with the timer implementation, but everything Works on My Machine and the cause remains unknown. Can you please post your binaries/logs/system_info.txt and motherboard information? Once the timer goes into an invalid state (which is reported by this error message), just about none of the game logic will work since it's dependent on the timeSinceLastFrame, which is why the units won't actually move. I'll be away for the next two days, but in the meantime you should be able to work around the problem by passing -wNoMahaf on the command line. (Please PM me if that doesn't work). FYI, this bug has also been reported at http://trac.wildfiregames.com/ticket/253.

Great, glad to hear it

Thanks for the pointer Just FYI, the sound problem is hopefully now fixed (see abovementioned thread).

Ah, that explains it. Thanks for the debug info! Line 1621 says "all queued buffers are now considered 'processed'", a claim that was apparently based on from page 42 of the OpenAL 1.1 spec.It seems this is not the case on both of your Linux implementations. Your alSourcei suggestion is good - it is documented to clear out the entire queue and doesn't rely on all buffers allegedly going into the processed state. I'm not sure why I originally went with the vsrc_deque_finished_bufs approach. It's probably better to do the cleanup in vsrc_reclaim and not just during shutdown, though - that way any leaks from game crashes are less likely/severe, and we avoid further contortions in al_shutdown. I have committed a corresponding fix (#7029), but it works either way on Windows. Please let me know via PM if it still doesn't work (though I'll be on the road until Friday and won't have much time during the weekend).

OK When I last tried it, VC didn't manage too big of a speedup (probably due to heavy IO). Thanks! I've gone ahead and committed the changes. (there was one more "for i,x construct" in extern_libs.lua:244)

Bummer, sorry to hear that some 64-bit bugs remain. The rest probably aren't going to be found via simple inspection, I need to get a Win64 build going and debug it. (Unfortunately this can't happen before early next week, am still quite busy.) In the meantime: are you seeing this bug only during the test (which uses the allocator a bit differently) or the same thing also from the game itself?

Thanks for the suggestions and comments! Having had fairly frequent contact with the build system, I'd like to weigh in. Yeah Even the first step, having to manually gather all dependencies, really sucks. I have little dev experience on *nix, but it'd be nice to make things as easy there as they are with our Windows infrastructure. Further requirements include being able to handle dirty Windows-specific stuff (.rc files, manifests) and assembling .asm files. Actually this part has always made me nervous. Newer versions of Premake may well include helpful or even necessary features since its dev model is "only add stuff when people ask for it" (i.e. it's not equipped to handle all needs out of the box). For example, v4.1 includes support for cross-compiling 32/64 bit and other platforms (e.g. Mac), which may be useful. However I agree that we could probably get by with the current version for quite a while. Amen. It's worth mentioning that the build system has 1300 lines of Lua customization plus the logic in Premake proper - replacing that would be a pretty big undertaking. In light of that, isn't there another option besides makefiles or SCons/CMake? Premake also generates Code::Blocks workspaces - would that help, or is using it a pain? Is there anything specific that could be done to make the generated makefiles less painful? Ah, interesting. That's a good argument, creating VC projects is pretty important for Windows devs. hm, is that really a killer feature? What kind of speedup are you seeing from parallel builds?

Great heh, we'll fix the errors one by one until none remain. Sure there can, especially in the realm of conflicting declarations. Googling "cssmconfig.h uint64 redefinition" shows a similar problem, but it is only reported to be a 'warning'. Unfortunately I don't have much advice about how to fix this one :/ It may help to look into the cssmconfig header and see if there are any macros you could define to prevent it from declaring its uint64 (possibly the include guard to just skip the entire header). This macro would have to be defined in our header that brings in SpiderMonkey or (depending on how cssmconfig is included) in the compiler command line (-> premake.lua).

Glad to Thanks for the reminder. I've now committed that patch (works fine on Win32). As to the deer problem, please see post#37.

Some 64-bit bugs should now be fixed. Could you please rebuild and let me know if it still has problems there? (will be heading home for the weekend, will have only intermittent connectivity and no access to svn).

We require the Enet library for networking, but unfortunately I can't help regarding its installation on OSX.

Just a minor addition: ct_oal is examined for purposes of reporting your sound driver version. While -quickstart does skip sound init, it also skips the system-info-retrieval code that results in binaries/logs/system_info (of which sound driver version is a part). Yeah, there are definitely gremlins lurking in that area (Wow64 does magic redirection of the system32 directory). Can you provide more details on what assertion is being triggered?

It's delightful to see 0 A.D. running on OSX - congratulations! I've hopefully fixed the snd_mgr trouble (OpenAL's ALC string types differ between platforms, ugh). Please PM me if it's still broken (unfortunately I can only test on Windows).

It really pains me to see how often this bug is reported online :/ My bad. I've had a quick look and that allocator has several 64-bit bugs (~0 vs ~size_t(0), it's also using 32-bit tags). Most of the time we were testing on 32-bit Windows, and it looks like most Linux users are on 64-bit. Have begun fixing those issues, but unfortunately I left the files at work (am now at home for 1 day of vacation). If a colleague is able to send me those files, then those issues will be fixed later today. heh, yes - this problem with the deer mesh has existed for a while. The problem is that the error message isn't annoying enough to galvanize the artists into action Thanks for the info, I see someone has already added that to BuildInstructions hm, the docs say alDeleteBuffers can only fail with that error code if the buffer is still in use. However there is a mechanism in place for unqueuing buffers and stopping the source, which should happen before freeing buffers (even when shutting down). Unfortunately this problem doesn't occur on Windows (more forgiving OpenAL implementation?), so it's difficult to investigate. Would you be up to firing up the debugger and seeing what happens in vsrc_reclaim when shutting down?

> Bit expensive huh. Yeah, that's out of the question :/ Vista+ already have such a driver built into the OS, so there's hopefully no need for ours (barring any further screwups and bugs). I suppose it would be possible to disable the corresponding code on Vista - would you be interested in doing so? You can also launch with -wNoMahaf on the command line for the same effect. hm, why would the driver signing only be an issue on amd64?