Pixel perfect in Announcements

Page: 1 2 3 4 5 6 7
#100 Sep 6 2011, 5:55 pm
Lummox JR wrote:
To respond to those issues quickly:

1) While I might not necessarily rule out decimal support for step_x/y for the future, at present they are not implemented that way internally and it's way more trouble than it's worth to do so.

2) This situation already comes up in legacy code. If you want the mob to move north when hitting a wall going northwest, you need to do custom processing for it. That hasn't changed. Changing this as you describe would be inconsistent and would break existing code.

The easiest way to implement #2 is to implement movement entirely in soft code. I wouldn't say that it breaks existing code because there was no existing code that used the native pixel movement. You're right that it's not consistent with the tile-based behavior, but it never will be. Moving a pixel at a time isn't consistent with the old behavior, this is just a consequence of adding a new feature.

Imagine a top-down shooter with 360 degree movement - you're being chased down a hallway but because you're not running perfectly parallel to the walls, the second your mob's shoulder touches the wall you stop dead and are easy pickings for whatever was chasing you. It's just not that useful of a default behavior.

3) A proc like you describe is simple to setup in soft code, but we have discussed the option of adding appropriate step and walk procs.

It's essentially just a convenience, but it's a convenience that everyone would want and including it shows that you understand how people would use the feature.

4) I'm more than happy to modify the Cross() proc, but what values do you suggest providing? The current distance or the potential overlap? Distance in each direction? Direction of movement? (Note the get_dir() is there on purpose because the mob's dir might not be the push direction, if moving diagonally.)

For the Cross proc the distance of the overlap and the direction of the breach (which side of the tile was crossed first). For the Bump proc there are more values that wouldn't be known: original position, magnitude of the potential overlap, total attempted move, direction of the bump. I'm not sure which values would be most useful, but in both cases the direction would be useful: making tiles that can be entered/exited in one direction, boxes that can be pushed in one direction, mobs that bounce elastically, etc.
#101 Sep 6 2011, 6:02 pm (Edited on Sep 6 2011, 6:19 pm)
It also seems odd that only movable atoms have bounds_ vars. When you need to do some custom position checking between arbitrary atoms (ex: a mob bumped into a turf, mob, or obj), you need to have two cases: one where the mob bumped something with bounds_ values set and another where the atom doesn't have those set or doesn't have them.

The bound_x and bound_y vars also complicate things when you need to do this type of position checking. With keeping pixel_x and pixel_y, I'm not sure why they're necessary. Maybe you could provide some built-in procs to check information about relative positions (ex: if one atom is to the left of another), but the problem with that is defining what it means to be to the left of an atom (your center is to the left of it's center, no part of your mob is more right than the atom's leftmost part, etc.).

Edit:
I also find it odd that the mob's loc isn't the location of its center, or the tile it most overlaps, but it seems to be the turf that the mob's bottom-left corner is in.
#102 Sep 6 2011, 6:20 pm
I don't see what the problem is with splitting diagonal movements into two separate x/y movements. It's what I did in Decadence (albeit with tile movement) and it worked just fine. Using my own movement system also allowed me to easily add in custom density/collision mechanics.

The bound_ variables should to have absolutely nothing to do with pixel_ variables. Where bound_ effects collision, pixel_ is purely visual. I think splitting them like that was the right decision.
#103 Sep 6 2011, 6:35 pm
Splitting the diagonal movement isn't correct because it can trigger events that a single move wouldn't trigger. In a platformer, if you do the y move first you'll miss more jumps than you should because you first fall, then move towards the ledge you're trying to reach (if you do the moves in the other order, the player will make more jumps than they should). It's also more costly because you have to check for collisions twice. I'm still pleased with the performance improvement, but having to call Move() twice per mob per tick is going two steps forward and one step back.

Having a bound_x of 8 is essentially the same as having a pixel_x of -8. It's just offsetting the bottom-left corner of the mob's bounding box.
#104 Sep 6 2011, 6:56 pm
Would it not be possible to (Lack of proper words is going to cause me to get laughed at, but it's the same concept) pixel-offset the 'shaded' areas that opaque tiles cause to try and match atoms?

Having lighting issues, looks weird :[
#105 Sep 6 2011, 7:10 pm
Opacity is ridiculously incompatible with proper pixel movement. It wasn't a consideration.
#106 Sep 6 2011, 7:12 pm
Lummox JR wrote:
Opacity is ridiculously incompatible with proper pixel movement. It wasn't a consideration.

I assumed as much, but I believe I've found a work around anyway.
#107 Sep 6 2011, 8:30 pm
The bounds() proc seems useful, but with the mess of arguments I'm not sure if it really is. A picture would be worth a million words when it comes to explaining it.

I found these two quotes interesting:

Lummox JR wrote:
we've made it our mission to do this in the most intuitive way possible.

var/r = 16  // rod length
var/d = dir1 | dir2 // find the diagonal
var/dx=0, dy=0, dw=0, dh=0
if(d & (NORTH|SOUTH)) dh += r
if(d & (EAST|WEST)) dw += r
if(d & WEST) dx -= r
if(d & SOUTH) dy -= r

var/list/targets = obounds(src,dx,dy,dw,dh) - obounds(src)


The code snippet was the answer to finding what enemies are in range of an attack. That's a simple question but I don't think anyone would accuse that answer of being the "most intuitive way possible". I'm not sure exactly how it could be improved, but I'm worried if that's seriously your idea of something being "intuitive".
#108 Sep 6 2011, 8:36 pm
The problem I responded to in that post had no intuitive solution. The author wanted something that would give an 8x16 bounds box, or 16x8, depending on the direction, and in some cases would cover a swing from one direction to another (a la 3D Dot Game Heroes). There was really no way to cover a case like this with a simple built-in function.

I agree however that a picture would be good. I'd love for the reference to have diagrams. At the moment this is frustrated by IE's lack of support for inline images (except for IE9) but I'd love to know of any good alternatives. We could distribute images with the ref but it complicates things.
#109 Sep 6 2011, 8:48 pm
DerDragon's integrating/ed Awesomium in Coggoid. I dunno how it's used or how user-friendly it is, but I thought of it off the top of my head so I might as well mention it.
#110 Sep 7 2011, 12:20 am
I have a question. If I have an object using bound width and height is there a way for me to do get step in the appropriate spot as opposed to it hitting itself when looking right?
#111 Sep 7 2011, 8:00 am (Edited on Sep 7 2011, 10:45 am)
Lummox JR wrote:
I agree however that a picture would be good. I'd love for the reference to have diagrams. At the moment this is frustrated by IE's lack of support for inline images (except for IE9) but I'd love to know of any good alternatives. We could distribute images with the ref but it complicates things.

It's not ideal, but you could use HTML elements to create a diagram. Very easy as long as you're dealing with rectangles.

I'm not sure if the reference would have support for this, but it'd be neat to have some JavaScript on the reference page so the user could type "bounds(...)" into a text box and see what the bounding region looks like for the specified arguments.

Also, is there no way to make icon delays treated as ticks anymore? Are they all tenths of a second now?

Edit:
Lummox JR wrote:
The problem I responded to in that post had no intuitive solution. The author wanted something that would give an 8x16 bounds box, or 16x8, depending on the direction, and in some cases would cover a swing from one direction to another (a la 3D Dot Game Heroes). There was really no way to cover a case like this with a simple built-in function.

The problem is that the bounds() proc will often be used in regards to a particular direction, but the proc doesn't acknowledge directions. People will want to find what objects are in front of a mob, but the proc deals with x/y coordinates, not directions.
#112 Sep 7 2011, 2:21 pm
Lolwut? What happened to the old 'Profile' button? Now I can only view network usage, this is most defiantly not ideal when I have a leak somewhere causing me 65% CPU spikes.
#113 Sep 7 2011, 2:21 pm
#define DEBUG is required for code profiling.
#114 Sep 7 2011, 3:40 pm
Build 1105: http://www.byond.com/download/build/490

The main thing in this build is the simultaneous macro feature, which is often tied into games with lots of (pixel) movement. Hopefully this will help out.

This release is looking pretty stable, so we'll go public with it shortly, pending no further reports.
#115 Sep 7 2011, 6:11 pm
That's a good update, but I still think key+up/down macros are better, especially for pixel movement. To make repeating macros completely viable you'll have to figure out a way to remove that small delay after the first key press.
#116 Sep 8 2011, 5:20 am
Well, since the trackers aren't working on my mobile browser for some reason, I shall post my issues here until I get to a desktop.

walk_to() and step_to() are not working for pixel movement. They work fine for standard movement and the rest of the walk() and step() families work properly for both.

There are a few layering issues I've noticed with SIDD_MAP. Nost notably, overlays are occasionally layered inproperly for NORTH and SOUTH states. Also, objects on the same tile with different step_x/y values are not layering as expected, with higher values being ordered in front of lower values.
#117 Sep 8 2011, 7:44 am
When you do post your issues (and you'll need to do so separately), I'll need some more details and probably some demos. In particular I know walk_to() and step_to() ought to work with pixel movement because I've tested them quite a bit, so if you found a specific situation where they break down I'll need to see what it is.
#118 Sep 8 2011, 10:35 am
I'll make a report within the hour. However, I can tell you that it really isn't a special case. I'm using walk_to(src,atom/A). It works fine, right up until I change src's step_size from it's default.
#119 Sep 8 2011, 10:48 am
I noticed some weird behavior with collisions not being detected when an object's pixel movement related vars haven't been changed from their defaults. It's like BYOND wasn't even considering bumping into the object because you hadn't set its bound_ vars to be different than the default (because you want them to be the defaults). Any change to a pixel movement related var made it work (even something not related to collisions, like changing its step_size).
Page: 1 2 3 4 5 6 7