[CDF Finalized]

I'm writing a programming guide for CDF, but (as always) it may take some time for me to complete.

 

Chris

[E-Types launched]

Have you optimised the sprites with D00d yet - I'm interested to see how much space that saves?

[E-Types launched]

Dropping the attract mode to fit in more samples seems like a good compromise to me.

 

Chris

[new samples, a new tune,]

The new sample sounds awesome - I hope you will have enough space for the rest?

Chris

[Disperse Revision]

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

[Disperse Revision]

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

[Disperse Revision]

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

[Disperse Revision]

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

[Disperse Revision]

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

[Disperse Revision]

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

 

Chris

[Battlestations]

This is coming along very quickly! Not sure how you find the time

 

Afraid I haven't had a chance to look at the 7800 CDF issue again - maybe next weekend.

 

Chris

[Station revisions]

Haven't tried it, but these mame invincibility cheats for bosconian could be useful for determining firing behaviours?

http://www.mamecheat.co.uk/forums/viewtopic.php?t=324

 

Chris

[Rules of the Game]

Might be some useful info here - http://www.vizzed.com/boards/thread.php?id=80884

[it exploded]

This is coming along great now - looking forward to hearing the speech..

 

Chris

[Minor revision]

Cool - I'm guessing the compiler was inlining the setPointer and setIncrement functions already.

 

Chris

[Minor revision]

You probably know this already, but the following command is very useful for figuring out where the space is going in your code:

 

arm-eabi-objdump -D main/bin/testarm.elf

Even if you don't understand the ARM/Thumb parts, the dissassembly give you a good idea of the length of each function. I can see that MenuVerticalBlank and SetGameDatastreams are taking up a lot of space. It seems that the compiler is not smart enough to optimize all those setPointer and setIncrement calls. You could probably save a lot of space by using loops, e.g:

 

for (x=0; x<12; ++x) {
  setPointer(DS_LOGO_A+x, MAIN_MENU_GRAPHICS_RAM + x*LOGO_HEIGHT + ((x % 2 ==0) ? offsetA : offsetB));
}

The setPointer seems to be particularly bad, as a separate 4-byte pointer is being stored every time. I suspect that using an offset from a fixed address may work better ...

 

Chris

[Minor revision]

No problem - the in-game speech is going to blow people away!

 

Thomas has a cool graphics overlapping tool if that would be useful to save ROM?

 

Chris

[Minor revision]

Interesting!

 

What is left to do in the game now? I guess audio/speech still needs some work?

 

If you have a spare 4K bank then I could have a look at getting high score saving working? (The flash memory can only be written in 4K chunks so a whole bank is needed). Though it might be better to use the space for more speech data?

 

Chris

[Minor revision]

On level 1 station's are always open, levels 2 & 3 the stations open/close, level 4 the stations start to launch missiles (the guide says this happens on level 3, perhaps there's a dip switch in the arcade game which controls that).

 

The Bosconian arcade manual references DIP switches to control the difficulty (Rank A,B,C, Auto), but doesn't explicitly define what effect these settings have.

 

Chris

[Minor revision]

This guide might be useful: https://strategywiki.org/wiki/Bosconian/How_to_play

[Starfield returns, new station cores]

That was a lot of effort for the cores, but they look awesome!

[Sprite Engine rebooted]

Nice work - is this the 4th or 5th rewrite Hopefully you'll be able to reuse the code in another game as it is quite generic?

 

Chris

[game screen progress]

Have you updated all the kernels to the new CDF/FastJmp method?

 

Chris

[Why didn't the Game Gear win the handheld wars?]

Back in the day people wanted a Gameboy because it was small, battery life was far better, it was cheaper, and it had better games. Those advantages were enough that people didn't care about the color.

 

Chris

[resizable ball]

Ah - I missed the RESxx, but it will still work before the HMP1 with a bit of padding.

 

On the VCS - if you don't rewrite the kernel at least 10 times then you aren't trying hard enough . I lost count of the rewrites for star castle!

 

Chris