I wonder if it might be possible to have some sort of function that would let you check if the icon on one object is overlapping the icon of another. If two icons are intersecting, disregarding parts where the alpha is at 100% on any part of the icon, then the function would return true. Assuming this was a reasonably quick function, it would make it doable to have pixel-based collision detection.
Maybe there's some way to do this now - I'm not at all familiar with BYOND's newer icon functions. But if it does exist, it's still probably somewhat slow compared to anything built-in.
ID:132865
 Sep 4 2009, 12:25 pm
|
|
|
Sep 4 2009, 1:12 pm
|
|
Kaioken
 |
Implementing something like this into some sort of a robust, quick built-in function would be awesome, as it would remove the (pretty much) main blockade in the way of making games "break the tile" efficiently, and would essentially open up whole new options for multiplayer BYOND projects, provided it's fast enough. I suppose the benefits and the importance of this are obvious enough, so I don't need to rant on about them. Hopefully, this suggestion will be somehow fulfilled. I also can't help but think, "how come nobody had thought of this before?". <small>Or had somebody?</small>
|
I don't want to derail a good suggestion, but I do think it's important to point out that collision detection is not the most important part of pixel movement, nor is it even close to the main thing holding back development of non-tiled games on BYOND. In fact, collision detection is pretty darned easy.
The problem is that collision detection is completely useless to the main workings of most movement system. Consider that a have a falling object, PLAYER, that is 3 units above another dense object, GROUND. Gravity wants to pull him down by 8 units. So I check if PLAYER.y - GROUND.y > 8, if it is, there's a collision, and the movement isn't allowed. Great, but now PLAYER is floating 8 units in the air. What is really needed is a system which can determine the maximum distance PLAYER is allowed to fall. This may seem like a very easy problem to fix, just move PLAYER.y - GROUND.y units on the y axis (-5). This fix falls apart once you consider that PLAYER can be moving along two (or three, if we have z coordinates) axis at the same time, and may need to check multiple objects, and make sure that it is checking them in the right order. But even that is an over simplification. Objects have differing heights and widths, so we're not dealing with a simple PLAYER.y - GROUND.y, but (PLAYER.y + sign(vel.y)*PLAYER.height/2) - (GROUND.y - sign(vel.y)*GROUND.height/2). Even then we have an over simplification, because we may have multiple different geometries, such are ovals colliding with rectangles, or rectangles that need to walk up inclines. None of these problems are solved by detecting an overlap in bounding geometry (in this case, icons); these problems are solved by applying math to the geometry of the objects, and their spacial positioning. | |
Of course, none of that matters when its a space game and you just want to see if the other guy got hit with the laser.
| |
Then you could probably use Hobnob's example of point-to-shape collision with pre-cached positions for each bearing.
But for true "pixel" collision, you could try something with icon.GetPixel(). Loop through the icon, check if the pixel isn't transparent with GetPixel and store that in some 32x32 list or something. | |
Kaiochao wrote:
Then you could probably use Hobnob's example of point-to-shape collision with pre-cached positions for each bearing. While I don't know much of anything about how Hobnob's example with the vectors and such works... The problem that we face with BYOND is that, yes, its possible do most of these things on our own. Its not remotely practical since the end results are abominably slow, but still, its doable. It also requires extensive workarounds which isn't really desirable for a language that claims to make game building easy. I suggested this purely as a way to avoid making a huge mess out of what would likely be a commonly used function for games that break away from the grid. But perhaps it can wait until someday when BYOND has some kind of non-grid drawing board to work with. | |
Ah, on a second thought I definitely didn't totally think this through or organize my mind or post well, but uh, I posted very late at night and it was a hasty reply, promise!
Sure, just detecting 'pixel overlaps' as the OP meant wouldn't automagically do just about everything (though it would still help). It could be expanded into more of that though, so there will be a set of instructions dealing with atoms and pixels. To be honest, this request is of course one of the "Even though I can already do this on my own, I want this built-in for the speed gain" requests, just a pretty justified one. Even though the problem is complex as you've described, as we all know, technically, you can already do everything on your own; the problem is that doing so is too slow. That's why anything the BYOND Staff adds as built into the language to help with pixel-movement-related stuff will help a lot here; the notion of this idea seems fairly good, instead of suggesting the BYOND Staff overhaul BYOND and remove the tile-based workings, they can add instructions that make working with pixel movement in the existing tile-based environment better and easier - doing that won't take nearly as much effort, and will still be beneficial. | |
Wouldn't that be rather counterproductive? Seeing as the dll has to be provided with a rather hefty amount of info?
| |