bounds variable already exists

Hardly any games use precise collision detection. The games that do, use it in a very limited capacity (only for certain attacks). For movement in most games, the player is treated as a simple shape (a box, circle, or sphere). Most of the time its not only easier, but better, to treat the mob as a simpler shape.

It sounds like a great feature but this wouldn't be that useful and would cause more problems. What if a player's icon state changes in a way that makes them now be partially inside a wall. Is the wall's Enter() proc called? Is Bump called?

SuperAntx wrote:

Game Maker can do precise pixel collisions for many entities at once.

I'm not trying to knock on BYOND, but if this feature were a viable option for devs here you probably wouldn't be able to say, "Hardly any games use precise collision detection." I would use it.

It would only make sense for a strictly top-down view, which very few BYOND games use. I didn't just mean that hardly any BYOND games use precise collision detection like this, hardly any games anywhere use it.

Only if they try to walk further into the wall. Which, is how the current system should work as well. At least optionally. The current method, where you get free range of an area once you've crossed its bounds, is undesirable in most cases.

Imagine a typical mob icon where the side view (the east/west states) are narrower than the north/south states. If you walk east til you're touching a wall, then move north or south, your wider image will be overlapping the wall. You'd already be inside that wall so you'd probably be permitted to walk until you reach the edge of the next dense turf, but this behavior is far from ideal. Using a simple shape, like a box that doesn't rotate or a circle (which is the same regardless of rotation) means the player's movement isn't affected by what pixels their icon happens to occupy.

BYOND's collision detection can certainly use improving and this seems like the next logical step, but it wouldn't be that useful. Bounding circles would be useful but I'd even be skeptical of that. The feature isn't really collision detection, its collision resolution. The current movement system leaves a lot to be desired - when a mob moving northeast hits a north/south wall, you'd expect them to slide north along the wall but they don't. With circular mobs there are more situations like this (ex: bumping the corner of a wall) that, based on the current movement scheme, probably wouldn't be handled desirably.

FA, your implementation is inverted. While the player should remain a static size, the world should be filled with circles, slopes, slants, and curves.

Albro1 wrote:

I wasn't talking about other languages. I was talking about DM.

You said that such a feature should be created by the game developer, instead of the BYOND staff. I was pointing out that such an expectation isn't very sensible; the feature is included in practically every other game engine.

Forum_account wrote:

There is quite a difference between colliding with a slope or curve and colliding with a pixel that's part of an icon that looks like a slope or curve.

How are they different?

It would be beneficial to have those types of shapes, but per-pixel collision doesn't achieve it.

How would it not?

The hard part there is the collision resolution, and to do that you need to be able to make assumptions about the geometry.

If by "resolution" you mean intelligently handling movement against such surfaces, then you have a point, but it is a completely different issue than the actual collision detection.

In any case, this isn't some super complex calculation full of assumptions as you keep trying to make it out to be.
http://www.angelfire.com/hero/straygames/ByondBugs/ PixelSlide.png
If that blue box is moving south, and collides with that red pixel, is is pretty obvious that he should "slide" to the left, to be able to intuitively continue on his way. This basic concept applies to pretty much every situation. If your hit-box is hanging into an open area, then you should automatically shift in that direction. The amount of overhang could be specified with a simple variable like slide_width, though even a single pixel should usually activate such an effect. If you are walking into a thin object, like a fence post, then you should slide towards whichever side you are overhanging more, or, if equally centered, it could just choose a random side to start shifting you.

Building in a sliding effect or some kind of physics based on pixels really isn't feasible; physics are best left to the authors. I'd guarantee that in Super Mario Bros. 3, the slopes were handled by a simple flag that said what kind of tile they were.

But I will mention that when we implemented pixel movement, pixel collision was something we considered and still have on the table. Tom's suggestion for this was that we could have a simple bit mask for each icon+state that would be animation-insensitive (I don't see animation sensitivity being practical). This would have to be optional, as the rectangular bounding box is far more useful.

There are some minor logistical problems with this, and with round bounding areas, that would need to be solved. One that comes to mind is that right now, an object's locs var lists any turfs it covers, but here you'd have the possibility of locs not including the actual loc at all. The right way to handle bounds_dist() is also in question. On the whole the problems aren't very big ones though, and the chief reason we didn't add this at the time was simplicity.

Forum_account wrote:

It's a different issue but it sounds like that's what people are really asking for. I don't think anyone would be happy with BYOND detecting these collisions if it didn't also handle them the way you'd like.

Considering this original request was for a feature like bounds (which already exists), but seems to have taken on a life of its own, I'm not really sure what people are expecting at this point.

The reason that's intuitive is because you're assuming the pixels form a curve and aren't just a sequence of tiny stair steps.

That doesn't matter in the least. Whether you have 50 objects forming actual stairs, an icon drawn as stairs, or some kind of programmatic code telling the object to have stairs as a hit-box; they all give you the same results. You are hitting a pixel, with a giant portion of your hit-box hanging into an open area, you should be moved towards that area. Assuming BYOND just does simple math on hit-boxes, and says "from x1 to x2" is dense, it would simply need to split your hit-box around the point of collision. If either side of the new hit-boxes can pass movement in the direction, then you should be moved towards that side, if both of them do, then you should be moved towards the larger side of the split.

It'd be hard for BYOND to make this kind of assumption. It'd be much easier (and it'd work better) to be able to tell BYOND "this object is a ramp with a height of 16 pixels" than to have BYOND try to deduce that from its icon.

How is that any better? If anything, that seems like it would be extremely limiting, even as a simple hill provider, no less for curves or anything that was actually more complex than a straight line turned at a simple angle.

That's getting pretty specific to the game there.

Not really, if you hit a point, you should slide around it, its a pretty simple concept that can be commonly applied to almost any situation.

If you were using pixel movement for a billiards or mini-golf game then you wouldn't want that type of sliding. It's not hard to add this kind of effect yourself.

If you are going to design something like that, then you have to have incredibly complex physics, and pretty much nothing BYOND builds in is going to help with that (unless they make an actual physics engine). This ball hit that ball at this point at this speed moving at this angle with these weights, what are the new movement conditions of the balls? That is far more complex...
The sliding effect that I am suggesting should, of course, be optional (on a per atom basis). If you shoot out a fireball or something, you don't want it sliding around a wall, you want it exploding on contact.


Lummox JR wrote:

Building in a sliding effect or some kind of physics based on pixels really isn't feasible; physics are best left to the authors.

This has nothing to do with physics. It is a simple concept of "My character is hanging 99% off the side of this wall, why the hell am I stuck on it?"

I'd guarantee that in Super Mario Bros. 3, the slopes were handled by a simple flag that said what kind of tile they were.

Side-scrollers are a different concept. In most cases, you wouldn't want to slide around tiles, only if there was a very small pixel collision (like on a hill) (as I mentioned, something that could be customized with slide_sizes). Very few BYOND games are side-scrollers anyway, so its not a huge point, but basically, in a more top-down approach, you want to slide around almost everything, whereas in a side-scroller, you don't want to slide around anything. It would be like climbing a wall in most cases when applied to a side-scroller, something that you probably don't want happening by default.

Tom's suggestion for this was that we could have a simple bit mask for each icon+state that would be animation-insensitive (I don't see animation sensitivity being practical).

This may work for most environmental objects, but for things like attacks, you need to know when the sword hits your enemy in the face. Presumably, you've been messing around with Flash, and have seen how things work there.

This would have to be optional, as the rectangular bounding box is far more useful.

Of course it should be optional. However, rectangular bounding boxes aren't all that useful. If they actually rotated with the object they were assigned to (if you could even properly rotate objects to begin with), like they do in every other engine, then that would be another issue. Again, compare to Flash.


SuperAntx wrote:

What Falacy is describing with the sliding sounds like a feature unto itself rather than precise pixel movement.

I assume you mean collision here, not movement? And yes, that is what I've been saying from the start. Detecting the collision, and intuitively moving around it are 2 completely separate issues.

Either way, it's something to be left to the game author rather than the engine builder.

You seem to be contradicting that with the Game Maker demo that you posted along with it?

What I was talking about was something more like this. It's just a simple platformer demo using this image. I didn't put in any special code, I just imported the sprite and set it to use precise collision. It was literally just a few clicks.

That seems to perform exactly how I explained a few posts ago. If you contact with a single pixel, you do not get stuck on that pixel, you are intuitively moved in a direction to allow you to continue movement. In that case, when you are moving left/right, you will be automatically "slid" up to to continue on your way. That system also seems to have some kind of simple gravity, which is yet another issue entirely.

SuperAntx wrote:

There's nothing automatic about it

How is it not?

Every time they step while grounded they are raised up, moved over, then dropped back down.

That doesn't seem very effective. What happens if they come to an area with a low roof or otherwise blocked area that they would normally be able to fit through? If they are just moved up by a constant amount every time regardless of the actual step size needed, then moved over, then moved back down, they would often whack their face on things that they shouldn't. That theory also seems like it would provide a much less smooth result than Game Maker actually does... Regardless, such an effect should be simple to accomplish in a BYOND side-scroller, which are a differently interactive environment than top-down games (what most BYOND games are).

What I thought you were describing was something where if you walk into one side of a door frame you're slowly nudged over until you walk through the door.

Pretty much. This is how it works in most top-down 2D games, The Legend of Zelda on the SNES, for example, and also in most 3D games. It is unlikely that the player was intentionally running a small portion of their body into an object in an attempt to stop on it, and much more likely that they were attempting to walk past (ie: into a doorway). The game should easily be able to compensate for this, making for a more intuitive and generally better experience.

That doesn't really have anything to do with pixel movement itself, just something achieved through the use of pixel movement.

How is it different from the demo that you provided? It is a method integrated into pixel movement that makes the movement much more intuitive and generally better feeling. Running a single pixel of your character into a wall, and coming to a complete stop, just feels clunky.