historic_bruno

I don't know if that's a limitation of those devices, or that 0 A.D.'s performance problems affecting all platforms are simply more noticeable. Of course it's not optimized for Android mobile devices and never will be, but there are things to do which will help (reduce memory usage, add quality settings for lower end hardware). This is quite unlikely and IMO wouldn't be a good use of our time. There are just too many higher priority things to work on.

As stated, it was only an example to show normal mapping on terrain, which you claimed doesn't work I'm not a texture artist, so I'm not about to attempt a more realistic example, but if you want to try, that's how it's done. The current terrain textures weren't selected with that in mind, however, because it wasn't implemented at the time.

I like the idea of having a configurable "cooldown" period for sounds, a delay before the sound can be played again, that should cover this bug. It's better handled in the engine because it knows how long the sound will play, but exposing an API for that in scripts would be needlessly messy IMO - or a hack to workaround current behavior. Battle sounds would be more involved, either a limit on how many instances can play simultaneously and/or switching to a different sound set for heated battle (to some extent, playing individual sounds over and over doesn't give the same dramatic impression as well-crafted battle sounds).

That would be very cool to have in the game, not that we would use it often, but for mods and demonstrations. Assuming you want to add water to a model, check out the temp/reservoir.xml actor for an example (or, more specifically its water prop). Currently, it is very much hardcoded for water rendering and can't be used on arbitrary textures.

Terrain materials do work, here's an example modded pure "white" texture with normal and specular mapping added (to make the effect obvious): Without more details, I don't know what you were trying that failed. You need fancy graphics options enabled to see it and the terrain in question needs to reference an appropriate material and define textures. Here's the modified terrain XML: <?xml version="1.0" encoding="utf-8"?> <terrain> <textures><texture name="baseTex" file="types/whiteness.dds"/> <texture name="normTex" file="types/alpine_cliff_a_norm.png"/><texture name="specTex" file="types/alpine_cliff_a_spec.png"/></textures><material>terrain_norm_spec.xml</material> </terrain>

One tool that shows promise for profiling/debugging the game is AMD's GPU PerfStudio. An older, simpler tool is gDEBugger. I'm sure there are many others besides.

What changed, wasn't GLES 2.0 enough previously? (It ran on a Raspberry Pi which I thought was GLES 2.0)

I moved this topic to the art development forum Hopefully you can get some good feedback here.

I tend to agree with the suggestion for LOD support, even if we don't have the artists to do extra work creating the models today, that didn't stop us from adding AO, specular, parallax mapping to the renderer, with basically the same concerns. There never have been enough artists and there never will be, but you notice all our buildings now have AO and specular The worst case is we would never use it, but I have the feeling we would over time. Of course, AO, specular, parallax, bloom, were all basically a community contribution, not from someone officially on the team (that's how it started anyway). There hasn't been any similar effort for LOD, but perhaps if it was a desired feature... That being said, I think the renderer looks and functions well enough to not be a focus of the programmers, unless a feature really improves performance or attracts a lot of interest. Any evidence this would do either? I can imagine some performance benefit, I don't know if it's enough to justify all the extra work (look at 0 A.D.'s default camera behavior - how would it be used in practice?) and we would have to solve LOD "popping" behavior too.

That looks very cool, glad it's working for you now

All I did was copy your files to the appropriate mod directories, start Atlas, place an instance of the actor and move the sun around (in the environment tab) to darken the map. If you try that and it doesn't work, then you might not have the fancy graphics enabled. My local.cfg is like this: preferglsl = truepostproc = truewaterugly=falsewaterfancyeffects = truewaterrealdepth = truewaterrefraction = truewaterreflection = trueshadowsonwater = truegentangents = truesmoothlos = truematerialmgr.quality = 10.0materialmgr.PARALLAX_DIST.max = 150materialmgr.PARALLAX_HQ_DIST.max = 75materialmgr.PARALLAX_VHQ_DIST.max = 30

This is something that was never implemented in the new sound manager, but was a desired feature from the start, so it should be implemented there. Every sound needs limits on how many times it can be played simultaneously, even battle sounds, and some like UI sounds should only play once like you propose.

It does, but it's not obvious due to the brightness of the sun. You would need to make the self-light stronger or something.

I must have been confusing it with AO maps. In fact, I tried the provided model and it does glow, though perhaps not the effect you were expecting? You can see in the screenshot below, the right one has self-light but the left one doesn't. I had to alter the sun angle to make the effect visible. I also tried it as a prop. This was how the effect was intended, as far as I know. It might be possible to tweak some of the material parameters and end up with a different effect.

Do you only have one UV map in your model? I'm thinking you need at least two for these fancy effects (if the material has multiple textures defined).

Can you post an example model trying to get glow working? Even if it's just a cube, and not only the actor XML, but all the files associated with it, so we can test. It could be a bug, a model error, a config error, it's certainly not an effect that gets much testing.

Yes, that is the plan

BTW, the reason for that is normally you only place actors on a map for decorative non-interactive things and they can get in the way of selecting/placing entities, which are the actual game objects (units, structures, resources, etc.)

What we have now is an improvement over the old farms in terms of eye candy, but it looks too crowded, too uniform and patterned. I think part of that is the bug with prop variants, but even so, they are always going to be precisely the same layout. Some ideas: link several meshes together in Blender into clumps, then have maybe 3-4 clumps per field, they could be randomly mixed and matched (that's still props but at least it's not like 64 of them per field). Or there is the possibility of what wraitii and Philip discussed in IRC the other day, having the engine combine meshes together to take the manual work out of it. And just like a handful of trees in 0 A.D. can represent a forest or grove, a handful of plants could represent a farm IMO Then there's terrain conformance, well I wouldn't build a farm on the side of a hill, around here farmland is quite flat, I would expect the same thing in ancient times. So terrain flattening under fields when they are placed wouldn't hurt.

Rather than placing a premade clump of trees, it would be much better to have an entity brush in Atlas. trompetin17 expressed some interest in working on that. Or since we have copy/paste now, you could copy a clump of trees and paste as many times as you like, even save the contents to a text document for later use (eventually we could have this feature built into Atlas). I think sticking a ton of props together isn't a practical or efficient solution (I don't like it on our farms either).

Definitely don't use Notepad, it's probably the worst text editor you could choose. I recommend Notepad++ on Windows. I don't think that would cause errors though, please copy/paste the errors from the logs if it continues to be a problem. PMDs are lossy binary formats used only by the engine because they are smaller and quicker to load, but almost all of them correspond to Collada files. For releases, we only package the converted PMD/PSAs, but you can find the originals in SVN. It's recommended to have an SVN checkout if you plan to be modding, so you always have the latest changes. We also have a public art source repository with some Blender source files, but not everything is there yet.

Packaging will happen very soon, then we need to test, I think this week is possible. For updates: http://trac.wildfiregames.com/wiki/ReleaseProcessDraft

For reference: #1088.

Fixed in r16397, literally the last thing fixed for A18

In other OS X news, it seems we won't be supporting 10.6 or older anymore as of Alpha 18. I don't think that affects many users in practice, but the situation is that we have transitioned to C++11 now and the C++ libraries on older OS X versions don't have as good C++11 support as we require. This may or may not change based on user feedback, but it should be easy for just about anyone to update their OS X version anyway (if you can't for some reason, feel free to comment).