Jump to content
  • entries
    298
  • comments
    862
  • views
    243,464

WIP, gameplay complete

Sign in to follow this  
Guest

771 views

The basic gameplay is now complete. Press the button and push the joystick right or left to dig. Comments, opinions & suggestions welcome.I also managed to trip myself up quite nicely as I was adding the new sprites. Basically I forgot that any access to $1FF8 aka $FFF8 on a SuperCharger will trigger a bankswitch. And I stuck the sprite data after the playfield bitmaps, which just happened to be on page $1F00. So the game would work quite nicely until it did the right blit and accessed $1FF8. Kaboom! This is one place where z26's trace log somes in handy since I had no idea what had happened. So I let z26 log until the game dies, then had a look at the last few frames in the trace file to try and figure out where things went amok. At first, I thought it was a rogue SC write which had trashed the code somehow. But later the real reason hit me.I was going to simply re-arrange the code & data to move the playfield bitmaps. But then I remembered my gold blit routine relies on the playfield bitmaps being at the end of the address space to simplify one of the loop tests. Sigh. So I've just temporarily shifted the offending spite to a free chunk of ROM. (I've just about used all 4K, although I'd always planned to use all 6K.)I think my next target is to rework the kernel to use a reflected playfield and do some other stuff to stabilize the level data format.(2005/12/15 - fixed some minor sprite glitches)

Sign in to follow this  


18 Comments


Recommended Comments

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.

Share this comment


Link to comment
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?

Share this comment


Link to comment
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 ;) :)

Share this comment


Link to comment

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.

Share this comment


Link to comment
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. :)

Share this comment


Link to comment
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.

Share this comment


Link to comment
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.

Share this comment


Link to comment
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?

Share this comment


Link to comment
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.

Share this comment


Link to comment

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.

Share this comment


Link to comment
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.

Share this comment


Link to comment
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?

Share this comment


Link to comment
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.)

Share this comment


Link to comment

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

Share this comment


Link to comment
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)

Share this comment


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

Cart owners get 8 extra scanlines for free. :D

:)

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...