Jump to content

  • Log In with Google      Sign In   
  • Create Account

Starnick

Member Since 06 Oct 2010
Offline Last Active Today, 10:50 AM

Posts I've Made

In Topic: Fluid - Spatial Grid

16 May 2016 - 07:29 AM

You can look into pairing functions to create a hash from XY coordinates:

 

http://stackoverflow.com/questions/919612/mapping-two-integers-to-one-in-a-unique-and-deterministic-way

 


In Topic: Is it C# Territory?

04 May 2016 - 07:06 PM

Depends on the company, I think AutoDesk has some products that you can interop with C#. Others, like my company (e.g. https://www.bentley.com/en/products/brands/openroads) use a mix of C++ and C#...many of our power applications sit ontop of a C++ platform for graphics, element storage, etc but a lot of the business logic and UI are in C#.

 

C# is more than suitable for a robust graphics application however, you will need to care more about memory management than a typical C# programmer may (e.g., the upcoming language feature of "ref returns" is a big deal to us, but at the //BUILD conference this year it kind of just was shoehorned into the C# team's presentation).


In Topic: BeginInvoke within XNA

14 April 2016 - 09:00 AM

If I'm understanding right...you're talking about a compile error?

 

Microsoft.Xna.Framework.Game doesn't have a function called BeginInvoke. Presumably your sp_DataReceived was declared in a type that extended a Form or some Control before you ported the code over to an XNA game. This is where MSDN documentation is your friend, as BeginInvoke is a method declared in System.Windows.Forms.Control.

 

You'll get an error if you try and modify state on a WinForm control from a thread that is not the UI thread (the thread that the controls are being run on). BeginInvoke allows you to send a message to the UI thread and perform an action that will update the UI at a later point in time. So call BeginInvoke on one of your WinForm controls and it should compile.


In Topic: 'External Code' taking up most of my CPU?

14 April 2016 - 08:48 AM

 

Ok, it looks like (from my own tests) calling ElementAt on the Dictionary's Values collection is really slow. I'm guessing it is an order-n operation that needs to iterate through items one by one, since the larger the index the longer it takes.

 

You probably want to use foreach instead (and hopefully the ValueCollection's iterator is a value type, to avoid unnecessary heap allocation)

 

In the little test I did, for a Dictionary of 10,000 items, this:

 

            for (int i = 0; i < blobs.Values.Count; i++)
            {
                value += blobs.Values.ElementAt(i).a;
            }
 
was more than a 1000x slower than this:
 
            foreach (Blob blob in blobs.Values)
            {
                value += blob.a;
            }
 

 

 

Just a FYI:

 

Dictionary, List, possibly a few others (except for Collection<T>) all have struct enumerators and explicitly implement the GetEnumerator() so the GetEnumerator that actually will be called in that foreach will return the struct enumerator and not do any boxing. 

 

With that said though, ElementAt is an extension method for IEnumerable<T> so the value collection is going to be treated as an IEnumerable<T> and the explicitly implemented GetEnumerator will be called, which means the struct enumerator will be boxed.


In Topic: The first video game enemy you ever murder.

02 April 2016 - 07:08 AM

For me I'm pretty sure it had to be Golden Axe, on an older arcade machine (when it was released I was only 2!) and it's only vague memories. It may have also been Wolfenstein 3D, but I have more concrete memories of playing that.

 

 


PARTNERS