Yves

Thank you! I'll have to look closer at it later.. I just discovered that I probably didn't test loading dylibs properly. I couldn't test with atlas because building it fails and collada doesn't seem to be loaded always (only the first time for converting something?). Otherwise it seems to work. The only small problem is that there could be a maximum of four error messages which will be written to one line that won't fit on most screens.

Joshua Redman - Sweet Sorrow

Those videos often seem a bit jumpy... I don't know what can be done technically at the moment, but I would try to use scripted movement of units and also scripted movement of the camera. Is something like that possible?

Thank you for the input! I haven't yet looked at CMake, but my experience is that usually there's no perfect solution and we will most likely have different problems with CMake we don't know about yet. Probably (I don't know) CMake fits our needs better, but in my opinion the situation is as follows: I've put a lot of work in the integration of premake4 and we are very close to integrating this and use it as a base for further improvement. I'm not willing to do the same from scratch with CMake probably just to see that It isn't any better after months of work. Maybe someone of you could do that much faster, but you'd still need a lot of time. You wouldn't expect how much time you loose for preparing environments and operating systems, switching between environments, recompiling, reintegrating changes, testing, finding bugs etc... I can help with the integration of Premake4 and probably some of the problems you mentioned can also be solved with the current release or future releases of Premake. There are some improvements coming with Premake4 like support for vs2010 and Xcode(probably still experimental). There are also other IDEs that could be integrated (Code::Blocks, CodeLite). I would appreciate a clear decision. EDIT: I've attached a patch for fixing known issue number 4 (dllloader not looking for *.dylib). In my opinion this should be changed no matter if premake or cmake will be used. The code now tries loading *.so, *.dylib, *_dbg.so and *_dbg.dylib in that order for release builds on the Mac. I've also changed the behaviour errors are reported. It now reports errors for all tries and not only the first one, if the loading fails. I've tested the error reporting and successful loading on both Linux and Mac, but not yet on Windows. Please do a careful review because I'm not yet familiar with the coding conventions you use and because I haven really coded c++ for quite a long time . patch.txt

Thank you for the feedback! I'll let you know if/when we meet on irc. Honestly I didn't look very deep into this. The first problem is that the current code simply looks for a *.so file instead of a *.dylib which should be easy to change. As far as I know dlopen can be used too, but I don't know if there are any differences that could be a problem. I can try to fix it when I have time to.

Ok I'll try talking to Philip around the end of the week or on the weekend. Currently I'm a bit too busy. Probably he will already have seen this thread until then.

My current work is attached in the last post. I've merged the recent changes and made some basic tests. Feel free to do with it whatever you want . I'm also willing to support if you find bugs, have questions or need changes. "Installation": Copy everything into your working copy according to the directory-structure replacing files with the same name. Usage: By default Premake4 will be used, but you can switch to premake3 by calling update-workspaces.sh with --use-old-premake(Linux and Mac) or editing update-workspaces.bat(windows) as described in the comments. @Sebovzeoueb It will support xcode projects, which is apple's development environment for the Mac. This first release doesn't really improve anything else on the Mac and Xcode support is still a bit "experimental". I've learned a bit about the Mac and I've also seen some of the problems, so maybe I'll be able to do more in the future. @k776 In this case it would be interesting to know if my work on premake4 will actually be used or not. It wouldn't be a total waste because I've learned a lot, but I won't spend more time on boring things like testing if nobody will every use it.

I have some questions about the release of my work and the integration into the svn repository. It is really a lot of testing necessary to make sure everything works as before (or better). The problem is that I don't have enough time for that and whenever I'm close to finishing my testing, there are new changes in the current premake3 files I have to integrate and test again. I've also red some threads in the forums where people are working on improvements that will affect premake3 files. Currently I'm a few weeks behind with my files and will have to merge a lot of changes made during that time. Would it be possible to just integrated it and resolve the problems later? After merging the changes, of course! It would save a lot of work for me and would allow a much faster integration of premake4, but some things would probably be broken in the beginning. I think the basic building on all platforms is quite stable, but some compiler- or linker-flags could be different or some less often used parameters for the premake-scripts could cause problems. We could also have preamke3 and premake4 in parallel. If there are problems, people could switch back to premake3. I've made it that way for testing. You can pass --use-old-premake to update-workspaces.sh for using premake3. Obviously the problem is the same... the work has to be kept in sync as long as we use both. What do you think? I've attached a list of know issues. I don't know if it helps much, because the bigger problem are the unknown ones . I' going to attach the sources as soon as they are ready for the current revision. Known-issues.pdf 0ad_premake4_1_0.zip

Good, thank you!

Hi Running test with runtimechecks enabled results in an error: ------- Run-Time Check Failure #1 - A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i & 0xFF); Changing the code in this way will not affect the quality of the resulting optimized code. ------- I've changed a few lines in tex_dds.cpp to work around the error. Before: static inline size_t access_bit_tbl64(u64 tbl, size_t idx, size_t bit_width) { size_t val = (size_t)(tbl >> (idx*bit_width)); val &= bit_mask<u64>(bit_width); return val; } After: static inline size_t access_bit_tbl64(u64 tbl, size_t idx, size_t bit_width) { size_t val = (tbl >> (idx*bit_width)) & bit_mask<u64>(bit_width); return val; } or probably even: static inline size_t access_bit_tbl64(u64 tbl, size_t idx, size_t bit_width) { return (tbl >> (idx*bit_width)) & bit_mask<u64>(bit_width); } The same should most likely be done with the function access_bit_tbl. It simply removes the need for a cast and makes it a bit less readable . That's the only problem I've detected so far with runtimechecking. What do you think? Is that right or did I miss something?

The progress is currently slow, but at least there is some progress . The problems described in the last post are solved and I was able to compile, link and run the game on osx with an xcode project generated by premake. Test generation is still missing for xcode, but I don't think that will be very difficult. Hopefully supporting older versions of Visual Studio will more or less just require copying the existing c++ code to the right place and converting it to lua syntax. Chances are good, but it could also be more complicated. EDIT- 28th of April 2011: All the main features are integrated and I'm now doing tests and fixing problems I find during testing. I can't really tell how long it will take until I'm ready to release a first version for public testing. If everything works well it could already be on this weekend... but I don't know what kind of problems I could still find. EDIT: I've found and fixed some problems, prepared the source for distribution and started writing some documents about known issues and test cases. Currently I'm comparing the know issues to the premake3 environment. This gives me some hints about how some of them could probably be solved. Premake4's problems with make and parallel builds are now fixed too.

I thought I red something about units loosing health slowly when they are in enemy territories, but I'm not sure if I remember that correctly. That would be similar to what you are suggesting, but much less complicated.

Maceo Parker - Shake everything you've got Make it funky! @feneur: I like that, very special.

You are right... I will have to check that. I keep it as it is for the first release of the premake4 scripts. There's going to stay some "room for improvement" anyway . EDIT - I have some questions about linking: Currently the pyrogenesis project/solution has all the library linking flags set (-lenet -lnvtt etc...) and some of those are also set in other projects. When trying to link on a Mac with xcode, this configuration leads to linking problems with all the libraries where only a dylib is avaliable and no static lib (*.a). The affected libraries currently are: -nvimage -nvmath -nvtt -Mozjs-ps-debug -Mozjs-ps-release I couldn't find the documentation confirming it, but it looks like libtool doesn't allow linking of dynamic libraries into static libraries. I've tried removing all the linking flags in all projects except pyrogenesis, and it works. Currently I don't understand all the details of what's happening and probably this is even different on the various toolsets we are using. Just to give an example: I'm not sure if the library will be included twice in the executable if it's linked statically by the static library and also by pyrogenesis itself. Could anyone give some basic guidelines/ideas of what the concept should be and what would probably be the best way to take? Should I just remove all the linking flags in all the static libraries and only keep them in pyrogenesis?

Currently this situation only exists on my Ubuntu and other systems where /bin/sh points to a shell that does not define HOSTTYPE. It isn't really a problem because the check with "gcc -dumpmachine" works on my system, but could be a problem if both checks fail (happens rarely I guess). There's a new function in Premake 4.4(not stable yet) that could be interesting: http://industriousone.com/osis64bit Currently architecture detections is nothing more than choosing between 32 and 64 bit, so if it's reliable we could replace a lot of code with calling os.is64bit() in the future. I also had a look at "platforms" introduced in premake 4.1 but currently I think that's not needed. Maybe I'll look at it later when premake 4.4 is released, but probably it's not worth the efforts. http://industriousone.com/platforms Edit: gcc -dumpversion won't work on the mac, but currently it looks like HOSTTYPE-detection will work.

... a detail: What do you think about changing the shebang of update-workspaces.sh from #!/bin/sh to #!/bin/bash? I've found out that some of the arch-detection problems could be related to the missing HOSTTYPE variable. According to the manpage of bash this variable is defined by bash. On my Ubuntu 10.10 system /bin/sh points to /bin/dash which does not define HOSTTYPE. Often /bin/sh is a link to bash anyway. On my Snow Leopard installation both /bin/sh and /bin/bash are the same version of bash.

I've been working on xcode support the last weekends, but encountered a lot of difficulties. It was the first time I've really tried working with MacOS, which didn't make it easier. One of the difficulties was setting up a VM with an acceptable low frequency of kernel panics . After some kernel patches, manually entered bus-ratio-settings and other ugly stuff, it works more or less, but It's still a pain to use. Make works, but xcode support is a bit more difficult. There were problems with architecture detection, pgk-config and sdl-config, assembling, linking, bugs in the code that got fixed in newer revisions and more. Currently I have a working xcode project and I was able to run 0ad. I've made many changes to the project manually and there's still work to be done until these changes are all integrated into premake. I keep working on it and hopefully there will be more progress in my vacations in the week after next week.

This topic made me think back to AOE2 times. I always hated these stupid villagers who cut the decorative trees in my village. I often killed them for doing that Maybe a category for decorative objects could be added for that purpose. This would not really affect gameplay.

A successful build in release mode creates the pyrogenesis executable in binaries/system. If you built in debug mode, it's called something like pyrogenesis_dbg. If there were errors during building (make), there won't be an executable there (only the prebuilt *.exe ones for windows). In this case you'll have to fix the build-errors first.

Did you follow these instructions? http://trac.wildfiregames.com/wiki/BuildInstructions If you did, please post the output of the make command.

Today/yesterday I've finished the vs2010 scripts. Vs2005 and vs2008 aren't working yet, because they have a different syntax for their project files. During the last week, I've been looking a bit closer at premake's development. The good thing is that there's quite fast progress. On the other hand, it means that the source is changing very frequently and it will be hard to get something upstream. Porting changes from the current 4.3 stable release to the development release and making them "final" would be a lot of work and requires deep knowledge of premake's internals and the different IDEs and their build-systems. The main developer has announced that he is trying to make contributions easier, mainly by creating a more unique code-structure... we'll see. For now I'm NOT focusing on getting changes upstream. Maybe I can give it a try again after premake4.3 is integrated and premake4.4 is released. Good night...

It's a bit too much "work in progress" at the moment and there are stupid "TODO" comments everywhere, some in german and some in bad english I'd prefer to wait with a first release until visual studio is supported. Something else... if OS == "windows" or not options["without-pch"] then package.pchheader = header -- "precompiled.h" package.pchsource = source -- "precompiled.cpp" ... It looks like on windows the option "without-pch" will not disable precompiled headers.. does anyone know the reason for that?

I've just executed the first build of 0ad created using premake4 and make. Unfortunately there was no way around extending premake. It's a bit easier with premake4 than it used to be with premake3 because nearly all the logic is now in lua-scripts instead of c-code and because some features now work out of the box. I had to customize premake for meeting the following requirements: - Using the output of pkg-config and sdl-config for library dependency input - Integrating assembler-code using nasm assembler - Using cxxtestgen - Using special linker options to work around circular references (-Xlinker --start-group $(LDDEPS) -Xlinker --end-group $(LIBS)) The next step will be getting visual studio solution/project creation working (at least 2005, 2008 and 2010 I guess) and testing it on a mac (make-projects first, xcode later). I hope I can get the required hardware and software for testing...

For clarity and convenience I've created a patch of the suggested changes. The dependencies of objectfiles created by nasm are now written to .d files correctly instead of a file with .asm ending. I didn't test the part with .c files because there are no .c files at the moment, but I'm quite sure double percent signs are wrong there too. The script uses the same functions to write these strings to the makefile. Feel free to apply this patch... or just wait for me to finish the update to premake4 . Patch.txt

Sorry I got that wrong. This line is the missing piece: -include $(OBJECTS:%.o=%.d) I don't have much experience with make and gcc and didn't catch how these files are used. Now I understand. About the other thing I'm a bit confused. I've tested the .asm-part with both two and one percent sign. It only works with one. I don't know why there are two here: "$(<F:%%.c=%%.d)". EDIT: I guess the double percent sign was made with character escaping in mind, but it's not needed there. At the moment, there aren't any .c files used in the build-process and the premake-scripts don't even search for *.c. In my opinion this part can be completely removed or should be corrected with one percent sign instead of two (even if it doesn't matter at the moment). else if (matches(ext, ".c")) strcat(g_buffer, "$(CC) $(CFLAGS) -MF $(OBJDIR)/$(<F:%%.c=%%.d) -MT $@ -o $@ -c $<\n"); Premake 3.7 does it this way in the original version: else if (matches(ext, ".c")) strcat(g_buffer, "$(CC) $(CFLAGS) -o \"$@\" -c \"$<\"\n");