Jump to content
  • entries
    657
  • comments
    2,692
  • views
    897,851

The Story of Stay Frosty 2, Part 11


SpiceWare

1,443 views

Next I worked on tracking down sources of static in the music. To help with that, I created a bunch of constants that were defined as AUDV0 or RAM. I then changed all the STA AUDV0 commands to STA M3VOS, STA M3VVB and STA M3VK in order to use those constants. By selectively defining those constants as AUDV0 or RAM I was able to track down sources of static. This image shows the constants defined so music is enabled for Vertical Blank but disabled for Kernel, Kernel Subroutines and Overscan.

blogentry-3056-0-54108500-1422722954_thumb.png

 

Using those, I was able to determine that static was occurring in Vertical Blank and Kernel. I narrowed the Vertical Blank static down to this section of code:

VerticalBlank:	ldx #2	stx WSYNC	stx VSYNC	stx VBLANK	lda #<AMPLITUDE	sta M3VTEST        ; <-- if this is set to AUDV0 there's static.  If it's set to RAM, no static	ldx #$2B	stx TIM64T 	ldx #110001 	stx CTRLPF	sta WSYNC	lda #<AMPLITUDE	sta M3VVB        ; <-- if this is set to AUDV0 the music sounds just fine.

I couldn't figure out why, so asked for help. batari came back with:

I think it's probably the DPC+ code occasionally taking too long. I think the problem is that the LDA # operand is fetched from flash during the current 6507 cycle. Fortunately, it looks like there's a way to fetch it during the previous cycle where there's more time. Here is a new DPC+.arm file to try.

So I dropped in the updated DPC+.arm (the DPC+ driver for the Harmony/Melody) and the static cleared up! This also fixed the static in the Kernel, which I hadn't looked into yet.

 

I revised object routines so they would use flicker to show up to 4 visible objects per zone. The prior routines only supported 2. Updated the elevator routines to support movement in the X and Y directions.

 

Replaced the Controller menu option's text with some placeholder graphics Nathan had done back on the 26th.

blogentry-3056-0-73944600-1422722982_thumb.jpg blogentry-3056-0-23563900-1422722974_thumb.jpg

 

liveinabin finished the label :thumbsup:

... THIS is the final label icon_smile.gif

 

StayFrostyII-3.jpg

Implemented Bonus Points, provided all the ice has been collected:
  • 1000 points for full-size Frosty
  • 50-550 for melted frosty
  • 0 if just a head remains
  • an additional 200 points if you have the carrot (even if just a head remains)

There was a flash of garbage graphics (left & right edge of display) that would show up on the very-first-game after powering on the Atari. I couldn't debug it in Stella, as it didn't support ARM code yet, so I made a video recording it so I could see it as a static image.

blogentry-3056-0-14484800-1422722970_thumb.jpg

 

Based on the 4 pixel wide, it had to be either the Nose(missile 1), or the Snowball (missile 0). Since the nose color is tied to the object and garbage data showed up over the ice chest, it had to be the snowball.

 

Turns out the routine that updates the snowball DPC+ register info wasn't being called until after the very first game screen frame was displayed.

blogentry-3056-0-25471000-1422722966_thumb.jpg

 

 

Added preliminary melt trail logic. It looked good, though created a new issue - since the melt trail was drawn with player0 collisions were occurring when they shouldn't - i.e. when making a mad dash thru a line of fireballs, each fireball would be hit twice instead of just once.

 

More questions - can the sky behind the mountains change color (to mimic sunsets and such)?

 

Also, can fireballs and ice blocks sit on and move with elevators? Can other objects?

 

And, since I'm 2600-less, how does the shifting work on wide levels? Do you get to the very edge of the first 40 pf pixels, then it scrolls left 16? Or do you get within a certain number of pixels from the edge, then it scrolls? I'm asking because I think it'd be cool to have the first wide level require a blind jump to make it scroll. icon_mrgreen.gif This would require falling off the bottom of the screen to equal death though.

 

Which brings up another level idea (alluded to before) - falling through to another level. I think to get to the end level of the game, it should require the player to have to figure out that they have to fall off the screen at a certain point to get to a subterranean level.

 

I'm thinking something like this for a progression:

 

5 1x width levels

5 2x width levels (10 levels worth of data)

5 3x width levels (15 levels worth of data)

1 2x width level "beneath" the last 3x level (2 levels worth of data)

 

If I read things right, that should fill up 32 levels.

 

As the game progresses, additional elements (carrot, ice chest, larger fireballs, double-jump, elevators, lava floors, bird) get added.

 

The first 2x wide level would require the blind jump, where it would appear that after all the ice was collected, there was nowhere to go except off the bottom of the screen, unless you took a flying leap off of a platform near the top of the screen. Then the screen would scroll, revealing the rest of the level.

 

Similarly, the same sort of thing would happen with the first 3x level, and the last 3x level, leading underground.

There's kernel time for color changes. ROM space, I dunno. I suspect this would be one of the last things added, provided there's space.

 

Except for Frosty, nothing can sit on the elevator.

 

My current goals are to:

 

1) free up some more ROM

2) finish the melt trail

3) make the sun hide behind the mountains

4) levels (main issue is the calls to the movement routines which will use up ARM ROM space).

 

For the levels I'm currently assuming 16 unique platform layouts, done as 32 levels by using each layout twice and varying the objects and level specific events (platform movement, lava, etc) between each use of a layout. If we have enough space we can then un-duplicate some of the layouts.

 

Bird movement routines aren't in place - the issue is the existing object routines don't support changing the Y position, just the X. I might eliminate the Y up/down idea and just put blank lines in the graphics below the bird to make him look like he's flying. I can then use the existing fireball left/right movement to change the bird's position.

 

Just saw you updated your post - I'm heading out to meet friends for lunch, will review & comment when I return.

I'll come up with schemes for both cases then.

 

 

So we can't do the trick from SF1 where we cause a platform to float by removing something from it?

 

 

Enjoy! I'm going to need to grab something to eat sooner or later here.

In regards to objects & elevators - the platforms can still move up/down, so we can still do "eliminate object to trigger moving platform" like in SF1.

 

Screen shifting is triggered when you hit somewhere from 1/4th to 1/3rd the distance from the edge of the display. Might be able to lock it - would have to see what the overhead would be.

 

For the falling thru I was thinking that down-levels would be more like bonus areas. They would only be accessible after you'd put out all the fire - if the exit arrow is showing you can drop down to it, else falling off the bottom would cause death. An easy to do object for bonus points would be presents - use the same graphic for all presents (bow in the 1st color zone, box in the 2nd color zone) but with different color combos - each worth a different point value. If level 10 had a down-level, the down-level would be #11 while the normal exit would take you to level 12. That would give the players a clue, if they're observant enough, that something was going on, and also mean we don't have to deal with trying to fudge the displayed level number.

 

The 5x1 + 5x2 + 5x3 +1x2 = 32 levels isn't quite right - the width of all the levels could exceed 32 levels, just there can only be 32 distinct levels. A level is defined by a combination of platform layout + the elevators & object layout + level specific ARM calls for movement (objects, platforms, etc).

 

Was thinking along the same lines for game progression, but had planned on double-jump being available from the start. Else we need something to "unlock it", plus the additional overhead of turning double-jump on & off.

 

Had some excellent Tex-Mex then stopped at Rice Epicurean to picked up some See's Candies to send in the b-day/xmas shipment to my brother's (2 of my nephews have December bdays). See's only sells pre-packs via holiday kiosks in Texas, but Rice made an arrangement with them to sell it year round. Besides the pre-packs, they have select-your-own-mix.

 

Anyhow back to trying to free up more space.

cd-w spun off a new topic looking into the use of an EEPROM. The EEPROM is not directly addressable via the ARM, instead data must be read from the EEPROM and stored in RAM in order to be used. While this wouldn't be ideal for code, it lends itself well to level data. He wrote an EEPROM Loader using the CodeSourcery ARM toolchain. We ended up not using an EEPROM, but the toolchain will be an important element in Part 12.

 

Implemented distinct sound-effects for carrot, bird, full-health, present, and throwing a snowball. Added masking for the celestial object, the sun now hides behind the mountains. Fixed the Horizon kernel, it had some minor issues which turned up when I implemented the sun masking. I looked into changing the color behind the mountain. There was time for it, but only mid-scanline which wouldn't look good, along the lines of Air Sea Battle:

blogentry-3056-0-20280100-1422722949_thumb.png

 

Added ARM logic for end-of-game Boss. At this point 448 bytes were available for additional ARM code. Still to do in the ARM were revised melt trail code, level specific calls and bird movement logic.

  • Level 4 tests object flicker & elevators. Interesting bit about the elevator, as seen by the one in the top-left area, the elevator can only be drawn above the ice so it disappears when it drops below the topmost ice position. The landing logic doesn't require it to be drawn so you can still land on it. The left/right collision bounce off only occurs if the elevator is drawn, so a low elevator could be used as an invisible step to reach higher positions. This is the first version of what would eventually become level 3 in the final game.
  • Level 5 tests what happens with more than 4 visible objects in a zone - only first 4 objects are shown, the others become visible as the prior objects are collected/extinguished.
  • Level 7 was used to test the bonus points.
  • level 8 - test of blocking fireball behind an elevator
  • Level 9 - after putting out the fire drop down to enter level 10, the Present Room. If exiting to the right, you'll skip to level 11.
  • Level 10 - initial version of the Present Room.
  • Level 32 - early version of the boss level. At this point touching the boss would instantly vaporize the snowman.

Boss spoiler:

 

 

The boss was created by using the masking RAM to triple the fireball's height

blogentry-3056-0-35869600-1422722960_thumb.jpg

 

The boss was well received :D

 

 

 

ROMs

sf2 20101128_NTSC.bin

sf2 20101128_PAL.bin

 

Source

SF2_20101128.zip

 

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

 

Blog entry covers November 17 - 28, 2010

2 Comments


Recommended Comments

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...