#28766 - ProblemBaby - Fri Nov 05, 2004 6:50 pm
Hi, Iam working with my XM-player and now i want to add support for Volume Envelopes I read this in The XM spec:
| Quote: |
The envelopes are processed once per frame, instead of every frame where
no new notes are read. This is also true for the instrument vibrato and
the fadeout. Since I am so lazy and the tracker is rather self-explaining
I am not going to write any more for the moment.
- max x value: 0x144 = 324d (for enveloppe points)
- max y value: 0x40 = 64d (for enveloppe points)
|
First: What is a frame?
Second: To anyone have a nice idea of how to do it without divisions?
And why, why is max x value 0x144 is that some kind of value that should be known in the tracker world?
#28768 - Lord Graga - Fri Nov 05, 2004 7:35 pm
a frame is one screenupdate. Happends every nearly 1/60th second.
Where the hell do you divide? :P
#28781 - tepples - Fri Nov 05, 2004 10:51 pm
The concept of a "frame" in tracked music is not the same as the concept of a "frame" in video programming. In tracked music, a "frame" is a 96th note, of which there are 24 in a "beat" as measured by the Beats Per Minute. For example, for a tempo of 125 beats per minute, there are 125 * 24 = 3000 "frames" per minute, or 50 "frames" per second.
Only at 150 BPM does the replayer engine run at 60 "frames" per second.
The Bresenham (divideless) way to approximate a variable rate frame counter for .mod, .s3m, .xm, or .it music is this: Every vblank, add the tempo to an internal counter, and every time the counter passes 150, run envelopes and effects and then subtract 150 from the counter. With a tempo over 150, it may overflow more than once in a frame, so use a 'while' loop rather than an 'if' statement.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28783 - bertsnks - Fri Nov 05, 2004 11:23 pm
i think he means the envelope delta values that have to be calculated between 2 points
#28793 - ProblemBaby - Sat Nov 06, 2004 2:56 am
Tepples: Thanks for that information!
bertsnks: You are right, that was what I also thinked of
#28794 - tepples - Sat Nov 06, 2004 5:14 am
Envelope delta values can be Bresenham'd as well.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28797 - ProblemBaby - Sat Nov 06, 2004 12:00 pm
How?
#28801 - tepples - Sat Nov 06, 2004 2:51 pm
For an envelope represented as distance over time, you add distance every frame, and every time it goes over, subtract time and move the volume by 1.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28925 - bertsnks - Mon Nov 08, 2004 8:04 pm
| tepples wrote: |
| For an envelope represented as distance over time, you add distance every frame, and every time it goes over, subtract time and move the volume by 1. |
If you are using the Bresenham algorithm, slopes where the delta y is greater than the delta x can get tricky. Most guides propose to switch x with y, but this is not possible with envelopes since you need the value for the next x. Any hints on speeding this up tepples?
#28926 - tepples - Mon Nov 08, 2004 8:17 pm
Finding the height of the envelope at a given time is exactly the same problem as polygon rasterization, also called scan conversion, but with only one edge rather than two. Use Google.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28930 - bertsnks - Mon Nov 08, 2004 8:44 pm
ok, thanks for the quick reply :).
But, doesn't scan conversion for a polygon mean you would need the gradient, and waste a divide? (gradient = dx/dy)
and correct me if i'm wrong, but doesn't a polygon scan conversion move y wise, while envelopes move x wise?
#28932 - tepples - Mon Nov 08, 2004 9:22 pm
| bertsnks wrote: |
| But, doesn't scan conversion for a polygon mean you would need the gradient, and waste a divide? (gradient = dx/dy) |
If you're using a DDA scan conversion, yes. However, you can make a table of possible values of dy and then use reciprocal multiplication. Or you can stick a fast (sub 60 cycle) divide algorithm in IWRAM along with your mixer. Or turn the slope of the envelope into a mixed number, add the whole part every frame, and do Bresenham on the fractional part.
| Quote: |
| and correct me if i'm wrong, but doesn't a polygon scan conversion move y wise, while envelopes move x wise? |
As you said, "Most guides propose to switch x with y".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28934 - bertsnks - Mon Nov 08, 2004 9:50 pm
| tepples wrote: |
| bertsnks wrote: | | But, doesn't scan conversion for a polygon mean you would need the gradient, and waste a divide? (gradient = dx/dy) |
If you're using a DDA scan conversion, yes. However, you can make a table of possible values of dy and then use reciprocal multiplication. Or you can stick a fast (sub 60 cycle) divide algorithm in IWRAM along with your mixer. Or turn the slope of the envelope into a mixed number, add the whole part every frame, and do Bresenham on the fractional part.
| Quote: | | and correct me if i'm wrong, but doesn't a polygon scan conversion move y wise, while envelopes move x wise? |
As you said, "Most guides propose to switch x with y". |
Ok, those options sound good; but just for the sake of it, i am not understanding the slope with the 'mixed number' method, can you please explain this some more?
#28950 - tepples - Tue Nov 09, 2004 2:41 am
Say you have to increase volume by 13 over a time span of 4 units. Therefore, your slope is 13/4. This is a "slope where the delta y is greater than the delta x", that is, an improper fraction. Break it up using one division (calling BIOS Div should be fast enough, or you can use custom ARM code in IWRAM linked to in the Beginners' FAQ), and you get 3 remainder 1, or 3+1/4. So increase the volume by 3 every tick and then use the Bresenham algorithm to increase by 1 every 4 ticks.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#29003 - Miked0801 - Wed Nov 10, 2004 1:32 am
Or bitwise and 0x03 for mod and shift :) (for this denominator only I know)