aggieblue92

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

184 Neutral

About aggieblue92

  • Rank
    Member
  1. Is c++ good

    C# is powerful, beautiful, and really wonderful. You'll be able to write a game in less time with C# assuming you know the language and how to do everything. But you probably don't, which is why you're asking. So here's the catch. C++ is the traditional language of game development, for computers anyways. There's more documentation and community support for C++ than (anyone can disagree here if they want) any other language. Tutorials, examples, books and open source games are written almost exclusively in C++, out of tradition. So you'll have a lot better luck learning in C++. That being said, if you know C++, you know C#. It took me three years to be fully proficient at C++, and three weeks for C#, and now I prefer C#.
  2. Large matrix Inverse.

    Gauss-Jordan elimination is nice and runs in O(n^2) time, but implementation can be tricky with row exchanges and all, plus it's only somewhat parallel programming friendly, if you're tapping into GPU resources.
  3. Handling time in a physics engine?

    Kudos on building your own, it is rewarding and empowering for a programmer. You're in for a wild ride though, so I'd recommend reading Game Physics Engine Development by Ian Millington (http://www.amazon.com/gp/aw/d/0123819768/ref=mp_s_a_1_1?qid=1396511885&sr=8-1&pi=SY200_QL40) It's really good, has great examples and aimed toward first time physics engine developers. It's missing a bit on rigid body contact resolution in terms of code samples, but all the theory is there. Best of luck! I'm just finishing my custom physics engine and can honestly say it was worth it, for me at least.
  4. Collision detection for two cubes (3D)

    Goodness me, I thought the LaTeX stuff would work here. My apologies, all. I guess I'll try again tomorrow, when it's not the middle of the night and I'm tired.
  5. Collision detection for two cubes (3D)

    Well, to all future readers, I solved my problem. It's definitely not optimized, but I at least have the math down. Thought I'd post this in case anybody else had the same question.   Given two cubes with properties (a) position in world space (b) orientation in world space (c) length, width, and height (not necessarily all the same length), identify vertices which can be potentially colliding.   The basic idea: to test two edges for collision: $\alpha$   Vertices of first edge (in world coordinates): Vertices of second edge (in world coordinates):  Vector representing length of first edge (in local edge coordinates): Vector representing length of second edge (in local edge coordinates):    If you can find the point on the two edges closest to each other, you can then find if they are interpenetrating, in contact, or not interpenetrating. The closest points on each edge can be represented as a vector representing length of edge (in local edge coordinates):  and , where the alpha values are unknowns that we will be solving for. If the edges are candidate for collision at all, the alpha values must both be in the range [0, 1].   The condition that you're looking for is:  and , pretty much saying that the line between the two closest points selected must be orthogonal to both edges.   Anyways, do a lot of shifting things around, as Gil Strang says, solving this problem is just a matter of moving parenthesis around. Eventually you get this:   You can solve that using any variety of methods, Gauss-Jordan elimination, or as I'm going to end up doing it, just a closed-form formula.   So, now you have two alpha values. You can then form a distance vector . Also, one last thing, I'll call the vector pointing from the center of the first box to the center of the second box .   Conditions of no contact:    In the case that the final condition is false, there is a contact generated, with the contact normal being the unit vector of negative c, and the magnitude being the magnitude of c.   OPTIMIZATIONS: --Separating axis theorem can check to see if we can guarantee the boxes are not colliding. Make a coarse check that can cut out doing all the math if we can easily prove the boxes as not touching. --Watch out for the case of infinite solutions, where the two edges are parallel. In that case, arbitrarily pick the alpha values to be 0.5. --Only consider edges that are formed by vertices which are in the direction of the other cube from the center of the first cube. This can easily be tested using the scalar product of the positions of the vertices in local coordinates of the first cube compared to the difference between the world origin of the second cube and the world origin of the first cube.
  6. @haegarr     TL;DR version - dot product definitely isn't the best method, but I like them conceptually. It's just another way of doing things, and the entire point of forums is for people to throw out their way of doing something, for the OP to then consider among the others.   Anyways.   Using the dot product is scaleable: As opposed to using inverse tangents (for sufficiently cases at least), really it's not any better. The whole looping thing does cause a worse complexity than the atan2 function probably is. The atan2 check is O(1), and my check is O(n), perhaps O(log(n)) if you added some crazy optimizations that would ruin the scaleability of the code anyways. The dot product method, should it have any advantage, would only be advantageous for a small set, like perhaps the likely 2-8 directions that the whole idea of discrete directional units like this calls for. I don't know the actual runtime of atan2, and I'm aware that it doesn't run a full Taylor series, but it still has to be more than a few multiplications and additions.   You also asked about scaleable - should the programmer decide they wanted to use more directions, say 9 or 12 or (more likely) 16, it would simply be a matter of finding more sines and cosines (pre-run time of course) and adding a few more cases to the select statement, and updating the constant NUM_DIRECTIONS. This is usually my practice, as I tend to like avoiding highly specific solutions unless I know I'm deep into development of an end product, usually not a condition I'm under when I'm on the forums. If you were doing an atan2, sure, you could write a bunch of if/else statements, maybe even do some clever division tricks, and get the same result. The other fun thing I was thinking about was the conversion from 2D to 3D mentality - this same type of algorithm applies quite nicely to doing the same thing in three (or more) dimensions. Which is totally against what I said in the first paragraph, I know.   Also yes, about the sines and cosines in the loop. That was for a display of what numbers the computer would use, and again, upon completion of the algorithm, would be replaced with an array found run-time. I mentioned that very explicitly in the comments below. Probably should have been above, I'll own up to that. This function, again, will work fantastically in the debug phase, and then could be easily modified and optimized in preparation for any releases.   Really, using the dot product is probably not the best way. I was just throwing out my suggestion, which the OP read and decided they preferred somebody else's solution anyways. I really like the dot product when doing anything with vectors, 2D or 3D, especially because of how well they translate between the two. Conceptually, I also find them a really powerful tool and taking advantage of vector mathematics.   Anywho. Don't mean to start any flame wars, just out here to contribute where I can. Constructively. Possibly, but not necessarily, helpfully.
  7. I'd have to make a pull for using the dot product too: if you take the dot product of all the direction vectors, the one that has the largest value is the direction you want to take. This also has an advantage of being scaleable, you could modify it easily to only support N/E/S/W, and also could easily support N/NNE/ENE/NE/... public static float DotProduct(Point2D.Float p1, Point2D.Float p2) { return (p1.x * p2.x + p1.y * p2.y); } public static Direction getDirection(Point2D.Float normalizedPoint) { int x = Math.round(normalizedPoint.x); int y = Math.round(normalizedPoint.y); // Order of directions: N, NE, E, SE, S, SW, W, NW int maxDir = 0; float maxScalarProduct = DotProduct(normalizedPoint, Point2D(0.0, 1.0)); // Check NORTH final int NUM_DIRECTIONS = 8; // Number of directions to look for final float DELTA = 2.0 * 3.141592654 / NUM_DIRECTIONS; // Change in radians from one direction to another // Go through other directions, look for largest float angle = DELTA; for(int i = 1; i < NUM_DIRECTIONS; i++) { if(DotProduct(normalizedPoint, Point2D(Math.sin(angle), Math.cos(angle)) > maxScalarProduct) { maxDir = i; maxScalarProduct = DotProduct(normalizedPoint, Point2D(Math.sin(angle), Math.cos(angle)) } } // NOTE: It would be a LOT faster if this code is a critical point (which it probably is) // to instead or using Point2D(Math.sin(angle), Math.cos(angle)), make an array like // xAngles = {Math.sin(0), Math.sin(45 degrees), Math.sin(90 degrees)...} from values you find yourself // and then load them instead. Computing the sine and cosine is expensive and unnecessary. switch(maxDir) { case 0: return Direction.N; break; case 1: return Direction.NE; break; // ... } return null; }
  8. Collision detection for two cubes (3D)

    Cool, thanks all.   Also, yeah, this isn't for end-use - it's more of a pet project than anything else. I'm planning to tailor it for individual games down the road, but it definitely isn't meant to compete with Bullet, PhysX and all the other major engines out there. I do want to be able to point other new game programmers to it to show how to do simple things, which is why I'm trying to make it agree with Ogre. It's pretty much done, except for contact detection and resolution - which I know is like saying a building is finished, except the interior.
  9. Beginner Game Development Help

    TL;DR version: Considering the programming end alone, if you're looking to build a serious operation pumping out sleek 3D games with physics, AI and fancy graphics tricks, C++ is unparalleled. If you're a hobbyist (like me) and just want to dabble into the wonderful world of game programming and design, C++ is fantastic but will take you a while to get a good grasp on, while Python is much friendlier and has a phenomenal 2D library (PyGame) which will get you programming games in no time.   That being said.   Pick one! I'm also an aspiring game developer, and I've picked programming in C++.   Upsides: --Extremely powerful, extremely quick. --Everybody on the Internet knows all about it and can help you ever step of the way --It has several open-source libraries to make things easier. I'm using OGRE for graphics, and writing my own open-source physics engine (Indigo Frost). --Powerful, free tools for debugging, design, and testing.   Downsides: --Pain to learn, especially without formal classes and whatnot. Not too much of a problem, you can find free programming classes online easily. Just be warned: you will spend a good many hours learning general C++ before you can even touch game programming. --While I have complete control over everything and my software runs FAST, I also have to worry about everything my software does, and often spend time on things I shouldn't have to worry about as a programmer.   That being said, I'm going to make a pull for Python here. Upsides: --It is a language built for the programmer to be happy. Programming in Python is SO easy and quick. --Python is also very well documented, because it is seriously the holy grail of programming. --PyGame is a fantastic 2D game programming library, taking care of the ugly stuff for you. Downside (right - just one): --Python runs between 10-400 times slower than c++. For 3D game programming, this means no complex physics, AI, or bells and whistles.   Java also has its qualities, and so does Visual Basic.
  10. Why "steampunk" is fun?

    I also have a strange fascination with steampunk... That same fascination is tickled in the Dwemmer remains in Skyrim, so yeah there's definitely something to be said for immersion in it in videogames.   For me, it's the mix of the old and the new. Machinery and marvels of fine engineering with nothing but cogs, bars and pipes? Fascinating. It has the old-school charm with the space-age itch.   The visual appeal of it is also striking - copper has such a smooth, sleek look to it. Just looking at something copper, I know it's cool, metallic, and the shininess of it screams clean and functional.   Past that... it's just cool.
  11. Ethereal - Now on Kickstarter!

    Concept looks great, I'm all for world-bending puzzle twisters. I could throw my money at games like Braid all day long, this looks like it's got potential.   I'm fluent in English and Spanish, I could do some translation there. As the project progresses, I'd be glad to spend some time testing it as well.
  12. Hey all,   So I'm working on a rigid-body physics engine, it's supposed to be easily compatible with Ogre and fairly straightforward to use, for beginning game programmers.   I'm working on collision detection and contact resolution, and have gotten stuck at checking to see if two cubes (rectangular prisms, strictly speaking) are colliding.   The approach I'm taking is to check for point-face collision (when a corner point of the cube is inside the other cube) and edge-edge collision (when two edges are touching), as the other types are negligible and will likely become another type of contact in the next frame anyways.   Point-face collision is easy, but edge-edge collision is tricky. How do I check to see if two of the edges of a cube are colliding?   My cube data structure is something like this: // Vect3 is a struct containing an x, y, and z elements, also equipped with normal vector operations like // getMagnitude, Normalize, scalar and vector products, etc. class Box : public Geometry { private: Vect3 m_halfSize; // Half-size in x, y, z coordinates         // The Geometry class is equipped with a transform matrix to transform // world coordinates into the object's local coordinates. public: // ... // Returns true if this box is touching the given sphere. virtual bool isTouching(Sphere* s) const; // Returns true if this box is touching the given box. virtual bool isTouching(Box* b) const; // virtual unsigned int GenerateContacts(Sphere* s) = 0; // virtual unsigned int GenerateContacts(Box* b) = 0; }; Really I just need the math behind this, I've looked online but can't find anything useful.
  13. Have you made a game engine

    Depending on what resources you use, you could bust one out from the ground up in six to eight months, but if you really wanta great one, I'd say you have a good 2014 goal for the year :P EDIT: if you're just building one for one game and not super rigorous, you could build one in a few months.