Hi,<div><br></div><div>I acknowledge that generic image collision detection in Canvas does have the following issues but please find my answers on them:</div><div><br></div><div><ul><li>No such support in 3D</li></ul></div>
<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>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). </div>
</div></blockquote><div><ul><li>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.</li></ul></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div><div>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.</div>
</div></blockquote><div><div><br></div><ul><li>False alarms</li></ul></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>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.</div>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Saurabh Jain<br>Director<br>SKJ Technologies Private Limited<br><a href="http://www.skjworld.com">http://www.skjworld.com</a><br>Author : Mobile Phone Programming using Java ME (J2ME)<br><a href="http://library.skjworld.com/mobile-technology/java/java-me">http://library.skjworld.com/mobile-technology/java/java-me</a><br>
<br><div class="gmail_quote">On Sun, Apr 4, 2010 at 8:56 PM, WeBMartians <span dir="ltr"><<a href="mailto:webmartians@verizon.net">webmartians@verizon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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?<br>

<br>
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?<br>
<br>
I agree that the facility is useful but claim that, before it is a required part of a standard, more definition must occur.<br>
<br>
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.<br>

<br>
Best!<br>
BdG/WeBMartians<br>
===<div><div></div><div class="h5"><br>
Saurabh Jain wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
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.<br>

<br>
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.<br>

<br>
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. <br>

Saurabh Jain<br>
Director<br>
SKJ Technologies Private Limited<br>
<a href="http://www.skjworld.com" target="_blank">http://www.skjworld.com</a><br>
Author : Mobile Phone Programming using Java ME (J2ME)<br>
<a href="http://library.skjworld.com/mobile-technology/java/java-me" target="_blank">http://library.skjworld.com/mobile-technology/java/java-me</a><br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br>
</div>