Hi Lincoln,
One of the problems you may run into is that we only have routines that handle image formats that we recognize, whether accelerated or not. Thus, if you create some kind of custom 32-bit format you would end up causing us to invoke our general custom-format routines which use all of the high-level pixel getting and setting method calls in Raster and BufferedImage. You would do better to do the blits yourself in that case.
So, if you want to stick with a built-in format, you would be best off with INTEGER_RGB which only has 24 bits to work with. If you use INTEGER_ARGB you then run into the strange way that we manipulate alpha in our XOR routines which does not do what you might expect. It might be possible to work around that, but I would avoid it if you can.
Another thing to consider is that if you use a format that is hardware accelerated then the pixel readback will be *VERY* slow on many platforms. If you plan to search for collision pixels I would recommend using a software surface since the readback from a hardware surface will more than offset any performance gains you get in drawing the figures.
Someone else mentioned using bounding boxes first as a collision detection technique and then only use bitmaps if you need them. If you do it that way then you are always doing a detection between A and B and you only really need 2 bits (one for A's body and one for B's weapon) and could use a byte format such as ByteGray. A software XOR of byte images should be pretty fast, especially since it is only needed when the bounding boxes collide...
...jim
--On Tuesday, July 13, 2004 10:56 PM -0400 Lincoln Quirk <[EMAIL PROTECTED]> wrote:
Hello list.
Okay, here's the situation: I'm writing a 2D game with pixel collision in Java. My current design has a graphics front-end, and a "physics frame" which is a non-displaying buffer the same size as the graphics region. Each character that the user sees is mapped to a "shadow" in the physics frame -- a two-bit representation of the character for the purposes of collision detection. (The two bits signify different parts of the character -- some pixels are 'collision' pixels, some are 'attack' pixels, and some are both).
Each frame, the physics system walks through the characters and renders each one onto the physics frame, checking for collisions. Every object rendered in this way should be able to collide with every other object, and identify both objects in any collision. I won't ever need to have more than 16 separately colliding objects at any one time.
I believe the way I want to do this is to render the physics frame in a 32-bit-depth graphics buffer object of some sort, allocate two different bits for each object, and keep a record of which bits correspond to which object so that when a collision occurs, I can "look back" and find out what object set that bit. Each iteration of the loop would involve shifting the two-bit bitmap to the next free slot, then transferring it using XOR onto the physics frame. To check for collisions, I can then do a pixel-by-pixel comparison of the region on the frame to the shifted bitmap in memory -- anywhere that the bits don't match, XOR them to find out what's different, and look up those bits in the record to find out the object I collided with.
Phew.
Now, what I want to know, is how you would go about doing this in Java, using fast BitBlt routines. I have been digging through awt's Graphics2D and GraphicsConfiguration, swing's ImageIcon, etc., but there's just a sheer number of classes that I cannot wrap my mind around what I need and what I can ignore.
So if someone could help me out -- how do I create a region that I can do some low-level, fast blt'ing to? Or, if you have a better idea on how I should implement my physics that takes better advantage of Java, some ideas about that would be good too.
Thank you,
Lincoln Quirk
========================================================================= == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
