Jump to content
  • entries
  • comments
  • views

Minor revision



I'm not very familiar with Bosconian, so I've decided I best put in some time to get a better understanding of how it plays. I cut the cord a few years back and use a Mac mini to drive my TV. Besides DVR software for broadcast TV, I've installed MAME, Stella, and OpenEMU on it. I also have a couple PS3 controllers that are paired via bluetooth. Works quite well.


The current game logic for Draconian was mostly written back in 2014 and, for the most part, I was able to drop it into the new CDF sprite/missile routines with minor revisions. While doing so I noticed some things I didn't do very efficiently, as well as some early assumptions that have proven incorrect with my initial playtesting.


As such, besides play testing Bosconian, I'm doing some behind-the-scenes reworking of Draconian to reduce the program size as well as fix the incorrect assumptions.


In this build I've moved the 6507 menu routines from bank 5 into bank 6, which allowed me to shift 1K of ROM space into the ARM/Graphics/Digital Sample pool. Additionally, Nathan had me revise how the stations open & close - they're rather slick.


For Harmony or Stella (requires Stella 5.0.0-pre8 or newer)

  • Like 1


Recommended Comments

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.

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



  • Like 1
Link to comment

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.

Link to comment



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?



Link to comment

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.

Link to comment

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?



Link to comment

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:

        .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


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

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.

Link to comment

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



  • Like 1
Link to comment

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

                0x00000000000010d4      0x418 main.o
                0x00000000000010d4                MenuVerticalBlank
 .text.NewGame  0x00000000000014ec       0x68 main.o
                0x00000000000014ec                NewGame
                0x0000000000001724      0x21c main.o
                0x0000000000001724                SetGameDatastreams
                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.

Link to comment

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.

Link to comment

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



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