[whatwg] Image Collision Detection in Canvas

[Saurabh Jain]

Hi,

I acknowledge that generic image collision detection in Canvas does have the
following issues but please find my answers on them:


   - No such support in 3D

As of now 3D is not there in Canvas in official WHATWG specification. When
3D comes the 3D game developer can be told that 2D collisions and 3D
collisions are different. We can have ray tracking in 3D when it comes
similar to what 3D API is there in J2ME (JSR 184).


   - If the object moves to fast it may not collide as in the first frame it
   is not touching the image and in the other frame it has gone past the image.

This issue is there but obviously the game developer has to give the correct
speed in this case. He can experiment with say a speed of 1 pixels, 2 pixels
or 3pixels a frame etc. He can get to right speed in 15-20 minutes of
testing. So this would not be a big issue.



   - False alarms

As for the false alerts in the flame or smoke example you gave, the HTML 5
game developer will use this collision detection method only when required.
Also the method will contain 2 images as parameters between whom collision
will be detected. Therefore false alarms issue will not be there as if he
does not want to check collision between two images he will not check for
them.


The main reason for my recommending this was that many novice and
non-technical people will develop games in HTML 5. Many photoshop designers
have the knowledge of HTML , CSS, JavaScript and would like to develop games
using HTML 5. We should try to help them by giving features which help them
to produce casual games in a fast manner. From my experience with J2ME
generic pixel level collision detection is a must for making the lives of 2D
game developers easier in any platform. Also pixel level work in any
developer platform scares novice people since they find difficult to
control.

Saurabh Jain
Director
SKJ Technologies Private Limited
http://www.skjworld.com
Author : Mobile Phone Programming using Java ME (J2ME)
http://library.skjworld.com/mobile-technology/java/java-me

On Sun, Apr 4, 2010 at 8:56 PM, WeBMartians <webmartians at verizon.net> wrote:

> Ages ago, I worked on this very facility. It is useful but limited -
> knowing that Pac-Man has eaten, indeed, an energy dot is a critical
> component of game play ... and my reference to Pac-Man reinforces my claim
> that this was "ages" (maybe, "eons") ago. There are times when a
> non-transparent pixel overlay should not cause a collision-alert (you allude
> to this in your posting). A good example is a pixel representing an opaque
> part of a flame - can you collide with a flame ... or smoke... or mist... or
> fog? Also, there are questions of what to do about bleeding (when a sprite
> is only partially visible). The collision matrix can become unwieldy
> (especially if color and transparency driven) and it is either
> non-rectangular or it is populated with duplicate flags (x0,y0 colliding
> with x1,y1 is not the same as x1,y1 colliding with x0,y0). ...and, once you
> have implemented the planar version of this, what do you do about 3D?
>
> There is, also, the filtering problem: if object A moves through object B
> at such a rate that it never appears to touch object B, has a collision
> occurred and how would it be detected?
>
> I agree that the facility is useful but claim that, before it is a required
> part of a standard, more definition must occur.
>
> In the meantime, with the advent of much improved Javascript interpreters,
> I speculate that implementing a specific collision detection system (similar
> to your description) might be far easier than rigorously defining a standard
> for a facility that would be seen, in short order, as underpowered.
> Affecting the success of this endeavor will be the definitions of just what
> services are available through <canvas>. Assuming that you pursue the
> Javascript approach, I wish to hear of your "adventures" and wish you
> success.
>
> Best!
> BdG/WeBMartians
> ===
>
> Saurabh Jain wrote:
>
>> Hi,
>>
>> I have a proposal for adding generic image collision API in Canvas. Given
>> two images HTMLImageElement objects and there respective x, y, clip width
>> and clip height the API call will let you know if there's any
>> non-transparent pixel (any opaque or translucent pixel) in one image's
>> clipping region that overlaps a non-transparent pixel in another image's
>> clipping region. The clipping region defined by this API call is for local
>> use only for this purpose.
>>
>> This API will be useful for game programmers. I am author of India's first
>> book on J2ME and have been developing mobile games since 2002. I have
>> through personal experience observed that this pixel level collision at
>> native level is required for game developers to build games easily. What I
>> am referring to is a kind of generic pixel level collision. People are free
>> to develop there own complex collision mechanisms for complex games but
>> small teams composed of new game developers find image collision detection
>> implementation the most difficult concept in the whole game development
>> process to grasp.
>>
>> Also pixel level checking for two 100 pixel x 100pixel images will involve
>> lot of execution time if done at JavaScript level since up to 10000 checks
>> may have to be performed. Native browser support can speed things a lot.
>> Similar thing happened in J2ME where before MIDP 2.0 people had hard time to
>> do pixel level collision both due to programming complexity and execution
>> issues.
>> Saurabh Jain
>> Director
>> SKJ Technologies Private Limited
>> http://www.skjworld.com
>> Author : Mobile Phone Programming using Java ME (J2ME)
>> http://library.skjworld.com/mobile-technology/java/java-me
>>
>
>


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100408/a7c0dd4a/attachment-0002.htm>