This may be a stupid idea. I don't claim to know what I am talking about.
But would it be possible to have some integrated procs for pixel collision? Where it would be easily detectable if one obj/mob's icon is touching overlapping with another obj/mob's icon?
Because I've heard that pixel collision libraries for byond are extremely slow but then I also heard that integrated byond procs are fast.
So, I was thinking it'd balance out or something...
Well there is my potentially stupid idea.
ID:132609
 Feb 21 2010, 2:23 pm
|
|
|
Feb 22 2010, 12:34 am
|
|
Ripiz
 |
Boundary boxes are best what you can hope, but they are fast even with BYOND code. Going for per-pixel detection, it's almost as physics, only needed to make gravity and realistic stuff, there's not much places where you could use it on 2D game.
|
I agree, boundary boxes would be most reasonable for BYOND. If your character is at most maybe 16 pixels wide and 24 tall, you code program it to recognize their boundary as a 16x24 box and use that for collision detection.
| |
Pixel collision would be slow even if it was integrated.
Consider what would be required: Each movable atom would be considered a candidate for pixel collisions, and with every other movable atom or turf. You would have to check the atom and overlays of not only every movable, but every turf that might possibly be in range depending on the biggest pixel offsets the server knows about. This is already a pretty hefty O(nm) algorithm. In the event any overlap was found, you'd have to do a pixel-by-pixel check of the overlapping areas on each icon, also taking overlays into account. Pixel collisions are not a trivial problem, which is why few games do them. In the '80s the opposite tended to be true; the way certain objects were drawn on screen allowed the hardware to instantly tell you if there was a collision. However the tradeoff was fewer moving objects. Now as for doing pixel collision tests manually, that might be easier as you could simply specify which two atoms to check and let the engine internally do its pixel-by-pixel overlap check on each of the icons. That would be quite a bit faster, but it's of limited usefulness and it still wouldn't be very fast. Lummox JR | |
It's not necessarily just the pixel collision proc that makes it slow, at least in my movement. Really it's the entire movement proc being ran constantly by multiple players that would make it slow, changing offsets and colliding and all. In reality the pixel collision doesn't have to be all that complicated. If you try to make it more and more complicated and "one size fits all", it's going to take up more and more CPU. If you keep it more simple and size the collision for your specific game, it doesn't make much of a difference than if you weren't colliding at all.
| |