[HELP]"projecting" a bitmap

honestly, ive gotten myself seriously stuck with this whole "super-perfect collision" deal ive been trying every now and then

its not so much i cant figure out what to do with the bitmap objects after collision, its simply determining the collisions in the first place

these bitmaps will be physic enabled objects (correction: MIGHT be, if i ever get anywhere with this) and will perform picture-perfect collisions no matter what their speed

because they may be travelling at high speeds, you cant just do a simple bitmap to bitmap collision, you'll have to collide the path of the object, with a background object

my question is therefore: does anyone have an idea on how to "project" bitmap paths? this things going to have a total combo of rotations, velocity, and accelerations all on it, so making a path is kind of tricky

that, and ive also downloaded flash 9 and dont have the foggiest idea about it either

would anyone be so kind as to offer some ideas?

here's something i made a while ago. I would probably do things a bit different now, but maybe it'll help you out.

I don't really want to think about new methods right now, so i can't help that much.

at first glance i guess i dont understand what this is doing, i suppose your testing your lines against others using that whole getColorBoundsRect thing, which I have managed to use succesfully already

in fact, i almost got a sphere supercollision working %100, until I found out that I might need multiple supercollision tests as the ball could bounce off really fast, and although the bounce would be determined correctly, it would not retest to see if it bounced more than once in a single frame

it would appear i got rid of that version however and replaced it with even more disfunctional ones? darn, i was going to post it (seeing as the path of the ball would remain drawn, the thing looked like a bullet ricocheting everywhere)

i had managed to determine slope of its collision based only off the rectangle it left behind, and the direction of the ball (though with the way I set it up, it seemed to work better with the ball going super fast)

thanks for posting (i really appreciate it), but its not exactly what I need

imagine defining the path of a ball, easy enough to do with your drawing api, but is it possible with a more complex shape? a complex shape, that rotates

i have a bad feeling i might have to try simpler collisions, because there does not appear to be a fast way of doing this

i really don't understand your problem. Maybe you could do s aimple diagram of what you want to achieve.

@ trogdor458: you are writing to much (makes my head dizzy),- would be more pleasent if you´d provide a demo or illusration of the actual question/ issue

it really sounds like you're trying to squeeze an elephant into a jar. doing a pairwise pixel by pixel comparison (maybe...) makes sense, but to force an object's path through rendering to determine collision is bypassing the mathematics of the situation by asking the flash player to work doubly hard.

find a way to represent your objects geometrically.

right, sorry if i wasnt clear enough, heres a basic diagram of what i need to do:
http://i106.photobucket.com/albums/m...58/picture.jpg
and i think you may be right newblack, either ill have to create my own vector data, or use the "marching squares" technique to determine the vectors of the bitmap ahead of time

although just a plain bitmap to bitmap collision might be impossible, i think i can figure out some logic in a line segment to vector collision

however, id have to figure out which side hits first (*sigh*), and the path of a single side would be really weird and possibly troublesome to calculate

i wanted to avoid this kind of collision, because i was hoping i could fit it into just a single procedure (which even then there's the possibility of multiple bounces)

bitmap & bitmap comparison is just waste of CPU imo. because a bitmap is basicly a very huge array each cell with a plain information (hit or not)- there are so many more effective ways as this brute force method (its almost like any other method is more effective as this one).

Perhaps you are searching for octree techniques:
http://en.wikipedia.org/wiki/Octree
this budy shows very good what it´s benfits are:
http://coitweb.uncc.edu/~rchang/rese...tree/ortho.jpg
insead of computing each pixel of the complex character shape you analyze before the shape and devide it into different block sizes. Once done you only check collision with those blocks and once hit do a brute force collision only on that block part of the detailed shape.

some links explaining better what as I can do atm:
http://www.gamasutra.com/features/19970801/octree.htm
http://www.flipcode.com/articles/art...ooctrees.shtml

no thinks, i think ill stick to the vector method, im pretty sure i might be able to whip up an equation thats based off a few variables:
xinitial,yinitial,length,rotation,acceleration,vel oinitial, and time

however, itll still be hard to test against all those other vectors...therefore, ill have to make something to narrow down the number of vectors it hitTests against

the good thing is that this means i can make this thing completely math-based, which ive heard as3 is VERY good with

ill need to use that instead if I can ever figure out why it keeps throwing all these errors at me

EDIT: why does veloinitial look like vel oinitial?

i made this a little while ago that illustrates collision detection for circles independent of their velocities:
http://lab.generalrelativity.org/circle_collision/

here's my post about it, where you can also find the source files:
http://blog.generalrelativity.org/?p=7

http://www.johanvanmol.org/content/category/6/23/37/
ball collision based on whether the vectors cross. Havent played with it but looked pretty solid

although that example is very nice looking, and again, thanks for the post, its irrelevant to the thing i may or may not get around to this weekend

for collisions like these, time is pretty much the variable youre trying to figure out (equations sure are useful!!), and then you can determine collision position and rotation off of that

since equations are pretty solid, it makes this process easier than the whole (make up fantasy ways of figuring it out)

got another question. will i just continue to slack off?

*shake*shake*shake*

Answer: Hell yes

Are your bitmaps going to rotate?

yes, if i had stuck with my initial idea

i think ill choose a different approach though, seems easier and more efficient

grant skinner has made a class to shape shape hitTest, you can google it
But if you think on f8 powers, this is nothing expectacular,Is just a matter of have acess to the pixels of each shape
I have an idea but havent tested yet, wich is make a shape shape hittest using 'tiles' that are just data for each pixel on screem, the complication will start when the shapes rotate, but i suspect its possible to pre calculate his pixel values for each rotation value...

...its not just a hitTest, im trying to calculate perfect physics.
you know how if things go too fast in some games, they'll go right through the walls? im going to attempt to fix that common problem

using colorBoundsRect is what I found to be an easy way to hitTest bitmaps

anyone know of a complex inequality solver lying around? if not, i might have to run this doozy of equations through a loop:

Quote:

---

//y=Math.atan(rotinitial+rotvelo*time)(x-xinitial-xvelo*time)+yinitial+yvelo*time
//y=avar*x*x+bvar*x+cvar
//Math.max(xinitial+xvelo*time-Math.abs(length/2*Math.cos(rotinitial+rotvelo*time)),xbegin)>=x>=M ath.min(xinitial+xvelo*time+Math.abs(length/2*Math.cos(rotinitial+rotvelo*time)),xend)
//time>=0

---

and ill have to find the smallest time possible...hell if i can solve it

anyone? becuz using a loop would kind of defeat the purpose here...
best inequality solver i found was the first one i found:
http://www.hostsrv.com/webmab/app1/M...advanced#reply

but when i ask something like sine(x)<0.5 it responds with x<0.523599, which is not true, and it warns me of this beforehand as it is nonpolynomial

What you're trying to do sounds rather easy, you just need to do a few things to make it all come together. Here's just one possibility:

Scale down a duplicate of your travelling bitmap when it is first being loaded. Use a routine to check for opaque pixels or pixels of a certain range of color to determine the irregular shape within the image, then store the results as an array of points (do this only once, at load time.) Scale the coordinates of these points back up to normal resolution and transform them along with the image each frame.

Finally, draw line segments between the current location of each point and the next expected location of each point. Use the same principle to create line segments in collidable surfaces, etc. If any of the projected lines of travel intersect with a surface line segment, objects have collided.

Does that make any sense?

yes, and ive actually thought of this before, but due to the overall complexity, you cant optimize it all that well

the point of this thread was actually to do amazingly accurate hitTests without plugging in every possible outcome

when i get around to it (i still haven't yet?), im going to set up a and solve a very complex equation

may be harder for me to do, but should mean that the collisions will calculate faster