Air on a Rasterline
My contribution to the C64 Music compo at Datastorm 2013, where it ended up on 5th place.
The tune is remarkable from a technical point of view, because the playroutine only needs 63 clock cycles (one rasterline) per frame, whereas a normal playroutine needs around 24 rasterlines. To put that in perspective, consider that simply calling the playroutine (jump to subroutine + return from subroutine) uses up 12 cycles, i.e. almost 20% of the available time. Obviously this severely limits the number of features the player can support; there's no vibrato, no arpeggios, and so on. Still, it was fun to try to work musically within those extreme constraints.
- Air on a Rasterline (SID tune, 2.9 kB)
- Linus Akesson - Air on a Rasterline (MP3, 2.3 MB)
This project then went on to inspire Hermit Soft to create One Rasterline Tracker, a tool that lets non-coders take part in the fun. However, his playroutine is not quite down to 63 cycles yet, and believe me, the last few are the hardest. Still, it's a great achievement!
Here's the csdb page for Air on a Rasterline.
Posted Wednesday 20-Mar-2013 16:08
Discuss this page
Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.
Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.
Tue 9-Apr-2013 23:11
Fri 12-Apr-2013 06:04
http://en.wikipedia.org/wiki/Loopless_algorithm
http://wwwx.cs.unc.edu/~snape/publications/msc/thesis.pdf
For example, loopless algorithms often need to use techniques like focus pointers; it seems to me that a playroutine would need several focus pointers.
Linus Åkesson
Sun 21-Apr-2013 22:58
It's an interesting comparison. However, when talking about time complexity one is typically concerned with how the execution time behaves when the size of the problem, expressed as N, grows very large. I don't quite see what N would represent in the context of playing a chiptune. The only property that can be arbitrarily large is the duration of the song (or some dependent property, like the total number of notes). But in that case, as N grows, so does the processing time available for completing the task.