SpiceWare's Blog

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

Thanks, I've been referencing them for a while (at least since the arcade screenshots in the comments, possible even back in 2014)

 

Things I'm playing it to figure out are things not covered in there, or are different, such as:

 

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).

 

I-Type and P-Type ships sporadically attack during the level as lone ships (not in formations). The I-Type appear to be more aggressive. You can outrun the I-Type on early levels, but they get faster than you later on.

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

Nice find!

 

Interesting option on switch 1, can select a 1 player only mode where you get a bonus ship for 2 credits and starting with the 2nd player's start button - ie: you you start with 2*x + 1 number of ships where x is the number of ships per game as specified on switches 7 & 8.

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

There's a lot remaining.

 

• graphics aren't finished: the destroyed station pods, station shots, and all the explosions are currently being worked on, they'll all be changed in the next build that gets posted.
• all audio in the game is currently placeholders. iesposta's working on new samples and sound effects.
• none of the enemy gameplay logic has been written. The station shots and energy core routines in place now were just to work out how to do the graphics. Likewise for the enemy formation that just flies around in a circle

I appreciate the offer, but there's no way I'll have spare 4K bank. At the moment I have 7,294 free. Remaining Gameplay logic, sound effects, and samples are going to exceed that, so I'm already on the lookout for things to optimize - such as when I put the new destroyed pod graphics in place I rewrote that routine for a 24 byte savings.

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

Yep - DOOD. I plan to run the graphics through that once we've finalized them. It'll take some prep work though - currently my graphics are like this:

AsteroidA:
        .byte %00110000 ; 0
        .byte %00111010 ; 1
        .byte %01111111 ; 2
        .byte %01101111 ; 3
        .byte %11110101 ; 4
        .byte %01110101 ; 5
        .byte %10110010 ; 6
        .byte %11010110 ; 7
        .byte %11001000 ; 8
        .byte %01111100 ; 9
        .byte %00111000 ; 10
        .byte %00011000 ; 11
AsteroidAHeight = * - AsteroidA

AsteroidB:
...

---

And the height values are put in a table like this:

ImageHeights:
...
AsteroidID = * - ImageHeights
        .byte AsteroidAHeight
        .byte AsteroidBHeight
        .byte AsteroidCHeight
...

---

Before I can run that through DOOD I need to take the final heights and hard code them in the table, then remove all the height calculations from the image data.

 

Another thing I'll be looking into is the compression Thomas wrote for Stay Frosty 2. I think I'll be able to use that for the menu screen graphics (I bet the logo compresses quite well) and the level data.

 

Think it's time to start up a To Do list so I don't forget anything.

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

sure didn't, that could be handy! What I've been doing is looking at testarm.map:

...
 .text.MenuVerticalBlank
                0x00000000000010d4      0x418 main.o
                0x00000000000010d4                MenuVerticalBlank
 .text.NewGame  0x00000000000014ec       0x68 main.o
                0x00000000000014ec                NewGame
...
 .text.SetGameDatastreams
                0x0000000000001724      0x21c main.o
                0x0000000000001724                SetGameDatastreams
 .text.ShowCharacter
                0x0000000000001940       0x70 main.o
                0x0000000000001940                ShowCharacter 

---

And with a quick glance I see those two functions use 1K+ and 0.5K+ respectively. Redoing those two are already on my To Do list as I knew it wasn't very efficient. I did them that way initially because I kept changing which stream did what, so it was easier to code them up that way until I finalized the stream usage.

 

One thing I plan to try is bypass setPointer & setIncrement and just use QPTR[] and QINC[] directly.

I changed SetGameDatastreams to use a loop. Went from 540 bytes to 196 (152 for function + 44 for the short int data table).

 

Surprisingly enough, using QPTR[] and QINC[] directly did not save any additional ROM. As such, I left it as setPointer() and setIncrement() so they can worry about the bit shifting.

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

 

Chris

Yep - looks like you flagged all those 1 line functions as inline in defines_cdf.h