zoot

This looks cool, but do we really want the building overlapping the scaffolding like that? Not a huge deal, but it may come off as a bit hacky.

Hello from Mars. In a few days, there will be hi-res video for the first time from another planet.

Right, seems elegant enough. Probably what I was talking about ("maximum tolerable inefficiency") should be addressed with some other solution, like the ability to toggle individual effects on and off.

Right, now I think I see it. As it iterates through the descending list of alternatives, it loads each one until reaching one that is below the quality setting? If this is the case, it does IMO seem a wee bit counter-intuitive that you might end up with a material whose quality is higher than your quality setting. It is in effect a minimum quality setting rather than a maximum quality setting? In a sense you're right - why shouldn't it be a minimum quality setting? I guess my concern is that users (AFAIK) tend to use these types of controls to specify "maximum tolerable inefficiency/lag". Maybe someone else can share their views on this. Or, if not, leave it as it is

Fixed link. wraitii's water shader can be adapted to do 'volumetric' fog, and myconid has some ideas for refining it, so there's a good chance it will make it into the game.

Totally off-topic, but I think we can all relate to the enterprising spirit: NASA's Mars Science Laboratory mission is landing its rover, Curiosity, on the face of Mars tonight at around 05:31 UTC (in about 9:31 hours at the time of writing). NASA TV will be broadcasting throughout the event. Good luck, Curiosity!

Upon reading the tip of the day while loading, I always expect it to pertain to the map somehow. It would IMO be nice if we could relate tips to maps with some JSON or some such, so e.g. on a naval map you would be likely to get tips about naval warfare, on a map with pyramids, you might get a tip about mining pyramids, etc.

Next feature in line: quality levels. This adds a quality setting to the config here. It also adds a constructor to CMaterialManager, which hardcodes the engine's default quality level to 5.0. The default is overridden by the manually specified quality setting, if one is present in the config. The quality level is then clamped to the range from 0.0 to 10.0. Quality levels apparently supersede the old 'if' attribute of the 'alternative' element in material XML. I'm not sure I understand this statement though: if (!(!cond.empty() && preprocessor.TestConditional(cond))) Would it not be slightly less confusing if written as: if (cond.empty() || !preprocessor.TestConditional(cond))) Anyhow, the point seems to be that if the old 'if' check fails, the engine will see if there is a 'quality' attribute instead. If there is no 'quality' attribute or if the 'quality' attribute is less than or equal to the quality level specified in the config, the engine will skip (?) loading the material alternative. (I would have thought it would be the reverse - if the 'quality' of a given material alternative exceeds the configured quality level, it should not be loaded?) Otherwise, the material alternative will be loaded as normal (?).

You can make any lava look burning hot with the new emissive effects What kind of weather effects were you thinking of?

Let's see what this 'render queries' thing does. One thing to note is that it adds a new <renderquery> element to the material XML, like here. It also instantiates in the CMaterial class an object to hold 'render queries' which can be accessed through CMaterial::GetRenderQueries() here. New render queries can be added through CMaterial::AddRenderQuery() here. Each render query appears to be represented by a string key. When the XML of a given material is parsed, the 'name' of each <renderquery> element is added as a key to the render queries object of the material here. Currently, only one such render query 'name' is recognized, one called 'time'. If this name is added to the render queries object, it is added to the object's private array of render queries. Otherwise, it is discarded. Note: There seems to be an superficial inconsistency with these 'name' strings sometimes referred to as 'name' and other times 'key'. Note: There seems to be a small amount of code pertaining to render queries that has been commented out throughout the patch, like here and here. Should this be left in? In ShaderModelRenderer::Render(), the array of render queries is iterated through here. If any 'time' queries are found, the global time is retrieved from the time manager described in the post above and passed to shaders as an OpenGL 'uniform' variable named 'time'. I didn't come across any glaring errors in any of the above.

General note: the patch sets preferglsl=true by default, where I think the consensus is that it should remain false for now.

I've been poring over the time manager component. Thinking out loud (doesn't imply anything is wrong with the code): The patch instantiates in the CRenderer class a "time manager" object which can be accessed through CRenderer::GetTimeManager(). Every time CGame::Update() is called, g_Renderer.GetTimeManager().Update(deltaSimTime) is called. Not completely sure what that means, but I assume it sends the time elapsed since last frame (the time 'delta') to the time manager on every frame update. The time manager stores the delta in a private variable m_frameDelta and adds it to another private variable m_globalTime. The point of the 'global time' variable would seem to be to keep track of time elapsed since the beginning of the simulation (?). It can be accesed via CTimeManager::GetGlobalTime(). This global time seems to be sent to another new component ('render queries') here, presumably for being passed on to shaders. I didn't come across any glaring errors in any of the above.

Depends on their stats. In any case, having an unmemorable number of different units per civilization is silly.

ao/parallax/normal/specular/emissive mapping; windy trees; time manager; render queries; etc https://github.com/m...c15520e21e72209 The community is invited to help review this patch. Discussion of the code is welcome. To apply the patch for testing, use git cherry-pick or old-school patch.

Which one would you like to model? Some of the designs you posted were from the imperial era, and those probably won't work. Also, if they require exotic gameplay mechanics (like units-on-walls) they will be difficult to implement. Finally there's balancing - I don't think we'd want one civilization with hundreds of siege engines, especially if they are nearly identical gameplay-wise.

Sounds like you are offering to put in the time to make several new high-quality siege engine models?

I think idanwin made a good resume. I have to agree that it gave a sense of accomplisment in AOE when you saw your buildings switch to better versions. I think we could as a minimum add support for it in the engine. Can I persuade you or someone else to create a nice-to-have ticket for it?

I guess he would like to know if there is any chance of those designs making it into the game and if not, whether there is anything that can be done about it.

Please do not quote it. That only aids his goal.

My precious fountains finally finds a purpose

Should be easy to do as far as programming is concerned.

IMO such things would be better done server-side on a future dedicated server, in order to avoid having to hardcode the latest social media fads (sorry, no fan ) into the client. If a given social network API breaks (which remote APIs tend to do), it's much easier to update a few server installations than it is to update thousands of consumer-level client installations. Honestly, it's a bit like getting a tattoo: it may be all the rage today, but will it still look cool 10 or 15 years down the line? (0 A.D. has the potential to be an evergreen which Twitter and Facebook IMO does not.)

Making new props would still take time, at least if they are to look any good.

That seems to discuss a hypothetical, non-existing component? What need do you propose solving using Qt? The game is already cross-platform (no "rewriting the source code" needed). In any case, Qt's future is currently uncertain.

I guess the real bit of news it that they managed to speed up OpenGL on Windows by more than 10% just by optimizing on Linux - my point being that the optimization techniques they will discuss at SIGGRAPH should also be of interest to the (much larger) Windows user base of 0 A.D. Of course, "the proof is in the pudding."