k776

@myconid: Zaggy found this neat resource: http://www.gamerendering.com/ See if you can use anything from it, particularly: http://www.gamerendering.com/category/lighting/ssao-lighting/ http://www.gamerendering.com/category/shadows/shadow-mapping/ http://www.gamerendering.com/category/water/

It looks like it :-) http://librocket.com/wiki/documentation/LocalisationBut do we know anyone brave enough to implement this?

Last time I tested it, it worked quite nicely without any issues. I suggest we approach this like we did for the graphical improvements. If the source is clean and matches the coding conventions, and any old code is gone (not left behind), I suggest commiting the bulk of the work, and then people can test, report feedback, and make tweaks.

Sounds good. How are things like bloom and distance fog coming along?

Maybe a cache issue? You might need to close the game, remove the cache, and try again.

@myconid Looks all good from here. As long as you're available for say, an hour after committing, we can get a bunch of people to test it quickly for any obvious issues. And then reporting any smaller issues over the next day or two. Re: Affecting ARB, any big changes like this are bound to have some issues somewhere. Again, as long as you're around the help fix any big ones soon after committing, and smaller ones the days after, shouldn't be a problem. Re: preferglsl and gentangents, if they both have to be enabled for things to work, remove gentangents and use the same preferglsl variable. We don't want reports from people who have enabled one but not the other. I would stick the material manager settings under the preferglsl too, and comment the entire block of those settings as "## Experimental" or something similar. And when you do commit, just remember to keep preferglsl on false for now. These big changes should be opt in until we know they are stable enough. You have a green light for commit :-) Awesome work. Edit: Also, before and after you commit, can you pop on IRC so we can report issues to you there in realtime? Thanks. Go to http://webchat.quakenet.org/ and join channel #0ad-dev

Well, there is two choices here. We can wait for someone with time to review them, and possibly not have them in Alpha 11. Or, since they only affect GLSL and not ARB, commit each commit with it's own SVN commit, and then all SVN users get a chance to opt in to the GLSL version for testing. We talked about the latter option, and I'm leaning toward it myself. Since GLSL isn't enabled by default, it won't affect much. Plus, if we get them in now, we have a week to fix any issues we find.

Please put this in a Trac ticket if it isn't already. Don't leave patches on the forum. They will disappear and die...

Ok. Then a button is needed. Something you can toggle the units AI's "Auto flee" functionality. If enabled, units garrison, if not, units stay put and fight. A town bell which garrisons everything inside on the users request would be a different button.

I don't know too much about the AI system, but I do know one major factor is serialization. If you start adding multithreaded without much thought, you'll end up causing players to desync.

I think it'd be better to build this into the AI. If any defenceless person is attacked, they run for the nearest garrisonable building (tower, town center etc). And they don't leave it until the enemy units within the area are gone. Adding a button to do this makes it very micro-managementy, which will slow down the games pace.

We have plenty of math geniuses in IRC that you can call on. For now though, if it holds things up, comment it out, make a TODO note, and polish what works.

Why not make Gaia choose a colour from the colours remaining? e.g. 10 colours, 8 players, gaia uses one of the remaining 2 colours (defaulting to white if not used by someone else).

I agree with Mythos. We need to keep some kind of standard for minimap colours. So use the same colours that are available now. You'll also need to make sure that when someone selects a colour, that colour disappears from the other dropdowns... And while rare, you'll need to support the case where all colours are assigned, but two players want to switch colours (they can't just select the colour because another player has it). Maybe a blank option that everyone can select?

Very cool. Sounds like a lot of changes. I guess they're all necessary. Hopefully we can get some of this reviewed within a week :-) Edit: Are you still pushing to Git? Can you pull everything together into merged when you get a chance. Thanks.

Sounds good. Give us the go ahead when your happy for the modelmapping branch to be reviewed.

Of those, which ones are finished and you're happy with the code? Let's try avoid reviewing and committing something that might be rewritten later... Like the multi-texture/multi-coord patches, is there another set of work that acts as a base for other features? And if not, recommend a feature that's done, make a branch with only the commits/code required for it to work, and put them on top of 0ad upstream, then let us know.

Well, for started, myconid's latest patch on Trac is most likely outdated. He's done a lot of changes lately. I agree, it would be nice to have his work merged in, and it was the driving force behind getting two of the support patches committed. @myconid It would help the developers reviewing if you could provide a hierarchy of your branches. i.e. which is the base, which ones can be merged in next, which ones are in progress etc. From what I can see, it sort of looks like this at the moment (please correct/fill in): modelmapping windtrees smoothlos postproc [*]terrainmapping terrainalpha2

Not quite. I think myconid's Git work is far ahead of those older patches. In theory, yes. It'll be much easier for developers to code review using Github's branch compare functionality.

myconid, your two patches (multi texture and multi coord) have been applied to SVN and the git clone has been updated. When you get a chance, please merge your branches with git://github.com/0ad/0ad.git which will make the 'git diff' much cleaner to look at.

Merged branch compiled. Appears things working properly (though the bumpy roof effect is less obvious now(?)). I get this when enabling water reflections from Menu > Settings. ERROR: Failed to compile shader 'shaders/glsl/water_high.fs': ERROR: 0:100: No operator '*' exists taking 'int' and 'float' (and no implicit type conversion allowed in GLSL 1.10) ERROR: 0:101: Use of undeclared identifier 'shadow' ERROR: 0:106: Use of undeclared identifier 'fresShadow' ERROR: 0:108: Use of undeclared identifier 'colour'

There seems to be a file missing in your 'merged' branch. I can't seem to compile it at the moment. Once thats in, I'm looking forward to seeing the latest changes :-)

Nice work. Keep it up. Also, we want the ARB and GLSL implementations as close as possible. So any code that can be shared between the two renderers should be shared please.

@myconid: We want to commit the multiple textures and multiple UV patches. Are the ones on Trac ok, else can you rebuild the patches with just the requires changes? Then we can commit them into SVN, I'll do a Git sync, and you can pull in 0ad/0ad which should clean up compare pages so further code reviewing. Anyway, provide the patches if the ones on Trac are different, and we can go from there...

Yup, it's working. With smoothlos enabled, the game didn't crash. Two bugs so far, both to do with developer overlay (Alt+D): * When you enable and then disable reveal map, the SoD isn't slightly transparent (you can see the terrain when normally you should just see black). * The "Pathfinder Overlay" option turned on looks a lot worse. Red lines, flickering. Also, using "Reveal Map" the fade in/out is really nice, but very slow (jumpy/stagey). Is it CPU or GPU? Can it be made smoother?