tperry2x wrote: ↑Sun Feb 18, 2024 8:58 pm
I see what you mean, it's very juddery, for want of a better phrase.
It's the way it's scripted. Repeat loops , loop via key downs, and move statements are not
the way.
First added globals, you can't expect clean/smooth
anything inside of key down events so you have to simply set some values in the keydown and allow the program to proceed and time things in another way.
global bAnimating -- are we animating? Then don't progress the game turns
global playerAnimFrame --- the current frame of animation
global animDelay --- only update animation frames every so many increments of the delay
global animDelayConstant --- the number of increments to wait before changing anim frame
global playerDirection --- either positive or negative 1
global lastPlayerDirection --- are we still going the way we were going?
global lastKeyDown --- is the key that was pressed still held?
global gCurrentTurn --- current turn of the game, just for keeping track that game.loop ran complete
global playerSpeed --- this would modify the pixels per turn the player could move, if they could
openCard now calls
init.App which calls
init.Globals and
init.UI and finally
game.validatePlaying
always gotta init the globals
The reset button stuff was moved to
init.UI
when you have a loop (ie, send Handler to object in x milliseconds) you always need a way to escape the routine, else you can get runaway program.
game.validatePlaying makes sure the mouseloc is within the window and "browse tool" is chosen.
The mouse thing could be removed and a global for "bPlaying" could be added to toggle via escape key or a screen button, whatever. Tracking the mouse is just an easy way to escape the program while programming it. Even when 15,000 'send in x milliseconds' messages are piled up in the buffer you can put the mouse outside the window, go get coffee any usually have your program done freaking out and waiting for you like an docile obedient monster.
Added a game loop and a sub loop for animation, ie, game doesn't continue until animation is complete.
One 9 frame animation of the wolf is ...uh 9 pixels of motion on the landscape and 27 pixels for the sky.
I had the wolf running around but commented that out (with one line) as it's not necessary , wolf runs, camera is centered on wolf, scenery changes around wolf, like in reality.
Wolf stops moving only when turning, first key press after turn = turn and stop, then it picks up again.
There is still an issue with ramping of speed, like you press key to go, you go real slow, hold down the key and the backlog of messages gets pushed through. It's strange behavior. Oh right, so currently once you start moving, unless you stop by turning followed by key up then you keep running,
weeeee. That's one of the reasons I froze the wolf to the center. Wanted to keep testing the animation speed without having to keypress.
Anyway, loops are the key. Note in this stack the loop goes from:
init.app to
game.validatePlaying to
to
game.Continue to
to
game.Loop which
..increments the
animDelay until that variable hits its limit per frame
....
turn.animate ---
....
turn.updatePositions
.........finally back to
game.Validate and round and round it goes.
If you just ping pong between two handlers you get a 'can't find Handler' error. if you send in x seconds between two handlers you can quickly run into recursion limit. Intermediary handler seems to handle this as long as one of the handlers is using a send in x milliseconds delay, else Error- Can't Find Handler!
