I wonder, what we should do in the vgm packs if there are cases like Totaka's song (e.g. http://www.youtube.com/watch?v=Js7y-KOO7Gg), or like that song from Mario Kart 64 that loops 64 times before moving to the second verse (http://www.youtube.com/watch?v=Iqqsewbj5Qw). While the second example isn't very relevant since the N64 can't be logged to vgm, someone might actually want to make a pack of Super Mario Land 2, so the question stands: what to do in a case like that?
I wonder if it would be possible to implement the concept of extended / dynamic loop points in vgm files, maybe not as full blown as module patterns, but flexible enough to support things like this: [A] B (C × 5) D (GoTo B) instead of the current [A] B C C C C C D (GoTo B).
Theoretical question about loops...
Technical discussion about the VGM format, and all the software you need to handle VGM files.
Moderator: Staff
Theoretical question about loops...
Also known as nineko.
-
- ValleyBell Offline
- Posts: 1611
- Joined: 2011-12-01, 20:20:07
- Location: Germany
That's actually a very good question.
When I made the first submission to the SMSPower Music Contest, I already thought about adding support for A [loop B] C. But I threw the thought away quite quickly, because there would be no benefit for game rips and only little benefit for homebrew stuff.
I'm still not sure if extended looping would be a good idea. (And extended loop points will be difficult to handle when it comes to seeking.)
For now, you have 3 choices:
1. record the full loop: A B B ... B C [goto B]
2. hack the game (or the VGM) or play A B B C [goto B] instead of A B B ... B C (this would be nicer to listen)
3. strip the part off that plays rarely: A B [goto B]
I would prefer 2, but 1 is also okay. 3 is out of the question and is only listed for reference.
When I made the first submission to the SMSPower Music Contest, I already thought about adding support for A [loop B] C. But I threw the thought away quite quickly, because there would be no benefit for game rips and only little benefit for homebrew stuff.
I'm still not sure if extended looping would be a good idea. (And extended loop points will be difficult to handle when it comes to seeking.)
For now, you have 3 choices:
1. record the full loop: A B B ... B C [goto B]
2. hack the game (or the VGM) or play A B B C [goto B] instead of A B B ... B C (this would be nicer to listen)
3. strip the part off that plays rarely: A B [goto B]
I would prefer 2, but 1 is also okay. 3 is out of the question and is only listed for reference.
Here is my idea (I know I just said this in IRC, but in this way people can discuss):(stuff) 0x4E 0x00 (more stuff) 0x4E 0xNUM (even more stuff)
The player detects the 0x4E 0x00 as the beginning of the loop and saves that position in memory, so when it encounters the other 0x4E it goes back a certain number of times. When seeking it could be ignored, but:
The 0x4E 0x00 can be replaced by a 1-byte unused command, too. In this way the start of the loop can be simply represented as 0xXX, and consider 0x4E 0x00 as a 0x4E 0x100 (e.g. 256 loops).
Code: Select all
0x30..0x4E dd : one operand, reserved for future useThe player detects the 0x4E 0x00 as the beginning of the loop and saves that position in memory, so when it encounters the other 0x4E it goes back a certain number of times. When seeking it could be ignored, but:
Just a random idea.<ValleyBell> but still ... it would look very odd in Winamp
<nineko> Right
<nineko> Then don't ignore it while seeking, and have Winamp calculate the "unrolled" length in advance
The 0x4E 0x00 can be replaced by a 1-byte unused command, too. In this way the start of the loop can be simply represented as 0xXX, and consider 0x4E 0x00 as a 0x4E 0x100 (e.g. 256 loops).
Also known as nineko.
