More Whoosh Hair

Waaayyyy back in August last year, I added a 'jump' sprite for when the player was jumping left or right (see diary entry here...).

It's always bothered me, however, that when the player jumped straight up and/or fell straight down, only the static 'standing still' sprite was displayed.  Well, I've spent some time today fixing that!  I've pixelled up a jump/fall sprite for both the boy and girl and added a tiny bit of code to check whether the player was jumping/falling (gravity is active or it isn't!) and if the gravity is active, the jump/fall sprite is displayed.

In practise, it looks a little like this; very simple, but quite effective I think...?

I've been intending to do this for a while, but have been concentrating on other things such as level design.  Now the jump/fall is done, I have now also fixed a slight movement issue whereby after a left/right jump, the walking animation didn't reset and the jump left/right sprite remained making it look as though the player was sliding everywhere.

If you're wondering why the sliding issue took so long to fix (it's been this way since August last year!), that's simple because after a joystick movement, the player movement routine checks what current sprite is being displayed and makes decisions on what sprites to display next based on that.  Since the jump up/fall down sprite has only just been done, now was the time to fix it!

I regard the control system in Chiller 2 quite simple, but it's still a bit of a maze of checks and conditions!  Please spare a thought and admire games with much more complex control systems!

Next diary entry...

FREEZE64 Christmas Demo

A few days ago, Vinny, who writes the really rather excellent C64 fanzine 'FREEZE64', messaged me on Twitter asking for a few screen grabs of Chiller 2 in action.  He is going to send an email out to his subscribers on Christmas Eve and will include some information about the game, along with said screen grabs.  He will also publish the URL of this blog to the "wider world".  Up to this point he is one of a very small, select group of trusted people who even know that this humble dev diary exists.

I should say at this point that Vinny has been very supportive "behind the scenes", offering lots of encouragement and interest.  Because of this support, I thought it might be a good idea to offer him an exclusive download as a thank you.

So currently, I'm stripping out all code pertaining to everything other than the title screen, level 1 and any display routines.  The result will be the first playable demo of Chiller 2.  I am limiting some things because I don't want to give too much away in this demo.  Thus, only a partial charset is included with the minimum number of sprites needed.  The music is a very early version of the main title screen music and amounts to about 10 seconds worth on a repeating loop.  If you play the demo and it drives you mad, tough!

As a bit of an afterthought, since this demo is an exclusive Xmas gift from FREEZE64 to it's subscribers and also riffing on the FREEZE title, I've decided to make the text in the demo white and various hues of blue, while adding settled snow and ice to the forest level.  I've also altered the "Chiller 2" sprites on the title screen to read "FREEZE64".  Why am I explaining this? Surely some images would be better!

Next diary entry...

Animating Chars

When I first designed the church interior layout for level 2, one of the little background features I added to "fill the gaps" was a flaming wall torch.  I say flaming, but originally as designed, the flame was static (see gif's in previous diary entry).

This has now been bugging me for a few weeks; nagging away in the back of my head somewhere has been a little voice muttering, "You want that torch animating really, don't you?".  Being new to 6510 coding, I didn't want to start bogging myself down with extras (feature creep?) but it REALLY has been annoying me that the flames don't move.  So today the investigation/research into character animation started.

And I wish I'd done it earlier because it turned out to be rather easy!  First, here is the code I came up with to "fan the flames" so to speak...

 ; background animations subroutine ---------------           
   
 process_bkgd_anims  
             
           ldy bkgd_timer           ; load up the bkgrd anim timer  
           iny                      ; increase it by '1'  
           cpy #$04                 ; is the timer equal to '4' yet?  
           bne bkgrd_anim_skip      ; no? don't update animation!  
                                    ; yes? better do some animation then!  
           ldx #$00                 ; zero x register  
 flame_ror  
           lda $2390,x              ; load mem location of the flame char  
           lsr  
           lsr  
           lsr  
           ror $2390,x              ; shift char to the right a pixel (bit)  
           ror $2390,x              ; and shift again 
           ror $2390,x              ; and again               
           inx  
           cpx #$08                 ; all 8 bytes done?  
           bne flame_ror            ; no? do the next byte then!
                                    ; yes?  
           ldy #$00                 ; load y register with '0'  
 bkgrd_anim_skip                    ; to reset bkgrd anim timer and...       
           sty bkgd_timer           ; store y register to bkgrd anim timer  
   
           rts                      ; return to main loop

The code above includes a timer (bkgd_timer) that slows the animation so it only executes once every 4 (TV / screen refresh) frames otherwise it animates rather too quick to be visible!  How does the rest of it work?

First, where is the flame in memory?  Well, when assembling my code, my character set is loaded to $2000 in memory.  My flame character is number "114" ($72) in the charset - the blue boxed char in the image above, also shown larger in the magnified section in the right hand side of the above image.  Each char is made of 8 bytes (8 rows, or bytes, of 8 pixels, or bits), so 114 x 8 = 912 ($390).  Therefore, my flame char should be at $2000 + $390 = $2390 in memory.

In the 6502 instruction set there are a few handy commands called LSR, ASL, ROL and ROR.  These basically allow you to shift bits of a byte left or right.  When it comes to character sets, this has the effect of "scrolling" a char block left or right 1 pixel, while "wrapping" around within itself.

This is something I'm still coming to terms with; being a graphics person originally, I still think of images (pixels) moving up, down, left, right and so on.  But as a coder, you need to thing of bits and bytes of memory moving around, which is what is really happening.

And it's as easy as that!  In my code you can see the starting memory location of the flame char being loaded, then the starting location is LSR'd / ROR'd 3 times to shift the char (memory) 3 pixels (bits) right.  This is done 8 times overall so each row (byte) of the char is shifted.  Why 3 times?  Well, that was just experimentation.  After pixelling my flame, the overall shape of it suggested that it should be "moved" 3 pixels right every 4 TV frames (screen draws/refreshes) to get the best "flickering" effect.  I did try other combinations, but the above worked best for my flame char.

And what does it look like?  Savour the animated gif below (disclaimer, the animation looks better than the gif suggests, honest!)...

Next diary entry...

Whoosh Hair

It didn't take long for the 'walking in the air' to get on my nerves - see the end of the previous diary entry here!

As a result, I spent an hour today pixelling a 'jump' left/right frame and then modifying my player movement routine to display the frame.  The result has been christened 'Whoosh Hair'!

I will be honest, I was inspired to pixel whoosh hair by a game I used to play on the Amiga called 'Kid Gloves 2', which made locks of the players hair 'stick up' when falling.

The jump now looks much better methinks - no silly mid-air walk!  Oh? What does it look like?  Something like this...

Next diary entry...