>>An object that is 2 units away from a wall or a pong-paddle and that
moves towards it at a speed of 5 units of length per page refresh will
travel 3 units too far before a collision is detected. Worst case scenario
is that it will go through the wall or paddle. And even if that happens the
physics will be unrealistic. The ball won't bounce off the wall, but inside
it.
Does making the math too complex include creating an attribute or function
attached to each object moving that can calculate where it's x and y
coordinate will be in the next refresh? Because that could be one way to do
it as well. If the next set of calculated coordinates meet the requisite
definition for a collision with some other object, than you can simply put
the object where it would be when it (theoretically) should have hit
between refreshes; that would probably only be a calculation in differences
between a set of x and y coordinates between two different objects.
On Thu, Dec 15, 2011 at 5:16 PM, Lars Gunther <itpast...@gmail.com> wrote:
> 2011-12-15 16:32, Nathan Sweet skrev:
>
> >>setInterval(function gameflow() {
>> I think you're off to a good start with using setInterval.
>>
>
> I will probably change that to setTieout later though...
>
>
>
>> >>The game should update the location of all objects 250 times/sec
>> However, expecting to refresh rate to be 250hz is a little unrealistic.
>> Nicholas Zakas literally just published a good article on timer
>> resolution in browsers here it is:
>> http://www.nczonline.net/blog/**2011/12/14/timer-resolution-**
>> in-browsers/<http://www.nczonline.net/blog/2011/12/14/timer-resolution-in-browsers/>
>>
>
> Good article. Some stuff that I'd missed. 4ms = 250 times per second I had
> picked up from HTML5, but not that it was only for setTimeout and that
> setInterval had a minimum of 10ms.
>
> Let me just explain why I want 4ms.
>
> An object that is 2 units away from a wall or a pong-paddle and that moves
> towards it at a speed of 5 units of length per page refresh will travel 3
> units too far before a collision is detected. Worst case scenario is that
> it will go through the wall or paddle. And even if that happens the physics
> will be unrealistic. The ball won't bounce off the wall, but inside it.
>
> One way to avoid that is to make the math more complex, which generally
> does not sit well with my students. It is doable for detecting a collision
> with a wall, but when both objects are moving the formulas will be way too
> complicated.
>
> If one OTOH checks for collisions more frequently, as in 250 times per
> second, the delta between each frame will be so small that the problems
> will disappear. Hence my desire to separate in-memory math from on-screen
> appearance.
>
>
> Here is a good tutorial that does some simple collision detection stuff:
>> http://billmill.org/static/**canvastutorial/<http://billmill.org/static/canvastutorial/>
>>
>
> I think we've got some kind of handle on the actual collision detection
> stuff, but I do appreciate the link.
>
> If I may show you guys what a student of mine is doing, have a look at
> http://keryx.se/lab/svg/**pacman.php <http://keryx.se/lab/svg/pacman.php>
>
> It is being developed at
> https://github.com/**Hasselmannen/Pacman/blob/**master/pacman.php<https://github.com/Hasselmannen/Pacman/blob/master/pacman.php>
>
> For this game we have no problems detecting collisions only 50 times/sec,
> but I expect some games to have objects moving a lot faster soon.
> https://github.com/**Hasselmannen/Pacman/blob/**master/pacman.php<https://github.com/Hasselmannen/Pacman/blob/master/pacman.php>
>
>
>
> --
> Lars Gunther
> http://keryx.se/
> http://twitter.com/itpastorn/
> http://itpastorn.blogspot.com/
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/**jsment...@jsmentors.com/<http://www.mail-archive.com/jsmentors@jsmentors.com/>
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/**jsmentors@googlegroups.com/<http://www.mail-archive.com/jsmentors@googlegroups.com/>
>
> To unsubscribe from this group, send email to
> jsmentors+unsubscribe@**googlegroups.com<jsmentors%2bunsubscr...@googlegroups.com>
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
