• Content count

  • Joined

  • Last visited

Community Reputation

113 Neutral

About DrDeath3191

  • Rank

Personal Information

  • Interests
  1. Continuous Collision Detection of Scaling AABBs

    Fair enough.
  2. Continuous Collision Detection of Scaling AABBs

    Yes, but you hit the horizontal line second, so why even test the vertical? Even in the case where you cross both axes and miss, you only need to test the last one to determine the intersection never happened.
  3. Continuous Collision Detection of Scaling AABBs

    You are correct, it seems I missed that. Apologies to Dirk. So the idea is that I calculate the minimum distance vector between the colliders shapes, and find when in the timestep a vertex moves more than that amount projected on that vector, am I understanding that correctly? This seems simple enough for me to get my head around. But why would you bother checking anything other than the maximum TOI? Doesn't the fact that one axis has a higher TOI imply that the lower ones couldn't possibly be correct? Placing an order as we speak.
  4. Continuous Collision Detection of Scaling AABBs

    I've been off the net for the past few days, which is why its taken me a while to post again. I understand the paper a bit more, and it seems compelling. However, I wonder if perhaps just doing a binary search would be better in the case of AABBs. I would do something akin to the paper; I could start with two variables, t0 = 0, t1 = 1. Take the midpoint of t0 and t1, and calculate the state of the AABBs of interest at that point. Then, create an encompassing AABB which covers the t0 and midpoint rectangles of each collider. If they collide set t1 to the midpoint, otherwise set t0 to the midpoint. Repeat until the bracket is sufficiently small, and return t0. It seems to me that just doing a bunch of AABB collision checks would be faster than having to recalculate the closest features multiple times. Am I wrong? Of course, there is always the option of just having slower moving projectiles. I've been spinning in my analysis paralysis for a while, as you can probably tell.
  5. Continuous Collision Detection of Scaling AABBs

    So I've thought about it some more, and I struck up upon an idea. Maybe good, maybe bad, not sure. The problem I had with my second plan was that I would have to perform 16 checks, one for each vertex on each box (the box is in 3D, sorry I didn't mention that). However, I think I really only need to check 2; the closest vertices on each box. So if I perform an interpolation of the nearest two vertices' paths in the frame, I can find a time where the line segments would intersect. The only case that I can currently think of that would break this is rotation, because the nearest points might not be the first ones that generate a collision. But I am specifically using AABBs, so there is no rotation to consider. Does that sound reasonable?
  6. Continuous Collision Detection of Scaling AABBs

    Well, that sucks. However, I still hold onto at least a slight thread of hope, because I think you misunderstood what I meant when I mentioned rotation earlier. If I was using the rotated AABB as a bounding box, I would have agreed immediately that I'm pretty much screwed. However, what I was talking about was building a new AABB based on the rotation; meaning that for all intents and purposes no rotation takes place at all for the collision check. Like I said, I'm not trying to make the world's most accurate physics simulation; I can be a little generous. So hopefully that leaves me marginally less screwed. If that hope is misplaced, I may have to reconsider the fast moving projectiles for now, at least until I feel more comfortable with collision detection logic. Thanks for all your help.
  7. Continuous Collision Detection of Scaling AABBs

    Yes, I figured that much out at least. The issue is, how do I get the time of intersection in this case? Please pardon me if I am not quite understanding, but do you believe this algorithm would not handle non-uniform scaling well? Because recalculating an AABB after rotation could very easily result in non-uniform scaling. I may have to read that paper a few times more to make sure I understand it, but it seems like overkill for what I need. I'm not well versed in this stuff, so I may be completely wrong, but I would imagine that the AABB case would have been a little simpler. Perhaps some false hope on my part?
  8. Hello, I have been doing some research on continuous collision solutions, because I intend to have fast-moving bullets. However, the AABBs of these bullets may change in scale, either by scaling directly or rotation of the underlying object. From what I've seen in my searches, continuous collision solutions such as Minkowski Difference and Separating Axis Theorem take the scale of the shape to be constant (if I am wrong about that, please let me know). So I'm at a bit of a loss as to what the correct solution is. I do have a couple of thoughts, but I'm not a fan of them; The easiest solution would be to create another AABB that encompasses the previous frame's and the current frame's AABB. This would not be the most accurate (though I don't really need it to be I suppose), but the bigger issue is how to determine the time of intersection, which I need to sort the collisions. My next thought is to create line segments for each vertex in both AABBs from their positions in the previous frame to the current frame, then check these line segments for intersections. This would make getting the time of intersection simple (I think), but it strikes me as monstrously inefficient. The other thought I had was creating a swept shape of the AABBs, and then using the Separating Axis Theorem to find collisions with the swept shapes. This is accurate, and highly used from what I understand, but I don't know how I would get the time of intersection, seeing as the scale of the AABB could easily change between frames. I don't plan on making a super-complex physics simulation; I don't need the minimum translation vector, the contact normal, or any of that. I just need to see that there was a collision, and when in the time-step it happened. If I am overthinking any of this, I sure would like to know. I've been wracking my brain on this for the last few days, and been feeling like a complete moron. Thanks in advance for any help!
  9.   Agreed. I'm not going to pretend I understand why it worked (especially since I am now intending on using another solution), but after all that crap happened I was happy just to have things up and running again.
  10.   This solution also works, and is probably the better one. Thanks for your help!     It sounds like you're testing in debug mode, and modern versions of Visual C++ perform a lot of debug checks on vector accesses.     I actually did test it in release mode. Same results. But perhaps other things have changed I am unaware of. I was working on a pretty old version.
  11.   Yes, I had assumed it was lock contention. It never happened before, which was confusing. Unfortunately, the plugin you suggest is not available in my version of Visual Studio. But funnily enough, I believe I may have found a solution. For reference, here's my update code for the audio: void SoundPlayer::update() { std::unique_lock<std::mutex> lock(mutex); for (int i = 0; i < MAX_SOURCES; i++) { ALenum state; unsigned int currentID = sourceIDs[i]; alGetSourcei(currentID, AL_SOURCE_STATE, &state); if (state == AL_STOPPED) { clearSource(currentID); //this helps when destroying sound effects in SoundAssetLibrary } if (state != AL_PLAYING) { continue; } int processed; bool active = true; alGetSourcei(currentID, AL_BUFFERS_PROCESSED, &processed); while (processed > 0) { unsigned int bufferID; alSourceUnqueueBuffers(currentID, 1, &bufferID); if (soundStreams[i]) { soundStreams[i]->fillBuffer(bufferID); alSourceQueueBuffers(currentID, 1, &bufferID); } processed--; checkForErrors(); } checkForErrors(); } } I was using vectors to contain my source ids and such prior to my upgrade. Looking at the handy profiling tools my Visual Studio does include, it turns out I was spending a lot of my time in my vector. So, out of desperation and curiosity, I changed them from vectors to std::arrays. A perfectly acceptable change seeing as the number of sources and other data should be constant. It works perfectly now. *head desk* I wish I could understand.
  12. I've had a pretty rough week;   My hard drive crashed. Luckily I was able to recover my data and learned an important (and expensive) lesson on backing up your data. But I needed to get a new hard drive and a Windows 10 license. After getting all my ducks in a row in regards to my data, I decided to upgrade my Visual Studio to the latest, seeing as I was working with 2012. This seems to have caused a huge problem.   Prior to this, my little game ran smoothly. Now however, it is an unplayable slideshow. The culprit appears to be my audio system. This system has an update method which loops through my sources and streams audio to them if need be. This function is called constantly in a separate thread, using a unique_lock and a mutex. Playing/Pausing/Stopping audio or altering audio source properties would make use of the unique_lock and mutex as well.   I have a moving audio source in a test scene. As such, it updates its position constantly, grabbing the lock. Before the crash the program ran perfectly fine; now its pretty much frozen. I was aware that contests for mutexes are somewhat slow, but now its having issues for entire seconds. And the longer the program goes on, the more slow it seems to get. Removing the mutex makes the game run smoother, but of course errors abound that way.   I am driving myself mad trying to suss out what's happening here. Things were perfectly fine a week ago. What can I do?
  13. Mixing Entity Templates and Parameters

      Upon reflection, it probably is not that complex. I was definitely overthinking it. Sometimes you just need someone to ask some simple questions and then you realize you were worrying over nothing.   Alright, you have me convinced. Thank you very much for your help!
  14. Mixing Entity Templates and Parameters

      In answer to the first; I could but I think it could get a little messy to mange that information. Perhaps I am overestimating how messy that would be, but that is part of the reason I am posting here; to get me out of my own head so to speak.   In answer to the second... now that I think of it, I'm not entirely sure. It seems rational to want a unified means of creating anything, but that may be me stuck in my own headspace again.   So I take it you would recommend the post-make method?
  15. Hello Everyone,   I am finally getting around to creating an Entity Factory. Essentially, its a bunch of smaller factories dedicated to each specific component type grouped into one class. Templates would be read from a file, and each factory would store which templates matter to it specifically. Then I ask for that specific template and each factory handles it as needed. Seems simple enough.   Where I am a little lost on is the best way to add parameters to this system. For example, things like position, what team a unit may be on, any sort of buffs or nerfs that may come into play, etc. would be determined by gameplay scenarios, and could not be stored in a file.   The way I am currently going about it is having a struct which would contain that information, and passing that along to the factory. This is simple enough, but I could imagine this thing becoming kind of large depending on how many things can change, and not everything actually requires these parameters.   I could create separate methods for things that require these parameters, like units or projectiles, but this seems like I would be defeating the purpose of a central factory somewhat if I don't have a central creation method.   I could add the parameters after creating the templated version, but this would either limit me to creating one entity at a time, or require a means of storing which entities created in a batch need to be different.   All these options have their own pros and cons, and I am having a bit of analysis paralysis over it. What option would you guys recommend, or have tried in the past?   I'm sure I'm overthinking things, but I would really appreciate your help.