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

[wallaby]

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?

 

I might have to cull some features.

[ZackAttack]

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.

[iesposta]

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?

 

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.

[wallaby]

 

 

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.

[+SpiceWare]

Don't know if it'll help, but I ported my Sound Effect driver to bB a few years ago.

[wallaby]

Thanks for that. I ended up caching my change sound requests and calling my routine once per drawscreen. That eliminated a lot of the space trouble I was having.

[+Gemintronic]

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