33 year old programming mystery solved

[Dmitry]

Ha, that title is ridiculous of course, but I am excited about making Nerm of Bemer respond to joystick input better.

 

And no, this is not a blatant promo for my upcoming game Frake.

Frake, the freshmaker.

© 2016, Dmitry

hehe, j/k

No, I'm excited because I theorized that the controls could be made more responsive, and it actually turned out that way. Winning!

So if you haven't heard the story... when my son and I were playing the Compute! magazine game "Worm of Bemer" we decided to do an assembly language version with much improved graphics...and we noted, the original game, while fun, was really laggy on the controls.

And when I dug into it, I noticed the original basic code read the stick position and then implemented it's delay loop.

Just switching it to do the delay loop first, then read the controls, then display the new snake position - fixes part of the lag.

But I also speculated, why have any game delay at all? In Nerm, the snake auto-advances at a set speed, getting faster as you go on. And you cannot reverse the snake, nor do you have to specify 'keep going' in the same direction. Control is only to take the snake at a 90 degree or 270 from your current vector.

So why not respond to a direction change immediately, as fast as your game loop will allow? Technically it grants you a move faster than your 'speed' setting allows, but a change of directio is not perceived as a speed up. I speculated it would only be perceived as being 'more responsive'.

Tested it today at lunch. Boom, works! OK, already long post, signing off....but because of ABBUC contest rules I won't be able to share Frake, but I think I will go ahead and patch Nerm and release it as an Altirra basic version. Altirra because it allows me to remove the old ML routine. It was supposed to showcase the power of basic, so I figure, make it pure basic, on a faster basic, and make the control changes - then it just needs all the other fixes...lol...ok gotta go, see ya

[snicklin]

For a few moments, I didn't have a clue what you were on about. Then it clicked.

 

I like your thinking, yes, this is a better way of handling your snake.

[Rybags]

I used to use tongs, but people would complain when I put them back in the salad bowl.

[Dmitry]

@snicklin. Yeah, its hard for me to explain. In frake, which is mostly assembly, I have it working, so I got excited.....BUT - I haven't gotten Frakes fine character animation done yet, but that's coming up soon, and this morning, I realized, that's going to be an issue now.

 

By switching out character sets, I planned to give the feeling of fine movement not only at the tail and head of the snake, but the entire body can appear to be moving, which is why I added the decorations - as shown in my snakes avatar - so say on the red snake with green stripes - those stripes would animate forward along the entire snake body, but I digress, the issue is at the snakes head.

 

The problem is on the first frame of the animation. So say you were moving up, and on the first frame the snake head is, by appearance, just a bit into the next tile. Then say the user turned right. And with this new scheme, you allow them to go right immediately, out of order. And you can't change the animation frame, because it's critical the two snakes stay on the same animation frame, otherwise you'd have glitchy collision detection.

So you do what you always do, you draw the new snake head, now one character over right and the character behind the snake head gets filled in. However its on first frame of animation, So what it looks like to the user is - I went just a little bit right, and but it jutted forward. Now that is only a problem of perception on the first frame. But it will happen plenty, so the game now will look glitchy.

 

Ugh, so I either give up the controls which really do feel better....or I give up fine animation.

 

Well, then there turns out to be another issue with fine animation too - its too slow. The machine displays at 1/60th of a second...if I moved one pixel (which is impossible for this screen mode, but lets say it could happen)...if I moved one pixel per 1/60th of a second, that's just plain slow for snake. Snake has to feel like a roller coaster about to go off the rails....that's its whole appeal. So, really, my limitation for this screen mode of 2 pixels movement at 1/60th of a second, isn't so bad, since the snake has to travel fast. However, I'd still have the jutting issue on turns that occur on the first frame, if out of order movement is allowed.

 

So, ultimately - I'm keeping the out of order movement, because I like it, and my finest movement will be half tile (4 pixel). That won't feel like its jutting so much - that's my theory, I'll know by next week hopefully.

 

Yeah, I'm rambling on about snakes again....lol, later

[snicklin]

I used to use tongs, but people would complain when I put them back in the salad bowl.

We don't want cheese in the bowl.