Jump to content
  • entries
  • comments
  • views

The Story of Stay Frosty 2, Part 13





To help with the jitter problem supercat, batari, and cd-w rewrote the BitReversal in ARM assembly - it didn't help. I did some research and found a site(now gone) that compared the use of BitReversal and the lookup table - the function took less than twice the time of the table to use, so that wasn't the source of jitter. The ARM assembly was smaller than the C code though, so I left it in place.


To figure out what was going on, I made a recording of levels 27 and 32 to see if I could spot anything by analyzing the playback. Level 27 is a very busy level with all the platforms moving left/right, snowballs flying around, etc. but it didn't jitter at all. Level 32 wasn't nearly as busy, but it jittered while throwing snowballs. Both levels had plenty of time left in both Vertical Blank and Overscan. I couldn't figure out what was wrong and it was getting late, so I headed off to bed.


When I awoke the next morning, I had an idea on what was causing the jitter - sometimes it really does help to get away from a problem and let your subconscious ponder the issue :) Since there was plenty of time in VB and OS, I figured that somehow the new defeated boss message was getting displayed. There's a variable that sets the message color, if it's 0 the message doesn't show but for any other value the message is shown. If the message color was somehow set to 1, the routines would be triggered, but in TIA color palette a color of 1 is black so wouldn't be visible on the black screen.


To see what was going on I disabled the line that set the screen to black and recorded a round of level 32. As I suspected, the message was displayed; though scrambled because the players weren't correctly positioned to display a 48 pixel image.



message is showing


The screen shot told me exactly what was happening, and it was related to these two datastreams - one used when displaying the Score

ScoreDataStream:	.byte 0		; 0 = display score	ds 6		; low byte for score 	ds 1		; high byte for scoreMSGc:	.byte 0		; 0 = done, >0 = finished level 32 message color

and another used when displaying the Lives/Level:

LivesDataStream:		.byte 1		; holds 1 = display lives & level	ds 2		; low/high bytes for head 1	ds 2		; low/high bytes for head 2	ds 2		; low/high bytes for head 3;	ds 2		; color palette for heads -  removed, always the same	ds 2		; low bytes for level digits	ds 1		; high byte for level digits	.byte GREEN + 4	; color for digitsPFnose:	ds 1		; ARM dataFireDown:	.byte 0;

here's what I wrote about the solution


The one active(score or lives/level) is set to data fetcher 5, which the selected kernel uses to read the data it needs.


The new level 32 message kernel occurs immediately after the score/lives kernel, and it reads 1 additional byte from data fetcher 5 to get the message color. For the LivesDataStream there is not 1 additional byte, so it ends up reading the flag for "firebutton down" (used to prevent multiple snowballs from being launched with 1 press of the firebutton - I had that happen once at the edge of the screen and immediately when from full-size to just-a-head!)


The reason I didn't see it occur on level 27 is because the score kernel is activated any time you increase your score, and it only switches to the lives/level kernel if 2 seconds have passed w/out gaining another point. On the level 27 there's ice blocks everywhere, so you seldom see the lives/level kernel active.


The lives/level kernel is never selected on the "defeated boss" screen because the sprites wouldn't be positioned correctly for the message, which is I why I'd neglected to include a copy of the "message color" flag in the lives/level data stream.


To fix it I moved that data stream so it's right before a constant 0.

Menu Graphics


Nathan posted the Logo and Controller Selection menu graphics.






controller selection


We all thought the graphics looked good, though I wasn't sure the logo could be done


Graphics look good - Red 2, I dunno. I think the only possible chance is to invert the graphics and use the playfield to show the text so that there's only 1 color register to update instead of 2. However, the color change appears to be required right in the middle of the time-critical code that makes the 48 pixel graphic work. I know it could be made to work with flicker, but the space to store 2 title images may not be there.

But I tried to implement it anyway. It didn't work as the color change occurred too soon, making the whole row red

	lda #<DF1DATA		; 2 35  <--- color change	sta COLUPF		; 3 38  <--- color change	lda #<DF5DATA		; 2 40	sta GRP1		; 3 43 <--- time critical	stx GRP0		; 3 46 <--- time critical	sty GRP1		; 3 49 <--- time critical	sty GRP0		; 3 52 <--- time critical

too soon


or too late, making the whole row the first color

	lda #<DF5DATA		; 2 40	sta GRP1		; 3 43 <--- time critical	stx GRP0		; 3 46 <--- time critical	sty GRP1		; 3 49 <--- time critical	sty GRP0		; 3 52 <--- time critical	lda #<DF1DATA		; 2 35  <--- color change	sta COLUPF		; 3 38  <--- color change

too late


batari thought SCORE mode might work, but that wasn't possible because both players are black when using inverted graphics. batari then came back with

I thought I might be missing something.


Maybe this would work: set the playfield red and change the background color. Right after the critical section, hit VBLANK and hit it again beforehand. PF0=PF2=0. PF1=$FF. For the multicolored section, PF is copied, for the single-color, PF is reflected. I'm not sure if the timing will work or if I'm also missing something here as well. If the timing is a bit off, perhaps the missiles could be strategically placed at the left and right side of the graphic to hide late or early VBLANK hits.

I thought the use of VBLANK and missiles could be promising, so did some changes and was happy with the results



VBLANK and missiles


so I finished updating the color table



updated colors


It looked good on a real Atari,



real Atari


provided the brightness and contrast weren't misadjusted.



too bright


A year and a half later Omegamatrix would provide some inspiration, which led to the elimination of the use of VBLANK.


Nathan posted a large reply that I'm going to break up into three sections.



Time of Day


Here are some ideas I've been putting together. Not sure if they're all desirable/workable, but here they are for the sake of discussion.


Regarding the time changing...


I was thinking we'd start Frosty out as evening fell. So the first part of the game would play at night in relative cold, and would stay pretty-much frozen for the early levels...





Night (maybe two or three, with the moon in different locations):


Early morning:


Just before dawn:


Morning (now the sun comes out, and begins heating things up):






Evening/sunset (as the afternoon wore on, the sky would get bluer, and shift through reds/oranges/purples):


There would be enough levels so the game ended at the middle of the second day - during the hottest part of the day. Maybe we could even do something where the first day had a cloud that drifted lazily across, instead of a sun, so the sun had less effect early on, but much more pronounced later.


Which is how the time of day progression came to be.



Level ideas


Also in the reply were a bunch of level ideas. I wrapped the boss-level ideas behind spoiler tags.


Some level layout ideas (these aren't complete... just some concepts), all of these take advantage of the "bottomless" screen:

Christmas tree (or pyramid):


Wreath (or ferris wheel):


Jumping test - each platform requires a maximum-length single-jump. To exit at the top right, you have to jump over and down to the small platform, then hop up the right side.


Tightrope - requires precise jumping:



For the first 2x wide level, I thought it would be cool to require a blind jump. So you get to the right-most platform of the left half, and have nowhere to go, but to take a flying leap. When you do, then the screen scrolls over and you land safely. This would be their introduction to wider levels.





The penultimate boss battle - a 3x-wide level, where they have to hop from hot platforms to grab ice chests to put out a big boss (double-width, 2x high). To get the carrot though, you have to race out to the center of the level and grab it before the fireball gets to it. There wouldn't be enough ice to beat the boss, only enough to reduce him to a tiny fireball. The trick is that he follows you around, and you have to get all the way over to the right edge of the screen, and lure him into falling through the hole in the floor. But then, there's no way out of the level for you. The only way out is where the fireball went...



To the final ice cave boss battle! (Not sure that really looks like an ice-cave though... but I'll work on it.) There are a couple of red eyes peering out that follow you (like the sun). You have to zip across the hot platform to get the carrot and ice chests to put out the giant (quad-width, however high we can make him) fireball. But he follows you around, and camps out on top of the ice chests, so you have to periodically lure him away by going back to the other side of the screen, and then back to the ice chests:





I'm still working my way though the test levels. I've noticed some have pretty insane flickering, due to the amount of objects on screen. I think we'd be better off in general going with levels that required more puzzle solving, than sheer numbers of fireballs to put out.


Also, I think introducing double-jumping as an acquired ability would be a good thing, rather than giving it to the player right away.


Maybe a progression like:

  • "Classic" Stay Frosty levels - single jump, no carrot, no ice chests.
  • Add carrot for snowball throwing.
  • Add double-jumping. (Some sort of power-up? Or maybe a reward for getting through single-width levels. Maybe add "Double-jump added!" screen showing Frosty double-jumping? Maybe we could do similar intermissions showing the carrot, ice chest, bird?)
  • Add Evil Carrot Stealing Bird.
  • Add ice chest, and wider fireballs.
  • Boss fireballs.

In there you can see the beginnings of levels
  • 7 and 23, the Christmas tree
  • 9, the tightrope
  • 10, the blind jump

Updated Graphics


I've also revised Frosty, making his neck thicker and scarf longer, plus a couple of minor tweaks. I'll break these out into individual GIFs for you soon.



Here's the carrot:




And ice chest:




The new carrot and ice chest looked much better than my placeholder graphics.



Current Build


I'd started work on the bird movement routines, but the game started to crash. So I posted a new build in order to have a roll-back point. The crashing was most likely due to the bug in the ARM chip used in the Harmony/Melody, though we wouldn't figure that out until next year (August 2011).

  • Updated graphics: New Logo, controller, carrot and ice chest
  • Fixed screen jitter/jump problem
  • Fixed triplicate carrot nose thru the score when snowman falls off bottom of the screen

Current ROM free state, 1885 bytes:

ARM - $450 - 1104

Bank4 - 68 - 104

Bank5 - $1fe - 510

Display Data - $a7 -167



sf2 20101204_NTSC.bin

sf2 20101204_PAL.bin





NOTE: While the ROMs work on the Harmony, they do not work in Stella.


Blog entry covers December 3 - 4, 2010


Recommended Comments

There are no comments to display.

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.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...