1 decade ago
by Joncom
For navigating a very large map while developing, I've set my players run speed very high. But I've noticed it's not fast enough, and I can't seem to get it to go higher.
Whether players speed & maxVel values are ~1,000 or ~100,000 my player runs at the same speed (which is fast... but not as fast as I'd like).
I'm not sure but exceeding screen bounds may, larger map or not, result in velocity capping.
1 decade ago
by Joncom
I'm not really sure what you mean. Do you mean that the max velocity cannot exceed the screen width or height in pixels-per-second?
Yes. But it's just a hunch, and also the first place I'd check: a quick look at game.js and entity.js should confirm/infirm that.
1 decade ago
by Joncom
I had a look through both and didn't find much. In getNewVelocity() in entity.js I found this line which I wasn't quite sure about:
return vel.limit( -max, max );
I'm not quite sure what limit() does. I can't seem to find any documentation on it for JavaScript, or any definition of in the ImpactJS library.
limit is part of
ig.core. It clamps nums between min and max.
getNewVelocity's max argument is indeed entity's maxVel so that shouldn't be a problem. You can test it by calling the function directly with some very high vel and higher-still maxVel. It probably won't clamp.
Perhaps a collision-map trace issue then (as invoked from entity.update, post-getNewVelocity. If you do have a collision map, collision-map.trace could be clamping speeds to prevent checks for out of screen positions. Talking thru my hat maybe, but again worth a look. Sorry not much time today to be more helpful.
1 decade ago
by Joncom
Quote from alexandre
Perhaps a collision-map trace issue
Thanks for the responses! I don't think its a collision-map trace issue because I'm currently not even using a collision map at all (just so its easier to navigate a very large map quickly).
Here is some of my player.js code:
speed: 69,
runSpeed: (138*8),
walkSpeed: 69,
jumpSpeed: 69,
maxVel: { x: (138*8), y: (138*8) },
And here is some code that has the exact same result:
speed: 69,
runSpeed: (138*32),
walkSpeed: 69,
jumpSpeed: 69,
maxVel: { x: (138*32), y: (138*32) },
Some code showing the context in which you use the speed property will help. Are you using that to set accel.x' value?
run: function()
{
this.accel.x = runSpeed;
}
Something like that?
1 decade ago
by Joncom
Once a key-press event occurs and it is determined that no collisions prevent the player from moving, this function is called repeatedly until the player has travelled one full tile unit.
move: function()
// instructs impact to move player
// in the direction he's facing
{
switch(this.facing)
{
case 'left': this.vel.x = -this.speed; break;
case 'right': this.vel.x = +this.speed; break;
case 'up': this.vel.y = -this.speed; break;
case 'down': this.vel.y = +this.speed; break;
}
},
I don't deal with acceleration at all. Just static 'moving' or 'not moving' rates.
From here I just let Impact handle the movement of the entity. On each update I run a check to see if the entity has reached its destination, and if it has I set this.vel.x and y to 0 and stop calling move().
1 decade ago
by Joncom
I haven't been able to fix this issue, so I took some video to record the run-speeds with different ig.Timer.timeScales. What I found was that after a certain movement speed is reached, it cannot be surpassed, despite increasing timeScale or entity.speed.
I did 4 runs. Here are the results:
1st run, ig.Timer.timeScale = 4; ...took 2.26 seconds
2nd run, ig.Timer.timeScale = 8; ...took 3.01 seconds
2rd run, ig.Timer.timeScale = 16; ...took 2.25 seconds
4th run, ig.Timer.timeScale = 32; ...took 2.26 seconds
Here is the video:
http://youtu.be/Sy41r921tI0
It would seem that Impact is (somewhere) hard-coded
NOT to scroll faster than a certain speed.
Although it would be nice to move faster than this speed, I think I've spent enough time on this...
EDIT Hooo-boy, was I wrong!
It ended up being that since my game movement is 'grid based' and each movement is 'snapped' to the grid, the following was happening:
Player could move X distance (let's see across the entire map!), then his update function would say, "Hey, I've reach the next tile (or gone a little over).. time to snap to the grid." The player then proceeded to backtrack to the tile which was next to the original tile.
In other words, the fastest a player could move was 1 whole tile per update, which was still pretty fast, but definitely a noticeable cap.
This
Page 1 of 1
« first
« previous
next ›
last »