Aug 10 2011, 2:09 pm
|
|
Tom
 |
Well, the obvious way to do it would be to go off the icon opacity itself, but that's kind of a difficult problem to do efficiently. In general I think that rectangles are good enough for these applications, and rects+offsets (as we'll have if we stick with this notation and support pixel offsets) slightly better.
|
Out of curiosity, when will v.490 be released? Not trying to rush, but the bounds var is going to help me a lot.
| |
Tom wrote:
I agree that the need to parse this string to update isn't ideal, but then it's hard to imagine this changing much at runtime. It's not just when you need to change it, it's any time you need to read the value too. The case where you modify it based on its own value is the worst because you're reading it and writing back to it. Suppose you want to determine, taking pixel offsets and bounds into account, how many pixels you are away from an object - are you going to parse the string every time? This might seem like a strange or rare case to you, but it's not. | |
Forum_account wrote:
Suppose you want to determine, taking pixel offsets and bounds into account, how many pixels you are away from an object - are you going to parse the string every time? This might seem like a strange or rare case to you, but it's not. Well, honestly if you are writing games where you need to do this kind of thing, I don't think that the reading/writing of a text string is going to add any real overhead (and with a function call it won't complicate the code either). Probably I'd just make my own atom vars for width & height for reads and have a routine to update them and then rewrite bounds for writes. Like I said, the idea behind the text bounds is for greater flexibility (initially for the border example I gave but also for possibly better resolution). If this isn't worth anything, I agree that numeric vars are more logical here. I guess we could always go with pixel_width/pixel_height AND bounds for when we want more resolution. Kinda seems like overkill but it's not like it's a real problem to do. | |
:megusta:
| |
Tom wrote:
Well, honestly if you are writing games where you need to do this kind of thing, I don't think that the reading/writing of a text string is going to add any real overhead (and with a function call it won't complicate the code either). Probably I'd just make my own atom vars for width & height for reads and have a routine to update them and then rewrite bounds for writes. It's not about the overhead, but there's no reason to do it. Considering you can't overload the assignment operator or define a proc that gets called when a variable is changed, it's kind of important that the feature is implemented reasonably. Isn't the point of this to eliminate the need for a library? =) If you want to stick to strings, there are some things you can (potentially) do, like: atom.bounds = "16,16" | |
Christmas came early this year.
| |
Forum_account wrote:
It's not about the overhead, but there's no reason to do it. If there were no reason, we would have done it the numerical way, but like I've said (three times now), the text bounds gives greater flexibility. Or so we think-- if no one is going to use that, then I agree that the numerical way is more straightforward. Still, if a game is really querying these parameters, I'm not sure why: atom/movable is such a big deal. Then you can just use width & height for all queries. And how often do you really expect to be changing the size of an object at runtime? Is this happening a lot in existing games (honest question)? If you want to stick to strings, there are some things you can (potentially) do, like: > atom.bounds = "16,16" I agree that this kind of string representation of a datum would be cool. But in this case there is more to the datum than the width & height; what we really want is a Rectangle type and associated proc calls. | |
Tom wrote:
Like I said, the idea behind the text bounds is for greater flexibility (initially for the border example I gave but also for possibly better resolution). Ah, I understand now. Thinking back, I do remember when we discussed this in the GV, and one of the points brought up against having non-atomic ("pixel") movement as a standard part of DM was the choice of bounding method. We generally think of bounding rectangles, but there's also bounding circles, per-pixel collision testing, and more complicated shapes. I see how a text string would allow BYOND to include alternate methods in the future. Perhaps a better solution would be to provide a toggle, either on the world object (and available at compile time only) or on individual objects (and modifiable at runtime). This would be similar to world.map_format, and would switch between any bounding methods that had been implemented. For example, there could be BOUNDING_RECTANGLES and BOUNDING_CIRCLES macros. Depending on the value of this variable (again, either on the world or on the atom/movable object) the object stored in the bounds variable would use different variables. In a BOUNDING_RECTANGLES world, the object stored in the bounds variable pay attention to the width and height variables. In a BOUNDING_CIRCLES world, the object would calculate collisions based on a radius variable. The object stored in the bounds variable (a /bounds object?) would always have all of these variables, but would ignore the ones it was not currently using. The ability to use multiple bounding models in the same game would be helpful in many projects, such as a space game where spaceships use bounding circles, but people walking around inside the ship would use bounding rectangles. The simple fix to have them play nice together would be to ignore potential collisions with objects that use a different bounding model. So, for example, a spaceship (using circles) that found its way onto a different part of the map would pass through a player (using rectangles) without even checking for collision. | |
Tom wrote:
And how often do you really expect to be changing the size of an object at runtime? Is this happening a lot in existing games (honest question)? In Mario it happens every time you get a powerup or take damage. In many games it happens every time the player presses down (to duck). I went back and figured out what (I think) you mean by the border. If you have a 32x32 icon where the player is 16x16 and is drawn in the center of the icon, the bounds would be "8,8 to 24,24". The way I'd handle this is to have the object's width and height be 16 but offset the icon. If I was creating this from scratch I'd have a single value for each coordinate (instead of having x, y, pixel_x, and pixel_y to represent the mob's position). That'd free up pixel_x and pixel_y to be used purely as graphical offsets to the icon. In the case of the example bounds above ("8,8 to 24,24"), you'd set width = 16, height = 16, pixel_x = -8, pixel_y = -8. It might seem like the text bounds gives greater flexibility and given your affinity for using strings for things like this I'm not surprised you instinctively did it this way, but there's a more elegant way to handle it with a set of numerical variables. Is the problem that it just seems counterintuitive that using a single variable to represent the information isn't the simplest solution? | |
Presumably /bounds would actually be sub-typed for the appropriate bounding strategy, and have a fairly limited interface to ask questions like "are these two atoms colliding" etc.
For the cases I've commonly seen, you want to grab width/height of the atom to do bounding calculation ... and maybe there are other functions, but they are unrelated and existing functionality probably doesn't support them so great anyway. If BYOND does the bounding calculation by one of a number of strategies for you, how you present width and height for atoms becomes a separate issue to bounding. More commonly, you want the width and height of the atom's icon, be it main icon or a merge of overlays and underlays. To ... generate new icons for armour, position icon text/health bars over something and so on. So the representation you want is visual, not bounding. BYOND presumably would determine bounding box/circle/whatever internally from the icon metadata it has to hand. So for the crouching case, the bounds change is implied by the icon change. | |
Don't feel like reading all of the comments right now. I can't wait for this, though.
| |
Neblim wrote:
tl;dr Just because it's not Flash support doesn't mean it's not beneficial to developers. Be an asshole elsewhere. On the update itself - this will definitely make handling the larger sprites in Eternia a lot simpler! =) | |
wow man this is a super cool update now we can make games where your only 1 pixel wide or something or even 128x128
| |
No. This update makes more tiles. As in multiples of 32. A 1-pixel wide atom would still function as 32x32.
| |
Byond Wars Episode 18.5:Attack of the trolls.
| |
Yut Put wrote:
Albro1 wrote: Is there any reason for that? What kind of game would use that? | |
Yut Put wrote:
Albro1 wrote: It sounds like this particular update will make the one pixel atom function as a 32 pixel atom because it still takes steps a tile at a time. Also, a 20x20 mob won't be able to move into the same tile as the 1x1 mob because it's just checking density per tile. The 1x1 mob occupies the 32x32 tile it's standing in, so the 20x20 mob can't enter it. With pixel movement it could. This is a step towards pixel movement, but not completely there yet. | |
Nothing was stopping you from using world.icon_size=1 for current pixel-movements, anyways.
Oh, wait, the fact that it runs really slow and your screen size is now maxed at 70x70 pixels was the reason that is useless. | |
Let's hope this native pixel movement is somehow able to get around the current problems we have when running our own pixelized systems over a server.
I definitely like the title of this post. You guys are finding it easy to dodge critique and embarrassment by not telling us about the big things you're doing anymore. | |