wraitii

Created a Githbub repo for a simple python script that sort of implements this. For now it's very naive and only uses entities as a source. https://github.com/wraitii/0-AD-RM-beautifier/ Sample output: http://pastebin.com/11MLkwTZ

I do not see many real improvements coming unless: map size is increased massively for more realistic scales Walls become much harder to penetrate while other buildings become much easier to destroy (meaning walls become more necessary) Both these things require substantial gameplay changes and code changes. The biggest problem imo is building time.

Generally speaking, any realistic implementation of siege warfare would be too "slow" to work in the game. Unless you went with very abstract things such as a special "mining" ability that just makes walls explode instantly or something.

Hello LittleDev, For your information the current AI developer is mimo, it was previously me (like 2 years ago) and before that a few other people. If you have questions, feel free to ask.

Something like Grass waving requires many many more grass actors than the rendering engine can currently support (test it yourself in Atlas), but the waving isn't a problem: trees already do it. To support that many actors we'll need to have some real instancing which is still a bit out of reach.

Seems like a brilliant change to me, with the caveat Sanderd noticed. For our purpose, maybe make it reach a little less far? It'd probably go into the meshes of buildings too much like that.

Oh god the lag

It would need some testing, I think that might be a bit too much, it really depends. Perhaps a proper implementation would be a separate "pop cap", where different buildings have different values. SO a house costs 1 slot, but a barracks 10 or 5 so you have to decide.

Yeah this color-fade effect isn't handled very well. I think another direction to work on is to base reflections more intelligently on normals. If the reflection vector ends up being "straight up" there should definitely not be a reflection of a nearby object from the map. About depth: I find the idea of a logarithm very interesting.

I think you made refraction too weak at low waviness.

Interesting. Limiting the number of building per phase might actually be an idea I'd like to try.

Yup, you're entirely right. I tried some stuffs to fix that but it just added more problems. I'm quite interested in your patch, looks good. Re normal maps: there are no visual artifacts. There's only a visual "issue" that you see flat reflections instead of seeing what you should see (a mix of water color and sky). Check out this picture, we see very little reflection in the distance, as the water isn't flat. Compare with this. And in-game in the attached picture. It only ever happens at low angles, but it looks very bad on cinematic shots.

Yeah, I'm aware of that last issue, but you're really free to change it if you think it looks better. About the normal map point: The textures used at low angle, even with a lot of anisotropic filtering, end up being blurred at low angles, or are very "sharp" which looks even worse (basically either left or right here). You need at least 16x anisotropic filtering to keep it acceptable, and even then it's never really enough. Also I might have done the linear fresnel thing on purpose: we as humans are used to seeing reflections on water, as we tend to look at water at a low angle. Looking at water from above with no reflections at all looks kind of odd, so I artificially made my water too reflective. You're right that looking at the side of a wave means more refraction, but because of the problem in my diagram above instead code usually shows reflections, which is basically entirely wrong. Feel free to ask any other question.

Are you sure about FBOs? Also Yves is definitely focusing on draw calls but not only that, and porting to OpenGL 4.0 requires quite q few changes so definitely talk to him if you wish to update the renderer. FYI the chrome was never committed as there were some slight issues with implementation details, but it used the skybox, not a "real" 3D Reflection. It would be pretty much impossible to render realistic reflections for arbitrary items, but for a few very important ones we could in theory render a very downsampled box texture of the surrounding terrain. This is the technique used by games such as GTA5. My belief remains that we need to implement software batching by actually merging objects together to unlock great performance. Also FYI the water shader is really separate from the rest so I used an "if" there as it was supposed to be a more "modern" feature, which are very widely supported. The rest of the code is supposed to be runnable for an Opengl 2 system, but that decision might change.

Speaking as the maintainer of the water code: Seems like you managed to fix the weird inverted normal Issue I had which made specular wrong and I never bothered to fix. By this point I expect you have noticed I'm using real reflections for the skybox and distorting a transparent "reflection map" for objects that are near. FYI the "artifacts" when you orient the wind north are dependent on graphic cards. It never happened for me on Intel GMA and I could never fix it because of that. Make sure to test your code with all textures types and all waviness settings as there is a lot of room for mistakes there. Likewise, the Red color that appears at low angle is WorkingAsDesigned and is there because of the distortion code. With the shader tries to get refraction texels that are "above water" pixel and contain garbage data. I detected this in the shader by checking the red component against the other one (the "horrible hack") and choosing the original undistorted texel in this case. However in some cases even that is insufficient. SO if you just remove the hack you're only going to break it further. The red comes from the C++ code, the refraction texture is cleared with (255,0,0) before drawing the refraction. So when you fetch a pixel that's not rendered (above water) you get full red, which is why it happens on the edges of the map. The proper fix for that problem is not trivial. Also FYI the shore waves took me months of thinking to get somewhat right. I do not believe they are recomputed every frame, though, if they are it's an insane bug on my part. IIRC I create polygons by trying to follow the shore, but I never got it to work really well. Edit: Oh yeah also I see you removed my comment about reflections being wrong at low angles far away, but the problem is still there. Just as an FYI, I still believe my "default to sky color" is the right way to go about this, but there is one thing to notice: since the normal map gets entirely blurry, the normal of the water plane becomes (0,1,0) ie straight vertical. But in real-life, you see the sky more because of the wave ripples. See my attached diagram. So that may be another thing to go after.

I agree that the current speed of cav should see them either trot fast or slowly gallop.

I think we should also come back to about 3 workers per farm or even fewer.

Looks pretty good. I've reviewed your updated patch and uploaded a slightly cleaner version for Leper to give a look at, I think you can continue with this and we'll get around to committing it.

Hello Lion, this is a known issue. The way we want to fix it is by implement scrolling, but we haven't so far. Thanks for reporting anyhow!

My opinion on the trade vs resources debate: I agree that resources should be faster when they are still present. However, I also believe they should be faster given equal technological investment, ie upgraded trading might be faster than basic resource collecting, but not upgraded resource collecting. I also believe that trading should be able to replace resource gathering somewhat efficiently when resources are depleted so that the game doesn't slow to a complete crawl. Finally, with that particular implementation, I think it might be worth it to have a civilization where trading might get more interesting than gathering overall for some resources not necessarily all of them though), for example the Persians, which are supposed to be a trading-strong civ (in SVN they get 25% more from their traders, here their markets are 25% more efficient). So say maybe for Persians, they don't have access to the best (say) metal gathering techs, but trading can compensate. Also worth noting is that trading rate currently depends on your trade preferences, which may or may not be a good idea, because if you focus entirely on one resource, you will get a much better rate. Perhaps players should no longer be able to determine what resources they want to gain from trading? I do agree that it would be interesting if players could raid markets, but it would require quite a lot of changes. In the meantime, perhaps markets should ungarrison units even when only slightly damaged or captured.

Uploaded an updated patch to a trac ticket.

Most of the team (at least those who played a bit) agree that the current "champs only" win strategy is boring as hell. We're looking at ways to change it.

Attached is a mod that implements (to an extent) my "context-sensitive GUI" idea. You'll find a few differences with SVN: -Garrisoned units appear in a new panel on the top left part of the GUI (similar to the production queue), leaving more room. -Commands are now in the left panel. -The "raise alarm" icons are now commands -The Middle area has been changed to feature the two most common armor types -There is a new context-sensitive row in the middle -The "identity" zone was made slightly bigger so you can see more of your unit badge. Overall I think the system works rather well. Obviously there are no tooltips yet, which would give more info, and I'd like to make it so that clicking on the unit icon opens a complete description (there's a ticket for that on Trac). But it will give you a feel of how it could work. GUIMod.zip

I agree with wow on that, it's pretty easy. Plus the GUI is super obvious about this.

I see where you're coming from with this Yves, but your approach has a number of technical issues and isn't necessarily more obvious. I think it mostly comes down to an interface problem - that can be fixed - and the fact that it's not the same as in AoK, but the system isn't difficult to understand and I think with a simple tutorial it'd work just fine. The tying of CCs with markets is mostly an artifice because allowing a player to have a ton of markets may be a little gamebreaky but I'd need to check that.