Jump to content
  • entries
  • comments
  • views

The Story of Stay Frosty 2, Part 15



We clarified the issues with the snowman graphics, things like how many color palettes were needed - it used to be 3, but was now 4.


cd-w reviewed the C code looking for optimization opportunities. He didn't see any, but gave some overall suggestions:


OK, I can't see too many more obvious places for optimisations:

  1. Try folding functions that are only used once into the parent function. For example, Initialize(), OverScan(), VerticalBlank(), and OverScanmenu() could all be folded into main(). This should remove the function call/return stuff. The compiler may already be doing this, but it might require the functions to be marked static.
  2. The InitLevel function is the largest. For variables that are set to zero, you could arrange for them to be contiguous in memory and set them to zero with a loop.
  3. If you examine the MAP file, you can see the other large functions. It might be worth trying to rewrite some of these to make them more efficient:
    RefreshLevelWindow 0x230
    LevelSpecific 0x250
    SetFrostySprite 0x3F0
    HMOVEobject 0x3A8
    ShiftPlatforms 0x3E8
    ObjectCollisions 0x53C
    InitLevel 0x554



We again discussed adding ARM support to Stella as it would make testing a lot more convenient. batari brought up the idea of building a custom version of Stella that included the C code for SF2. Neither option was pursued at this time.


I ran into a bug and started to back track in the source code to figure out when it first appeared. Nathan and I discussed being a bit disappointed about the lack of playtesting, such as nobody finding that bug, as well as the lack of level design suggestions/feedback. We felt that others weren't that interested in the project. I'd actually been debating throwing in the towel on the project for the prior few weeks and the next day posted:

Anyway, after sleeping on it and considering that Christmas is in 14 days and we haven't even bothered to announce it yet, the towel has been thrown in.


and this:

One of my main concerns is what Nathan mentions here:

I'd really like to see the levels get the extra playtesting and polish this time around that they didn't get in the first game.

Play testing is quite important - the bug I noticed just before heading to bed on the 9th shows up in builds going back the few days I tested last night. Since nobody has time(or those that do don't have a Harmony), and I'm not willing to put out something w/out adequate playtest, I don't see any chance of a 2010 cart at this point.


Discussion that ensued showed that people were interested, just that real life was preventing them from spending much time on SF2. I eventually decided:


The last thing we want to do though is have Darrell get burned out

You know, that's probably a big part of it too - I feel... drained.


How about we reconvene on January 1st, with some additional Harmony owners on board for testing, and shoot for a February 1st release?


Further discussion resulted which decided that taking a break was a good idea, but striving for a specific release date was not.


Over the weekend I felt much more relaxed and decided to spend some time on Sunday playtesting. I eventually figured out how to consistently trigger the bug and was able to track it down. It's entails the boss, so this bit's behind the spoiler:




After chilling out on Saturday, I felt much more relaxed and did some play testing on Sunday. I figured out how to consistently trigger the bug and was able to determine it had been introduced on the 6th. I then found that Xcode has a nice file comparison tool called FileMerge (found in /Macintosh HD/Developer/Applications/Utilities/) that made it easy to track down what caused it.


Basically, the line of code added to "darken the boss" was put outside the if block instead of inside it. This resulted in the boss logic being run when any fireball was hit by a snowball, not just for the boss fireball.


It's amazing how dated that screenshot now looks.




While looking at the bug, I also noticed another space savings opportunity:

I also noticed a very simple change that resulted in a 72 byte saves in the ARM code. There are a number of places that used code like this:

queue[LEVEL_CONTROL_DATA + flag]

to reference the Level Control variables that are saved in the Display Data Bank (these are the flags that hold "platform 1 is currently moving left, fireball 2 is currently moving right, etc"). I added a global define gLevelCode and changed all the queue[LEVEL_CONTROL_DATA + ... ] to use gLevelCode[ ... ] instead, like this:

volatile unsigned char *gLevelControl=(unsigned char *)(0x40000C00 + LEVEL_CONTROL_DATA);  <-- global define    gLevelControl[flag]

The exact same change can be done for a number of other queue[] usages, such as those listed below, so there's lots of opportunity for ROM savings. (Does the DPC+ change in post 313 mean I get more globals, or just a bigger stack?).

queue[ICE_PLATFORM_DATA + x]queue[ELEVATOR_Y + x]queue[FB_DEBOUNCE + x]queue[VISIBLE_OBJECT + x]


I also posted one final build with the changes I was working on before the bug reared it's ugly head, as well as decided:

If I do any additional work on SF2 before the 1st I'll concentrate on ROM savings, so there won't be any more uploads before January.


The changes:

  • remainder of the updated Frosty images in place
  • extra Frosty color palette in place
  • mid-jump image now triggered just before top-of-arc.
  • present sound changed
  • full health(ice chest) sound changed

Current ROM free state, 634 bytes:

  • ARM - $130 - 304
  • Bank4 - 3f - 63
  • Bank5 - $5b - 91
  • Display Data - $b0 - 176


sf2 20101213_NTSC.bin

sf2 20101213_PAL.bin





(yes, the source is dated one day before the ROMs)


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


Blog entry covers December 9 - 13, 2010


Recommended Comments

The only thing I would change is the part where playing the music too loud causes all the stray dogs in a five block radius to encircle your house and run in a counterclockwise ring..


..just kidding, the game is a radical feat!!

Share this comment

Link to comment

LOL. Thanks!


Been busy with RL of late, was out of town last weekend and will have a house full of company this weekend. I hope to resume my blog updates next week.

Share this comment

Link to comment

The hardware in the Encore is slightly different than the Harmony and the original DPC+ driver doesn't work on it. This even affects some released games.


The games can be fixed using a hex editor, there's just a few bytes that need to be changed. We're getting ready to head out to the art car parade so I don't have time to track those instructions down for you. I think they were posted in one of the Encore topics in the Harmony forum.

Share this comment

Link to comment

Batari mentions the issue in this reply, and posted the fix in this reply:


To fix any errant DPC+ games, use a hex editor to change the bytes at offset 0x200 from 00 A0 85 to 01 A0 C5. Then they will load on Encore (or any other Harmony version) with no problem.

He also mentions that he's going to work on an updated BIOS for the Encore that will recognize and fix the bug automatically, though I don't know if that's happened yet.

Share this comment

Link to comment

Hmm, just tried forcing stella and it kinda fixes the menu - it almost looks normal, but there's no snowman and I can't select any options.

Share this comment

Link to comment
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...