It's felt like time to work on another level design because I've been a bit tired of looking at the forest and the church levels for the last month. Since the first level was exterior and the second interior, I guess it makes sense for the next level to be exterior again? That wasn't planned at all, but that's how it seems to be panning out...
In the original "Chiller", there was a level called "The Ghetto" and I wanted to do a "call-back" to this, so I spent this morning starting the design for a level that I'm calling "The Apartments". Using the word ghetto these days would seem a little non-politically correct.
When I say starting the design, it ended up being an almost complete design for the level, save some modifications that will probably need to be made to platform spacings, mushroom locations and some other embellishments (once I've thought of them).
The original brief to myself (i.e. what I dreamt up 5 minutes before pixelling commenced) stated that the window ledges were to act as the platforms and there was to be a couple of different coloured buildings for contrast on screen. Drawing the the fence, brick and window chars took no time at all and I had a basic layout within half and hour. However, it did look a bit plain with an all black background, even with my star, moon and cloud chars drawn in.
Then I had a brainwave, well as about as wavy as my ageing brain gets these days. Make the sky a different colour to previous levels and since this game is supposed to be set at dusk/night, dark blue made sense. I copied and reverse some existing chars (clouds, stars) to set on the night sky and then, as another "call-back" to the games of yore, used black chars to pixel in some silhouette skyscrapers in the background. What old games inspired this? Think "Ocean Software" and "Robocop". Consider this level, therefore, my "love letter" to those Ocean games that gave me hours of pleasure as a young teen.
Here is the level as it exists at the moment in "ChillED", my screen editor.
My Grandson did give it an initial thumbs up when I showed him this afternoon and wanted to "play" it straight away, but I still need to export the screen and colour RAM data and add it to my level data "includes" file. And then code the level set-up. That will be another day.
On a side note, after giving the initial level 3 design the thumbs up, my Grandson asked to play a few games on my C64mini, so we transferred the latest build of game over as well for a quick test. Chiller 2 seems to be C64mini compatible so far as well! ;)
Next diary entry...
Saturday, 31 August 2019
Wednesday, 28 August 2019
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...
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...
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...
Tuesday, 6 August 2019
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...
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...
Monday, 5 August 2019
Jumping
A couple of weeks ago, I asked about people's preferences on Twitter (read here...) for joystick control in relation to 'jumping' a player character and the general consensus seems to be to use the fire button to jump.
Therefore from this day forth, the fire button will activate the jump function in Chiller 2!
After a bout of coding (I won't share the code here because it's so tied into the main control code, it would be too long!), the player can now jump! At present, no platforms are detected, but these will be coded up in the next few weeks.
The jump looks like this...
The only slight annoyance is that the sprite carries on the walking animation while in the air which to my mind looks rather silly, so I'll probably have to fix that next less my O.C.D. tendencies will play havoc...
Next diary entry...
Therefore from this day forth, the fire button will activate the jump function in Chiller 2!
After a bout of coding (I won't share the code here because it's so tied into the main control code, it would be too long!), the player can now jump! At present, no platforms are detected, but these will be coded up in the next few weeks.
The jump looks like this...
The only slight annoyance is that the sprite carries on the walking animation while in the air which to my mind looks rather silly, so I'll probably have to fix that next less my O.C.D. tendencies will play havoc...
Next diary entry...
Subscribe to:
Posts (Atom)






