janwas

Actually, it sounds like the version of NASM in play doesn't support x64 at all. What does "nasm -v" say? The Windows EXE in svn\build\bin is 0.98.39. The list displayed by "nasm -hf" doesn't include elf64 and win64, which is a clear indication that it doesn't support x64. I am using the much more recent (but still old) 2.06, which is sufficient. Are you able to upgrade NASM?

Thanks, I wasn't aware of that Hopefully it'll help the people who are running into this.

Indeed It's a good thing the browser allowed navigating back after that edit, hehe.

hm, if it works one day and not the other, it might be something related to dependency checking, timestamps or screwups during parallel builds. However, that option I mentioned is in the linker settings -> General -> Use Library Dependency Inputs.

That can easily be changed In the meantime, I've added the missing options, but that apparently wipes out the previous votes. Doh! The previous state was "4, 1, 0, 4, 0, 1, 0, 3, 2, 0, 1".

hm, I've never seen that one in (admittedly infrequent) VC2008SP1 builds on a 2x4 core machine. Are you both using SP1? Besides the parallel build issue, does it help to toggle the "Use Library Dependency Inputs" linker option? PS: VC2010 actually looks like a useful upgrade, we'll hopefully be getting that mid-May.

1920x1200 here. Though a second monitor is now available, I'm still running in 1024x768 windowed mode (probably due to habit/inertia, but it is more convenient during development). Philip: nice! What monitor is behind the 2560 number?

That's what gates are for And depending on how bad the area of effect damage is, you'd have to think twice about running into artillery. hm, I have very mixed feelings about that CoH feature. If heavy artillery is in play and you retreat, expect the opponent to know exactly where your (Axis) rally point is and drop a well-timed barrage on it. Add to that inexplicable delays before retreating and the ability to temporarily block those units, and you have a recipe for disaster. On the plus side, at least those pesky snipers can be chased down with jeeps/krad. It seems hard to pull off such a feature and make it seem fair. Shouldn't even retreating units still be slaughtered if they run by emplacements? They are by British Bofors, but not by everyone else's heavy MGs, nor Axis mobile antiair. I bet this feature would be equally controversial/annoying in 0ad.

OK, so wopen (which just converts to UTF8 and calls open) is failing. Insufficient access rights is the usual cause, so we report that (*), but it needn't be that case here. Another possible reason is filesystem encoding - is it UTF8? Could you please add some instrumentation to file.cpp, e.g. debug_printf(L"pathname: %ls\n", pathname.string().c_str()); before the wopen and debug_printf(L"errno: %d\n", errno); afterwards? * It would be better to return LibError_from_errno(); and ensure all file-related errnos are included in an ERROR_ASSOCIATE (EACCES already is).

This is indeed a very useful feature, and it's also done by Supreme Commander, where the zoom is critical to gameplay.

Hey Goblor! I'm glad to see your interest turn into enthusiastic participation Welcome aboard!

I appreciate the good intentions, but an installer is still probably not a good idea (see http://www.wildfiregames.com/forum/index.p...howtopic=12533). There will be a pre-alpha release quite soon, and fairly regular releases after that. In the meantime we'd be happy to see programmers giving the code a spin, but making things accessible to gamers via installer will probably only lead to frustration on both sides (witness the above thread).

update-workspaces is "only" required when files are added/removed to the project. Since it does take a little while (VS isn't great about reloading solutions), it's best not to run this before every build. I guess hooking into SVN would be possible for this purpose, but definitely overkill. The most economical solution is to get into the habit of checking for relevant SVN messages (whether a file was added/removed) and/or to try updating the workspace whenever build failures are encountered If there's a nicer solution, I'd love to know about it. Philip: build indeed succeeded on Windows here (VC2005)

Greetings! You're apparently missing the Spidermonkey library for Javascript. Have you tried running "./update-workspaces.sh --with-spidermonkey-tip" as suggested here? (http://www.wildfiregames.com/forum/index.php?showtopic=12757)

I've not noticed any performance problems or lack of inlining in that case, but have no objection. Even better, how about a global search+destroy of cpu_memcpy, replacing it with memcpy? (the optimized memcpy is no longer necessary, see http://www.gamedev.net/community/forums/to...opic_id=560308)

hm, I'm not able to study the VFS lookup internals today (#459 definitely sounds like a bug there), but a quick workaround for #458 exists. We skip touching mods/internal in any way if -onlyPublicFiles is passed on the command line. That switch made sense from our perspective before OSing (allowing testing of the public version without breaking most artist's files by default). However, in the current situation it'd make sense to flip that around, not using internal at all unless the internal mod is explicitly requested. What do you think?

Nice one I like how the lighting angle is chosen to cast shadows on that hill Thinner beams definitely sound good, though (think about the figures carrying one of those). About the naming convention: wrld is good, that matches the existing naming and seems applicable here.

Thanks, Erik

It's good to see some numbers; what a great speedup, thanks for doing this! I may be able to look at this later today..

We've had to require 10 posts before enabling PMs to combat the spam problem. Unfortunately I can't see where this can be disabled for individual users in the control panel. Erik, can you give me a pointer?

Yeah, sounds good, I think this is what Simon/olsner was doing. Righto, copy-pasta coming up! Gentlemen, start your forks: 17:43 < olsner> someone<tm> should implement that "unity build" (or whatever someone called it) system for 0ad 17:43 <@Philip-> I think I prefer incremental builds that aren't as slow as full rebuilds 17:45 < olsner> I think you can bundle up quite a bit of code until you reach the point where your own code is larger than the amount of headers 17:45 <@Philip-> The headers are all precompiled :-) 17:46 <@Philip-> ...I suppose they could be precompiled in a unity build too 17:47 <@Philip-> but incremental builds currently take a fraction of a second per file, and I can't imagine that compiling n concatenated source files wouldn't be significantly slower for large values of n 17:48 < olsner> unless the time is spent doing complicated stuff like template instantiation, I think we should be able to speed the build up by 10x or something, based on the number of lines of code 17:49 < janwas> olsner: unity builds are a great idea, we've been wanting to do that for a while. 17:50 < janwas> Philip-: i think it's common practice to enable incremental unity builds by disabling the unity step for whatever subproject you're working on 17:50 < janwas> that way, you'd get faster full builds while still allowing incremental 17:50 < olsner> but yes, there's a tradeoff in the size of compilation units... I think once each unit takes more than half a second you're starting to slow down incremental builds 17:50 < olsner> but until then it'll just be faster the more you concatenate 17:51 <@Philip-> How much code can you have before compilers run out of RAM? 17:52 < olsner> hmm, I have some data on that, but it's not readily available right now 17:53 <@Philip-> If I remember correctly, the source files that compile the slowest are the old simulation entity ones that have lots of headers full of lots of giant templates 17:53 < olsner> for some category of files, 700 files was too much (they required about 2GB of ram for gcc, 5 minutes to compile with optimization) 17:53 <@Philip-> but hopefully they'll be obsoleted and removed soon anyway 17:54 <@Philip-> Link times are the biggest pain in incremental builds now, and gold seemed to help with that 17:54 < janwas> hm, CMake seems to make unity builds fairly simple (http://cheind.wordpress.com/2009/12/10/reducing-compilation-time-unity-builds/) 17:54 < janwas> Philip-: "gold"? 17:54 < olsner> unity builds improve link times too 17:55 < olsner> less debug info and less I/O overall 17:55 <@Philip-> janwas: [url="http://en.wikipedia.org/wiki/Gold_(linker)"]http://en.wikipedia.org/wiki/Gold_(linker)[/url] etc 17:58 < janwas> Philip-: ooh, hadn't heard of gold. nice! 18:01 * Philip- imagines it shouldn't be that hard to add unity builds in Premake - when the script collects the list of source files, just write a single new file that #includes them all and put that into the project instead of the individual ones 18:02 < olsner> yeah, shouldn't be too hard... one unit per subproject 18:02 < olsner> and then the fun work of making the code actually compile and work in that configuration 18:02 < janwas> sure, it's doable. probably less unpleasant than in cmake because we have an actual language (not some cobbled together crap) behind it, even if i am not really fluent in lua 18:03 <@Philip-> Hmm, it wouldn't generate useful VS project files though 18:03 < janwas> olsner: oh yeah i bet there will be tons of fun because we haven't namespaced each cpp file etc. do you have any experience with that, how painful it is? 18:04 <@Philip-> Are the only likely problems with static / anonymous-namespace functions that have conflicting names? 18:04 < olsner> janwas: basically, don't overdo per-file macros, undef if you do define local macros, either put static functions in headers or give them unique names 18:04 < olsner> "good" code shouldn't be doing any of that anyway, so it's easy to motivate the required refactoring 18:05 < olsner> it may be useful to provide some mechanism for compiling "difficult" files separately 18:06 < olsner> so that you can postpone fixing them for a little while 18:06 < janwas> i agree it'd be good to fix things eventually, am just wondering if breakage is rampant in practice 18:06 < janwas> AFAIK we usually #undef macros and static function names oughtnt collide that often 18:09 < janwas> ok, doesn't look like we can think of excessive breakage but what about the project issue that philip raises? would we create another new project for the unity builds and have the actual source files reside in another project whose build is a nop? 18:10 < janwas> ISTR that adding files (for browsing convenience in the IDE) also causes those files to be built 18:10 < olsner> if we move the functionality into premake proper, we can add all the individual units but set "exclude from build" to true 18:11 < janwas> i suppose we could add all source files and set a custom (no-op) build step, and then add the unity files 18:12 < janwas> olsner: right.. that'd work 18:12 < janwas> (but then again, it's preferable to avoid premake customization, especially since it does seem to be under active development ) 18:15 < janwas> anyway, it seems doable and i've made a note to try that too whenever i get around to making our build script compatible with premake4 18:32 < olsner> at least hte network/ subproject compiled out-of-the box as a single concatenated unit, not so lucky for simulation2, MESSAGE and INTERFACE get redefined 18:32 <@Philip-> That should just need a handful of #undefs 18:32 <@Philip-> in the files that include TypeList.h 18:38 < olsner> typical error from unity builds: missing, misspelled or non-unique header guards 18:42 < janwas> olsner: ooh, interesting. i've made an attempt to be consistent in source/lib, using INCLUDED_PATH_BASENAME (the rationale was allowing external header guards in the cpp file). probably not much of the codebase bothers, though 18:42 * Philip- does INCLUDED_BASENAME except in one case where BASENAME conflicted with a header in a different project 18:42 <@Philip-> (and expect in any cases of bugs) 18:44 < janwas> ah, so basenames haven't conflicted much? at work, it happened often enough that i now prefer to add at least projectName, if not path 18:45 <@Philip-> I think you use shorter filenames than I tend to use :-) 18:45 <@Philip-> (The conflict I had was Entity.h) 18:46 < janwas> olsner: crikey, i see we often don't even have include guards at all probably going to need a script to fix things 18:47 < olsner> ProfileViewer.cpp:40: error: conflicting declaration ‘int g_xres’ 18:47 < olsner> Interact.cpp:61: error: ‘g_xres’ has a previous declaration as ‘float g_xres’ 18:49 <@Philip-> Neither of those files actually use g_xres, it seems 18:50 < olsner> looks like it'll require a load of really trivial fixes, and a few non-trivial ones, like how Errors.cpp redefines a bunch of classes that are also defined in various headers all over the place (where the ERROR_GROUP and ERROR_TYPE macros are invoked) 18:50 < janwas> olsner: wow, wonder how that happened. int is definitely the correct one 18:50 <@Philip-> nor do the two uses in simulation/ 18:52 * Philip- isn't sure how to do the Errors.cpp thing differently 18:53 < olsner> maybe by having Errors.cpp include all the headers instead of redefining the classes 18:53 < olsner> the perl script does know which headers contain error definitions 18:54 <@Philip-> Hmm, perhaps 18:54 * Philip- doesn't dislike the error system enough to want to redesign it entirely 20:34 < olsner> so I played with unity builds this saturday and/or sunday ... now everything compiles! but it only almost links... 20:35 < olsner> it's these network message macros I built 5-6 years ago that aren't properly generated when they have already been included in header form in a different source file 21:24 <@Philip-> Sounds good 21:24 <@Philip-> except for the part that doesn't work 21:25 < olsner> one way around is to compile "difficult" files outside the unity based on either hardcoded exclusions or something more sofisticated 21:25 < olsner> ... but just until a better solution to fix the source can be made 21:25 <@Philip-> Is there no way to fix the network macros that isn't really complex/tedious? 21:28 < olsner> it should be trivial really, just need generate declarations and definitions separately (which the code already does), but make sure that generating the declarations doesn't magically break the other stuff 21:29 < olsner> debugging macros just isn't entirely easy 21:35 * Philip- ought to try to look at the network code some time and see what how it works, because he'll need to integrate it with the new simulation system eventually

Here's a quick tour of our Premake build system (for use by lyfestile and anyone else interested). We're mostly reading backwards in premake.lua: First, the solution is split into several projects (rationale: VC2005 is only able to build concurrently on the project level, so it helps to split the engine into static libraries. Static is easier than dynamic (no dllimport/export annotation needed).) Mostly, it's the Atlas editor stuff (which consists of multiple standalone executables, hence projects, though the very long term plan is to integrate them all into the main app), a self-test, those static libs, then the main game executable. Duplication is avoided by moving the project (which Premake calls package) setup stuff into functions like setup_atlas_package. The main EXE setup requires a bit of platform-specific junk (linker settings, extra dependencies), and there is a bit of magic concerning external libraries. The lowlevel static library (OS-dependent stuff) brings in dependencies like dbghelp / OpenGL etc, but they aren't linked into the static library and must instead also be injected into the main EXE project, hence the used_extern_libs table. setup_static_lib_package is where those static libs (major modules of the game, like simulation and graphics) are created. Basically it receives a list of directories, which a helper function traverses and searches for all source files. extra_params is a general idiom for passing flags/special-case stuff like disabling PCH where not desired. The package_* helper functions will need to be modified, since that seems to be the main focus of changes from Premake3 to 4. Fortunately, most of the changes should be contained there. At the beginning of the file, we have code to detect OS and options (of chief interest is probably adding Atlas to the solution via --atlas, because it requires wxWidgets to build and that's not included in SVN by default) Perhaps the trickiest part is the handling of external libraries. Since they all differ in terms of names/paths etc., but we don't want to write separate add-with-premake-syntax for each of them, we have some logic in extern_libs.lua that handles all the cases that came up, and is driven by a big table of external libraries and their respective properties. In the simplest case (something like an 'average' or ideal layout of a library and its include paths / debug suffix etc.), very few table entries are needed. It gets slightly longer when libraries like ffmpeg include several DLLs, or the debug/release versions are identical as in OpenAL, etc. wxWidgets is probably the worst, its layout is unlike most other libraries, so we pretty much special-case it by calling add_func instead of using the other data-driven stuff in the table. Some other miscellany: - when adding source files, premake creates folders within the project for each component in the path, which means that the files are very deeply nested in VC. To avoid this, we added a premake extension trimprefix. If this isn't yet possible with Premake4, we might want to add that - and get the patch upstream. - our other premake customizations involved assembling .asm files via custom build step and precompiled headers; both are now supported by Premake4, but require different syntax. One final point: while we're updating the build system, we were hoping to implement Unity builds. In a nutshell, that involves new C++ files that just #include other source files, which can be compiled much more quickly because the compiler needs less IO. We discussed this and possible implementations last week; see http://zaynar.co.uk/0ad/0ad.log (search for unity build). Whew, all done! Hope the overview helps. It's definitely nice to have a capable build system that provides a good infrastructure for the project - premake has served us well so far, and I hope things can be improved still further

Done, added to svn root. (Due to current-drive issues, I couldn't get it to work without "cd /d "%appdata%\.."; start .", but I don't see a downside to that.)

As discussed in the meeting, that list looks good to me BTW, a surprisingly high fraction (5/17) of those A1 entries are already complete - wow!

Wow, the "arguments" they had with developers who didn't want to believe they had bugs are indeed depressing/unbelievable (one would think they could easily be settled with a copy of the ANSI C standard). Very interesting to hear about the real-world experience these guys had - thanks for mentioning it! On a positive note, it's good that these checkers are in more widespread use (I personally am very happy when a bug is found via static analysis, because programmers are anything but infallible). @Erik: that reminds me of a funny Japanese saying: "If you understand everything, you must be misinformed."