Previous Thread
Next Thread
Print Thread
Page 28 of 55 1 2 26 27 28 29 30 54 55
Joined: Sep 2007
Posts: 56
K
Member
Offline
Member
K
Joined: Sep 2007
Posts: 56
Hmm, this is the only reasonable fix that I can come up with:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2008-01-29 16:28:48.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-04-22 21:36:00.000000000 -0700
@@ -357,7 +357,7 @@
 			slot->EG.volume-=slot->EG.D1R;
 			if(slot->EG.volume<=0)
 				slot->EG.volume=0;
-			if(slot->EG.volume>>(EG_SHIFT+5)<slot->EG.DL)
+			if(slot->EG.volume>>(EG_SHIFT+5)<=slot->EG.DL)
 				slot->EG.state=DECAY2;
 			break;
 		case DECAY2:


This will push the crash cymbal sample immediately into the DECAY2 state, bypassing the troublesome zero-valued DECAY1.

Additionally, I've just discovered that using a different driver version fixes the problematic Shining the Holy Ark tracks (e.g. sha-07.minissf) where the SCSP-slot assignment gets derailed. I'm at a complete loss as to why the game's original driver is doing this in the rip.

You can get the "fixed" copy here for now:

http://h1.ripway.com/kingshriek/Shining_the_Holy_Ark.7z

Joined: Feb 2008
Posts: 107
D
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
It's rather difficult to compare my AEG code to what AO uses (many fundamental differences in timing and channel flag handling) but here's what I'm doing:

Code:
if (kanal.AEG.poziom < 0)
  {
  // przejscie do Decay 1 / Decay 2
  kanal.AEG.poziom = 0;
  if (kanal.AEG.poziom >= D2AEGP)
    FazaAEG (kanal, AEG_DECAY2);
  else
    FazaAEG (kanal, AEG_DECAY1);
  }


This is for the case when the current phase is ATTACK. As you see, I'm switching directly to Decay 2 if DL (I call it D2AEGP) permits it.
AFAIR this is what I observed on hardware. The switch to Release however will need at least one more sample, there is no direct route even if both Decay values are set to immediate.

As for slot assigments - sometime ago I belive I mentioned that AO seems to start playing with channel numbers in 0x2F range (rather then zero, like my player). Haven't really tested it since and it was alpha stage back then...
I still say you handle the key-on/off thing wrong (as in: hardware does it different way) and that could be the problem with the driver. This shouldn't have such effect though, I'd be rather expecting "ghost" (repeats) or incompletly defined sounds to appear - since you allow the channel to be keyed on in situations where it should not be possible.
But then again this doesn't seem to be happening so far, I guess nobody is trying to pull such dirty tricks on AICA smile

EDIT: Seems like the board doesn't like non-latin letters much. Fixed. And some nasty typos too.

Last edited by Deunan Knute; 04/23/08 09:30 AM.
Joined: Mar 2001
Posts: 16,750
Likes: 29
R
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,750
Likes: 29
Ahh, it sounds much nicer with the patch smile

Joined: Mar 2001
Posts: 16,750
Likes: 29
R
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,750
Likes: 29
SDK is updated with that patch.

Last edited by R. Belmont; 04/24/08 02:46 AM.
Joined: Mar 2001
Posts: 16,750
Likes: 29
R
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,750
Likes: 29
DK: the exact same voices with the exact same parameters are keyed on between our cores, it's just they're on different slots. (And I've not seen such an effect with the SCSP). Probably they use timer ticks to seed the slot allocation or something.

Joined: Feb 2008
Posts: 107
D
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
This was just a wild guess. I'm simply pointing out things, since I'm too lazy to investigate myself smile

Joined: Mar 2001
Posts: 16,750
Likes: 29
R
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,750
Likes: 29
smile

That's ok, meanwhile I've realized I should apply that envelope change to the AICA too.

Last edited by R. Belmont; 04/27/08 02:26 AM.
Joined: Jul 2008
Posts: 5
A
Member
Offline
Member
A
Joined: Jul 2008
Posts: 5
some piece of "eng_dsf" code need clarification:
1)
if(slot->mslc)
{
AICA->udata.data[0x12/2] = addr1; // 2812 has no description. only 2814 contains monitored channel position (CA). so what's the purpose of 0x2812 ?
if (!(AFSEL(AICA)))
{
AICA->udata.data[0x10/2] |= slot->EG.state<<13;
AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
}
}

2)where is no "voff" checking (channelOffset + 0x28 bit 6 - according to great Neill Corlett's notes).

3)aosdk 1.4.1 handles 0x2892 & 0x2894 address for TimerB & TimerC instead of 0x2894 & 0x2898.

Last edited by ajax16384; 07/14/08 04:08 PM. Reason: typo#2
Joined: Feb 2008
Posts: 107
D
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
1) Probably a bug. CA is used mostly for ADPCM streams, so this has little impact on AO I guess.
2) & 3) - those are never used anyway smile


Joined: Mar 2001
Posts: 16,750
Likes: 29
R
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,750
Likes: 29
I was gonna say, the fact that something uses timers B/C is bigger news than our mishandling of them wink I'll fix it anyway though.

Page 28 of 55 1 2 26 27 28 29 30 54 55

Moderated by  R. Belmont, Richard Bannister 

Link Copied to Clipboard
Who's Online Now
0 members (), 32 guests, and 1 robot.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,940
Posts117,521
Members4,994
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com