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.
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. | |
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 :[ | |
Opacity is ridiculously incompatible with proper pixel movement. It wasn't a consideration.
| |
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. | |
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 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". | |
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. | |
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.
| |
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?
| |
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. | |
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.
| |
#define DEBUG is required for code profiling.
| |
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. | |
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.
| |
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. | |
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.
| |
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.
| |
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).
| |
If you can get that down to a demo, FA, please make a report on it and I'll take a look. I haven't seen any issues with bumping default bounds.
| |
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.