Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 01 Sep 2011
Offline Last Active Nov 26 2014 11:41 AM

Posts I've Made

In Topic: Modifying entities and sending updates

05 September 2014 - 02:12 PM

Microsoft, but the physics library already puts enough pressure on the GC to cause occasional pauses, so I try to keep the GC pressure to a minimum where possible. I admit I'm not hugely familiar with the inner workings of the GC, so maybe pressure from short lived objects doesn't matter, but it can't hurt to try to keep it to minimum

In Topic: Modifying entities and sending updates

05 September 2014 - 11:10 AM

After looking through my code I found that I'm not actually doing any addition/removal of components after the initial setup phase, so perhaps I don't need to allow that. I suppose if I did need to allow that, I could pass a lambda function to a ModifyEntity function which the main thread could run at an appropriate time.

The function composition is a good idea Sean, shame I didn't set it up that way from the start. Refactoring that is probably going to be quite a pain, more-so because I'm using c# and lambda functions that use capture end up causing allocations, so I'll have to rearrange things to avoid any capturing.

I think this'll probably solve the issue though, so thanks for the input guys.

In Topic: Modifying entities and sending updates

04 September 2014 - 05:31 PM

I suppose that would solve the issue during creation time. There'd still have to be an extra call at the end of creating the entity but at least forgetting that would just result in a useless entity rather than a crashing bug, so that's a plus. What about entity modification though? Suppose I want to add a component to an entity after it's already in the world.

In Topic: Pathfinding for large units

25 June 2014 - 03:29 PM

So I fiddled around with the code a bit, made some of the supporting code a bit more efficient. The time is down to about 15s now. Not exactly sure what I changed that made such a big difference, since I got nothing useful out of the profiler and I had to change a lot of things all at once.

In any case, the storage requirements are still an issue if I need to store multiple edge values for each block. Using a dictionary to store only non-zero values doesn't help in the least bit since there end up being around 90k entries and apparently each entry costs around 20 bytes.

I suppose the next thing I could try is to compute it on the fly and store only a small subset.

In Topic: Pathfinding for large units

22 June 2014 - 11:15 PM

It's hard to say for sure without disassembling the IR for your code, but my two guesses for your worst performance hits would be (A) doing a lot of redundant work when calculating indices into your voxel arrays; and (B) that inner foreach doing something weird, which I can't see for sure without knowing what the definition of the "directions" variable looks like.

Also, note that casting a byte to a double to call Math.Min() and re-cast to a byte is a really painful operation. Just write out the code longhand for the min check, it'll probably be faster.

The directions variable is just a small array of 8 Vector3 offsets. The casting is actually going to happen no matter what because C# doesn't support addition of bytes. It always casts them up to an int32. I'll try replacing the Math.Min call with an if statement though and maybe see if I can do something about the index calculations.