Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 19 Aug 2002
Online Last Active Today, 03:55 PM

#5238377 Why is controller support for pc game so poor?

Posted by Nypyren on 04 July 2015 - 01:56 PM

Why do you think controller support is so poor for pc games?

Which PC games are you talking about? All the PC games I've played with controller support worked great.

#5237135 delete file on Windows

Posted by Nypyren on 27 June 2015 - 12:55 PM

I highly recommend using an IDE or text editor with good syntax coloring, since it will be painfully obvious whether you've closed a string properly or not, and you'll get feedback as you're typing.

Every single backslash you want to put in a string needs to be doubled. When \ is used as an escape character, it only 'escapes' one character after it. So if you have multiple characters you need to escape, you need a new \ to escape each one:

"\\" is a string with a single backslash.
"\\\\" is a string with two backslashes.
"\\\\\\" is a string with three backslashes.

#5236662 Oauth 2.0 and Unity

Posted by Nypyren on 24 June 2015 - 09:27 PM

The first thing I notice is that you're calling WaitForAccess directly, yet the function contains yields (in Unity terminology, it's a coroutine). Calling coroutines directly doesn't work. You need to call StartCoroutine(WaitForAccess(www)) or something similar to execute it properly. This should at least let you get a response from the web service. Whether it'll work or not, I can't tell at a glance.

You should use Encoding.ASCII.GetBytes(string) instead of making a byte[] and calling Buffer.BlockCopy.

You don't need to use the 'new URL' part. Just pass that URL string literal directly in the WWW constructor.

You might try using a WWWForm instead of the plain Dictionary as well. It looks like it's more convenient and might help eliminate typos more easily.

#5236611 flocking sim help

Posted by Nypyren on 24 June 2015 - 02:10 PM

Yeah. Something like this...play with the numbers to see how they modify the flocking:

velocity += sperationvec * 0.05f + aligvec * 0.2f + conhesionvec * 0.02f;

#5236602 flocking sim help

Posted by Nypyren on 24 June 2015 - 01:41 PM

Your cohesion function is using the alignment radius for its check instead of the cohesion radius, but that shouldn't necessarily cause major problems.

My guess is that your existing boid velocity are just being modified too quickly by the flocking velocities.

Try multiplying the flocking velocities by small fractions such as 0.05f or so. I would personally put cohesion as the weakest force, separation slightly stronger than cohesion, and keep alignment fairly strong.

#5236235 Lake flow

Posted by Nypyren on 22 June 2015 - 05:42 PM

Breadth-first traversal: Start at the ocean, follow rivers upstream, set the height of each lake to max(current height, downstream lake/ocean height + some amount). Allow the traversal to revisit nodes even if they were reached from another path.

There are more efficient ways to traverse the graph if you have huge numbers of lakes and rivers, but that should get you started, anyway. Ideally, you only want to set a lake's height after you've calculated all the heights of its downstream lakes. https://en.wikipedia.org/wiki/Topological_sorting would order the lakes so that this condition is met.

It sounds similar to algorithms used in https://en.wikipedia.org/wiki/Layered_graph_drawing , actually.

#5235884 Monogame, Ray Intersection not working correctly

Posted by Nypyren on 20 June 2015 - 12:05 PM

You still need to show your code that calculates enemyToPlayerNormalized. I'm not concerned with the .Normalize call. I'm concerned with what comes before the Normalize call.

It looks like you find the center of your objects, make a new box there, and then are firing a ray between the corner of those boxes. That'll still have a corner-to-corner problem like I describe above.

It might be enlightening if you add some code which draws a debugging line along the same path your ray takes, as well as the bounding boxes for the enemy and player.

What else might your ray hit? Are you testing for obstacles between the enemy and player? If you fire a ray towards the player, but it hits *nothing* (not even the player), then that means the ray passed the player (for example, due to the ray grazing a corner). If all you are checking for are obstacles between the two, then a null result is the same as if the ray reached the player.

If you're only using it for a distance check, you don't need to use a ray for that.

#5235784 Monogame, Ray Intersection not working correctly

Posted by Nypyren on 19 June 2015 - 05:43 PM

You should also show how you calculate enemyToPlayerNormalized.

It looks like you're starting the ray at the corner of your bounding box, rather than at the center. If your enemyToPlayerNormalized direction points from corner to corner, the ray might barely touch the player box's corner, which may or may not intersect due to the imprecise nature of floating point numbers.

I'd suggest aiming the ray direction towards a point on the player that won't have this problem, such as the center of their bounding box.

#5235601 Why didn't somebody tell me?

Posted by Nypyren on 18 June 2015 - 07:52 PM

I know how that goes. I have trouble clearly pronouncing words ending in -rer or -ror. Imagine the awkwardness when I try to tell people I like horror games...

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

Posted by Nypyren on 18 June 2015 - 05:07 PM

Database concepts in general and SQL in particular are pretty important to learn. You're probably shutting yourself out of a LOT of job opportunities without it.

#5235532 What is the future of the Game Dev. industry?

Posted by Nypyren on 18 June 2015 - 11:33 AM

...should i opt for developing my own games as an entrepreneur or start working to get a job in big firms like Ubisoft ?

If you have a pessimistic outlook for a given market, then it's probably not a good idea to become an entrepreneur in that market. Your motivation, confidence, and vision will not be strong enough to compete.

#5235197 Why didn't somebody tell me?

Posted by Nypyren on 16 June 2015 - 04:02 PM

I just discovered you can toggle bits on/off in the Windows Calculator when it's in programmer mode just by clicking on the 1's and 0's themselves. That's... I can't... why didn't someone tell me?!

#5234771 hash

Posted by Nypyren on 14 June 2015 - 01:12 PM

That's an incredibly bad hash function for any of the possible purposes where hashes can be used...

#5234386 Strange twitching with an orbit camera

Posted by Nypyren on 11 June 2015 - 08:57 PM

I'd keep {targetPos, distanceFromTarget, pitch, yaw} as my camera state. I'd update those when new input arrives. Then I'd use those four variables to calculate the view matrix from scratch: Either make some matrices representing the translation and rotation operations you'd use to transform the camera to the right position/orientation and multiply them together, or hand-calculate the equations for each element of the entire matrix. Constructing the matrix in this way will keep your right/up/forward vectors aligned properly at all times.

From prior threads, it seems that view matrices can be made without using Math::LookAt or other view-matrix helper functions by simply making a transform that you'd use to position a mesh at the camera, then take the inverse of that matrix.

Here's a link that might help explain what's inside a view matrix: http://stackoverflow.com/questions/349050/calculating-a-lookat-matrix

#5234175 Strange twitching with an orbit camera

Posted by Nypyren on 10 June 2015 - 07:00 PM

All of the code prior to the last three statements is operating on the old camera matrix.

Then he changes the camera position, but doesn't fix the right or up vectors. They still have values that are only correct from the old position.

Then he makes a matrix using: LookAt(new camera position, same camera target, OLD up vector);

I believe you're right that you can pass some constant up such as (0,1,0) to the LookAt function and that the function fixes everything internally. I remember doing that, but was never sure if I was actually supposed to or not.