janwas

Sounds good! I am wondering about the synchronous bit, though - is there any reason to tell code whether the texture has already been loaded? There is the mipmap color hack, but we shouldn't be doing that anyway for performance reasons. Instead, I think it'd make sense to always load asynchronously (ideally in a background thread), return a handle that is immediately valid, and at a defined point in Frame(), upload the textures that have just finished and update the underlying "texture" object. (It'd be even nicer to do the uploading in the background thread, but multithreaded OpenGL has some gotchas and is probably better avoided.) A thread is definitely helpful in that it'd reduce the performance impact of loading new stuff (which happens at runtime) - regardless of whether they need extra (de)compression. That's fine on single-processor systems too, since it is idle most of the time.

Aha! 64-bit, even though the system is 32-bit? Is that the case here? (Wasn't commented upon above) heh, it'll also work, just need to comment out everything that causes a compile error. Your cassert idea is simpler still, though. I've added those sanity checks to cpu.cpp, can't hurt. The debug_printf really should be the very first thing (that comment notwithstanding), but it is no longer needed. Instead, the new casserts in cpu.cpp will probably explode - what messages are you getting? (I'm still not sure whether the problem is an inadvertant definition of ARCH_AMD64 or incorrect definition of intptr_t)

OK, thanks. We now know that our predefined macros believe your system to be 64 bit Unfortunately I screwed up the latter half of that snippet - `sizeof' isn't known to the preprocessor, oops. Instead, we need to add an actual line of code somewhere that is sure to run, e.g. as the first line within main() in main.cpp: debug_printf(L"here are the sizes: %d %d %d\n", sizeof(int), sizeof(void*), sizeof(intptr_t)); Those 3 numbers should then be displayed somewhere in the console/terminal - can you please post them?

As mentioned, it is basically impossible to retroactively optimize multi-core performance in a meaningful fashion, i.e. scaling properly on 8+ cores. The usual way of managing that nowadays is splitting the simulation updates into microtasks and dispatching them to available cores. That (as with other huge change in requirements) entails a major redesign+rewrite, which is not in the cards right now

The first error is probably caused by stale registry entries pointing to an old graphics driver that no longer exists, and our attempt to read its version therefore fails. Any chance you could fire up the debugger, add a breakpoint on wdll_ver.cpp:61, and see the value of modulePathname_?

It looks ARCH_AMD64 is defined to 1 and i64 and intptr_t aren't the same. Can you please verify this by (temporarily) adding something like #if ARCH_AMD64 == 1 #error "arch is 64, remove me" #endif #if sizeof(i64) != sizeof(intptr_t) #error "size mismatch, remove me" #endif in cpu.cpp? The next question is of course: why and how is intptr_t defined? It should be the same size as a pointer, or else all kinds of stuff will break.

(Was also discussed in today's meeting. Looks like NVidia's texture tools are fine, and Fabian Giesen/ryg's code is a bit too basic for our needs.)

Greetings and welcome! (Sorry about the late reply, I've been on vacation with almost no internet access.) The AI is a huge field and should probably wait until we have a solid foundation for AI scripts. Aviv has put together some Getting Started info that will probably be of interest

Have you updated your graphics driver? Please post the contents of your %appdata%\0ad\logs\system_info.txt file (you can just paste the filename into Start -> Run).

hm, that sounds like it might be worth going with one of say three thicknesses depending on zoom. However, when zooming in/out, one would see the thickness 'pop' to the next level.

Roger that. Just to clarify: I meant a pixel's intensity depends on its own distance to the circle, not the circle's distance from the camera. BTW, looking terrible at low zoom factors is to be expected due to cheap downsampling filters. I've attached an image showing the difference between box, cone and the abovementioned optimal polynomial filter.

A quick note before heading to work: the 'proper' way to do antialiasing is to convolve the continuous signal with a lowpass kernel. It turns out that (in the case of lines), the pixel intensity/blend factor is merely a function of its distance from the line and can be precomputed. Here's a nice description of how to implement this on a GPU: http://http.developer.nvidia.com/GPUGems2/..._chapter22.html I figure this could be easily adapted towards circles. If anyone is interested, I can provide the optimal (in the sense of minimizing aliasing energy) cubic polynomial filter kernel and help derive the term for convolution with the circle. Then again, this is probably overkill and a simple texture with a halfway decently rendered circle may also suffice

The question is, how many of those Linux guys are actually using Netbeans and/or Eclipse? I'm not sure about that, I think there were problems the last time we tried (help would be appreciated, though!() If you just want to get it running as soon as possible, VC2008 is a safer bet.

Those warnings are now fixed in the source (see new comment in wsdl.cpp) - thanks for the report!

D'oh I though this was fixed (see above trac ticket). But then again, maybe this is a chance to finally understand the cause. Could you please fire up Filemon (or Process Monitor IIRC, since Filemon won't run on Vista) and report the last file accesses that pyrogenesis_dbg.exe makes?

Just a comment on this: rewriting single operations in asm often turns out not to be worthwhile, partially because VC is really stupid about integrating it into functions. Also, VC x64 doesn't allow inline asm at all :/ We do some external asm where there's no other way, but this probably isn't such a case. If you'd like to try your hand at vector stuff (just for fun, knowing it's probably not necessary nor worthwhile), I'd recommend using intrinsics such as _mm_mul_ps instead.

Thanks for the report. I made a silly mistake that only affected a rarely used codepath (for rather old CPUs), which is now fixed.

hm, the matrix layout doesn't match the common (row, col) indexing - the elements and operator() are indexed by col, row instead. However, even accounting for that, you are right in that operator* seems to have it backwards. HOWEVER, it all seems to be rescued by operator*= again flipping the order (a *= b => a = b*a). I don't often have contact with this code or this kind of linear algebra, but it does seem unnecessarily contorted. Unfortunately, we probably won't be able to reconstruct the original author's intent or thinking. Do you think it'd be worthwhile to ensure the previous operator* is only ever called from operator*= and then flip it around? As to Goblor pulling out his group theory, that is to be expected from (almost) mathematicians - he also happens to be interested in sound

Hey chlin, writing some documentation as you explore the project structure would be very valuable! Again, let us know if you encounter any trouble or have questions. The formations issue is quite an undertaking, but when a task is and remains interesting, a lot can be accomplished. Philip is back from his vacation and I've mentioned your plan, so he'll probably be in touch soon with some ideas for the formation/pathfinding stuff.

Caution, I mean the 'Assertion failed: "numPackagesTimesLogical != 0"' fix - you can get that by updating SVN and rebuilding, or after the next autobuild and/or pre-alpha release. There are no news yet on the other collada issue.

As discussed in IRC, this latest error is now fixed. Thanks for reporting it!

Ah, I see - then the proposed solution sounds good! BTW, as mentioned in the meeting, the 5000 tile limit might be a bit low - it's reached when ordering the right group of infantry to move to the end of the maze. Given that a hierarchical pathfinder would remove much of the performance penalty of a higher search distance, and that incorrect paths are much more surprising than a stall after a long-distance move order, how about we slightly increase that distance for now? (That's easier than changing the map, hehe)

Just mentioning this for completeness: Starcraft II (going by the battle report videos), as did the original Starcraft, don't allow building over enemy units. If one has spare time for micromanagement and the map is small, cheap units can be sent to block important expansion points (dodging like crazy so they survive long enough to matter). I'm not sure we want or need that particular gameplay mechanic, though (ugh). hm, is it really "exploitation" to spam foundations in the enemies' way, knowing that it's expensive and the foundation can be obliterated with a single attack? If so, an alternate workaround would be to only place the foundation when the builder is nearby (thus making exploitation in the face of ranged units much more difficult).

That can happen in times of heavy load - you could check out with depth="Immediate children", which will only get you the (empty) top-level folders and files. Then move into source/, update, repeat as necessary until everything is there. (Might be more convenient to use the command-line SVN client for that, because it can more easily be automated) Once you've gotten source/, build/ and libraries/, it should be possible to compile; binaries/ is of course much bigger and will take longer to download. You may also prefer to download a snapshot (http://trac.wildfiregames.com/wiki/LatestRelease) and update from there - that'll be easier if your bandwidth is good but the SVN server is overloaded.

Greetings! The driver in question is binaries\system\aken.sys (plus its 64-bit and debug-mode variants). Does the driver warning really torpedo the entire game, rather than asking you whether it's OK? That's a bit harsh. You can prevent the driver from being used by specifying -wNoMahaf on the command line. I am also somewhat closer to being able to finally sign the code, because my employer has the requisite PKI (but the ever-worrying legal department is first checking to see if that might lead to increased liability..)