Why not do something like this? Decoupling these two operations sounds
like a cleaner design.
// Like somebody said, 4ms is too fine of a resolution
setInterval(function gameflow() {
// This includes collission detection
move_all_objects_in_memory(); // DOM is left alone for SVG
}, 4);
// Use requestAnimationFrame instead
setInterval(function gameflow() {
move_all_objects_on_screen(); // DOM is updated for SVG
}, 16); // 60fps
On Dec 16, 4:20 am, kik <[email protected]> wrote:
> Check this project out:http://www.glge.org/It is like a port of blender's
> game engine to javascript and is quite advanced.
> He uses setInterval(blahBlah, 1) everywhere and after that calculates the
> actual fps, so I would stick to setInterval
>
> On Fri, Dec 16, 2011 at 4:27 AM, Nathan Sweet <[email protected]>wrote:
>
>
>
>
>
>
>
> > >>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 <[email protected]> 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/**[email protected]/<http://www.mail-archive.com/[email protected]/>
>
> >> To search via a non-Google archive, visit here:
> >>http://www.mail-archive.com/**[email protected]/<http://www.mail-archive.com/[email protected]/>
>
> >> To unsubscribe from this group, send email to
> >> jsmentors+unsubscribe@**googlegroups.com<jsmentors%[email protected]>
>
> > --
> > To view archived discussions from the original JSMentors Mailman list:
> > http://www.mail-archive.com/[email protected]/
>
> > To search via a non-Google archive, visit here:
> >http://www.mail-archive.com/[email protected]/
>
> > To unsubscribe from this group, send email to
> > [email protected]
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
