Creations Favorites Medals Posts ID:181669
 #20 Dec 13 2009, 6:04 pm In response to Loduwijk (#18) Loduwijk wrote: Jerico2day wrote: Bounding boxes? Super easy. In Pseudo BASIC: > > x1 = top horizontal > > y1 = left vertical > > x2 = bottom horizontal > > y2 = right vertical > > ... > > I think you have your terms backward there. x1/x2 should be the left/right verticals, y1/y2 should be the top/bottom horizontals. I'm pretty sure I have it right. Since x is on the horizontal axis, and y is on the vertical axis. For 2 bounding boxes: > > ... > > > > 'check each object against each other object, usually in while/endwhile loop or similar > > > > ... > > By "check each object against each other object" do you mean check each point in obj1 to see if it's in obj2, and check each point in obj2 to see if it's in obj1? If so, then good. using the logic i printed checks inside each object, you use a recursive loop to check each object that is collidable against each other object. It can add up to a whole lot of objects real quick, so you gotta keep your collision objects low and only check em if absolutely necessary. You can setup zones to exclude objects. There's other methods of collision which may be faster. Another point to bring up concerns if you are using non-square rectangles. They weren't specifically mentioned, but it's a good thing to keep in mind since bounding boxes often end up being non-square. In this case, you can have a collision without having any of the points of one rectangle inside the other rectangle. For example, if obj1.x1obj2.x2, and obj2.y1
In response to Loduwijk (#19)
Loduwijk wrote:
Jerico2day wrote:
Has get pixel ever been fast in any language? :D

Yes; see the following.

Perhaps in C++ it's fast depending on how it's setup. In the higher level languages I've used, get pixel (or the equivilent name) has always been really slow.

You can store the pixel data in an array and then it would be fast enough:)

If you're working lower-level, such as in C or C++, you often do have pixel data in an array. Remember, that's how the computer keeps track of it behind the scenes anyway. In lower level languages, you often have direct access to that.

For example, for textures in OpenGL, when you put your graphic data into an array and feed that to OpenGL to tell it what an image looks like, there's nothing stopping you from doing anything else with your array of pixel data you've created. In fact, 24-bit bitmap file format is so simple that I just created my own function for loading bitmap data into an array and one for saving it back to a bitmap.

If you wanted to have access to something like this in Byond, remember that you can do DLL stuff server-side now. You could create a function that takes a dmi file's filename and returns an array of pixel data. Even though it has to be in string format on Byond's side, you could still have the C function make a byte array and return it as a character string, and on Byond's side you could use text2ascii() to get the byte values from the string.

The following example is going to assume that the C function prefixes the return value with 2 extra bytes, the first being the width of the icon in pixels and the second being its height in pixels. Also, this assumes that the dmi has only 1 icon state to search for, otherwise you have to do more stuff, though the more stuff could still be mostly on C's side.
 ```> proc/dmi2array(filename)> var/returnString = call("myLib.dll","dmi2array")(filename)> var> width = text2ascii(returnString,1)> height = text2ascii(returnString,2)> var/list/imageData[width][height]> > for(var/indexy = 1 to height)> for(var/indexx = 1 to width)> imageData[indexx][indexy] = text2ascii(returnString, 2 + indexx + (indexy-1)*width)> > return imageData> ```

And you could set up the C function to handle more than just dmi as well, obviously, since you could handle it however you wanted.

Not only that, but if you make a dll with a function to load up image data, you might as well make one right in there that returns a bit map of which pixels are opaque to make a sprite for collision detection out of. So you could also have a proc/getCollisionArray(filename)

It would be interesting to see the speed advantage of doing it this way.
Page: 1 2