Leaderboard

I'm creating this topic to discuss parallax creation, and fixing for all the civs, like the persians won't don't use it at all. So here is my workflow : 1. Open the texture in gimp2 2. Desaturate. 3. Duplicate the layer 4. Apply a 1px gaussian blur on the top layer 5. Apply a 3px gaussian blur on the bottom layer 6. Set the top layer to substraction You should get something like this : 7. Go to luminosity contrast and bring the luminosity down till you get something like this. 8. Merge the layers 9. Invert the colors 10. Apply a normal map with those settings : 11. Apply Blur 12. Set opacity to 90. 13. Done. I don't have any wrong glitch with that which is good. But I think there is a better way. Example of "glitch" Final on the model :

It seems like pushing back to after A17 has no drawback other than "it makes A17 weaker"? Given that Philip is afaik still looking for a job, it would be better to ask him when he estimates he'll be over with this. I haven't really followed your progress but I don't think it'd be a good thing to push A17 back.

The currently planned schedule needs replanning. We have several options for the upgrade and related tasks and need to decide on the priorities. Unfortunately, the two major bugs (bug 991820, bug 984537) have not yet been fixed or not in time for v31. This means the performance improvement of the upgrade won't be as big as the best results in the first post of this thread (nearly 20% simulation performance), but if the first measurements are still valid, it should still be nearly 10%. These numbers are only valid for that specific testcase and can be different in other cases of course. I was hoping that generational GC could mitigate the impact of these bugs, but the public API is not quite ready to control generational GC yet and I haven't yet tested if it really helps. I wanted to get ready with exact stack rooting support (ticket #2415) before the upgrade because it needs a rebuild of SpiderMonkey with different flags (and new Windows binaries). It would also be good if our programmers get used to exact rooting now. Most of the changes for exact stack rooting are done, but there's still quite a bit left. Especially it needs careful testing. We have to test specifically for that because rooting issues are very hard to find by just playing the game. The same thing could work a thousand times and then suddenly fail because of garbage collection timing. There's dynamic rooting analysis which can already be used and we might also need static rooting analysis, which is probably quite a bit of work to implement (ticket #2729). I still don't know enough to tell if we really need the static analysis though. The SpiderMonkey 31 upgrade itself (without all the additional things like rooting) is a bit behind schedule. I haven't heard of any progress from Philip on the autobuilder (which we need for C++11 and SpiderMonkey) and I noticed that there's no bundled release from Mozilla yet. In addition there's still some work I have to do on the code. After all this is done, a testing period of at least one week is needed. I don't think this is all going to happen in less than two weeks (until the currently planned Alpha 17 release). I would reduce it to two options now: We aim for Alpha 17. In this case we'd probably keep exact rooting disabled but would continue with the API transition. Developers could also enable it if they want and don't mind rebuilding SpiderMonkey. This also depends a lot on Philip and whether he can/wants to complete the autobuilder work in time. The Alpha 17 release would most likely get delayed. We would have a small performance improvement. We plan the upgrade for after the Alpha 17 release. In this case we have more time for the autobuilder and exact rooting and it could be committed with exact rooting already enabled. Most of the benefits from exact rooting won't be accessible before the next SpiderMonkey version, but it would still help a bit. Some JIT compiler bugs were related to the conservative stack scanner for example. I haven't yet done performance tests with only exact rooting enabled.Here's a little visualization of the dependencies:

It's a wonder, I don't really mind if it's always green. However one big green decal might work better than 15 small.

-One small thought to slow a little bit cav rushes: make the corral a prerequisite for cav units. (One civ could have a bonus that allows to make cav without it). This would give more value to this building (I know that the main function isn't implemented yet) - I like the changes, but i'm worried about the way. The team was aware and agreed on this? -About the units attacking fields with javs (or swords): AOE 3 style wasn't the most realistic, but is better to have people tearing down buildings by swords. Torches and flamming arrows, you know. Still unrealistic when a stone wall is destroyed by pikeman throwing torches, but in general, I think is better. -Lordgood drawings have been kicked? I liked his work - It would be nice an dev report, not only for throwing this, but for show what have been done and what are the plans. Cheers.

I like both. A grass hill in a desert will always look funny anyway.

Could you give us some pointers on what you don't like so far? Hopefully just thing's we haven't finished yet

I think he meant on how to convert from playing AoK to 0AD, not unit conversion.

While I don't fully agree with the "surprise" commit (it could have a forum post with a little explanation, major changes list, etc) I don't see the issue either for the same reasons as Brian.

I don't see an issue with it. I see it as another combination to try. If we end up liking the balance branch better than the recent changes, it won't be a big deal to add it to SVN.

The only hotkey that I miss having is a single keypress that will pause the game.

New texture preview. VS

Finally done Little screenshot : RotaryMill.7z