SpiceWare's Blog

Great progress (again) - looks like spy ships and e-type missiles are really the only things missing?

 

Chris

Thanks!

Not much left:

• spy ships & red alert
• e-type launch from station
• gameplay balance (difficulty ramp up)
• Delta Quadrant
• final sound effects
• space optimization
• final samples

For the Delta Quadrant I want to have user designed levels, so need to figure out how to set up a way for that to occur. I'll probably write a PHP program for that and put it up on my web site. Have the user type in # of stations, station X-Y locations, and the ship's starting location, then have the PHP program create a patched a ROM with that info. I won't need sound effects or samples in place for that, but will need the rest so foresee the level designer being done in August.

 

The space optimization will be a major undertaking as I'll need to make space for the final samples. At the moment I have just over 2K free (1K in bank 6, the rest in the ARM code space). The two test samples currently in place use 2.5K of space.

I'm a little annoyed with how the SECTOR display currently works as at the start of the round I want to see the radar to determine which way I need to go. From Rules of the Game:

• At the start of a round (or new ship) there's an opening tune played. After it concludes the phrase "Blast Off" is heard. When the phrase ends the Star Fighter will gradually ramp up to full speed

---

only the gradual ramp up to full speed is in place. I think what I'll end up doing at the start of a round (or new ship) is this:

• show SECTOR #
• play opening tune
• play sample
• show Score/Radar/Lives
• ship starts to move

or this:

• show SECTOR #
• play opening tune
• show Score/Radar/Lives
• play sample
• ship starts to move

The 2nd one looks good.

 

Don't forget to let us have time to see our final score at the end of the game. Because as it is now, when the game ends you're blown right into the title page/menu instantly.

The space optimization will be a major undertaking as I'll need to make space for the final samples. At the moment I have just over 2K free (1K in bank 6, the rest in the ARM code space). The two test samples currently in place use 2.5K of space.

 

Feel free to upload the source to the CDF thread and I'll see if there are any obvious ways to save space. I'm sure Thomas will also be able to find a lot of innovative ways to reduce the size.

 

Chris

Don't forget to let us have time to see our final score at the end of the game. Because as it is now, when the game ends you're blown right into the title page/menu instantly.

 

 

I've been thinking about not doing a demo mode in order to give more space to the samples. If I do that I'll show the last & high score on the title screen. They would get zeroed out if you changed any option, other than TV-TYPE, so as to prevent somebody from playing the KIDS level and claiming it was HARD.

I think you could save a lot of space by packing the level definitions into bytes. It looks like you use co-ordinates between 0 and 1023, but I suspect you don't need all that resolution? You could divide the coordinates by 4 to fit into a byte, and then multiply by 4 when you read the values? The HS and VS issue could be solved by having 2 lists, e.g: a level with 2 VS and 1 HS station:

 

 

typedef BYTE unsigned char;
const BYTE alpha_1[] =
{
    253/4, 504/4,   // ship starting X, Y location
    2, 1,           // station counts
    320/4, 255/4,   // station 1 X, Y location
    224/4, 320/4,   // station 2 X, Y location
    96/4, 576/4,    // station 3 X, Y location
};

 

Chris

That's one of the things I was looking at, though I was planning on station count followed by a bit pattern for station type as there's a max of 8 stations

 

Also the X values would be divide by 2 as their range is 0-511.

Cool - have you considered adding a random element to the levels, e.g. randomly adding an small offset to the coordinates, or flipping the station orientations, so they are not identical every time?

 

Chris

I've pondered on flipping station orientations when they're replayed on later levels.

 

Hadn't considered random offsets - some of the levels, like A-6, have stations that are next to each other. Those will need to be reviewed when trying the x/2 and y/4 to make sure they still work as expected.

The following magic will tell you which functions are using the most space:

 

arm-eabi-readelf -sW testarm.elf | awk '$4 == "FUNC" { print }' | sort -k 3 -n -r

 

Which shows the top 10 functions by size (3rd column is the size) are:

 

   326: 00000d99  1200 FUNC    GLOBAL DEFAULT    2 InitLevel
   274: 00001299   936 FUNC    GLOBAL DEFAULT    2 MenuVerticalBlank
   294: 00001c41   808 FUNC    GLOBAL DEFAULT    2 DrawSprite
   233: 00001f69    688 FUNC    GLOBAL DEFAULT    2 ProcessJoystick
   415: 000019ad   660 FUNC    GLOBAL DEFAULT    2 PrepScoreRadar
   206: 000034bd   636 FUNC    GLOBAL DEFAULT    2 MoveFormation
   375: 00003bd5   632 FUNC    GLOBAL DEFAULT    2 MissileCollisions
   324: 00002219   588 FUNC    GLOBAL DEFAULT    2 DrawMissile
   316: 00003e91   564 FUNC    GLOBAL DEFAULT    2 MoveEnemyShips
   392: 00003739   536 FUNC    GLOBAL DEFAULT    2 StationMissiles

InitLevel and MenuverticalBlank are taking almost 1KB each, so are probably good candidates for optimization.

 

Chris

That's much nicer than eyeballing the function sizes like I've been doing.

I'm wondering if it would be better to have the sprite data in C, rather than ASM. The problem with the ASM version is that the C compiler can't do anything to optimize all the references to the sprite data, and so a lot of the binary is just offsets into memory.

 

Instead of:

 

AsteroidA:
        .byte %00110000 ; 0
        .byte %00111010 ; 1
...
AsteroidAHeight = * - AsteroidA
 
AsteroidID = * - ImageHeights
        .byte AsteroidAHeight
        .byte AsteroidBHeight
        .byte AsteroidCHeight

 

You use:

 

typedef struct Asteroid {
  char height;
  char[] data];
} ASTEROID;
 
ASTEROID asteroids[3] = {{12, {18, ...}}, {{13, {18,...}}, {14, {20, ...}}};

 

This would require a lot of work and wouldn't necessarily result in a big saving.

 

Actually, that wouldn't let you overlap the data. I guess you'd actually need something like:

 

 

BYTE spriteData[] = { <all sprite data> };
 
typedef sprite {
  short start;
  char length;
} SPRITE;
 
SPRITE asteroids[3] = {{100, 12}, {112, 13}, {125, 14}};

 

And then we are back to offsets that can't be optimized ...

 

Chris

Sprite image data will eventually be run through Thomas' DOOD, which will save a bit of space. I need to hard code all the heights before I can do that.

I think you could save a lot of space by packing the level definitions into bytes.

Revised the level data to use unsigned char, instead of unsigned short int, for a 608 byte savings. I used 284 of them to allocate space for 16 Delta levels for next month's level design contest.

Back from vacation. Let me know if you need more space.

Hope you had fun!

 

Always need more space, especially when digital samples are involved! I have a couple more things to do to finish getting things ready for you, well let you know when I'm done. Can DOOD handle data like this:

Shift_Explosion_Player3:
        .byte HMOVE_0  | 0 ; 0
        .byte HMOVE_R7 | 7 ; 1
        .byte HMOVE_L7 | 0 ; 2

---

Or do I need to revise those to be

Shift_Explosion_Player3:
        .byte $00 ; HMOVE_0  | 0 ; 0
        .byte $97 ; HMOVE_R7 | 7 ; 1
        .byte $70 ; HMOVE_L7 | 0 ; 2