Entry posted by SpiceWare
1,441 views
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:
- 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.
- 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.
- 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
Chris
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:
You know, that's probably a big part of it too - I feel... drained.The last thing we want to do though is have Darrell get burned out
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
ROMs
Source
(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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
7 Comments
Recommended Comments