Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Aug 2002
Offline Last Active Today, 02:23 AM

#5206328 Domino effect physics

Posted by Nypyren on 23 January 2015 - 09:10 PM


...should get you started.

#5206324 Machine Learning for procedurally generated levels.

Posted by Nypyren on 23 January 2015 - 08:52 PM

Extremely difficult.

#5205913 Projectiles in a video game

Posted by Nypyren on 21 January 2015 - 09:13 PM


#5205912 C#: leaving unused reference-types

Posted by Nypyren on 21 January 2015 - 09:04 PM

Both proposals are actually the same. The implementation of List<T> uses what you describe in #2 (keeps an array internally, resizes when it goes over capacity, and keeps a count of the actual number of slots occupied in the array).

The most costly operation is resizing. You want to minimize that. Using List<T>.Clear will leave the internal array at its current capacity and just set the 'count of elements' to 0. This is useful if you have roughly the same number of elements in the list per frame.

If you know a rough ball-park estimate of the number of items you'll be adding to the List, you can reserve the expected capacity ahead of time, which avoids multiple resizing operations.

Just go with the List<T> for now, and profile later if you have problems.

#5205700 I am beginning to hate the IT and gaming industry.

Posted by Nypyren on 20 January 2015 - 10:34 PM

...then rather quickly went to the "do you have questions for me?"  That's a sure sign of not getting the job in my experience.

I'm part of the interview process where I work, and we always ask "do you have any questions for me?". It's never a sign that we've made a hiring decision. Usually it's a sign that we're near the end of our pre-determined interviewing time. We also do this because otherwise the person never gets a chance to breathe.

The way the question is answered can contain a lot of useful information for us. It can give us insights into their personality, interests, how well they might get along with coworkers, and lots of other things depending on what is said.

People have asked us about the town (if they would be relocating), how we like our jobs, whether there are any good places to ski nearby, what our favorite kinds of games are (we ask them this, too - getting into discussions about good games can be extremely useful), etc.

#5205419 What is VC#

Posted by Nypyren on 19 January 2015 - 05:25 PM

Visual C# is Microsoft's product (the tools such as the IDE, compiler, etc). C# is the language.

Visual Studio 2012 includes Visual C# 2012, which supports C# version 5.0.

#5204630 isnt XNA dead?

Posted by Nypyren on 15 January 2015 - 08:55 PM

On the plus side, you no longer have to worry about rewriting your code each time a new version of XNA comes out.

You also don't have to wait 6 months to a year for the XNA team to support the latest version of Visual Studio (which adds support for the new C# hotness) when new versions of that come out.

#5204370 Checking the equality of objects in C#

Posted by Nypyren on 14 January 2015 - 08:43 PM

Also remember to override GetHashCode if you override Equals!

#5203718 C# Code Snippet Review

Posted by Nypyren on 12 January 2015 - 12:22 PM

I assume DrawCard removes and returns lDeck[0]?

Also, your code is performing two cuts per loop (Overhand Shuffle just splits the deck in two and swaps the two sub-decks). For a single cut, all you really need to do for a single cut is something like this:
deckCutPoint = pRng.Next(lDeck.Count);
for (int j=0; j < deckCutPoint; ++j)
Personally, instead of an Overhand Shuffle, I would use a Fisher-Yates shuffle which is faster and randomizes the deck completely with a single pass: http://en.wikipedia.org/wiki/Fisher–Yates_shuffle

If you just want to make your original code better and preserve the algorithm exactly as it is, here's what I would change:

- Lists have an internal array which expands if necessary. The expansion operation makes a brand new (larger) array and copies the old array into the new one. You can avoid this by reserving a starting capacity in the constructor: new List<Card>(lDeck.Count) for example. If you have a reasonable upper size limit, reserving that limit will prevent all resizing overhead.

lDeck = lDeck.Concat(secondCutDeck).Concat(firstCutDeck).ToList();

It would be more efficient to do this instead:


#5203536 About computer instruction in relation to RAM consumption

Posted by Nypyren on 11 January 2015 - 02:30 PM

The stack grows down the memory addresses from the top of the allocation near 0xffffffff (not quite this high though for various technical reasons) whilst the heap grows upwards from the bottom of the allocation directly after the program code (generally a much lower address).

The "stack and heap growing towards each other from opposite directions" stuff isn't used anymore. I'm not really sure why computer science books even mention it.

There's one stack per thread, and they're scattered throughout the address space. The first thread's stack on Windows is typically between addresses 0x100000-0x190000. The main EXE is usually loaded around 0x400000. DLLs are usually loaded at higher addresses. Multiple heap and read-only sections are scattered throughout memory, seemingly at random. Additional thread stacks can be allocated anywhere in the address space.

#5203316 About computer instruction in relation to RAM consumption

Posted by Nypyren on 10 January 2015 - 01:39 PM

#1: In order to execute an instruction, the instruction needs to be loaded into the CPU. If the instruction is on a hard drive, in the worst case it means all of the following have to occur: Hard drive spin up, hard drive seek, hard drive read, bus data transfer to RAM, RAM transfer to CPU cache(s), instruction load from cache, instruction execution. The hard drive is a physical machine with moving parts, which makes it slower than purely electronic systems like RAM. If the program is already in RAM then the first, slowest parts of the process can be skipped and the process goes much faster.

#2: Ignoring instruction fetch bandwidth and cache misses, the speed of instruction execution does not depend on its encoding length.

#3: Usually a lot of stack space is reserved, and stack activity is VERY rapidly moving the stack pointer up/down within the reserved space as pushing and popping occurs - the space reserved does not typically change unless the reserved area needs to expand, and then the expansion is typically permanent (until the process exits).

#4: RAM is fast, but not infinitely fast. Compilers are smart, but aren't perfect. Algorithms may be inefficient due to human mistakes.

#5: There are bottlenecks everywhere. You'll eventually run into some smile.png

#6: That's right. More time taken per operation = fewer operations per time = slower.

#7: Real-time games are typically written to consume 100% of each core they can run on. It sounds like you have either a 4-core hyperthreading processor or a 6-core processor and are using one core.

#5202706 What is the ideal solution for a repository in my case?

Posted by Nypyren on 07 January 2015 - 05:50 PM

Words = new HashSet<string>(File.ReadLines("words.txt"), StringComparer.OrdinalIgnoreCase);

// later (do not load the file once per word lookup, obviously)

var wordIsValid = Words.Contains("whatever");
Ship it.

#5202680 Should I learn C before learning Objective C

Posted by Nypyren on 07 January 2015 - 03:46 PM

Learn the language you intend to use. Don't learn precursors just because they're precursors.

#5202493 Something went wrong with exportation...

Posted by Nypyren on 06 January 2015 - 11:35 PM

The position has been divided by 5.0, and Y and Z are swapped.

Your original scene probably has an unexpected transform somewhere that you or the exporter aren't taking into account...

I've never used that exporter so I can't help you with that...

#5202484 inverted GJK --- you're a genius if you can solve this

Posted by Nypyren on 06 January 2015 - 10:19 PM

I see a problem with this idea: Let's say the landing ship is halfway in the hangar, and halfway in space.

You'll detect a partial collision with the mothership, and WON'T get full overlap with the hangar, yet you *still* don't want the landing ship to collide with the mothership.

You can't just extend the hangar zone into space because you'll still run into problems around the edges of the hangar entrance.

If you absolutely must avoid using an algorithm that handles concavity, I would split the mothership's single convex hull into multiple convex hulls that take the empty hangar space into account, then see if the landing ship is colliding with any of them.