Jump to content

Sonarpulse

Community Members
  • Posts

    166
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Sonarpulse

  1. Garbage collector is a very bad idea for intensive real-time systems such as 0AD. I've worked on games in C# before and the GC always got in the way once the engine was sufficiently complex. Furthermore, debugging dangling references that cause obscure leaks is just ridiculous.

    In general we do very little in actual memory allocation with the new patch - you can see it in the memory timeline graph. Once the game is underway it's mostly smooth. If we used C#, memory usage would keep climbing very fast, until it hits a GC cycle - then the whole game will freeze for half a second. Definitely not something we want. Ever. Dealing with JS GC is quite enough trouble already.

    The best approach here is to allocate as much as possible beforehand and not do any allocations or deallocations during the game loop. This is something you can't really do effectively with GC based languages.

    Sure, GC-induced stalls are horrible with real-time systems, and thus I don't advocate them during gameplay. But does it make sense to treat the loading stage before the match begins as a real-time system? I'm saying for the loading stage maybe use some GC library (not switch languages) for temporary objects which will be deallocated before the match actually starts, because nobody cares whether GC cycles stall the loading process if it's still faster overall.

    Of course, if you can get rid of little allocations cleanly enough, as it looks like you have done, that great. But judicious use of GC could potentially both be easier and make for cleaner code than such manual methods.

  2. Switching the spikes from manual memory management to garbage collection could also speed things up. GC alloc is typically much faster, and since GC'ing itself has a time complexity with respect the number of live objects, garbage collection can actually be much faster when you have lots of short-lived objects, as seems to be the case hear. Any stalling from GCing (the price of more throughput) is also more appropriate during initial map loading than game play.

  3. Well if you are going for a big donation push, now's the best time to seek these things, as some things might merit rewriting anyways. Also if enough new code needs to be rewritten vs just maintaining old stuff, the new code can be in the new language and the old stuff kept in the old. Even if something were rewritten, and in the short term the rewriting slowed things down, you may be glad you did it. It's like the US switching to metric, it's annoying, it's painful, but it's only going to get more difficult in the future. Better incremental changes now than a complete engine rewrite for the sequel.

    Last I heard (about a year ago), much of 0ad's performance woes could be traced to the fact that it wasn't very parallel. Haskell provide very per formant lightweight (implicitly preemptive) concurrency http://benchmarksgame.alioth.debian.org/u32q/performance.php?test=threadring and unlike, let's say node.js, distributes those threads across multiple OS threads/cores. Additionally transaction memory, and/or immutability means deadlock and the other normal concurrency woes are out of the picture.

    Rust also supports similar lightweight concurrency, though I am not sure if it's implementation is as mature. It doesn't support transaction memory for safe shared state, but also allows rigorous use of immutable data structures and additionally offers unique pointers / notions of ownership to tackle the same problem. Additionally it's probably easier to interface with the existing C++ code.

    Javascript doesn't support parallelism, so there is little you can do to tackle that problem while staying with it. Even with existing code, I wouldn't say rewriting in C++ is going to be less painful than one of these languages, and without a good preemptive concurrency library you may still not reap all the performance benefits.

  4. On a related note, what if you have have multiple "bases" that are either a certain distance apart, or separated by water, they have separate stockpiles and you'll need to shuffle resources between them (with traders or something similar)? You could always build a string of cheep buildings in between to make the two bases one contiguous base ...but that would be much harder to defend.

    I imagine this would probably entail overall big changes in the engine, but it would add a whole new dynamic to the game.

  5. you know, honestly the best whitewater I was was the little creeks in Skyrim. And a swear it was just a couple layers of animated textures with only specular highlights as an effect. This only applies to splashes and rapids, not waterfalls proper or any bigger waterway, but it's a start.

    Look about minute 8

  6. I think your first orange was in fact perfect for leaf-litter, though the existing leaf litter texture can do too. As to the grass, it depends an what you are looking for. Grass doesn't change color like deciduous trees, it can however brown due to a lack of rain, as in the South African pick.

    If this is supposed to be a like a New England (or England for that matter), I think their is enough rain so the grass wouldn't change color at all (it would just be covered with leaves, and in a clearing or meadow there wouldn't be less leaves for that matter.

    In the steppes of Asia, western United States, that place in South Africa I guess (If that counts as Savannah probably other Savannahs too), the grass would dry out (what ever season that might be). AFAIK, the dry grass is tends to be less orange and more brown-yellow like the grass in the foreground of the South African picture. Not really sure what's making the grass so orange in the middle of the valley though, never seen grass like that before.

  7. As for your git questions you have a number of options.
    • You can make a temporary copy of your water branch in git, squash the commits you created, write the squashed commit to a file to create a patch, checkout the svn code and patch it with the "patch" command. Make sure everything is merged properly and then "diff" a new patch for submission. Remember not to include any of my model/terrainmapping code when squashing, though!
    • It may be easier if you add the official 0ad git repo to your local git (which I believe is up to date enough,since the terrainrenderer isn't changing much), make a copy of its master branch and cherrypick/apply the commits you want from your water branch. You could then squash and create a patch to test with the svn code, though I'm fairly sure you won't need any further changes.
    • Another option would be for me to update my master repo from upstream and you pull the updates through me, though I can't be bothered to regenerate the actor/terrain xml files, so I'd prefer we avoid this for now.

    I believe you don't need to squash your history to make a patch. I just searched and it seems their are a number of ways to convert a git patch to a svn patch.
  8. Indeed. I didn't bother researching the right word (we say "sheep" in French).

    Eh, don't worry about it. You've got better things to do than research that. Foam isn't wrong at all. (in fact, I'd also say the white that is left over after the wave breaks is more correctly called foam that whitecaps).

    The problem with that is that the top of waves (where whitecaps usually are) are the less distorted. I could easily do that if I knew where the top of waves are, but the texture has no heightmap in its current form.

    I picked the most distorted on the crude analogy that distortion was proportional to wave height (which is probably more true for breaking waves than normal ones, if ever true at all.) Anyways though, in this case i think realism is less important than finding a metric that somehow makes the whitecaps in look related to the distortion effect (which I believe is realistic), even if that relation is bogus.

  9. Here is an idea for waves and whitecaps ('whitecaps' probably being a better term than 'foam' for what we are trying to achieve):

    Looking at the (gorgeous I might add) screenshots of the tower, it looks like you guys are using dynamic distorting (for both refraction and reflection)? In that case I would say a wave texture isn't needed. Likewise, if possible you guys could scale the distorting near the shore (using the depth texture), you would get bigger waves near the shore (somewhat realistic, especially with bigger waves like tsunamis). Lastly, if the amount of distortion exceeds a threshold (per pixel), the pixel can be tinted white to simulate whitecaps.

  10. It would, but it gives weird results on maps like Oasis, and generally shallow maps. Technically, realistic result would be achieved by calculating "difference in water depth", which I might try.

    @Myconid: actually, I ended up using the x-z vectors of the terrain normal, so I get the "direction" of shore. With a bit of blurring, the effect is very nice.

    I don't know any relevant fluid dynamics, but I'd imagine what you'd really want is the gradient vector field based off the height map. https://en.wikipedia.org/wiki/Gradient

  11. You don't need real raycasting to calculate that. Here's a clever little algorithm I've come across:

    1. First render the terrain.
    2. Get the depth buffer which tells us the distance between the camera and the ground at each fragment.
    3. Pass the depth buffer as a texture into the water shader.
    4. Transform the water plane and calculate the depth value of each vertex, then interpolate with varying.
    5. We now have the depth of each point on the plane and the depth of each point on the terrain exactly behind it.
    6. A - B = the distance light travels through water.

    And what's more, when I implement the Postprocessing manager, the depth buffer will always be available as a texture.

    Haha, is that http://www.digitalartform.com/archives/2006/05/faking_simple_v.html from page 8 of this thread? Also, for ultra-realism wouldn't what you are saying need the light-ray-in-water distance computed from the camera's perspective and the light source's?

×
×
  • Create New...