In-game (during gameplay) music

It's here:

https://youtu.be/bFJLZWDOA-M

Here is rough outline how the second approach could work. It needs to have IM2 interrupts and HALT before a new game frame. Does not matter if there is few TV frames per game frame, but more constant CPU load time is preferred, to avoid major variations of the sound bursts duration.

Once program needs to perform HALT, it rather calls HALT_SE.

HALT_SE:
restore all registers required for sound/music generation
LOOP:
generate sound, needs to be the usual short loop
scf
BREAK=$
ccf
jp nc,LOOP
restore ccf opcode at BREAK
store back all registers, the point is to be able to smoothly resume sound generation during next call
ret

IM2 interrupt should just replace ccf at BREAK with nop, thus breaking the sound generation loop (could be any other way).

It may sound crazy, but if the game is simple, you can use a beeper engine that uses IM2 interrupt mode (like Special FX or Plip Plop) and run the game on interrupt.
Be warned that both the sound quality and game speed will be lower. This is why this must be a simple game.

Hi Shiru, first to all, I want to thank you for your mFX player that I'm already using for my games Gandalf and Manic Pietro. Currently I'm working on a Pacman clone and I want to target the 48, with beeper sound fx. Do you have any code example for that obscure solution that you mention?

I've run some test, this are my findings (I'm a newbie on the 48 beeper)

-Sounds can be placed as long they don't mess with interruptions, for example the Basic Beep routine can be used on short intervals and also out254 based sounds seems to be work ok, with no screen flickering or corruption.

-Also I've try to use BeepFx but it disables interrupts.

-Steve Turner player works but it may be interfering with some registers that SDCC needs, as the code jumps to an unexpected place.

-I've placed a call to tiny out254 routine on the Nirvana ISR, to make some noise each time pacman eat a dot and works ok.

What do you think, Any idea or suggestions?

Regards

No, if I had something, I sure would publish it already. At the moment, the only game I can think of that kind of used this approach was Sea Dragon port, where I did beeper effects. It used very crude sample-like effects, like every so often during rendering a frame the game just read a bit from an array and outputted it. As it was 50 hz targeted, rendering speed was relatively steady, thus 'sample rate' was steady enough too. I don't have this code around, and can't really recall how many times per frame the routine was called. I think it was the least possible number, to avoid introducing slowdowns. Maybe 8-16 updates per frame.

I don't think there is a way to fix it. Even changing the pitch will not make the samples play as intended.
Interrupts and beeper sound don't mix well. And iirc Nirvana's interrupts take up almost the entire frame.

Actually, I have implemented exactly this idea in my 1K intro "Splash" (2014). The beeper engine there is very simplistic, single voice, but this is purely due to the size limitations I was dealing with.

In fact, I think that it won't be a large overstatement to say that most of my beeper experiments were about trying to push the envelope of how beeper sound can be combined with other things.

Shiru's methods 1 and 2 can be found in quite a few old games with beeper music. I never liked the resulting sound, so I did not do much research on it. Hence, I am not sure if e.g. Manic Miner uses method 1 or method 2 (method 1 seems more likely, given the lack of vsync in the game). My beeper scroller in "Dat Fuzz" (2014) is using, I guess, a variation of the method 2, with one modification: the visuals occupy small fixed time remaining after playing something like 2.5 frames of sound. So, improving the quality of sound is easy - just ensure that the sound does not get interrupted much.

Like I said, method 3 in Shiru's list can be found in "Splash" (2014). At the same time, outside of beeper, I am pretty sure that at least some demos with digital sound use a similar approach (e.g. "Scroller" (2010) or "Atarin" (2018)). In fact, I'd say that the devil is in the implementation detail: visuals usually require v-sync, while beeper (or digi) need +- constant rate of updating, which does not fit well with updating visuals synchronized to vsync or, more generally, doing any non-trivial logic. Specific solutions of this clash of needs can be different and varied; what I did in Splash does not make me happy and I am currently experimenting with another approaches.

A good way to think about all these methods is to think about code responsible for visuals as something that "distorts" sound. Then your strategy to improve the sound quality would always be about something that reduces the distortion. The larger proportion of time you can spend on making the sound, the better sound quality you'd get. This applies to all three of Shiru's methods.

However, there are other methods for reducing the distortion. Instead of trying to reduce the "amplitude" of the distortion ("amplitude" in the PWM sense would be the duration of anything that is not generating sounds), you can change the dominant frequency with which distortion occurs. E.g. the scroller in "Dat Fuzz" operates on the basis of one scroll every 3 frames only partly because this was the only way to significantly change the proportion of time between the work of the beeper engine and the work of the visual code. It is also important that the base frequency of the resulting distortion becomes 18.5Hz (which cannot be heard) instead of the pretty obvious 50Hz produced by engines operating on the basis of single frames logic. If taken to the extreme, some games do all drawing between the rows in the beeper engine, which tends to mask quite well even pretty significant interruptions in sound. Of course, from the point of view of visuals extremely slow updates do not work very well.

My demo "Rain" (2016) was an attempt to see what happens at the other end of the spectrum. What would happen with the sound if the distortion was to operate at very high frequency? In "Rain", the visual code occupies every 4th iteration of the sound loop running at something like 12kHz. It does distort the sound, but the nature of the distortion is such as to create "spacey" sound, which seems a lot more acceptable that what methods 1 or 2 can provide you with. Of course, the type of code you need to write for this mindset is not very vsync-friendly and, in fact, is not very visual-effects friendly. However, you do get surprising amount of time for doing useful work beyond making the sound, so definitely consider this approach too.

Well, Octode XL used in Rain is not really a pin pulse method, not in the usual sense of the word, because pins are at least as wide as the period of discretization loop (and are often wider). Squeeker method is also a funny mixture of two other mixing approaches. I got behind your recent work on new engines (you make too many of them, mate!!! ), but I think that the overall question of which mixing method would be more suitable for in-game music is still very much open in my mind.

I.e., the principles I covered in my write-up have nothing to do with the method of mixing. OK, I based Rain on Octode XL because it has low discretization frequency, which made it easier to interleave audio and video codes at high frequency. You can probably make similar claim about the Squeeker engine. I do not think we have any other guidance in this case, do we?

Welcome back, mate! Looking forward to what you will come up with. If you have any questions we're here to help, of course.
I think Hikaru's new AMP16k might be interesting for you to study as well. Generally, the "Squeaker" method used there is a good candidate for in-game music because its CPU requirements are not that high, and it tolerates some deviance in timing as well. Though pin-pulse like synthesis like in Qchan should work well, too.