• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

218 Neutral

About PaulEdwards

  • Rank
  1. Seems to me that Spoonbender is saying the right things, but C++ makes it tedious to define functions for everything they *should* be defined for. With no support for unnamed functions, the overhead for creating a new function for one or two lines of code is enough that it's easier to just inline the function manually. It's annoying to have to jump all the way out of the function, write a new one, come back to where you were before, and call the function from there. It's also annoying to have to do this while reading someone else's code. It's even worse when it's a member function and now you have to edit a header file as well. I think if functions could be defined within other functions, there would be much less argument towards what Spoonbender is saying. Since this isn't the case, the matter is very subjective.
  2. Really Annoying

    XDigital, everyone above me raises valid points and definitely take their posts to heart... However, the code you presented compiles fine for me on gcc... The only thing that's somewhat in error is that instead of "char* tribes[3]", you would want "const char* tribes[3]", since when you do the assignment character.tribes[0] = "Saxonia", the string literal, "Saxonia" should have type (const char*). When you use the term "Saxonia" in your code, the compiler will place the string "Saxonia" somewhere in your final executable, and when you do character.tribes[0] = "Saxonia", you are simply setting tribes[0] to the address of the constant "Saxonia", and there is nothing wrong with this. But you may need "const char*" because you should't change that string, it's assumed to be constant by the compiler (if you change it, another part of your code may have name = "Saxonia" and in this case the memory to store "Saxonia" may be the same memory used to store "Saxonia" before, so if you change it in one place you'll (probably unintentionally) change it in all places. Bottom line, string literals are const char*, don't change them, and match your types up for assignments. It probably would have helped if you had provided the error or warning that code was giving you when you tried to compile it.
  3. rolling ball over heightmap

    Although not perfect (innacurate results when a ball is moving horizontally and just grazes a vertical peak in the terrain), you can try this: On a collision, we'll want to at least cancel out the ball's velocity in the normal's direction. We can do this by doing R = (N dot V) * N where V is the ball's velocity, N is the surface normal and R will be the vector that will cancel out the ball's velocity in the normal's direction. So. If you want the terrain to absorb all the momentum, then compute V' = V + R where V' is the ball's new velocity. If you want a perfectly elastic collision, do V' = V + 2*R. If you want something in between, you can do V' = V + (1 + a)*R, where 0 <= a <= 1 and a represents how elastic you want the collision to be. Alright, 24's on, hope this helps, gotta go.
  4. thannett, thanks, that was certainly all that it needed. I haven't worked much with Windows resources and didn't really know how all the pieces fit together (just that I needed the icon added as a resource to my project). So anyway, problem solved, thanks to all who replied!
  5. Strict Camera Positioning

    What I meant is that with a typical perspective projection matrix, the two parts to the angle f will be equal (where d is heading straight at what you're looking at). So if those two angles are equal then you can see intuitively that the far triangle will have a longer "ground line" than the near triangle. Mathematically, knowing d, knowing f/2 and knowing that the far left angle is less than the far right angle (in your diagram), we can use the sine law to show that the length of the far ground line will be greater than the near ground line, unless of course the camera is directly overhead. Man you really do need pictures for this don't you? But you mentioned not making the effect too severe, that could be a bit different, and then I *think* that if you chose the minimum length difference between the two sides that you're willing to accept (and realize that the line d bisects angle f) that the angle ? should be solvable.
  6. Thanks for the suggestion and I checked it out, but the situation is that I already have a project written in C++ and all I'd like to do is add a resource (an icon) to it. SharpDevelop seems to only support C# and VB and expectedly didn't seem to work out when I tried to open up and modify my C++ project. So am I doing something wrong with SharpDevelop or are there any other ways of simply adding a single icon resource to a project?
  7. Strict Camera Positioning

    Here's what I think. If we're using a standard perspective projection matrix, this is impossible unless the camera is directly above the player (since the far side of the player will always be longer than the near side). So we'd have to change the projection matrix. If we do this though, we can place the camera anywhere we want, and still make this work. That means that the angle ? does not depend on d, we can change d and ? and still make this work (in the 2d example this is actually polar coordinates for the camera position). So, to help build a new projection matrix, we'll need to know the two angles that sum up to angle f in your diagram. But choosing a ? and a d give us enough information to solve everything inside the triangles (since the floor length is v). This includes the two parts to f. Now it's just a matter of fitting this information in to a projection matrix.
  8. What other transformations are happening to the camera? Most camera matrices consist of translations and rotations only. If this is true in your case, then yes, those vectors are still represented by the camera's global transformation matrix. Think of your forward up and right vectors ([1 0 0], [0 1 0] and [0 0 1]) untransformed. Now translations in your camera transformation matrix will do nothing to vectors, which makes sense since no matter where our camera is, if it's only translated, up is still up. So we're left with camera rotation. So muliply your camera matrix by say, the up vector and you will get a rotated up vector which yes, corresponds to the up direction in your camera's space. Since the up vector is [0 1 0] (let's say), then multiplying this by your camera transformation matrix gives the second column of your camera transformation matrix. Like Zipster said, scaling will obviously denormalize your vectors, but camera transformations don't normally include scales. Also, you don't want to use your inverse camera matrix as was suggested, just use the camera transform matrix.
  9. how homogenous vectors are dealt with

    As Sneftel was saying, you had it right to begin with. Points should have w=1 and vectors should have w=0. One reason for this is if you have a translation transformation matrix (ie: last column (or row) contains an offset to translate by), then multiplying your point by this matrix gives a translated point and multiplying a vector (w=0) by this gives the same vector as before. In other words, translations don't affect vectors, and they shouldn't. It might be helpful to double check this on paper if you don't see how that works right away. It helps to distinguish between vectors and points in your code so you don't accidentally take, say, the dot product of 2 points (which again, as Sneftel pointed out, dosn't make sense and shouldn't be done). Essentially though, if you are working with 4x4 matrices (which presumably you are if you're using Direct3D or OpenGL), then you should work with 4D points and vectors with w=1 for points and w=0 for vectors.
  10. Okay thanks, I wasn't sure if that was the case or not.
  11. I have a console C++ application in MS Visual C++ 2005 Exress and I'd like to add an icon resource to it. The Project->Add Resources menu item is greyed out though. Does anyone know why this is and how I can add my icon?
  • Advertisement