egr wrote:Delek, are there benefits to using bpms that are divisible by the refresh rate vs those that require "extra code" to achieve?
From the point of view of the user, there's no difference.
Technically is a little bit geeky stuff going on there, I will try to explain it in a simple way:
In a normal game environment, it is simply "enough" to use the screen refresh rate or another slow IRQ (interrupt request) to build your logic and music inside it. There are no needs for a "specific" tempo, no one cares that much about this (with exception of Music only apps or Chipmusicians).
Now, the implications of building your music update at a custom refresh rate are:
ALL your logic must run at that speed (multi-threading is something obviously outside of imagination)
You will need very precise and complex playback routine (timing, optimizations, strange hacks, etc)
Obviously more CPU use (particularly annoying in battery powered devices)
And even with all of this stuff, you are at the end of the day limited by the MASTER CLOCK of the device, behind the interrupts there is a master timing limit that is the actual clock of the core CPU (all becomes a multiple of 1/master_device_clock).
(Now it is easy to see why back in the day, the SEGA Genesis for example, used only the Z80 to play samples (a fast process) and leave the Motorola 68000 for the logic and simple music events)
egr wrote:what are the refresh rates of the DMG and GBC?
Its CPU runs at 4194304 Hz, to display a full frame it takes 70224 cpu cycles. So 4194304 / 70224 = 59,727500569605832763727500569606 Hz
d3Ni$e wrote:But if I open a tracker and I see that the speed is set to like "3" how fast is that approximately? Is it over 100bpm or under?
Insufficient data for meaningful answer.
"3" means that it will take "3 ticks". It is up to the tracker if a tick means 1/60 seconds, 1/50 seconds or 1/300 seconds (normally you can find this in the manual or in the source code of the program)