Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 28 May 2011
Offline Last Active Today, 01:38 PM

Posts I've Made

In Topic: Using octrees for spatial representation

Yesterday, 06:22 AM

I would not use the same data structure to do all those things you listed. It would be better to give each task its own optimal data structure and later determine if its possible or necessary to share a data structure between two tasks.


Using the octree for everything might work, but wont necessarily be very flexible or efficient.

In Topic: Logo Feedback

27 March 2015 - 08:40 AM

Yeah, anteater was my first impression as well.


But the way its curled up in a ball or whatever doesnt really tell me much...

In Topic: Need help changing the date of a game

15 March 2015 - 05:43 PM

You could try contacting the creator(s) of the tool you mentioned that can change day/month if they have any information.

In Topic: Other Reasons Laptop Is Overheating ( n5010 - WIN7 ) ?

22 February 2015 - 11:55 AM

vacuum cleaner


I heard you shouldnt use a vacuum cleaner to clean computers because a lot of static electricity can be generated, possibly destroying some delicate electrical components.

In Topic: problem with circular resource movement in strategy game

22 February 2015 - 11:51 AM

Do not write the same data you are reading, or at least write the system such that the iteration order adds no directional bias.


You can do this by double buffering the relevant game state.


A more memory efficient method, if you can guarantee that you only read data from adjacent tiles and write to the current tile, is to go on a row by row basis, and BEFORE writing to a row, save that entire row in its 'previous state'. Use that saved row for the reads that access that row when processing the next row (instead of reading the 'new state' you just wrote to that row!). And when processing the row itself, use a similar method for the other axis, as iterating from start of the row to the end of it.


Basically, make sure you are only using previous state when calculating the new state (you can forget the previous state when you no longer need it to save memory, and you dont need to save a copy until you are about to update it with new data).



This issue is usually discussed together with grid based fluid simulations (since iteration order bias can cause fluid to prefer to flow in one direction).


Another 'hackier' solution that is probably easier to add, is to change the iteration order between each update, such that the bias will even out over time. In your example, this would mean that sometimes you get that lock situation, but sometimes dont, so it still works out. This solution causes your simulation rules to be somewhat 'nondeterministic' or unpredictable, so take that into consideration.