WIP, gameplay complete

supercat
Dec 14 2005 1:42 AM

WOW. That's a 2600?

The game does seem exceptionally hard, and I can't figure out any way to resume after dying (is there any?) Also, someimes a wide pink bar appears over my character when digging (probably a sprite artifact).

Still, pretty darned impressive.

Report

Cybergoth
Dec 14 2005 3:47 AM

Hi there!

Rats! Interesting stuff like that always shows up when I'm at work...

Greetings,
Manuel

Report

EricBall
Dec 14 2005 5:58 AM

supercat, on Wed Dec 14, 2005 2:42 AM, said:

The game does seem exceptionally hard, and I can't figure out any way to resume after dying (is there any?) Also, someimes a wide pink bar appears over my character when digging (probably a sprite artifact).

Sorry, currently no way to restart except to reload the game. Probably shoulda put in the RESET logic. I'll see whether I can bang something quick out. Probably won't be pretty. Hmm...

Pink bar? That's weird. Can you give me some more details?

Report

vdub_bobby
Dec 14 2005 11:52 AM

EricBall, on Wed Dec 14, 2005 3:58 AM, said:

supercat, on Wed Dec 14, 2005 2:42 AM, said:

The game does seem exceptionally hard, and I can't figure out any way to resume after dying (is there any?) Also, someimes a wide pink bar appears over my character when digging (probably a sprite artifact).

Sorry, currently no way to restart except to reload the game. Probably shoulda put in the RESET logic. I'll see whether I can bang something quick out. Probably won't be pretty. Hmm...

Pink bar? That's weird. Can you give me some more details?

I was going to attach a screenshot, but you can't attach things to comments.

So I'll PM it to you. It shows up on only some of the animation frames and seems to happen towards the middle of the screen, not near the top - maybe it has to do with how many sprites are in a vertical band?

Also, only when digging to the right.

EDIT: I just played the binary a little more; it looks really good!

A few comments:
My preference would be for everything to move faster. It runs a little slow for my taste.
Relatedly, the holes fill in too fast, I think - it is darn near impossible (it is possible, right?) to get the gold that requires you to dig a big hole, jump in the hole, then dig another hole, then fall through that hole to get the gold.

Still, a lot of fun

Report

EricBall
Dec 14 2005 3:19 PM

I can't easily change the speed of movement. The player moves 1 pixel every 1/10 second. This is to make the PAL version (yes, there will be a PAL version) run at exactly the same speed.

I can, however, change how long the holes are open for. (Changing how quickly they empty/fill would be a little trickier.) But one hint for digging is once the hole starts you don't need to stick around....

I think I know what's causing the pink bar. It looks like it's an unintentional SC write, hopefully only part of the blit initialization. I'll have to walk through the code and see if it's required.

I think I have an idea for scoring, but I'll wait a while to post a new blog to make sure everyone sees this entry.

Oh, I tried to quickly add in some code to check the RESET button, but ran out of space in the first 2K bank. Ugh.

Report

vdub_bobby
Dec 14 2005 3:34 PM

EricBall, on Wed Dec 14, 2005 1:19 PM, said:

I can't easily change the speed of movement. The player moves 1 pixel every 1/10 second. This is to make the PAL version (yes, there will be a PAL version) run at exactly the same speed.

Two responses to that:
1. Thomas J had a great suggestion for the PAL conversion of Reindeer Rescue - have the NTSC version run at 270 scanlines per frame and the PAL version run at 300 spf - then the speed difference between the two is closer to ~11% rather than ~20%

2. You have a ton of RAM when you use the SC, why not use fractional math to track positions?

IMO being able to finetune the gameplay is more important than having the NTSC and PAL run at exactly the same speed. Use fractional math and then you can increase the speed as players move farther into the game or have 2+ difficulty settings, as well as please nitpicky impatient folks like me.

Report

supercat
Dec 14 2005 5:45 PM

vdub_bobby, on Wed Dec 14, 2005 4:34 PM, said:

1. Thomas J had a great suggestion for the PAL conversion of Reindeer Rescue - have the NTSC version run at 270 scanlines per frame and the PAL version run at 300 spf - then the speed difference between the two is closer to ~11% rather than ~20%

I don't like that idea; my 1990's television set couldn't manage a stable display with Karate, and that was only 269 lines. Some new LCD sets are picky as well.

Report

vdub_bobby
Dec 14 2005 6:20 PM

supercat, on Wed Dec 14, 2005 3:45 PM, said:

vdub_bobby, on Wed Dec 14, 2005 4:34 PM, said:

1. Thomas J had a great suggestion for the PAL conversion of Reindeer Rescue - have the NTSC version run at 270 scanlines per frame and the PAL version run at 300 spf - then the speed difference between the two is closer to ~11% rather than ~20%

I don't like that idea; my 1990's television set couldn't manage a stable display with Karate, and that was only 269 lines. Some new LCD sets are picky as well.

Thomas said that Thrust+ and Jammed both use those numbers and nobody has complained yet.

Thrust+ certainly worked on my 1990s TV when I played it with a CC1.

Report

supercat
Dec 14 2005 6:54 PM

vdub_bobby, on Wed Dec 14, 2005 7:20 PM, said:

Thomas said that Thrust+ and Jammed both use those numbers and nobody has complained yet.

Thrust+ certainly worked on my 1990s TV when I played it with a CC1.

Thrust+ Platinum clocks in at 262 according to Z26. Were earlier versions more?

Report

vdub_bobby
Dec 14 2005 6:56 PM

supercat, on Wed Dec 14, 2005 4:54 PM, said:

vdub_bobby, on Wed Dec 14, 2005 7:20 PM, said:

Thomas said that Thrust+ and Jammed both use those numbers and nobody has complained yet.

Thrust+ certainly worked on my 1990s TV when I played it with a CC1.

Thrust+ Platinum clocks in at 262 according to Z26. Were earlier versions more?

I dunno. I never checked. He must have been referring to an earlier version.

Report

EricBall
Dec 14 2005 7:43 PM

I am using fractional positioning for the enemies, but I need to have the player move at a constant rate so I only have to check for player "on grid" every sixth frame (fifth for PAL). The player can also reverse direction at any time, which would play havoc with fractional positioning. (Can you say roundoff errors? Good, I knew you could.)

It all really boils down to is with the current method I only have to go through the full action logic (which is a lot of testing against the bitmap) for one sprite each frame.

Now, I don't want to say it's impossible. I've been proven wrong at least twice so far on this project alone. But right now there are some higher items on the list.

Oh, and the SC has tons of RAM. But as we've seen, it's a pain to write to. I'm also not tight on normal RAM yet.

Report

supercat
Dec 14 2005 8:45 PM

EricBall, on Wed Dec 14, 2005 8:43 PM, said:

I am using fractional positioning for the enemies, but I need to have the player move at a constant rate so I only have to check for player "on grid" every sixth frame (fifth for PAL). The player can also reverse direction at any time, which would play havoc with fractional positioning. (Can you say roundoff errors? Good, I knew you could.)

Instead of using fractional positioning as such, you could use fractional rate adjustment. Every frame (whether the player is actually moving or not) you do something like:

  sec
  lda movespeed
  adc movephase
  sta movephase
  bcc move_never_mind
  jmp handle_playermove
move_end:

If movespeed is 255, the player will be allowed to move on every frame. If zero, player moves once every 256th frame. To move on five frames out of six, use a value of 204. If it's necessary to support higher speeds (more than one move per frame), then you can do something like:

  lda movespeed
  asl
  bcs movehighspeed
  sec
  adc movephase
  sta movephase
  bcc move_end
jmoveonce:
  jmp player_move_once
movehighspeed:  
  adc movephase
  bcc jmoveonce
  jmp player_move_twice
move_end:

In this case, the value of movespeed is the number of moves per 128 frames, minus one. So a value of 192 would cause alternative frames to move once or twice.

Report

Thomas Jentzsch
Dec 15 2005 2:02 AM

EricBall, on Wed Dec 14, 2005 10:19 PM, said:

I can't easily change the speed of movement. The player moves 1 pixel every 1/10 second. This is to make the PAL version (yes, there will be a PAL version) run at exactly the same speed.

If you are already planing a PAL version, why don't you switch to fractional math?

Report

EricBall
Dec 15 2005 6:03 AM

Thomas Jentzsch, on Thu Dec 15, 2005 3:02 AM, said:

If you are already planing a PAL version, why don't you switch to fractional math?

Right now I can change to a PAL version without adding fractional math to player movement. The current code checks one sprite for "on grid" every frame, but has a dummy 6th sprite so it works out to 0.1s for a complete cycle through the sprites.

For PAL I'll remove that dummy so it's still 0.1s for a complete cycle through the sprites, tweak the fractional math used for enemy movement, dup 2 of the lines in the kernel (easy, just don't update the Y index), and fix the colors. Whew!

Though, thinking about it, it should be possible to add fractional math to player movement. I just have to work within the restrictions of keeping the 0.1s cycle. So right now a player moves 1 pixel every 0.1s; which means it takes 0.4s = 24 frames to move 4 pixels.

Now, to speed up player movement, I'd need to change that to 0.3s = 18 frames for 4 pixels, or 0.222 pixels per frame, or 56.889/256 pixels per frame (68.267/256 pixels per frame for PAL). The only trick then is to make sure player reversals don't cause problems.

And if the player is moving faster, the enemies can go back to non-fractional movement. (Although I think the speed difference will be more significant than it is now.)

Report

legeek
Dec 15 2005 8:29 AM

Cool!

I noticed that the player animation is reversed when running to the left (sort of like a moonwalk). I think the digging animation is starting on the wrong frame (it looks fine once looped) If it's starting on frame one, maybe it should start on frame two? Also, I think I need to rethink the climbing sprite as it doesn't match the others very well.

The speed and difficulty seem about right to me. I was able to clear the board on my 4th or 5th try. This has been a lot of fun seeing my little sprites in a 2600 game. Thanks!

Cheers,
Ben

Report

EricBall
Dec 15 2005 11:11 AM

legeek, on Thu Dec 15, 2005 9:29 AM, said:

I noticed that the player animation is reversed when running to the left (sort of like a moonwalk). I think the digging animation is starting on the wrong frame (it looks fine once looped) If it's starting on frame one, maybe it should start on frame two? Also, I think I need to rethink the climbing sprite as it doesn't match the others very well.

Whoops, didn't notice the moonwalk. It's a side-effect of the Xpos -> sprite mapping. Moving right is 0->1->2->3->0, while moving left is 0->3->2->1->0. I've done some quick label changes and it's okay now. I've also fixed the order of the digging animation so it starts with the shovel down. Plus I've taken care of the pink bar glitch. No reset or player movement speedup, sorry; that requires coding.

Updated binary (first post)