wraitii

Interesting... Seems like you have an intel GMA 950, perhaps it doesn't support some of the stuff I'm doing. Does the post processing work (independently from the water)? If it happens every time, could you try debugging using gdb? I'm afraid the logs don't give enough information. (while this gets sorted out, check these (1,2) out.)

@Historic_Bruno: I might be wrong, but I believe Atlas doesn't work either without this change.

you should set fancywater and superfancywater to true, and it ought to work. It's disabled in Atlas though, for performance reasons. (and it requires recompiling)

@Zaggy: frankly, I don't believe there's an easy way. It should be possible, but using a different system than the one I'm currently using, and I'm probably not going to have enough time to do that now. (note that I'm not completely happy with waves. If most people feel they look fake, I'll deactivate them for the time being).

Should be committed... And it's probably a bit too late for "before" screenshots, unless someone else wants to do them. Else I could try recreating an existing screenshot.

From earlier testing, the medium setting is on par or faster than the regular one. The super high quality one is probably slower, but I believe it's acceptable... I could fine tune it and add more settings for customization (enabling waves, foam, realistic depth, shadows independently, mainly) if it's needed.

And of course that's what it was, thanks a lot Myconid. Okay, I'm taking various screenshots because it looks cool and the new post-proc effects are dead awesome, then I'm busy for a while. I think I'll commit tomorrow morning in case there's any problem. Else I can do it in circa 4 hours, but I'll only be here on and off for 5/6 hours. Link to said screenshots (I'm digging the full skyboxes BTW, but the lower bound should be slightly below the horizon. On the "man" image, I had to touch up the horizon because there were black lines). Apart from said slight touch-up of the horizon, it's all in-game screenshots.

Okay, there is a conflict with the post-process manager and the very high quality water shader, which is a bit too bad obviously. I believe it's linked to the depth buffer, Myconid's probably changed something at some point. Should be an 'easy' fix (though not right now, I'm getting a haircut)

I think it's a path issue. I've had the very same issue with the collada lib, and changing the DLLLoader.cpp file (in source/ps) from #if OS_UNIX static CStr prefix = "lib"; #else static CStr prefix = ""; #endif to #if OS_MACOSX static CStr prefix = "@executable_path/lib"; #elif OS_UNIX static CStr prefix = "lib"; #else static CStr prefix = ""; #endif made it load properly. However, the collada library must be put in the same folder as the executable (in the current repo architecture, it should be that way. If it's a packaged app however, the path may need to be changed. As I understand it, Geek, you're trying to compile the project created by update-workspaces, so you should only have to apply the change I just wrote).

I think it's only GLSL at the moment, wether it's activated or not. There were no ARB water shaders before, and I haven't ported those yet. I'll do a series of testing tomorrow, check the code is allright and then commit-IRC if I feel it's allright.

Got this to work again against the latest SVN, no noticeable issues appeared. Should I post a patch to be reviewed or should I commit and then quickfix if by bad luck it does break a few stuffs? (Asking because it's basically mostly art.)

Having translated those before (pre wind-changes and many other stuffs), your code seems allright. You're using the same texCoord (4) for both v_tangent and v_normal in some cases though. Also, if you hit the hard limit of 8 texCoords, you may want to put some things together to use the 4 coordinates (can't recall exactly, but perhaps v_los is only 2 parameters for example, and could be put with v_tex). Dunno if you'll need it, I seem to recall having to do it but that may have been before some optimizations in the code/myconid's work.

My code is not up to date, but generally it should not have changed a lot so it should be pretty straightforward. ARB is extremely basic, and indeed the reference is a godsend. It's quite annoying, but it's really really predictable. If you want to give my code a go and have problems, I could likely help. (BTW, the latest version of my patch is on TRAC, on the ticket 1572.)

Low level tactics have not been implemented in any AI as of yet. The best Aegis does is attacking buildings with the siege units, and units with the rest (or buildings if there are no units). Ultimately, this is one spot where an insane amount of work could be done.

Does this affect my water patch or is totally independent?

Acropolis could trigger some pathfinding issues because of the Acropolis setting. The AI isn't quite adapted to such situations.

That was me, Mythos. Updates aren't really needed, the code is pretty much there. There's a patch in Trac, it just need to be tested against the latest SVN, as it's quite old now... The only last thing to touch up were the waves but they're already "quite" good.

Could use a lower amount of rock actors and a transition terrain between the lake surroundings and the grass. Could use different grass patches. Also: the forest are really not fairly placed.

I agree. It will probably mostly be a function of my available time though (particularly since my first two weeks of september can't be used for 0 A.D.).

Should have to check, but this map might have a lot of entities, which could cause this even for a normal sized map.

A very good release indeed.

Iirc the plan is to have only Aegis if possible for Alpha 12, with the new shared API. However with school restarting for me, and other issues I've had progress is mostly stalled for two weeks, and after that it'll still be fairly slow.

qBot? Might be an attack that couldn't "reach" its target. If I recall correctly, it checks for distance to the middle of the formation, and here it may not trigger. If it's not attacked it keeps walking forever in that case.

Slightly related: I've updated the wiki page with a warning for Mountain Lion users about GateKeeper (can be changed if needed, obviously).

So it doesn't load the scripts from a random other map, it just creates a completely random stuff?