janwas

We still need to add the actual macro invocation. I'd suggest replacing the HAVE_CPUIDEX block with #if defined(_MSC_FULL_VER) && _MSC_FULL_VER >= 150030729 // VC10+ and VC9 SP1: __cpuidex is already available #elif GCC_VERSION # define __cpuidex(regsArray, level, index)\ __asm__ ("cpuid\n\t"\ : "=a" (regsArray[0]), "=b" (regsArray[1]), "=c" (regsArray[2]), "=d" (regsArray[3])\ : "0" (level), "2" (index)) #else # error "compiler not supported" #endif Now cpuid() can just invoke __cpuidex without the need for any additional #if faff. Does that work? *drumroll*

hm, Philip had already fixed this one by adding <bitset>. I think <set> is no longer needed (there's certainly no std::set in there), so replacing <set> should be fine. Unfortunately I can't help with the nasm problem, except to indicate that we're really close to stomping out the last of the asm. I've been discussing this with Philip and the best guess at something GCC-palatable is: #define __cpuid(level, index, a, b, c, d) \ __asm__ ("cpuid\n\t" \ : "=a" (a), "=b" (, "=c" (c), "=d" (d) \ : "0" (level), "2" (index)) This would be inserted into static void cpuid #if !HAVE_CPUIDEX, replacing the two asm calls. level is the initial value of regs->eax, index is regs->ecx, and a,b,c,d are the output values that are to be written to regs->eax,ebx etc. Would you like to give that a try? If that compiles despite GCC -fPIC, then we're golden.

That's true, the BMP format is quite flexible. However, I wasn't aware of viewers that correctly support 16 bits *per channel*. If we claimed our heightmap is a 5:6:5 bit pixel format, it would look very strange indeed Update: hrm, I'd rather not do battle with the CinePaint source tarball, especially given that the websites say `deployment on non-*nix OSes is a challenge' and `current architecture is broken on Windows'. GIMP 3.0 is good news, though - thanks for the pointer. Funny interface or not, it's better than nothing. We also frequently have this problem for multispectral satellite imagery.

hehe, thanks for reporting this and confirming it's fixed Sorry for the trouble.

16-bit pixels are always a pain in terms of viewers. Irfanview and Photofiltre flat out fail. We're working on one, but the idea there is to convert to yet another internal representation. 16-bit TIFF are probably more common, but that would entail adding another dependency (boo). Do we really need export? Seems like a simple screenshot might get us a lot of the benefits for zero work.

Thanks for confirmation You may find the `watch this thread' (blue button near top of page) useful - that will notify you via email when a reply to this particular thread is posted. Wraparound: oh, right, I thought we were talking about the system shell. I can live with the lack of wrapping in this case, though it's good to avoid in general. Would you appreciate you giving Atlas a go if/when time permits!

Further to that: you can toggle fullscreen mode by pressing Alt+Enter. The game can be slow initially due to the (one-time) conversion of images and XML files, which is running during the main loop.

Philip mentioned the following during the meeting: 1) he will be busy for the next few days upgrading the server to one with more (and expandable) disk space 2) after that, the plan is to commit the Premake4 build, replacing the old one at the same time 3) any problems that may arise should be easy to fix, there's no point maintaining a second version. Sounds good to me

Ah, progress Those warnings are harmless. The missing file is a showstopper, though - you will need to acquire the Gamin and/or FAM development libraries.

Integrating+committing would be great I'm not sure if you are planning on keeping Premake4 as the default, as suggested by Yves. I think that would be a good thing in terms of testing, but could also live with the reverse, where we have to specify an additional option to get Premake4 until it has proven itself.

Those two missing files are part of our repository. Presumably your SVN checkout was incomplete (you can try `svn up'; it'll finish downloading any missing files) or the include paths are wonky. The latter is rather unlikely, since it works for most people, but you could have a look inside the makefile. It should contain an instance of libraries/valgrind/include and libraries/cxxtest/include/cxxtest.

Oh yeah. Some of the code is quite old (mentioning problems with Win98 and 2000), and some of it was also designed to minimize size (being part of 4K demos). That's great, similar cleanups are very welcome Additionally, two minor requests: please use tabs (not spaces) and try to match the coding convention at that particular spot. Certain parts use if (expression), others write if(). It's nice to keep that consistent.

Great job on that ticket! I have just reviewed, cleaned up and committed the patch. These features are very useful; thanks for adding them! I think your approach of adding similar features and fixing a bug that came up makes sense. There is no benefit to generating extra "paperwork" if the other tasks are related and you are willing and able to accomplish them in one sitting. I assume you have a local todo-list that provides a little morale boost as each entry is marked done, so there's no need to use trac tickets for that. However, the two extra tickets you created make sense, since they relate to different topics and might take longer to fix. As to patch size - we've had huge ones before; if that's called for by the size/scope of the task, so be it. It's good keep each patch related to a single issue, though, so we don't accidentally throw the baby out with the bathwater and/or get things confused

Thanks for your offer I think some programming and debugging experience will be needed to fix the runtime problems. However, attempting to build from source is a great start! If you post the resulting errors here, I can have a look and might be able to fix minor issues within our code. (I can't help with issues pertaining to system libraries, though, especially the SpiderMonkey JS engine.)

There's been no work done on the audio front, nor Atlas. Help would be very welcome!

hrm. Shall we try to get Atlas to compile and run, while we're at it? Yes, Collada is only loaded on demand - a heavy-handed way to ensure that would be to delete the entire cache (not a bad idea anyway, that gets rid of old/no longer needed files). Yep. Doesn't the console wrap around, though? The final error messages are probably uninformative anyway, so I don't think this is a problem.

Thanks for this patch! I've committed it after some modifications (using ARRAY_SIZE magic to avoid the need for constants, simpler loop logic and error reporting). It has been successfully tested on Windows, but I'd appreciate a quick test run on OS X, because of the extra #if that changes things (you never know) I personally am sympathetic to Premake - partially because it gives us a full programming language, which is nice when we need some unforeseen project customization (asm, PCH, other complexities). CMake's scripting language sucks, but it does have more logic for common cases built in. I guess one thing we can do to narrow the gap is to implement some of that in Lua rather than the shell script - should be nicer + more flexible. However, my understanding of Linux builds is too vague, so let's talk this over together with Philip Just let me know a time.

Cool! Apparently dlopen does indeed support dylib: http://en.wikipedia.org/wiki/Dynamic_loading I'd suggest additional cases for the primarySuffix definition, and then we should be good to go

Yeah, it's hard to hit a moving target I think your suggestion of integrating the current status is a good one. Only if there are real dealbreakers would we have to specify the --use-old-premake flag. This would greatly ease testing, since so many people would actually be using it. I have some comments on your open issues: isn't a major problem, since it should be possible to upgrade to VC2010 (this used to be annoying before the advent of the Express Edition, but the price is now right ) typical usage is to create the makefile on the system that will compile. I don't see a need to exchange makefiles between systems, so it's all good. can't comment here, don't know anything about *.app. does the POSIX dlopen API not support dylib on OS X? What would be required to make it work on OS X? Something like a sys_LoadLibrary interface could easily be added with platform-specific backends. Currently, we've been using POSIX dlopen as the "lowest common denominator", but if that's incorrect, we can adapt. Thanks for your work on this Once you and Philip have agreed on a time, I'd appreciate you letting me know and will also try to be there. Philip recently mentioned a bit of trouble with assembly code and his CMake (which I understood to be an experiment and not at all a decision), so I have ripped out all the .asm locally, and it's no longer something we need to worry about. It's not yet committed, though, due to lack of testing on OS X, which is kind of ironic, hehe.

That's correct A shorter way of accessing that directory (which also works in Windows XP) is %appdata%\0ad\data .

Thanks! It'd be good to add as the first line of main(): debug_printf(L"%hs\n", argv[0]); As to sys_ExecutablePathname, that's a bit more complicated. Please apply the attached patch (mutatis mutandis, I can't compile it here) to linux.cpp and post the resulting console output (the first line, and the one starting with "sep"). Unfortunately I can't help with the other questions. debug_sep.patch

That error indicates we're not finding the path to the executable; even argv[0] isn't usable. The game still runs because there's a second mechanism (XDG) to find the paths to the data files, but it'd be nice to find out what's going wrong. Would you be so kind as to trace into sys_ExecutablePathname, and also print argv[0] in main?

Since you and I are also active in the research field (once cleverly defined as "that which I am doing when I don't know what I am doing"), we get to declare certain things to have been `instructive' rather than just a failure, providing we did actually learn something from it Sorry to hear it was a dead-end, but I'm glad you're rolling it back rather than letting it fester.

Back! Reading this thread again, it looks like we've got a not entirely simple bug. Debugging is hard any way you slice it, and I guess we'd need an experienced OS X developer to find out what's going wrong. We'll get it eventually, though. When OS X is better supported and we release a binary installer, you will be in the game

To be clear, it is not at all possible yet The previous "i18n" system was in fact deleted and needs to be replaced before any translation can begin.