Go BIG or go home! in Announcements

Page: 1 2 3 4 5 6
#80 Aug 11 2011, 4:36 pm
Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box?

I know for a fact I would use that first thing.
#81 Aug 11 2011, 5:06 pm
Lummox JR wrote:
For this reason I get where FA is coming from when he mentions preferring two numeric vars to represent x*size+pixel_x and y*size+pixel_y, for instance.

You're simplifying it there. I think it'd be something like: absolute pixel x = x * icon_width + pixel_x + bounds.left

x is the atom's x var
icon_width is parsed out of world.icon_size
pixel_x is the atom's pixel_x
bounds.left is parsed out of the bounds string (if you set bounds to something like "8,8 to 24,24", it'd be the first 8)

I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string. If you have any questions about how to make it work by exposing a set of new variables to the developer, pose some questions to the community. I'm sure we can come up with something.
#82 Aug 11 2011, 5:12 pm
Forum_account wrote:
I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string.

Since bounds can theoretically represent many things besides a simple width x height, it is more flexible to use a text string. Yes, assigning to a datum would be nicer but that is a lot more work and has some limitations, which Lummox JR and I have both gone over multiple times.

If there is really this huge need to constantly read or write the bounds, and for whatever reason people don't want to use the extremely simple method I proposed, I suppose we could provide width/height in addition to bounds (which could store more complex information).
#83 Aug 11 2011, 5:13 pm
Mista-mage123 wrote:
Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box?

Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.
#84 Aug 11 2011, 5:27 pm
Tom wrote:
Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.

If that's the case, then would non-square icons work as well, like triangles and circles? Would they bump based on pixel collision? I'd love to see this.


#85 Aug 11 2011, 5:27 pm
Tom wrote:
Neblim wrote:
Tom has only played MUD based games.

This is not true! I am an avid Halo player but I can't reveal my gamer tag because of my penchant to teabag and trash talk.

^Lol'd.
#86 Aug 11 2011, 5:29 pm
Bravo1 wrote:
Tom wrote:
Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.

If that's the case, then would non-square icons work as well, like triangles and circles? Would they bump based on pixel collision? I'd love to see this.


.... is it even possible to have an image with a non-square canvas? ..
#87 Aug 11 2011, 5:32 pm
Yut Put wrote:

.... is it even possible to have an image with a non-square canvas? ..

Not the canvas, If you take opacity into account, the technically, yes.


#88 Aug 11 2011, 5:59 pm
Okay. I read every single comment and have thought about what Forum_account, Tom and LummoxJR have discussed here.

Would it not be feasible to add one extra var called something like bounds_mode that is used to determine what the bounds var is used for? I know this goes somewhat against the KISS principle, but let me explain what I mean.

Basically, there would be constants that it could be assigned to: NO_BOUNDS (default), RECTANGLE_BOUNDS, CIRCLE_BOUNDS, ICON_MASK_BOUNDS, etc.
What this means is that the bounds var would be interpreted based on the bounds_mode, instead of what kind of data it is assigned to.

You could add another rectangle mode (RECTANGLE_NUMERIC_BOUNDS?) that allows use of a couple vars (bound_width, bound_height) that are otherwise ignored (internally, and by the developer) in all other modes that instead use bounds (since they only require a single var for say, the icon mask, the bound string "8,8 to 24,24", the radius, etc.).

It seems to me, something like this would please everyone. (It adds more vars, but Tom said he was already considering to do that.) Plus, having a mode var that requires a single integer comparison seems much more efficient than parsing a string to determine what mode the bounds are using. Not to mention, it's much easier for the developer to make a small typo in the string and not realize it, when a macro like that would give a compiler error right away.

I do see an extra comparison being needed to now check that the bounds var is of the form that bounds_mode says it is, but that doesn't seem like it would be more than a single integer comparison.
#89 Aug 11 2011, 6:26 pm
What I'd rather see is something like this:

var
    const
        RECTANGLE = 1
        CIRCLE = 2

atom
    var
        shape = RECTANGLE
        
        width = 32
        height = 32


If the shape is set to RECTANGLE, BYOND uses a rectangle with the specified width and height as the bounding box. If shape is set to CIRCLE, it uses a circle (or maybe an oval) that fits inside that rectangle as the bounding shape. If you added another bounding type you'd add another constant and maybe some additional vars (if they're needed).

For example, if you wanted to support rectangles that could rotate, under each method (bounds string and vars), you'd do:

bounds = "5,21 to 10,5 to 26,10 to 21,6"

// or
shape = ROTATED_RECTANGLE
width = 18
height = 18
angle = 20


To support this using vars you'd need to add a new constant and the angle var, but think about what it takes under each method to rotate the rectangle:

// using vars:
angle += 5

// using a string:
proc
    rot_x(x, y, cx, cy, angle)
        x -= cx
        y -= cy
        . = x * cos(angle) - y * sin(angle)
        . += cx
    
    rot_y(x, y, cx, cy, angle)
        x -= cx
        y -= cy
        . = x * sin(angle) + y * cos(angle)
        . += cy

// scroll to the right, this line's a doozy!
bounds = "[rot_x(x1,y1,cx,cx,angle)],[rot_y(x1,y1,cx,cx,angle)] to [rot_x(x2,y2,cx,cx,angle)],[rot_y(x2,y2,cx,cx,angle)] to [rot_x(x3,y3,cx,cx,angle)],[rot_y(x3,y3,cx,cx,angle)] to [rot_x(x4,y4,cx,cx,angle)],[rot_y(x4,y4,cx,cx,angle)]"


It's been said that using a string makes things more extensible, and that sounds good, but I don't see any examples. It just looks much more complex to parse as you have more advanced bounding methods and, in this case at least, it even becomes difficult to set.
#90 Aug 11 2011, 7:07 pm
I guess this means I can scrap G-Move.
#91 Aug 11 2011, 7:42 pm
Gakumerasara wrote:
I guess this means I can scrap G-Move.

LOL, if every addition is going to be nitpicked like this, then this won't be out for a few years so no worries.
#92 Aug 11 2011, 7:51 pm (Edited on Aug 11 2011, 8:18 pm)
Forum_account wrote:
It's been said that using a string makes things more extensible, and that sounds good, but I don't see any examples. It just looks much more complex to parse as you have more advanced bounding methods and, in this case at least, it even becomes difficult to set.

Actually, you just gave a great example of how the string makes things more extensible, because your example can be coded as a library to do exactly the notation you want. You just have to call some kind of update() after setting your width, height, angle etc. It's kind of ridiculous to have us hard-code ROTATED_RECTANGLE or all of these other arbitrary shapes when you can just do it yourself.

That said, this proposed notation is actually feasible so we'll keep it in mind (you could also assign shape/bounds to an icon).

#93 Aug 11 2011, 9:51 pm
Tom wrote:
(you could also assign shape/bounds to an icon).

You make it seem like pixel-based collision is a good solution to everything.
Correct me if I'm wrong, but isn't pixel-based collision ridiculously inefficient compared to almost any other collision detection and almost never used because of it?

Sure, it would be great if we could make icon masks for any imaginable shape we want and just do pixel-based collision for anything, but I thought that wasn't feasible.
#94 Aug 11 2011, 10:03 pm
Naokohiro wrote:
Correct me if I'm wrong, but isn't pixel-based collision ridiculously inefficient compared to almost any other collision detection and almost never used because of it?

In 2D-space it's actually not that hard of a problem and certainly something we could do without much overhead. It would involve storing either a grid of opacity bits or a depth value to the nearest opaque pixel for each point on the perimeter. I'm not saying we'll have it in immediately but it's an option and hence something to consider in the notation.
#95 Aug 25 2011, 6:11 pm
I wanna know where this bound update is I have a game that needs bosses to be larger than 1 tile and this would be perfect.
#96 Aug 25 2011, 6:45 pm
First round of development (bounds + pixel movement) is finished, and now in testing/demos. We'll put it in beta next week and get some feedback in case we want to change some things up.
#97 Aug 25 2011, 6:49 pm
Tom wrote:
First round of development (bounds + pixel movement) is finished, and now in testing/demos. We'll put it in beta next week and get some feedback in case we want to change some things up.

yea+9000
#98 Aug 25 2011, 6:52 pm
This should be interesting.
#99 Aug 25 2011, 7:21 pm
Just FYI, we took the suggestions here and changed to a numerical notation and added a few handy accessibility functions. Furthermore, we decided (also as per comments here) to keep pixel_x/y/z as purely visual (so as to reduce conflicts with existing games/libs) and use new movable step_x/y vars for the physical offsets. There are a few new functions that we'll describe in the upcoming post. I'm hoping that people can use this without having to resort to hacks, and the main purpose of the demos/testing is to get case studies (as will the beta test). Obviously we won't cover everything but hopefully it'll be pretty good.

I don't know if I'd call this "interesting" since you can do most of this already with the excellent libraries people have written up, but it is faster for many cases and does seem like something that should be built into the language, since it is expected of modern games (I believe this was the crux of Falacy's argument). I believe that for more extensive operations (eg, Forum_account's sidescroller and gravity implementations), people will want to continue to use libraries but those libraries can leverage this new functionality to be more efficient.
Page: 1 2 3 4 5 6