Made revisions to the double jump logic. Added level-specific routines such as the ability to move platforms. Started building PAL ROMs. After posting another test build, Nathan came up with some more ideas:

I'm going to try and sit down this evening and work out some ideas for the levels. Progression, types of puzzle elements to solve, that sort of thing.

 

I think there should be some goal to reach for the game. Maybe Frosty has to rescue someone (Santa? Holly? Chucky the Christmas Weasel?), or fight some huge boss (fireball that breaks into smaller ones? giant evil Santa? evil flying reindeer? a lava-octopus (see: Name That Game)? fruitcakes? AT-ATs?), or perhaps rescue someone from an evil boss (see also: Donkey Kong, but less blobby)? Maybe we could also have him collect items (besides carrots and ice chests) along the way. Every few levels, there could be a toy or something he has to collect to complete the game 100%. If he misses one, the player could still win, but wouldn't get as high of a score.

 

I think having some sort of mission to accomplish would make the game feel more complete.

which established additional elements of the game such as the presents to collect for bonus points and characters to rescue.

 

ROM space was already becoming an issue, only $F34 (3892 decimal) bytes were left:

------ $6ec bytes of ARM User Code left ------ $30e bytes of BANK 4 ROM left ------ $b5 bytes of BANK 5a ROM left ------ $73 bytes of BANK 5b ROM left ------ $6f bytes of BANK 5c ROM left ------ $fd bytes of Display Data ROM left ------ $29c bytes of Frequency Data left

cd-w supplied some tips for optimizing the C code:

 

 

 

 

Some space optimization tips for the ARM (which I learned while writing the Harmony C driver code):

1. Reduce the number of functions if possible - each function requires a prologue and epilogue. If you have a function that does not need this code, e.g. a main function that never returns, you can use __attribute__(naked).
   
2. Always use int (or unsigned int) if possible. Shorts and chars require lots of extra masking and shifting code.
   
3. Functions that only take a small number of parameters can be passed as registers, rather than requiring stack space and extra stack saving and restoring code.
   
4. -ffunction-sections (in the Makefile) is useful to see how the compiler translates functions to ARM code, as it puts each function is a separate section. However, you can get slightly smaller code without this option.
   
5. Use thumb-mode if possible (I believe you are already).
   
6. Some functions are better hand-coded in assembly if the compiler is doing a bad job of optimizing them. Also, some may be more efficient in ARM rather than THUMB, if you can make use of the barrel shifter and extra addressing modes.
   

I hope this helps - I was able to save a lot of space in the Harmony driver just by converting to the int type everywhere.

 

Chris

so I started implementing his suggestions. The first batch of changing variables to INT saved 640 bytes of ROM. It did use more RAM though, and additional variable changes resulted in odd behavior that was most likely due to the C variable storage colliding with the C stack. I've run into this problem a number of times while working on ARM based DPC+ games, such as this time while working on Frantic. Not being able to see the state of the Harmony/Melody RAM made it difficult to diagnose, so I eventually dived into Stella's source code and added a Cartridge RAM tab to the debugger screen. It first appeared in the Release Build of Stella 4.0.

 

batari implemented the IRQ driven music. I'd already ported cd-w's DPC Danube demo for the DPC+ Programming demo, so dropped it in so we could test the IRQ routines. It took a bit of time to get the music to work right, but we eventually got there.

 

 

liveinabin posted the first draft of the label, which everybody liked:

Right, I've been kicking around some ideas for the cover; primarily, what NOT to do. When I say the words 'platform game', I bet all of you can envisage the standard cover art: Protagonist(s) in smiley jumping (or failing to be cool) pose in foreground, enemies lined up behind. Bloody awful and done to death by Nintendo and everyone else.

 

So, since this game also functions as a Christmas card, of sorts, from AtariAge - I think a more general approach might be the one. So I submit this idea - we have our snowman and a flame in cosy seasonal fireside shot, with our hero slowly melting into a pool of water. I'm getting together a load of 1950s seasonal imagery for the color palette.

 

As for the logo, the same fonts as Stay Frosty 1, but I've found that a '2' looks a lot friendlier than a 'II' for the suffix. Speaking of suffixs (suffixes?), the 'Stay Frostier' tagline doesn't look anything like as Bruce Willis as I'd thought so shall we keep it? Also thinking of having the 2 in red with the same red bleeding into the blue of 'Frosty' to illustrate the build up of heat (might even thaw out the snow on that last 'y')

 

Anyway, I figured I'd post it here so you can all pitch in cheers!

 

At this point the game is fully playable, though only a handful of levels existed:

• 1 - test of bird stealing carrot. Bird is stationary and drawn with cheesy programmer graphics.
  
• 2 - pays homage to level 16 of Stay Frosty.
  
• 3 - Early version of level in final game. Use hidden elevator to obtain carrot. Level is 1.2x screen width to show that wide levels are not restricted to 2x, 3x, etc in width.
  
• 6 - variation on level 2
  
• 11 - Early version of level in final game, pays homage to level 32 of Stay Frosty.
  

Just walk across all other levels to exit them. Since the music just repeated Danube, it got to be annoying while testing; so, I added code for the Left Difficulty switch to control music playback: A = ON, B = OFF.

 

ROMs:

sf2 20101108_NTSC.bin

sf2 20101108_PAL.bin

 

Source:

SF2_20101108.zip

 

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

 

Blog entry covers November 1 - 8, 2010