• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

188 Neutral

About JohnRaptis

  • Rank
  1. Hi IYP,   Thanks for the terrifying equation help!   Let me ask this... I define my planes like this: // // Plane // class Plane { Vector mPos; Vector mNormal; float mD; void Create(Vector thePoint, Vector theNormal) { mPos=thePoint; mNormal=theNormal; mD=-theNormal.Dot(thePoint); } }; // // Frustrum // enum {     FRUSTRUM_RIGHT=0,     FRUSTRUM_LEFT,     FRUSTRUM_TOP,     FRUSTRUM_BOTTOM,     FRUSTRUM_NEAR,     FRUSTRUM_FAR }; class Frustrum { Plane mPlane[6]; }; So essentially my frustrum is just a bunch of planes cutting into eachother.  While I'm good with 2D, I have trouble conceptually adding that third dimension into equations (I do 2D geometry native, but am just an idiot savant in 3d), so I'm a little unsure how I would extract L1 and L2 from my set of six planes (except via a brute force method that would do the trick but probably is optimized away by pure math).   Do you think you could give me a suggestion on how to extract from these classes into the variables to plug into your dread equation of darkness?   Thanks!
  2. Hi all,   I'm trying to get four corner coordinates of a plane, where it is bound in my view frustrum.   As illustrated here:   I want to get the XYZ coordinates of the intersection of the view frustrum with my plane in real space.  The plane is infinite, and always with a normal pointing straight upwards.   Is there an easy way to do this?
  3.   Yeah, that's not enough to matter for my purposes.  It's more that I was wondering if there was some completely alternate way of doing it that I might be missing out on-- you know, like all those nice tricks you can do with dot and cross products.    For my specific purposes-- direction toward/away from infinite line from a particular point, I hoped their might be some common equation that I was ignorant of, rather than "find closest point, normalize vector."  That WORKS, but again, sometimes there's cute tricks, and that's what I was hoping for.
  4. ?? Every cycle's sacred... every cycle's good... every cycle's wanted, in my neighborhood... ?   However, I don't need it PERFECTLY normalized... I just need it pretty close to one.  I wonder what tricks I can do by multiplying my vectors by huge numbers, so they approach infinity, and then divide them by eachother.  That might work for my resolution.
  5. Sadly, that's pretty close to what I have.  I was hoping there was some method of figuring it out without that "normalize."  I'm using this to potentially, at worst case, unembed a whole lot of things, so I want it to be as efficient as possible, and without sqrt.
  6. Hi all,   This is for 2D...   Say I have a circle at Point pt, with radius r ... And I have a line that goes from Point p1 to Point p2.   Assuming the circle is embedded in the line, I want to know-- as fast as possible, without normalizes, etc, if that's even possible-- what direction to push my circle in to unembed it most efficiently.   I currently have a pretty simple method where I do this:   1. Find closest point on line to center of circle 2. Take vector of that to center of circle and normalize it 3. Move circle in that direction.   Is there a faster, math wizardy way?   Thanks!
  7. A final update... it appears this problem cannot be solved simulaneously... or the solution is more than a quick velocity mod can handle.  I started another thread, showing all the conditions that work, and the one condition where it fails: http://www.gamedev.net/topic/668296-collisionunembeddingpushing-and-a-seemingly-impossible-case/   If you're interested in following up, click over there... this has become somewhat of a quest to me now, and I'm actually writing a small, shallow simulator because I'm now interested in the mechanics philosophically rather than just practically.
  8. Hi all,   I asked a few questions about Box2D a few days ago, and learned a whole lot about how that system works.  As a result of that, for fun and optimization, I'm trying to roll a stripped down system of my own for kicks, learning, and edification... with one enhancement that seems "impossible" in a simultaneous physics simulation.   Impossible is usually a result of looking at things from the wrong perspective!  Show me the other angle!   I want to develop a process where the density of an object, and the object's ability to display another object are two seperate variables.  Every physics simulation I've run into represents their object something like this: struct {        Point        mPosition;        Point        mMoveDirection;        float        mDensity; } For the purposes of gameplay elements, I want to represent an object like this: struct {      Point        mPosition;      Point        mMoveDirection;     float        mStrength;      float        mWeight; }; Let's further say that:   if ObjectA.mStrength<=ObjectB.mWeight, then ObjectA cannot displace object B. else if ObjectA.mStrength>=ObjectB.mWeight*10, then ObjectA pushes object B at normal "collision seperation." else (ObjectA pushes ObjectB at an interpolation between 0*CollisionSeperation and 1*CollisionSeperation).   With those rules in mind, consider a simulation where ObjectA and ObjectB are both in motion, and they end up overlapped after their mMoveDirection has been applied.   The following rules come into play:   I've managed to make the whole simulation work with every condition except the very last one.  It's a problem!    There's two circles that are overlapping, but are NOT allowed to displace eachother.   Can anyone think of how one would resolve this situation?  If one circle is at rest, it's pretty simple, you treat it like one of the conditions where one cannot move the other.  But if both circles are in motion, then their unembed essentially should hold them in place relative to each other-- while still granting them the ability to slide and jostle around eachother as they both push but cannot advance.   (Note that conditions 1 and 2 are really the same as condition 3, just with the midpoint position weighted properly... the equation to get that is incredibly fiddly and I still haven't come up with one that works, but I think it exists)   * * *   I can solve "condition impossible" by making the simulation non-simultaneous-- moving each object one by one, and unembedding it and it alone, and then moving on to the next object.  The speed hit from this is horrible, not to mention you get unfair situations because whoever is higher in the list gets primacy!  So I'm looking for a way to make it simultaneous.   Any ideas?
  9. Ah thank you, with the latest changes I'm able to see what's happening and I can work with it!
  10. Hi Alex,   I wish I had but more upvotes to give.  That does the correct modification of the velocity.  However, if I'm not mistaken, the strength is not related to the weight at all?  I.E. if I set the strength to .1, then it's .1 push-power against everything.   Can you suggest a way I can make that related to the weight of the other object?  My first inclination is to intercept the solver's constructor and set the "strength" explicity by just comparing it to the density of the other object and setting it anywhere from 0 to 1.0f depending.   Does that sound right to you?   The system I intend  to set up is something like this:   if (strengthA<=weightB || weightB==0) {A cannot move B at all} else if (strengthA>weightB*10) {A pushes B without any hindrance, sort of like Box2D normal behavior} else {A pushes B at a linear interpolation depending on it's placement between weightB and weightB*10}   * * *   Edit: I've been fiddling around with the code a bit, trying to make this happen... I'm running into an issue in that during the push, strengthA is related to strengthB... whereas what I'm looking for is for strengthA to be related to weightB.   I made a quickie function: float32 ResolveStrength(float pushStr, float pushedWeight) { if (pushStr<=pushedWeight) return .00001f;// Should be zero actually! if (pushStr>=pushedWeight*10) return 1.0f; pushStr-=pushedWeight; float aMax=(pushedWeight*10)-pushedWeight; return (pushStr)/aMax; } And I use that like so in b2ContactSolver's constructor: vc->strengthA = ResolveStrength(fixtureA->GetStrength(),fixtureB->GetWeight()); vc->strengthB = ResolveStrength(fixtureB->GetStrength(),fixtureA->GetWeight()); (I added a weight component to fixtures, to seperate it from density-- for the purposes of my initial test, everything has a density of 1 so that it's not a factor) So when I do this, I set up:   CircleA, weight = 1.0, strength=11.0 CircleB, weight = 10.0, strength = 10.0   ...and it works exactly as expected, with the pushing circle barely budging CircleB.   BUT!  If I decide CircleB is going to be a weak guy, and give it a low strength, then suddenly circle A has more power to move it.  So those attributes are still related to eachother, albeit with finer control.   But picture this situation: A horde of Chasers are set up.  Each chaser has weight 10, strength 1.  This prevents the chasers from pushing much (including eachother, so they aren't just batting eachother out of the way constantly) but meanwhile the player character has to have at least strength 11 to push back at all.   There's probably an on-the-fly modification I could do to inv_mass to make this all come together--but for simplicity, is it possible to just divorce out the relationship between strengthA and strengthB when deciding how much the players seperate?
  11. Well, sadly, it's starting to look like this is either impossible, or well beyond my capabilities.  Any progress I am able to make is immediately negated by a side effect elsewhere.  It's strange to me that Box2D doesn't have some way to do or simulate this, because it seems almost a requirement to me, in game dev, to be able to seperate out an object's push energy from its density!
  12. Alex, thanks for all your help, I really appreciate it.   I must be doing something wrong because I still see no effect at all.   In WarmStart, I modified the point loop like so: for (int32 j = 0; j < pointCount; ++j) { b2VelocityConstraintPoint* vcp = vc->points + j; b2Vec2 P = vcp->normalImpulse * normal + vcp->tangentImpulse * tangent; // // MODIFIEDTAG // b2Vec2 PModA=P; b2Vec2 PModB=P; PModA*=.1f; // Fake something just to see effect.... wA -= iA * b2Cross(vcp->rA, P); vA -= mA * PModA; wB += iB * b2Cross(vcp->rB, P); vB += mB * PModB; } And in SolveVelocity I did this: if (vc->pointCount == 1) { b2VelocityConstraintPoint* vcp = vc->points + 0; // Relative velocity at contact b2Vec2 dv = vB + b2Cross(wB, vcp->rB) - vA - b2Cross(wA, vcp->rA); // Compute normal impulse float32 vn = b2Dot(dv, normal); float32 lambda = -vcp->normalMass * (vn - vcp->velocityBias); // b2Clamp the accumulated impulse float32 newImpulse = b2Max(vcp->normalImpulse + lambda, 0.0f); lambda = newImpulse - vcp->normalImpulse; vcp->normalImpulse = newImpulse; // Apply contact impulse b2Vec2 P = lambda * normal; // // MODIFIEDTAG // b2Vec2 PModA=P; b2Vec2 PModB=P; PModA*=.1f; vA -= mA * PModA; wA -= iA * b2Cross(vcp->rA, P); vB += mB * PModB; wB += iB * b2Cross(vcp->rB, P); } I've confirmed that my A and B objects are what I expect them to be (I'm got an incredibly simple setup with two objects and no gravity) and I'm just moving A toward B with the arrow keys.   Whether I modify those PModA/PModB values seems to make no difference at all-- I can even multiply them by zero.  Have I changed it in the complete wrong place?   Thanks again, I do appreciate the time you've put into this.  Solving this is the difference between my using Box2D or trying to roll my own, inferior collision system.   Edit to note: I was wrong, I don't see "no" effect... if I make the numbers larger than zero, my circles are allowed to interpenetrate eachother, slowly.  
  13.   Aha, there's the missing piece. So in each iteration I'm actually sorting my list to put anything embedded up front.
  14. I'd *love* to do it without going into the engine and tearing stuff up... the issue is, each collision needs to be relative to its other body-- i.e. when BodyA hits BodyB, BodyA's velocity damping is value n... but when BodyA hits BodyC, the damping value would be m.   I have no problem going in an giving each fixture a "strength" attribute to have an effect against the mass in the collisions... where I'm running into trouble is figuring out what to do with it.   It seems like this would be a very good addition to Box2D... isn't the need for this everywhere in games?  To me, the need is so universal it almost seems there must be a way to do it, and I'm just not typing in the right google keywords to turn it up!
  15. Hi, thanks for replying.  Yes, that makes sense... so you basically just unembed everything, which COULD cause some embedding, which gets fixed in the next update.   But what about a situation like this:   Update: Circle A moves, not embedded in anything Circle B moves, gets embedded in Circle A Circle A+B resolve their collision.  As a result of resolution, Circle A is slightly embedded in a line   Next Update: Circle A unembeds from line Circle B continues to move toward Circle A Circle A+B resolve.  As a result, Circle A has been pushed back into the line it just unembedded from   ...As long as B continues to press against A, is it considered okay for A to remain constantly embedded, with the line and Circle B just constantly fighting eachother for unembedding poor Circle A?