3 ms·
That might be true in theory, but not relevant in practice unless you're on a really old or really esoteric CPU (one could extend that to: the C standard is imp
by flohofwoe 4y ago
That might be true in theory, but not relevant in practice unless you're on a really old or really esoteric CPU (one could extend that to: the C standard is important in theory, but usually not relevant in practice - the only thing that matters in the real world is how specific C compilers behave).
In the real world, for this type of code (audio code, most likely for games), only a very small number of CPUs (Intel and ARM) and C compilers (Clang, GCC and MSVC) matter, and on those, int is 32 bits wide.
PS: For new code I would also suggest using the "new" C99 fixed-width integer types though.
- ant6n 4y agoBut what about the game boy!
- minimaul 4y agoI think you’re okay there, the Game Boy doesn’t have any sound output channel this could work with anyway :)
- ant6n 4y agoHe does, too! https://problemkaputt.de/pandocs.htm#soundchannel3waveoutput https://problemkaputt.de/pandocs.htm#soundchannel3waveoutput
- minimaul 4y agoI was aware of this, but I don't think a 32 sample 4-bit wave RAM is quite good enough to make something representative :)
- ant6n 4y agoIt's possible to play ~8KHz+ 4bit PCM. Just need to update the wave RAM four times per frame using an hblank interrupt handler. Or write completely deterministic code that unpacks the audio and writes it out at the correct time intervals.
- RobotToaster 4y agoDont a lot of 8 bit micros still use 16 bit ints?
- flohofwoe 4y agoMight be (Arduino maybe?). AFAIK there's still quite a bit of C code written in the homecomputer retro scene, using specialized C compilers like sdcc or cc65, but IME this requires so much manual tweaking and platform specific hints that it is very far away from 'standard C', and most common open source libraries wouldn't even work even if the code was fully standard compliant C, just because of memory constraints.