Aug 11 2011, 2: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:26 pm What I'd rather see is something like this: ```var const RECTANGLE = 1 CIRCLE = 2atom 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"// orshape = ROTATED_RECTANGLEwidth = 18height = 18angle = 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, 4:07 pm I guess this means I can scrap G-Move.
 Aug 11 2011, 4: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, 4:51 pm (Edited on Aug 11 2011, 5: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, 6: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, 7: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, 3: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, 3: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, 3:52 pm This should be interesting.
 Aug 25 2011, 4: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, 4: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, 5: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, 6: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