A variable tick time is inevitable if you’re using rAF, and in many other environments. In a fixed timestep situation, your simulation is only executing as fast as you want it to. If 20 seconds passed since the last tick, a fixed timestep application would loop through that large chunk of time in whatever increment you want (e.g. 16ms/60fps) to prevent weird stuff from happening due to the large tick.
Holy cow,i tried it and it was fast.
But it only worked for firefox version 28.0
it didn’t in google chrome Version 34.0.1847.116 m due to security issues
but when i used a html server it worked…
then i added an fps counter it was like 167 fps average…
i tried it in appjs it runs 56 fps average…
without pixi,it runs 22 fps average…
Oh, c’mon guys, it ain’t that impressive…
I mean, just look at the code!
Exactly - YOU HAVE WRITTEN SOME CODE.
Most people on the planet cannot do that.
Your code makes a game, and you have done it in three hours. Well done!
Give me three hours and a computer and these days a I tend to complain about being tired then go and look at fail compilations on youtube!
We’re proud of you - you should be too :D
Should I be proud of myself because I can do something the average person can’t?
I don’t think so…
I should only be proud of myself if I did something substantially harder than what my past self could do.
If @David posted this three months ago, my three month past self could probably do the same thing.
That’s what I was talking about with @David, once I’m confident about and idea, I can implement it in no time.
But being confident about a game design idea is impossible to me.
That’s what I’m pursuing…
With that said, I appreciate all your nice comments! :D
Just a question: did this game need BoxD2? It feels like overkilling it.
That’s what I though initially, but it turns out that top-down driving is actually a rather complex physics problem. We need to compensate the lateral force as the tank turns, get metadata for collisions, among other things. Also the box2D physics is what allows the behaviour of the boxes as you crash into them. So in the end we’re using it rather heavily!
Well, you could just use circles to check collisions and still get a reasonable accuracy, I think.
The only problem with Box2D is that it runs at 15 fps on my PC, which really isn’t an issue, considering that most gamers have a faster PC than mine.
What sort of preferences did you have for the API? The way the path was returned? Setting start and end points?
Stuff like that, yeah. I think in general the API for the code I found was fine, but it didn’t smell like me ;) That’s just my process; I actually cannot fully comprehend by reading alone, I need to get in and move stuff around.