Scali wrote:Well, I think 50 Hz was carried over from the Amiga, where the MOD format originated. It was developed by the European scene, so […]
Show full quote
Well, I think 50 Hz was carried over from the Amiga, where the MOD format originated. It was developed by the European scene, so everything was PAL-oriented.
The first PC trackers started as clones of Amiga trackers, and wanted to be compatible with Amiga MODs, so 50 Hz was a requirement.
Not to mention that they used software mixing, so they wouldn't necessarily have to run on a timer. They could run on the DMA interrupt of the sound card, at whatever buffer size you want to choose.
Mind you, by the time this stuff became popular, frame-related timing was not an issue on PCs anyway. Most stuff was just 'bruteforce' double-buffered rendering, and syncing to the screen was not useful anyway.
Yeah, I forgot that you're dealing with a sample stream on the SB, so you'd be doing sample-counting for the timers.
50hz has some neat musical perks vs. 60hz: The common 120BPM fits nicely into it: 6 ticks per 16th note gives you perfect 32nd notes in that tempo. There's something pleasing about the tempos derived from that tick rate, but maybe that's just conditioning.
Hmm, I think syncing to the screen is rather nice if it can be managed. You can really see judder in a 2d game that's panning at a 1:1 framerate if you drop a frame, and it makes tearing really visible too. With the 3d games that DOS gamers like myself liked to play, it was less of a big deal (the movement tended to be more 'into the screen', and they often maxed out at half framerate, which they often didn't reach on the systems I played them on), but I got really spoiled by all those arcade games that opt for the rare slowdown rather than using a frame-independent timer. Really beautiful stuff, IMO. Completely silky movement, and by the time you got to all those arcade cabs that could pull it off at high res, that was really a treat.
Actually, speaking of timers, I didn't find a way of timing frames that I was totally happy with other than vsync. A lot of people recommended setting the PIT to the same as the refresh, but what guarantee would you have that it'd be locked with the refresh and wouldn't drift at all? What about the phase of the timer (if it's not in phase with the display timer, your measurements will be off depending on when you check)? I'm guessing the right way to do it might be to use the PIT as a high-res timer and do expensive scaling for all the movements..?
Scali wrote:It seems like you'd quickly run out of voices before you could do most GM compositions justice. The General MIDI standard calls for a minimum of 24 voices; OPL3 provides 20 at best. If you resort to any sort of layering and/or 4-operator modes for one or more instruments, you're even farther behind. Of course, you could also support multiple cards, or design your own multi-OPL3 device, if you think it's worth the trouble.
I'm thinking that a good voice allocation/stealing algorithm can go a long ways. It could be my experiment will fall flat on its face (or I'll have to supplement the nice rich 4-op sounds with lightweight 2-operator ones), but I've got high hopes I can make it work! One reason you can get so much mileage out of trackers is that the human is doing all the voice allocation, but... I think I can automate a lot of what I do.