Go BIG or go home!

Page: 1 2 3 4 5
Aug 11 2011, 3: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.


Aug 11 2011, 3: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.
Aug 11 2011, 4: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.
Aug 11 2011, 5:07 pm
I guess this means I can scrap G-Move.
Aug 11 2011, 5: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.
Aug 11 2011, 5:51 pm (Edited on Aug 11 2011, 6: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).

Aug 11 2011, 7: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.
Aug 11 2011, 8: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.
Aug 25 2011, 4: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.
Aug 25 2011, 4: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.
Aug 25 2011, 4:52 pm
This should be interesting.
Aug 25 2011, 5: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.
Aug 25 2011, 5:58 pm
That's a big relief that you're not changing pixel_x/y/z's function.

I'm excited to see how these new features work out. This is definitely the most exciting update for me since the whole change to BYOND 4.0, mainly because this should greatly increase how well pixelized movement runs online if what you say is true.
Aug 25 2011, 6:24 pm
Now the BIGGER question! Will this lead into BYOND 5.0, which will hopefully introduce the pixel movement as stated throughout this?
Aug 26 2011, 7:28 am
Tom wrote:
There are a few new functions that we'll describe in the upcoming post.

I'm eager to hear what the new functions are. I have some ideas for functions I'd like to see, but I don't get the impression you're open to input.

My biggest concern is that there will be a feature/performance tradeoff if some of my library's features cannot be made to work with the built-in feature (particularly ramps and 3D movement). It sounds like the feature is handled largely inside the system and little will be exposed to the developer, which'll make it hard to extend using DM code.
Page: 1 2 3 4 5