Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Aug 2009
Offline Last Active Oct 02 2013 05:18 AM

#4849305 OpenMP omp_get_num_procs

Posted by on 15 August 2011 - 03:07 AM

Are you sure you are compiling with "-fopenmp"?

#4847633 Negative Reputation

Posted by on 11 August 2011 - 06:15 AM

What always confuses me about something as simple as a "like" button is that I don't know on which "scale" I'm supposed to rate the post. Do I "like" the way it is presented? Was the content useful to me? do I agree with what was written?

So for example when I'm reading a thread in the more technical forums I "like" posts that I learn something from. Generally posts that explain something in a understandable way ("was this helpful?"-button) or even ones that just point me into the right direction. Posts I'd vote down would be the ones that I know are incorrect, in which case I'd also try to answer and address the issue.
But then when I open my own thread with a question I suddenly feel like I should thank everyone who tried to help me, even if he misread my question. So now I'm treating the button like a "thank you" button. In the lounge I'd want to "like" stuff that has an entertainment value to me, like a post in a funny picture thread or an interesting point in a discussion (even if I don't fully agree). Someone else will probably rate the same post in the discussion based on whether he agrees or not.

So by using something as generic as a "like" button you just end up rating arbitrary (and maybe orthogonal) properties on an arbitrary scale and then somehow represent them in a single number.

For the technical forums I'd just go with a "this was helpful"-button and a "disagree/incorrect"-button for which you somehow have to give a reason (basically a variant of the quote button). If you really want it to be fancy you could weight the "disagree" post based on how many people disagree with the disagree :D. In the more off-topic forums I'd go with no rating at all since you'd have to either make a very complicated tagging system or end up with another meaningless number since there is no way to enforce or even suggest a unique scale to rate on.

#4845902 Moving from collision detection to simple interactions with an environment

Posted by on 07 August 2011 - 03:00 PM

Im just worried that using minimum penetration depth instead of penetration depth in the direction of motion could cause strange behavior such as an actor hitting a wall and then being placed beside the wall, heres an example below. Now you say as long as they arent moving to far per single step it produces reasonable results, would it produce better results if it was done in the direction of motion?

Both approaches are somewhat unphysical, but i think the minimum penetration generally is the one you should try first and only start "fixing" it when actual problems arise. I imagine that calculating penetration along the movement direction would result in actors instantly getting stuck as soon as they hit something. This could be especially problematic when there is gravity. With gravity a moving actor will pickup a slight down movement every time step which should then be corrected by the collision. Now if he is in a valid position "touching" the ground at the beginning of the step the simulation with gravity will make him move diagonally downwards, so if you resolve the collision by backtracking along the movement direction he ends in the latest valid position which is the same one he was in at the beginning of the step...
Correcting along minimum penetration will automatically give you most of the expected behavior, like actors that hit a wall at an angle will slide along the wall instead of just being stuck on it.
In your example the penetration is very large in comparison to the object sizes which is the main cause why it ends up looking weird. A way to reduce/fix this would be to detect if the penetration is big in comparison to the object size and if necessary to perform "substeps" in the movement. Also the objects that are affected by this kind of glitch are usually fast moving so the glitch wont be as visible anyway.

#4845817 Moving from collision detection to simple interactions with an environment

Posted by on 07 August 2011 - 10:47 AM

Most depth algorithms i've looked at find a 'least depth' distance of penetration. Would that be more useful for developing a system seen in the above pictures? Any resources anyone could recommend?

The minimum penetration depth is useful because it tells you the minimum displacement needed to resolve the collision for convex polygons. So a good point to start with is to just offset the position of your object/player/whatever by that minimum penetration. As long as stuff isn't moving "too far" in a single time step this already produces reasonable results. It can lead to weird problems like objects "tunneling" through each other when the object size is in the range of the movement per time step or be glitchy when objects end up in impossible situations like being squeezed into a space where they don't fit.

#4845427 Why am I only told what not to do

Posted by on 06 August 2011 - 08:14 AM

Thanks for the replies.

So what I take away from this at the moment is that these kind of dogmatic statements usually target an underlying problem and try to avoid it by forbidding all the possible causes beforehand.
I can absolutely see why one would do this, but find it very confusing when there is no explanation available. Also without knowledge of the underlying problem the "bad programmer" that you are trying to keep from doing something stupid may be working around your rule in an even more stupid way. I once saw en example where someone apparently knew that he shouldn't use goto. So instead he emulated the behavior with huge "do{... }while(false)" loops and break statements. I'd also suspect that someone who is only told to not allocate in a constructor will just move the allocation to some even more "dangerous" spot.

So: Please don't propagate a dogma without explanation. :)

#4845260 Why am I only told what not to do

Posted by on 05 August 2011 - 04:54 PM


So maybe this is some sort of selective perception thing but I'm getting somewhat annoyed that software design articles/discussions and such seem to be mostly about what not to do. Were I to follow all the "advice" about bad practice I wouldn't write code at all.
So I was reading the "Demise of the game entity"-thread and while I agree with the problems described there and encountered them myself, no one is actually suggesting concrete solutions. Then I went on to read the articles the thread references to and right at the beginning I find this:

I have encountered some architecture’s that have banned the use of Constructors and Destructors in game entities! Usually because of a misunderstanding of how C++ works and usually backed up by the fact that some engineers just can’t stop themselves from doing memory allocations and other nonsense in the constructor.

When did allocating memory in a constructor become a bad idea?

I always feel stupid when I encounter this kind of statement, since the apparently competent authors are dropping these things like it was completely obvious that this is nonsense, but it isn't to me. Does that mean I'm a horrible programmer? And again, I'm told what not to do, but not what I should do...

(sorry, if this is kinda rantish)

#4819015 Septernion multiplication

Posted by on 03 June 2011 - 05:37 AM

Quaternions are an algebraic construct that is obtained by extending the space of complex numbers (and losing the field property in the process). You can't just define a "n-ternion" (in the sense quaterions and octonions are obtained) and expect to be able to define useful group/ring/field-structure on it. From the mathematical standpoint the use of quaternions to describe rotations is more "accidental".

That said, if you have an object's position described by a quaternion and a translation the operation to create the new configuration is obviously obtained by multiplying with the "change quaternion" and adding the translation vector (algebraically this is the direct product of the multiplicative group of the quaternions and the additive group of real 3-vectors).

Calling the configuration a septernion seems just like making up a confusing name for an obvious concept.

#4813900 Dynamic gravity vector

Posted by on 21 May 2011 - 11:16 AM

So the accelerometer always gives you a normalized vector to the "down"-direction? Then just multiply that vector with the magnitude of your g.

#4811429 GameDev.net Community Challenge!

Posted by on 16 May 2011 - 08:08 AM

The obvious has happend. I just started building the game with a vague mechanic in my mind which turned out to be crap (couldn't figure out a single interesting puzzle/challenge involving it) and now I have nice looking "not-game". Well maybe I can still figure out something very simple...

#4811058 GameDev.net Community Challenge!

Posted by on 15 May 2011 - 06:51 AM

Fist screenshot of the working "engine".


This is only a testlevel to test the "Plane switching". Gameplay is 2D but allows to switch between planes at crossroads (slightly FEZesque, without the impossible geometry) to give the world more dimension.

Edit: added some "art":

#4807287 Best C++ container to use?

Posted by on 06 May 2011 - 02:41 AM

I can think of a solution to this, but it wouldn't be as pretty as I'd like. I could use a 3D vector instead, and for each of the usual 2 dimensions, have either 0 or 1 elements in the third dimension. 0 elements would mean that chunk was not loaded, 1 would mean it was. The only reason I don't like this idea is that I would have to access the world vector all over my code with something like "world[chunk_location_x][chunk_location_y][0]," and that would not look as nice.

Well, then write a wrapper around that "not as nice" looking construct. I guess If i were in your place I'd either use a Hash Map with some sort of unloading strategy (mark every element with the time it was last used and when there are too many chunks loaded at the same time unload the "oldest" ones) or have a "local" 2d array and a offset and have everything outside the local array unloaded.

#4803483 Perspective (in)correct rendering of 3D models in a semi 2D world

Posted by on 27 April 2011 - 04:40 AM

Orthographic projections don't take away the 3D-ness of the models and won't keep you from rotating them however you wish. There is just no "perspective correction" as you call it. As long as objects don't have huge depth they shouldn't look that different anyway. What you want "breaks the laws of geometry" which also means you have to compromise at some point. I described two ways to do that. Using locally orthographic projections or orienting everything towards the camera. The "billboarding" approach for example would produce unnatural looking results for very deep objects like some sort of spire rising towards the player...

I personally would just stick with a perspective projection and use a rather narrow field of view.

#4803473 Perspective (in)correct rendering of 3D models in a semi 2D world

Posted by on 27 April 2011 - 03:59 AM

Well, using orthographic projections would give you the first result, but then your stuff wouldn't scale with depth (I guess you could fake that by explicitly scaling objects that are farther away). If you insist on a perspective projection you could get the desired effect by always orienting the objects "towards" the camera like you would do when using billboarding. But what is the point of having 3D models if you take away all the 3D aspects? If you only want to see one side of the model then render that side to a texture and only render a quad.

Edit: I didn't realize that you might want to explicitly rotate stuff. I guess in this case the "faking it" approach by applying a scaling factor depending on z would be a reasonable starting point.