Uzebox Forums

As discussed in another thread, I checked to integrate some arpeggior code I made a long time ago. I found it and it's not as complete as I thought. Made me think the reason maybe was that's it's not required since you can somewhat do that already with the loop patch command. For example, something like this would yield a major chord sounding arpeggio:
Making ADSR envelopes is a bit cumbersome but seems it can be done with a series of loops (apart for the sustain bit). So I think I will leave that old code out for now.

Also, the code for the sound engine is getting too big for my taste and I can see a lot of waste in ram and rom for unused patch command types. I'd look to add conditionals for the "extended" patch commands (tremolo, slide, loop). Just that can save 512 byte of flash and 32 byte of ram. By default they'd be on of course for backward compatibility.

I missed this post back then apparently. I was looking into possible addition of more patch commands, as well as potentially not needing them by use of alternative techniques like this. Specifically trying to match some pretty radical modulation found in some C64 SID instrument sounds, I find the nature of the straight forward multiplicative Uzebox wave table doesn't allow for much modulation besides volume with Tremolo. Then, making custom sounds.inc one could probably cover the very limited use cases of this anyway without bloating the code.

It makes sense then, that any additional limited use code should be weighed well before just adding it in, as well as new code being #ifdef. Off the top of my head, I'm not aware of any finished games which actually utilize PC_LOOP or PC_SLIDE, except I suspect perhaps @Artcfox might in his Laser and Circuit Puzzle games? I sort of wonder if we aren't in too deep yet, to simply add the makefile options to whatever limited games use them, and make it off by default. I'd imagine the majority of new Uzebox games wont use them, and having an extra 32 bytes of RAM and 512 bytes flash without needing to dig deeply to find this info might be better?

I do not use PC_LOOP or PC_SLIDE in my Laser Puzzles or Circuit Puzzle, but I do use PC_SLIDE in my Unicorn demo.

Would it be reasonable to add something like: ..in the Unicorn makefile? If you do that...100% backwards compatibility is achieved in one move

I think it should be possible to select either or both, and only use the RAM/flash required for the features enabled. All of those happen before actual mixing I believe, so I don't imagine it's too complex to add.

Maybe I'll just implement it, let it sit on GitHub, and merge it if there are no arguments within a month. It seems very clear(and I agree) that Alec's opinion is that it would be better that way. Free RAM/flash for the majority of games, selective use of advanced features, yes please!

Why not invert it for full backwards compatibility? and/or and then by default every existing Makefile has all the options, and when someone gets advanced enough that they start optimizing, they can selectively turn things off by adding those defines? As my programs get more optimized, I find myself tweaking the kernel options more and more to disable the things I don't need. Once all my sounds are finalized, I'll set the MIXER_WAVES to only include the ones I actually use, but for initial development it is nice to have all the options available, so I can drop in any sound effect patch that I can find, and it will just work the way it is supposed to.

Here is my WIP:

I could see that too and it would work. Maybe Alec can chime in, since I get an ambiguous read on what he said to actually indicate which direction.

My main feeling on it, is it's like the kernel grew after those games were made, without them having a chance to makefile out those options. The upside to the inverted direction, it's like an extra cheat code you become in the know on, once you start looking to scrape the last bits of resources for your game. I do sort of like that, and it is fun discovering extra stuff you didn't know was there for the taking.

Also it makes the documentation more clear with less caveats. Those commands are there, unless you intentionally take them out. I'm not aware of any older game which is broken by having them included, but I'd like to go back to every demo makefile and add that. I guess I'm leaning to the inverse also unless Alec has suggestions. I might take a swing at this, shouldn't be all that much change really.

D3thAdd3r wrote: ↑Sun Jul 09, 2023 11:30 pm but I'd like to go back to every demo makefile and add that.

Actually scratch that, that's a characteristic I'm trying to work on. "If it ain't broke, don't fix it"