Yut Put wrote:
Albro1 wrote:
No. This update makes more tiles. As in multiples of 32. A 1-pixel wide atom would still function as 32x32.

not if your icon_size is 1

Is there any reason for that? What kind of game would use that?
Albro1 wrote:
Yut Put wrote:
Albro1 wrote:
No. This update makes more tiles. As in multiples of 32. A 1-pixel wide atom would still function as 32x32.

not if your icon_size is 1

Is there any reason for that? What kind of game would use that?

hmm, light cycles
Yut Put wrote:
Albro1 wrote:
No. This update makes more tiles. As in multiples of 32. A 1-pixel wide atom would still function as 32x32.

not if your icon_size is 1

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.
Forum_account wrote:
Yut Put wrote:
Albro1 wrote:
No. This update makes more tiles. As in multiples of 32. A 1-pixel wide atom would still function as 32x32.

not if your icon_size is 1

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.

I meant world.icon_size =P
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.
We don't post infrequently to dodge anything; mostly the thing is we're just busy, and it's hard to post about stuff that's still up in the air. This post actually would have come even sooner in the week but many of the details were still in flux at the time. We go back and forth on design issues a lot, and also many things come up during testing that weren't necessarily obvious before.

To answer your concerns about servers though, Fugsnarf, I suspect performance gains will be pretty much down to the difference between handling things internally vs. with a great deal of soft code. Certainly the collision checking that has to be done with soft-coded pixel implementations currently will be much simplified. Hard or soft code though, any game in which a very large number of atoms is moving every tick is going to have performance issues, more so if tick_lag is lower. However many of the client-side performance issues currently seen are due to the old pixel offset approach which was in use before version 489, and to the network delay issue being fixed in 490.
Well, fear not Lummox Jr, I can run about 50 mobs, all with AI code with a dual core at about 30% CPU usage, and that's with a pretty sturdy AI code. I wouldn't be surprised if we see more and more p_m games.

I just got done playing 8bittrip with Resonance, and may I say, one of the most fun games I've played, and that includes games outside of byond. I wish it were longer/had more content
There is one problem I can see from this.

This part concerns me: "By giving an obj or mob explicit bounds, that tells the server that its pixel offsets (x and y, not z) matter"

What if you have a big object you want to give specific bounds, but you still want pixel offsets to be visual only? The way I see it, some people might not want a system where an object can bump more tiles than it should simply because of pixel offsets.
Mista-mage123 wrote:
There is one problem I can see from this.

This part concerns me: "By giving an obj or mob explicit bounds, that tells the server that its pixel offsets (x and y, not z) matter"

What if you have a big object you want to give specific bounds, but you still want pixel offsets to be visual only? The way I see it, some people might not want a system where an object can bump more tiles than it should simply because of pixel offsets.

I don't think that this would be too big of a deal, I've never really come across a situation like that; the only case where I could really see this being an issue is for when someone creates an icon with open space, which is pretty silly, anyway, especially when you can create icons with any dimensions you could think of.
Well, think about its implications. What it's basically saying is you can't have a bigicon use multiple tiles without pixel offsets impacting movement. As crazy as it sounds, pixel offsets are used for purposes other than movement.

For example, I have a 2D Sidescroller big icon facing one direction, I want to flip it ingame. After flipping it, I want to reposition the character so its in relatively the same position as it was standing the other direction, which requires adjustment via pixel offsets. This would mean the icon would be bumping another tile it isnt bumping when facing the other direction, which causes problems.

Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is.

These aren't the only examples, i'm sure you can think of many other practical uses for pixel offsets that have been used outside of a pixel-movement engine.

Basically, pixel offsets can only be used for movement in such a system, which is pretty lame as they do have other purposes.
All I can say is yes =), and kinda bumping out the need for better programmers ;p.
Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is.

It's a big mistake to make this work based on pixel_x and pixel_y. It complicates a lot of issues *and* removes the ability to have purely visual offsets.

Suppose you want to make an attack that hits enemies within 48 pixels of your mob, you need to:

1. Parse your bounds and use the parsed values, mob's coordinates (x and y) and pixel offset (pixel_x and pixel_y) to find the corner points of your bounding box. Then extend the box 48 pixels on each side.

2. For every nearby mob, do the same computations (taking x, y, pixel_x, pixel_y, and the parsed bounds values into account) to compute the corner points of every nearby mob. Then check if the mob's rectangle overlaps the area of the attack's effect.

Not to sound like I'm against a native implementation, but it shouldn't be clumsier to use than the existing libraries. The way my library handles this is that the atom's px and py vars are the lower-left corner of its bounding box. The pwidth and pheight vars tell you the size of the box. To compute the corner points (and to compute the distances between two objects) you can just use these numbers to do the math. The object's coordinates are single numbers, not the products of combining many numbers.
Forum_account wrote:
Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is.

It's a big mistake to make this work based on pixel_x and pixel_y. It complicates a lot of issues *and* removes the ability to have purely visual offsets.

Suppose you want to make an attack that hits enemies within 48 pixels of your mob, you need to:

1. Parse your bounds and use the parsed values, mob's coordinates (x and y) and pixel offset (pixel_x and pixel_y) to find the corner points of your bounding box. Then extend the box 48 pixels on each side.

2. For every nearby mob, do the same computations (taking x, y, pixel_x, pixel_y, and the parsed bounds values into account) to compute the corner points of every nearby mob. Then check if the mob's rectangle overlaps the area of the attack's effect.

Not to sound like I'm against a native implementation, but it shouldn't be clumsier to use than the existing libraries. The way my library handles this is that the atom's px and py vars are the lower-left corner of its bounding box. The pwidth and pheight vars tell you the size of the box. To compute the corner points (and to compute the distances between two objects) you can just use these numbers to do the math. The object's coordinates are single numbers, not the products of combining many numbers.

Tom explained over and over again why they chose the current implementation and I kind of like it. You could always create a bounds datum yourself and create procs to handle the changing of the bounds variable for you.
ExPixel wrote:
Tom explained over and over again why they chose the current implementation and I kind of like it. You could always create a bounds datum yourself and create procs to handle the changing of the bounds variable for you.

I still don't fully understand the explanation.

I understand what it lets you do, but I don't understand why its preferred over having multiple numeric variables. All this simplifies is the easiest case (setting the bounds and never changing them), but that case is easy no matter how you do it. Using this string complicates any usage that's more advanced than that.

Saying "oh, but you can work around it" misses the point that you shouldn't have to work around it. If you can make a feature easy to use, why not do it? I haven't heard (or I missed it, there are a lot of comments) a reason why it's not feasible to use numbers for this.

It can be tough, but BYOND should find ways to make difficult things easy. That's the selling point: multiplayer game development is tough, BYOND makes it simple. It's not as good of a selling point to say "we make easy things even easier (and the hard things even harder)".
Forum_account wrote:
ExPixel wrote:
Tom explained over and over again why they chose the current implementation and I kind of like it. You could always create a bounds datum yourself and create procs to handle the changing of the bounds variable for you.

I still don't fully understand the explanation.

I understand what it lets you do, but I don't understand why its preferred over having multiple numeric variables. All this simplifies is the easiest case (setting the bounds and never changing them), but that case is easy no matter how you do it. Using this string complicates any usage that's more advanced than that.

Saying "oh, but you can work around it" misses the point that you shouldn't have to work around it. If you can make a feature easy to use, why not do it? I haven't heard (or I missed it, there are a lot of comments) a reason why it's not feasible to use numbers for this.

It can be tough, but BYOND should find ways to make difficult things easy. That's the selling point: multiplayer game development is tough, BYOND makes it simple. It's not as good of a selling point to say "we make easy things even easier (and the hard things even harder)".

What if they decide to implement bounding circle collision. Why have 3 variables instead of one. IF there are two types of collisions you would end up with:

var/pixel_width
var/pixel_height
var/pixel_radius

Instead you could always just have one variable to handle it all:

bounds = "[width]x[height]"

or

bounds = "radius-10"

or something similar.
Extensibility is the main reason a bounds var would be preferred, but I understand the intrinsic value of having raw numbers to work with too. Tom and I had a talk about this last night following the comments that popped up, and we agree this needs more thought.

As far as using a single coordinate pair to represent the location, I'm not sure that's so easy to handle--at least not unless we break it down internally into simpler, more familiar terms. Using pixel_x/y for this seems much easier in a lot of ways. Perhaps though it'd be handy to have such vars around so that modifying one of them would simultaneously impact loc and pixel_x, for instance. I see your point about the possibility of wanting to mix visual and tactile pixel offsets, though I think in practice this won't come up at all; also, altering the bounds could be enough to achieve that effect.
Lummox JR wrote:
Extensibility is the main reason a bounds var would be preferred, but I understand the intrinsic value of having raw numbers to work with too. Tom and I had a talk about this last night following the comments that popped up, and we agree this needs more thought.

Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes?

As far as using a single coordinate pair to represent the location, I'm not sure that's so easy to handle--at least not unless we break it down internally into simpler, more familiar terms. Using pixel_x/y for this seems much easier in a lot of ways. Perhaps though it'd be handy to have such vars around so that modifying one of them would simultaneously impact loc and pixel_x, for instance. I see your point about the possibility of wanting to mix visual and tactile pixel offsets, though I think in practice this won't come up at all; also, altering the bounds could be enough to achieve that effect.

Think about what would factor into computing an object's absolute location. Having a single var to give you this simplifies a lot of things.

About the underlined part, I'm not sure why you think that. Also, having a way to set a visual offset eliminates the need for the full support of the bounds string as I understand it. Setting bounds = "8,8 to 24,24" would be the same as setting the size to 16x16 and giving it a -8,-8 offset.
Forum_account wrote:
Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes?

That's the gist of it. It might for instance be feasible to handle collisions on the individual pixel level of icons. Not that it'd be fun to implement.

Think about what would factor into computing an object's absolute location. Having a single var to give you this simplifies a lot of things.

A single-var loc with pixels would basically be the x position in pixels, y in pixels, and z in tiles. A single 4-byte value can't handle that so it would have to be done in some kind of new specialized type that would have to be refcounted. That'd be really ugly, internally. And that wouldn't be friendly to work with, either, since you couldn't set mob.pixel_loc.x=... in that scenario. This could be done if every movable had its own unique pixel_loc with a special ref type (in much the same way contents works), in which case we would just need two new ref types (or maybe three, if you wanted to account for turfs at least for collision-checking purposes).
Forum_account wrote:
Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes?

Yes. For example, you could assign bounds to an icon to be used as the mask to support arbitrary bounding regions.

We may compromise and have a generic bounds assignment as well as a width/height for the common case of the rectangle.

We'll have to play around with the visual/physical pixel offset modes. It shouldn't be difficult to let the user control the interpretation, but we don't want to add too many settings as to make the system confusing.
Page: 1 2 3 4 5 6