Source and MusMod2 module on the dev site.
Changes from 0.03:
- Now initialises QTM in 8 channel mode
- Mus_Effect now cycles the effects on channels 4 to 8 to reduce cut-outs (fixes BlowPipe)
- Mus_Run commented out (fixes Jahangir Khan World Championship Squash)
- Mus_LaidBack implemented - no idea what it does though!
- Mus_SampleStarts implemented (fixed Mad Professor Mariarti)
Working
Battle Chess
BlowPipe
Chuck Rock
Heimdall
Hero Quest
James Pond
Mad Professor Mariarti
Manchester United Europe
Known issues
Battle Chess - !Battle.NOTHING won't play (worked around I believe by changing the !Run script)
Jahangir Khan World Championship Squash - sound effects sound wrong, could be linear samples
Manchester United - !!MUFC!!.ZilchMus won't play, so the music doesn't stop when you start a game
Lemmings - Music starts too early when starting a level (fixed in 0.05)
Lemmings 2 - !Lemmings2.Lemtitle is silent (fixed in 0.05) and it hangs during loading
Nebulus - No music (fixed in 0.05)
Outstanding development
Mus_Patch - Requires QTM extending to support this (entry R0=songpos, R1=songpos). When songpos hits value in R1, jump to songpos in R0
Mus_Sector - Possibly protection related
Mus_Effectcontrol
Mus_Instruments - Requires QTM extending to support this (no entry values, exits R0-R3 containing the instrument no. currently playing in channels 1-4)
Mus_FXonly
Mus_Repeffect
Mus_Mus_Routines - may not be required
MusMod 2 QTM v0.04 available
Re: MusMod 2 QTM v0.04 available
A typo on my part in *mussongpos which I've now fixed.JonAbbott wrote:Lemmings 2 - !Lemmings2.Lemtitle is silent
It requires Mus_ScaleSamp, which I've now coded.JonAbbott wrote:and it hangs during loading
After calling this SWI 17 times, it locks solid, so there's another issue somewhere. There's no further calls to Mus_ SWI's so it could me a * command at fault.
Re: MusMod 2 QTM v0.04 available
Chuck Rock now hangs with Mus_ScaleSamp implemented.
It's version of MusMod2 implements "Mus_Instruments" instead, so I'll add a * command to alter the behaviour of the higher SWI's.
It's version of MusMod2 implements "Mus_Instruments" instead, so I'll add a * command to alter the behaviour of the higher SWI's.
Re: MusMod 2 QTM v0.04 available
The problem here is Mus_Run not being implemented, I've taken a guess and coded as:JonAbbott wrote:Nebulus - No music
Set Song position to the value passed in R0 and play the music if <>0, pause the music if the value is 0. However, this has highlighted a few issues in QTM:
1. After issuing QTM_Pause, samples don't play via QTM_PlayRawSample. To work around this, I've switched to using QTM_MusicVolume, this highlights another problem:
2. Both QTM_Volume (R0=-1) and QTM_MusicVolume return 0 if no music is playing - they should surely return either the default (64) or the last volume set.
I've worked around the 2nd issue by hardcoding the volume to 64 when Mus_Run R0<>0 is issued.
EDIT: Issue 1 could be caused when QTM_Pause is called twice...I'm not certain at this point.
EDIT2: Issue 2 - it would appear the default volume is 0 ... which explains all the issues I'm seeing with volumes being wrong. I'll try setting it to 64 when the this module is initialised
Re: MusMod 2 QTM v0.04 available
On second thoughts, I wonder if the value in R0 is a countdown timer to start the music playing. When starting a level in Lemmings for example, it issues the following immediately:JonAbbott wrote:Mus_Run ... I've taken a guess and coded as:JonAbbott wrote:Nebulus - No music
Set Song position to the value passed in R0 and play the music if <>0, pause the music if the value is 0.
Mus_Volume &FF
Mus_Effect &37368 (the "Lets Go" sample)
Mus_Run &37
Mus_Songpos 0
However, there should be a pause before the music starts playing to let the "Lets Go" sample finish. Mus_Run is the obvious candidate here as the music is already playing in the background at volume 0.
EDIT: Looking at the MusMod source, it doesn't do anything with the value passed in R0 apart from check if it's zero, so its a toggle...of what though.
Re: MusMod 2 QTM v0.04 available
Mus_Run think I finally have this one figured after many hours of testing with Lemmings and Nebulus (famous last words as I've not tested with any other games!)
What I've ended up with is:
If R0=0, check via QTM_SongStatus to see if the song is paused, if not, pause it
If R0<>0, start the song
This seems to work around all the random issues I was seeing with volume and QTM_Pause causing samples to stop playing. All very odd behaviour.
What I've ended up with is:
If R0=0, check via QTM_SongStatus to see if the song is paused, if not, pause it
If R0<>0, start the song
This seems to work around all the random issues I was seeing with volume and QTM_Pause causing samples to stop playing. All very odd behaviour.
Re: MusMod 2 QTM v0.04 available
Mus_Instruments - I've just noticed whilst comparing Chuck Rock under QTM and MusMod that the musicians play on queue to their instruments. So ... this SWI must return a value if a sample is playing (R0 is 2, 4, 5 or 7, so it must be the sample number).
We'll need to extend QTM before we can add this.
We'll need to extend QTM before we can add this.
Re: MusMod 2 QTM v0.04 available
Now I've disassembled this version of MusMod2, this takes no input values. It simply returns values in R0-R3, at a guess they're the instrument number playing on the respective channels.JonAbbott wrote:Mus_Instruments - I've just noticed whilst comparing Chuck Rock under QTM and MusMod that the musicians play on queue to their instruments. So ... this SWI must return a value if a sample is playing (R0 is 2, 4, 5 or 7, so it must be the sample number).
We'll need to extend QTM before we can add this.
EDIT: I've confirmed its the instrument number (1=female guitar, 2=male guitar, 4=keyboard, 5/6=drums, 7/8=bass)
Re: MusMod 2 QTM v0.04 available
Excellent work, can't wait to try this out. Is the source code on the dev site too?
I may have an hour or so spare this weekend, and could fire off a few QTM tweaks into a new test version, if that's useful?
- If so, could you make a priority list of things we need to add/implement to QTM? Also take a look at the v1.43 docs file of future ideas - I think some of the proposed SWIs would cover requirements you mention? and I had already started on some
I may have an hour or so spare this weekend, and could fire off a few QTM tweaks into a new test version, if that's useful?
- If so, could you make a priority list of things we need to add/implement to QTM? Also take a look at the v1.43 docs file of future ideas - I think some of the proposed SWIs would cover requirements you mention? and I had already started on some
Re: MusMod 2 QTM v0.04 available
Certainly is. It defaults to compiling to <ADFFS$Dir>.trackers.MusMod2steve3000 wrote:Excellent work, can't wait to try this out. Is the source code on the dev site too?
That would be very helpful, I did look at the QTM source with a view to adding them myself last night, but quickly decided it's probably best left to you.steve3000 wrote:I may have an hour or so spare this weekend, and could fire off a few QTM tweaks into a new test version, if that's useful?
- If so, could you make a priority list of things we need to add/implement to QTM? Also take a look at the v1.43 docs file of future ideas - I think some of the proposed SWIs would cover requirements you mention? and I had already started on some
Priority list:
1. Add QTM_Instruments, entry value in R0 - to return the current instruments playing. Return all 4 in R0 (or in R0-R4 if easier) if R0=0 on entry, or return the instrument on channel X if R0<>0 on entry
2. Add QTM_PatchSongPos, entry values in R0, R1 - to move songpos to the value in R0 when it hits the value in R1
3. Find out why !!MUFC!!.ZilchMus doesn't play, add support if possible
4. Extend QTM_PlayRawSample to support linear samples (although I need to confirm this is the cause of JK's effect problems first...which I'll try to do today). If you're not going though a log>linear conversion step (ie 16bit) in the DMA code, this may be a real pain to implement. Should this be the case, I could add a log conversion step into the shim to convert them the first time they're played...actually this is probably a better method of doing it (unless the proposed QTM_ConvertSampleData is implemented, in which case I'll use that instead)
An observation from looking at the QTM source, there's a lot of unrolled loops which inflate the module unnecessarily and are really only applicable to ARM2. Might be worth considering an ARM3+ compile option to strip out the ARM2 code in the future.
EDIT: I've confirmed JK's effects are signed linear (&80 being 0), I'll add a * command to the shim and have the shim convert them on the fly, so you can leave (4) for the time being.