Jitter
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.
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
Menu GraphicsThe 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.
Nathan posted the Logo and Controller Selection menu graphics.
We all thought the graphics looked good, though I wasn't sure the logo could be done
But I tried to implement it anyway. It didn't work as the color change occurred too soon, making the whole row redGraphics 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.
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
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
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 the use of VBLANK and missiles could be promising, so did some changes and was happy with the resultsI 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.
so I finished updating the color table
It looked good on a real Atari,
provided the brightness and contrast weren't misadjusted.
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
Which is how the time of day progression came to be.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...
Twilight:
Dusk:
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):
Mid-day:
Afternoon:
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.
Level ideas
Also in the reply were a bunch of level ideas. I wrapped the boss-level ideas behind spoiler tags.
In there you can see the beginnings of levelsSome 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.
- 7 and 23, the Christmas tree
- 9, the tightrope
- 10, the blind jump
Updated Graphics
The new carrot and ice chest looked much better than my placeholder 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:
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
ROMs
Source
NOTE: While the ROMs work on the Harmony, they do not work in Stella.
Blog entry covers December 3 - 4, 2010
0 Comments
Recommended Comments
There are no comments to display.