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 24 Mar 2010
Offline Last Active Nov 09 2014 09:17 AM

Posts I've Made

In Topic: Player movement without physics engine

29 September 2014 - 08:58 PM

Let me see if I can explain this better. I'm looking for approaches for controlling the movement of a player character (guided by the user), that do not use a physics engine (using the collision portion of Bullet is fine). So a non-physical or non-dynamic character controller, which would seem to be considered a kinematic character controller? (Though I'm not sure if the second approach below would be considered a kinematic character controller)
1. The approach that I have attempted to implement in the past used only the collision portion of Bullet to perform sphere-casts against a triangle mesh representing the world. So it calculates how far a sphere can move in a certain direction, and if that distance is less than the desired movement direction, it then projects the movement vector onto the surface that was hit, and performs another sphere-cast to allow for sliding collision. It might repeat that a couple times depending, and also does another sphere-cast in the vertical direction to handle y-velocity and stepping-down (to avoid floating/bouncing while moving down an incline. I believe that was also used to determine whether the player was standing on the ground. There were a number of issues that I ran into with this approach including getting caught when sliding along certain geometry, jittering in obtuse corners, and bouncing along the edge between the ground and a surface that is considered to steep to walk on.
2. The other approach is one that I have not attempted to implement yet. It would involve using a navmesh similar to what would typically be used to handle NPCs, except for the player. This is a slightly more limiting than #1 in that the player is constrained to the navmesh. Even though the player could jump, they could not, say, jump across the edges of the mesh (ex. over the edge of a staircase back to the floor). They basically move around within a triangulated 3D polygon. There would be no real collision detection between the player and the world geometry. One of my current uncertainties with this approach would be the handling of other obstacles (ex. enemies moving around).
So I'm wondering:
  • Are the above approaches actually used?
  • What other approaches exist?
  • Are there any good resources on implementing these approaches robustly?



Rough sketch of #2

Attached File  second.png   8.41KB   1 downloads

In Topic: Reflection problem in C#

25 September 2014 - 08:53 PM

You could use generic methods for arithmetic operators such as those provided by MiscUtil (http://www.yoda.arachsys.com/csharp/miscutil/usage/genericoperators.html), invoking, for example, Multiply<T>(T, T) through reflection.


However, that seems a bit overkill. Is there any reason you can't just cast the stat value from object to float when you're performing the arithmetic?

In Topic: V-sync and crispy textures

02 September 2014 - 05:38 PM

Wouldn't grainy / crispy textures indicate a lack of mipmaps? Or maybe incorrect texture sampler settings?


[Edit] Oops, Voidmancer beat me to it.

In Topic: Terrain rendering problem

03 January 2014 - 11:47 AM

Also, before that line there's a "Access violation reading location 0xFEEEFEEE", which would mean that something is referencing memory that has already been freed.



In Topic: C++ DX API, help me get it?

08 July 2013 - 09:01 PM

Allow me to pick off part of #6:


D3D11CreateDeviceAndSwapChain has two parameters that accept pointers to D3D_FEATURE_LEVEL. The first one is a pointer because it is actually looking for an array of D3D_FEATURE_LEVEL (and the parameter following that one is the number of elements in the array). The second one is a pointer because it is an output parameter to where the feature level that was actually selected can be stored.





Also, I expect that a lot of the reasons for the API being structured how it is are due to http://en.wikipedia.org/wiki/Component_Object_Model