wraitii

Okay, Alpha 10 bundle seems to work correctly in fullscreen, even when I start the executable directly. The scenario editor requires X11, which is no longer bundled with OS X Mountain Lion, so that might be a problem. However, there's XQuartz that's fairly easy to download and that fixes the problem. Still can't compile the scenario editor myself or have the fullscreen work, though, no particular idea why. The problem on compiling the scenario editor seems linked with some functions not being available in the proper architecture, for some reason.

Does it include some of my portings to ARB? If not, is it a priority that I port this to ARB?

I'll check that. I used macports, I'll check for updates, and report back.

Okay, so I've successfully built and run 0 A.D. on OS X Mountain Lion, compiling with Xcode's 4.4 LLVM 4.0 compiler (ie not GDB). Apart from a few "updates" that Xcode did automatically on each project, I did not encounter problems. However, the fullscreen option bugs, and results to the game reverting to windowed mode but with issues: it's stuck in the bottom left corner and i have no actual window to speak of (no title bar). Edit: ActorEditor fails during linking though, it's apparently linked to wxwidgets.

I've just installed Mountain Lion, will report about SVN buildabilty once I get the latest X-Code.

It's harder to do a lot of small waves properly in some cases. I'll have to give a look at some sort of wind direction. Anyway I'll retry with the mesh thing. Given my current timetable, this would probably push waves to after Alpha 11, though.

The hardest part here is that the geometry must take into account the convexity of the map (to avoid overlapping). If you look at page 6/7 (can't recall which) you'll see I had that for some times, but it felt unsatisfactory. I could retry with your system.

Not much to be done with the current code, as it's all created in the shaders. To do the waves in screen space, I'd need to restart that from scratch (and i'm not really sure how to do it anyway).

It would, but the hard part here is actually number 1. Drawing the waves on screen properly is harder than I expected, at least to me. I may be missing something, though.

I'd really like some sort of Asterix cheat. Something like "Cacofonix" (the bard, Assurancetourix in French), that would replace every melee weapon prop with a fish (even if just for the graphics). Any idea how this could be implemented? (I'm willing to do this completely on my own, as it's really about the most unnecessary thing ever).

Very hard to have a nice result given that it must rotate 360° and it has to scale (and textures too) properly.

Tried that but it was unsatisfactory in some cases. Right now I'm using the "distance to shore" parameter to have the shader add a texture, but it's really not that good-looking. Your idea could work, I'll have to see how hard/easy to do it would be. I assume you'd require some sort of knowledge of perspective, and a way to keep track of waves/update.

I certainly can, and it certainly can be deactivated until someones finds a better looking way. The only problem here is committing to SVN efficiently.

Allright. I'm really having troubles with the waves, and i can't figure how to do it in any kind of a beautiful way. I have right now a system that has waves following the curve of the ground nicely, but it's ugly. I'm really unsure how to improve on that...

Myconid, would it be easier for me to work from a clean SVN (ie Kieran's master branch) or from your merged branch?

Okay I'm back from holidays and will try again with the waves stuff.

You need to reflect the water height too. So for each height that has a water plane, you'd need to re-render the whole screen. Even with proper optimizations, given that the terrain is rarely perfectly flat, this would probably be a fairly big performance hit.

Okay, so I've forked from the latest update in 0ad-git, and I've applied the necessary changes for my water patch, and only those. It's two patches because I forgot some stuffs on the first commit. I've tried (and succeeded) to compile and make it run from this clean patched branch, so I assume there is no problem (unless in the last two days someone changed everything but I don't think that happened. I've linked them as attached files... Would that be enough for committing in SVN? (I've changed the Atlas stuff so it doesn't use the super fancy water, and since I haven't yet ported to ARB It'll always use GLSL). 0002-Clean-commit-of-my-water-Shader-in-theory.patch 0003-Fix-messup-ready-to-SVN.patch

I can confirm this. And if the map is intended to be the Loire, I'd recommend making the river a tad larger. Thing's big.

To be perfectly logical, shouldn't that actually be reversed? Make a lot of money selling to the foreign market, make little selling the ally's goods in yours? I'm thinking a 80/20 mechanic would work better than a full 100/0 here.

BTW, I've given a shot at this but it wasn't so good, so I've restarted slightly the other day but I've been busy with the water stuff so if somebody else wants to give a go at texturing it, I'm OK with it

We'll change things when we get that in. But yes, it does look very nice thanks to the depth buffer (particularly around edges, where the normal fancy way gives really wrong results in some cases). I think I'll pick the second option, it sounds like it's the most obvious and the easiest one to implement. Atlas is slow because it recreates the texture every frame, in case the water height has changed. It ought to only when the water height changes, or it could be deactivated in Atlas... Is there a way to know in-code if it's Atlas or not? That should be a very easy fix.

Allright, I've finished the "clean" version. It fixes most remaining problems: water texture/foam texture looping issues, small depth buffer things that could prove distracting, and MEM_ACCESS crashes (I don't think there remains any, but it's always possible that there's a well hidden rare case). The only thing lacking is waves, but in the concern of putting this in the game, and since I believe there will be a lot of trial and error with waves, and I'm not there this week-end+, I think it's better. So it's all committed here. I'm not sure what the procedure on committing to SVN is, I don't think I can do it, or at least am unsure. Since there are probably other modifications than strictly the water stuff in this branch (which I believe I forked from myconid's merged branch some time ago, and anyway it's not up-to-date with SVN), would it be better if I took a clean SVN, merged with the water patch myself (by hand?), and then committed those files/gave those files to someone who can commit? Is the GIT mirror for SVN up-to-date? In this case I could fork that and patch, and then it'd probably be easier to put into SVN.

I do realize that . Okay, so I'm not happy with how the waves look. I could pull out a sort of workable system that would be bugged in some situations but would work in others, but I don't think it's really that good-looking (and given how the rest of the water now looks, I feel it's a step back). Therefore, I'll now try to clean up my patch for the water (without the waves) so it can be put, whatever happens, in alpha 11, and then I'll work on another solution for the waves: cutting the water mesh in two: a "coastal" part and a "high sea" part, that will allow me to have both shaders more efficient at what they do (the main bulk of the code would be the same, but some stuffs about foam or reflections could slightly change). With that system, I'll get rid of annoying mesh and z-fighting issues, and I think I could pull of some niceties a-la AOE3. Perhaps. Not as good. Perhaps. If that's okay with you.

Could use a stronger orange under the forest, but I really like the grass there.