2D collisions, passing through
BlitzMax Forums/BlitzMax Programming/2D collisions, passing through
| ||
| I've done a search but with no results so I'll start a new topic on it, has anyone solved the fast moving objects passing through another object problem, as in if it's moving at 5 pixels per loop it may skip straight through another object. Thanks. |
| ||
| There is no solution for that in pixel perfect collision other than doing swept collision (in between collision checks on fast movement). Only polygon collisions can "easily" be fixed in that scenario. |
| ||
| ofcorse there is. i also applied this in my RPG. WHEREVER, at somepoint, you move the object. It is here where you instead of appling 5px, you run a loop from 1 to 5. In which you keep checking for collisions. or am i missing something? it works for me. |
| ||
| Which is what Dream said :-) Of course, you only want to use swept collision detection on the bare minimum of your objects given that it has to do much more work (and hence slower!). Things like bullets, since they are small and fast, are prime candidates. But generally, anything that moves faster in one cycle than it is large. ie. the number of pixel movement is greater than the size of that object in pixels. |
| ||
| There is a slight difference between checking the moment every 1 pixel and doing a swept polygon collision. A swept collision means you have a very smooth and possibly curved path that the object will move through and you turn that path into a polygon, like a bendy tube, and then you test against the tube. That's different to just testing every 1 pixel of movement as you may have less overall tests to do. Another solution is to use fixed rate timing logic and increase your hz rate so that you are checking all objects with a finer resolution. I actually do like the idea of checking further-moving objects with more detail dynamically, though. |
| ||
| The simplest would be storing a factor in your "sprite" class that defines how complex it is which directly influences how many pixels it can maximally move without inbetween collision test. |
| ||
| Never let your sprites move that large at a time. Seriously, limit the maximum distance a sprite can move. Also your bullets should never move any great distance than they are wide. A 1 pixel width bullet should never move 2 pixels for instance. You need a faster moving bullet, make a wider bullet. |
| ||
| Another solution is to use fixed rate timing logic and increase your hz rate so that you are checking all objects with a finer resolution. One common way of implementing this is to pass a float to your update function so you can set the size of the step it should take. Then loop through as many of those as you need to complete one full step. something like: Type Tgame Extends TList Method update(timestep) Local n:Int While n<1 For Local t:Tthing = Each in Self thing.move(thing.angel, thing.speed * timestep) Next Wend EndMethod EndType While Not AppTerminate() game.update(.2) Wend there is a slightly more complex version of this where it takes into account the frame rate when calculating the number of loops to update through which keeps the update speed steady when the frame rate drops. you can read about here http://www.gaffer.org/game-physics/fix-your-timestep/ |
| ||
| A method I'm planning to use in my current 2d project is a kind of a mixture of swept collision detection and pixel perfect collision detection with sprites. A fast preliminary check is made by imagining two (or more, depending on the width of the moving object) lines between the current and last known coordinates of the object, and checking if any of those lines intersect a circle (or rectangle) representing the object we are checking collisions against. If they do, we'll do a pixel perfect collision check in the intersecting area. That way I can minimize the amount of slow pixel perfect checks using a fast line-to-circle or line-to-rectangle approximation method. This trick is still sitting unimplemented on the drawing board, so I'm not yet 100% sure if it'll actually work. ;) |
| ||
| Another solution is to use fixed rate timing logic and increase your hz rate so that you are checking all objects with a finer resolution. I do this. |
| ||
| I would too if my logic calculations wouldn't take more time than rendering. There's a complex physics simulation under the hood that requires some out-of-the-box thinking. |
| ||
| "I would too if my logic calculations wouldn't take more time than rendering." Yikes, that is bad. I would take a serious look at my logic requirements/needs in that scenario. |
| ||
| Well, the requirements come from the fact that the game is a newtonian space flight simulation with all the bodies gravitationally bound to each other, including a few hundred AI pilots tracked across the entire universe. This is all running on top of a dynamic supply/demand -based economics simulation for more than 500 worlds. The intention is to do an immersive living universe, so the routines will consume CPU cycles for sure. As a side note, at the moment I'm doing development with an older 1.5GHz Pentium M laptop, which will not be the kind of hardware the target audience is likely to play the game on. |
| ||
| The intention is to do an immersive living universe, so the routines will consume CPU cycles for sure. Then don't use fixed rate logic with a very high frame rate. It's a very brute-force solution to your problem. Your problem definitely sounds like something which wants swept collisions, or possibly even a third party physics/collision engine which already does this. |
| ||
| Let the thread hijacking continue... ;) Then don't use fixed rate logic with a very high frame rate. It's a very brute-force solution to your problem. I figured that much. I'm still sticking with a simple delta timer with a capped frame rate. Your problem definitely sounds like something which wants swept collisions, or possibly even a third party physics/collision engine which already does this. Unfortunately commercial 3rd party engines are out of the question, as my game will be free and is open source. Besides, the engine is pretty much finished already and I think swept collision detection will not be a problem either. |
| ||
| Chipmunk physics module? Simplest thing would be decouple rendering and logic, that gives you more freedom on the collision end or the whole "physics" end if you let it tick on a different frequency than input handling, rendering etc |
| ||
| Oh, I keep forgetting that most of the developers here are aiming for commercial market and prefer rapid application development over do-it-yourself mentality. I'm doing this just for kicks and think game projects as learning experiences. Nothing beats the joy of real achievement when you put small pieces together yourself instead of using ready-made building blocks. Implementing advanced rotational kinetic simulation using only my old physics books as reference felt really good compared to few simple cuts & pastes. Simplest thing would be decouple rendering and logic, that gives you more freedom on the collision end or the whole "physics" end if you let it tick on a different frequency than input handling, rendering etc I've been thinking a lot about using a fixed logic timestep and visual tweening, but so far have opted against it because the logic part is so heavy on the CPU resouces. I'm implementing a time slicing method for some heavy background calculations which - at least in my mind - shouts for a dt for simplicity. I know the physics will behave a bit differently depending on the FPS, but in a single player game it's really not a big deal. |
| ||
| few simple cuts & pastes. oh if only this were the case.. hats off to you for rolling from scratch though. I got about 1/3 of the way through a physics engine when I realized how long it would take to actually get to the place where I wanted to be - making games. One thing Ive learned though - it's a lot easier to understand your own code than someone else's. |
   |