Thousands of them...

Can this be done now? It's been proven that there is no need for a pixel-movement solution on the engine's end. Maybe these votes could be dispersed to something that could really use them.

Right, I believe that eventually something should be done to address this but now is not the time. There are more important issues afoot and this request should be locked. The votes can be put to use elsewhere.

CauTi0N wrote:

Why do we need pixel movement built in? (didn't read below comments)

Because BYOND is a failure. If they want to help correct that problem, then this is one of the steps that needs to be taken. Apparently they don't, though. As you can see by majority of the prominent community members going against such a blatant improvement. Oh well, have fun with your unresponsive controls, lackluster graphics, and terrible overall games. Those 0 players that all of you pull in are sure to win the world. There's a reason why all of the most populated "games" on BYOND have no actual gameplay.


DivineTraveller wrote:

It's been proven that there is no need for a pixel-movement solution on the engine's end

If you're basing that on the fact that FA made a library to partially handle this request, then I've already "proven" that there is no need for any of the other requests on the tracker either.

Maybe these votes could be dispersed to something that could really use them.

Yes, lets delete the highest voted, most important feature on the tracker; because a few of the staff members think it isn't necessary. Wouldn't want BYOND to start following any type of sensibly legitimate operating practices at this point in its career.

Falacy:

"They don't if they're hosted on a decent machine. Lag in an FPS game is a major issue, one that most competent gamers would quit over."

---------
Falacy:

"... BYOND is a failure."

So if competent people quit bad games and BYOND is a failure; yet you've using BYOND for 5~years. By your logic your an incompetent player.
Therefore why would any BYOND staff member, or any competent player here agree with you?
If BYOND is soo horrible in your eyes, then quit. I'm sure BYOND will have an option to use pixel movement in the future. But for now, there are 100s-1000s of features that are more important.

You are no longer following this issue.

This isn't a feature request, it's a flame war.

I don't always leave a community, but when I do, I make sure to stay around and tell them all how much better I am than them.

Stay douchey my friends.

I weighed in on this quite a while back, but as I recall the gist of what I said was that the customization issue is quite relevant, and that the laundry list of items in this request is a little on the vague side.

Some of the items Falacy listed are totally impossible, like making the direction in walk() work as an angle, because BYOND's directions are bitflags and an angle would be a number as well, making it impossible to distinguish between the two cases. A different walk() would be required, and the walking and pathfinding in general would require major changes.

Stuff like bumping, and handling Entered(), becomes a lot trickier in this scenario as well. If you're between tiles and you bump into two walls at once, which one gets the bump? Obviously an atom only has one loc, but what if you wanted to see what other turfs it covered, and more importantly what if you wanted any turf.contents to include an atom partially on it even if it isn't technically its loc? This is all so non-trivial to work out that it has also had implications for big atoms, which is why those are still treated as strictly visual.

I don't see any way pixel-based hit detection will ever happen. I just don't see that being feasible under any circumstances. Hit boxes on a pixel level are a different story, but doing hit detection in the individual pixels themselves is way more difficult (and not entirely meaningful in an animated icon, either).

As far as bringing existing games into this system, that's not feasible. Legacy games have certain expectations about movement and there is absolutely no way to reconcile those with this kind of system. To give a simple example, take a game where the movement basically uses a simple delay timer to prevent you from walking too fast. That movement still expects you to move one tile at a time. In a system like this, Move() would have to know both the x and y pixel offsets because just a dir would be inadequate, and the old code would still be trying to foist a delay on micro-movements. The only way to reconcile this would be to track the pixel changes internally and only call Move() for full-tile changes. Ugly.

Just as a suggestion, you could try recalculating the dynamic lighting less frequently, either by firing up an event timer or just only doing it every so many ticks.

Hey look, somebody actually made legitimate points that may be worth discussing!

Lummox JR wrote:

like making the direction in walk() work as an angle, because BYOND's directions are bitflags and an angle would be a number as well, making it impossible to distinguish between the two cases. A different walk() would be required, and the walking and pathfinding in general would require major changes.

This is probably one of, if not the most complicated part of the entire request. Having a completely new walk() function would be perfectly acceptable, if not all together sensible in my opinion. walk_in_angle(atom,angle). Path finding on such a proc wouldn't be necessary, and path finding on the existing procs shouldn't require too many changes - for the most part it should just automatically change to calculate based on the new hit detections.

Stuff like bumping, and handling Entered(), becomes a lot trickier in this scenario as well. If you're between tiles and you bump into two walls at once, which one gets the bump?

The lowest/leftest one, same as would be determined by running something like oview(). It could also be sensible to return a list of everything it bumped, or even just call the bumb on all of them at once. If you walk half into a door, and half into a wall, I could understand it calling the bump on both. Though if you walk doubly into a pit of lava, I could see that causing problems. This is one of those things that you should just play around with until the results feel right, and then let the developers deal with any alternatives.

Obviously an atom only has one loc, but what if you wanted to see what other turfs it covered, and more importantly what if you wanted any turf.contents to include an atom partially on it even if it isn't technically its loc?

If you wanted to see all the turfs your player was over a simple (pixel based) oview() call should take care of that. turf.contains could be a new list which has anything partially overlapping it, though this wouldn't be necessary, since an oview() call with some pixel calculations could suffice here as well. This seems like something that could just be left out, and, if deemed necessary after release, a developer could make a more specific request geared towards such functionality.

This is all so non-trivial to work out that it has also had implications for big atoms, which is why those are still treated as strictly visual.

Which is why the option for built-in "big atoms" should either be removed, or completed into a fully functional feature. And it surely shouldn't be the default, at least not in its current state.

I don't see any way pixel-based hit detection will ever happen. I just don't see that being feasible under any circumstances.

Why not? Flash does it. Hell, we could even do it ourselves pretty easily using GetPixel() to assemble lists of "dense" coordinates.

Hit boxes on a pixel level are a different story, but doing hit detection in the individual pixels themselves is way more difficult (and not entirely meaningful in an animated icon, either).

It can be quite meaningful in animated icon states. When you swing a sword or something, you would want to know when and where that sword collided with an enemy.

To give a simple example, take a game where the movement basically uses a simple delay timer to prevent you from walking too fast.

As I've pointed out before, limiting movement speed with that method is a terrible idea to begin with, and just makes games feel even more unresponsive. I'm also not expecting this to be an automatic plug-an-play conversion for legacy games, as I've also stated, just for it to be as painless as possible. Somebody using a movement delay system, converting their game to pixel movement, would want to much more intelligently turn down the size of pixel steps, instead of just shutting off the player's controls for a set period of time.