Jump to content
IGNORED

I don't have enough ROM space for my DPC+ 32k game. What are my options?


wallaby
 Share

Recommended Posts

I fell over the edge, so to speak, when I realized I needed to write an audio driver. Leaving sounds to the end is normal for me, but I didn't anticipate how much space I would use calling the sound sub program for each sound.

 

I still have plenty of graphics bank space, but I tried running code from there and it doesn't work.

 

I don't suppose there is a 64k DPC+ option? :D

 

I might have to cull some features.

Link to comment
Share on other sites

How much space are you over by? I'd at least try to make it all fit into 32k before you start culling features. I bet if you post the source and ask for help, someone on here might be able to advise you on how to optimize for ROM space.

 

You should start off thinking big. Look for an algorithm that can be changed to unlock a large chunk of space instead of trying to save a few bytes here or there.

 

List out each component and its subcomponents and estimate how big each one is. The biggest ones are the most likely to have an opportunity for meaningful space savings.

 

If you have spare CPU cycles you should keep an eye out for algorithms that can be swapped for slower/smaller ones.

  • Like 2
Link to comment
Share on other sites

I fell over the edge, so to speak, when I realized I needed to write an audio driver. Leaving sounds to the end is normal for me, but I didn't anticipate how much space I would use calling the sound sub program for each sound.

 

I still have plenty of graphics bank space, but I tried running code from there and it doesn't work.

 

I don't suppose there is a 64k DPC+ option? :D

 

I might have to cull some features.

 

PM me the source and I'll comment changes I make so you can learn.

Also the data that the Visual bB music program creates can be hand optimized unless you want tons of "instrument" Channel changes and many Volume changes. If you have a simple sound effect you can set AUDC0=12: AUDV0=8 then the data table is just all note values.

Link to comment
Share on other sites

 

 

How much space are you over by? I'd at least try to make it all fit into 32k before you start culling features.

 

Not sure how much yet. Since this is my first Atari program I don't really know how much any feature costs in ROM size yet. I'm trying to fit the entire engine in 32k, and I think I'll be able to. It just won't leave any space for making the game any fun. Definitely no real CPU cycles to spare. I'm already alternating code per frame. I'll start by finishing the whole game engine. I'll only have a few hundred bytes left over assuming I'm successful.

 

 

 

PM me the source and I'll comment changes I make so you can learn.

 

Thanks for the offer. The program is over 5,000 lines at the moment. I'm already putting just about any re-used code in sub-programs, but even calling them is expensive size-wise. I've replaced a few bB lines of code with slightly smaller ASM ones, but they're only saving a few bytes here and there. bB is a pretty decent pre-compiler!

 

 

 

If you have a simple sound effect you can set AUDC0=12: AUDV0=8 then the data table is just all note values.

 

You mean there is some special processing in bB that reads notes in that mode? Or that is just a good starting sound for music?

 

What I ended up writing was code that reads a 5-byte line describing a sound. The coolest (in my opinion) feature is it can chain data together to make complex sounds - it just treats them like a new sound. So simple sounds might have one single data entry. Complex sounds might have 3 or more all chained together like a linked-list but played back as if they're a single sound.

 

The issue is I have to bank switch to set the initial sound. That costs ~20 bytes just to call a sub program. Instead, I'm planning on altering it so it just caches the index of the sound and only bank switches once per frame to set the sound. Instead of setting it right away.

 

20 bytes per sound is costing me a few hundred bytes even though the playback engine I wrote is small.

Link to comment
Share on other sites

  • 2 weeks later...

The smallest sound system I've come up with is something like this: I use two variables "sounda" and "soundb". The length of time a sound is played is represented by the current value of the variable. The sound changes with the variable value as well so longer playing sounds will be different from shorter ones. If a sound is decremented down to zero I kill the volume.

main
 if sounda > 0 then sounda = sounda - 1 : AUDC0 = 8 : AUDV0 = 4 : AUDF0 = sounda else AUDV0 = 0
 if soundb > 0 then soundb = soundb - 1 : AUDC1 = 2 : AUDV1 = 4 : AUDF1 = soundb else AUDV1 = 0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

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

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...