#9やっと＊ＢｕｆｆｅｒＲＬ

#9やっと＊ＢｕｆｆｅｒＲＬ（２００６－０２／０９）



■初めてＤＧＥＮ１００のＵｐｄａｔｅＯｎｅを見た時から変だなと思っていた。
＊＊Ｂｕｆｆｅｒ（つまり、＊Ｂｕｆｆｅｒ［２］）を、＊ＢｕｆｆｅｒＬＲに変更した。
（ＵｐｄａｔｅＯｎｅのみ読むとＬＲみたいに読める）

が、調べたら（始めの予想どうり＊ＢｕｆｆｅｒＲＬで）名前が違うので、
＊ＢｕｆｆｅｒＲＬに変更した。
つまりここから先はたぶんＲＬになっているので、直す必要がない。

ＵｐｄａｔｅＯｎｅのみのバグ（ＲとＬが逆）という事が判った。
（だってＣＤの規格がＲＬなんだもん。苦労してフィリップスと作った資産なのに、
ソニーがＰＳＰでＬＲで作る訳ないじゃん。そんな異常な事したら担当者、即首。）


やはり、ＵｐｄａｔｅＯｎｅを呼ぶ所が間違ってる。
「ｍｄｆｒ．ｃｐｐ」
略
	else　　←音声をＯＦＦの場合は、音声バッファをクリアする。
（でないと前に使ったゴミを合成して発音してしまう）
	{
//		for( i=0 ; i < len /2 ; i++ )
		for( i=0 ; i < len ; i++ )　　　←どうせ＊ＢｕｆｆｅｒＲＬなん
だから、一気に２倍（左右両方）処理。
		{
			((unsigned long*)sndi->r)[i] = 0 ;　　←作った
人は＊ＢｕｆｆｅｒＲＬである事を知っている。
			//((unsigned long*)sndi->l)[i] = 0 ;　　←＊Ｂｕｆ
ｆｅｒＲＬだから無駄な事はしない。
		}
	}

	// Add in the stereo FM buffer
//	FMSAMPLE *buf[2];　　　　　　　　　　　　　　　　　　　　←これが噂の＊＊Ｂｕｆｆｅｒ
//	buf[0] = (FMSAMPLE*) sndi->l;　　　　　　　　　　　　　←標準のＭＡＭＥで
はデジタルミキサーやデジタルフィルター等入るので、外部仕様はこの様になっている。
//	buf[1] = (FMSAMPLE*) sndi->r;　　　　　　　　　　　　　　　こういう＊＊Ｂｕｆ
ｆｅｒで実装しとけば、５＋１ステレオにも簡単に対応できる。（ソースを直す必要がない）
「ナムコシステム２１ＷｉｎｎｉｎｇＲｕｎ」の様に標準で４ｃｈのゲームも世の中には存在する。
（右前、左前、右後、左後、で４ｃｈ）これ基盤（’９１）持ってるから今度ダンプしなくちゃ（世界中で誰もやってないらしい。「Ｒ９１１」）
がＰＳＰでは無駄っていうか。（別にいいけど）
//	FMSAMPLE *bufferRL = (FMSAMPLE*) sndi->l;　　　←元はこっちに
なってた。（だから＊ＢｕｆｆｅｒＬＲなのかと思った。）
	FMSAMPLE *bufferRL = (FMSAMPLE*) sndi->r;　　　←＊ＢｕｆｆｅｒＲＬなんだからこっち。

	if( (snd_mute & 0x3F) == 0 )
	{
		YM2612UpdateOne(bufferRL, sndi->len /*, snd_mute*/);
	}

昨日７６４９６のソースも見たが、この実装なら、さして一緒にしても、パフォーマンスアップしないかも
しれない。（やってみなくちゃ判らないが）
そんな事をするよりも、先にＤＡＣのミキサーを取っ払った方がいいかも。（このソースの直前がＤＡＣの
ミキサー）

■ＵｐｄａｔｅＯｎｅの外部仕様は、こんな感じになった。

typedef unsigned short FMSAMPLE;
略
/* Generate samples for one of the YM2612s */
//id YM2612UpdateOne( FMSAMPLE **buffer, int length, int flags );　　　　昔の。
//id YM2612UpdateOne( FMSAMPLE **buffer, int length /*,int flags*/)　　古いの。
void YM2612UpdateOne( FMSAMPLE *bufferRL, int length /*,int flags*/)　違いが判かるよネスカフェ。
{
略
//	FMSAMPLE  *bufL,*bufR;　　もういらない。
略
	/* set bufer */
//	bufL = buffer[0];　　　　　　　ここも接続する必要がない。
//	bufR = buffer[1];

#define ADVANCE_PAN \
			int lt,rt;\
			lt = 0 ;\
			if( pan0L ){ lt  = out_fm[0]; }\
			if( pan1L ){ lt += out_fm[1]; }\
			if( pan2L ){ lt += out_fm[2]; }\
			if( pan3L ){ lt += out_fm[3]; }\
			if( pan4L ){ lt += out_fm[4]; }\
			if( pan5L ){ lt += out_fm[5]; }\
			lt += bufferRL[0]; \     ここはこうなってる。（７６４９６やＤＡＣのデーターと合成）
\
			rt = 0 ;\
			if( pan0R ){ rt  = out_fm[0]; }\
			if( pan1R ){ rt += out_fm[1]; }\
			if( pan2R ){ rt += out_fm[2]; }\
			if( pan3R ){ rt += out_fm[3]; }\
			if( pan4R ){ rt += out_fm[4]; }\
			if( pan5R ){ rt += out_fm[5]; }\
			rt += bufferRL[1];\     ここはこうなってる。（７６４９６やＤＡＣのデーターと合成）

接続はこんな感じ。
*((unsigned short*)bufferRL++) = rt;	*((unsigned short*)bufferRL++) = lt;
*((unsigned short*)bufferRL++) = rt;	*((unsigned short*)bufferRL++) = lt;
*((unsigned short*)bufferRL++) = rt;	*((unsigned short*)bufferRL++) = lt;
*((unsigned short*)bufferRL++) = rt;	*((unsigned short*)bufferRL++) = lt;
４４１００なら１行分でいい。（これは１１０２５の場合。）
ここは別に、（rtがintなら）(int=32bit)(short=16bit)
rt<<=16;
rt|=lt;
*((unsigned long*)bufferRL++) = rt;　　　（long=32bit）
としても、いい筈。ちょっとテストしてみるか。（でも遅くなる気もする）
あ、他との兼ね合いがあるから、取りあえず
*((unsigned long*)bufferRL) = rt;　　　（long=32bit）
bufferRL++;     
bufferRL++;
いまBufferRLはショート型のポインタ。
ロングにするのなら「ADVANCEPAN」の合成部分も変えないとだめ、と思って
めんどいからテストやめよ。（やるなら、もっとずっと後で（ロングになった頃）だな）


■実験的に、７６４９６のＵｐｄａｔｅＯｎｅと
ＤＡＣと
ＤＡＣのミキサーと
サウンドレンダーゼロクリアを外して、
「ＢＦ０３チェック」をしてみた。
（本当は７６４９６のＵｐｄａｔｅＯｎｅはダミーで動作させた方が参考になった）

昨日（ＭＵＳＡＳＩ２．ＸＸ／ＧＣＣ４．０．０）「Ａ１２」
ＯＦＦ
８３ｆｐｓ
５５１２ｋＨｚ
７５～７６ｆｐｓ
１１０２５ｋＨｚ
７３ｆｐｓ
２２０５０ｋＨｚ
６８～６９ｆｐｓ
４４１００ｋＨｚ
６０ｆｐｓ

ＦＭ以外外す実験（ＭＵＳＡＳＩ２．ＸＸ／ＧＣＣ４．０．０）「Ａ１３実験中」
（速くなるに決まってる）
ＯＦＦ
８４～８５ｆｐｓ
＋１～２
５５１２ｋＨｚ
７９ｆｐｓ
＋３～４
１１０２５ｋＨｚ
７７ｆｐｓ
＋４
２２０５０ｋＨｚ
７２～７３ｆｐｓ
＋４
４４１００ｋＨｚ
６３～６４ｆｐｓ
＋３～４

これ以上はＭＩＸＥＲは頑張っても無駄という指標が欲しかった。
このうち、７６４９６のＵｐｄａｔｅＯｎｅは搭載しない訳にはいかないから、１～２ｆｐｓは下がるだろう。
しかし、ＤＡＣはもっと簡単な実装で済ませ、殆ど負荷を０にする事ができるだろう。
つまりＭＩＸ関係を最適化した場合。上記より、１～２ｆｐｓ低いのが、理想値という事になる。

この結果で着目して欲しいのがＯＦＦの結果だ。（他は実は予測できる範囲なので、どおでもいい）
ＯＦＦの実装がタコなのが、ばれてるだろ。
つまり、ＦＭ音源ユニット自体のエミュレートが重いのではなく、
ＰＳＰはバス転送速度自体がとろいのではないか？（ＣＰＵが３３３でも６６バスとかさ）
バッファへの０クリアの処理時間と、
バッファへのＦＭ音源のレンダリング処理時間の間に、
酷い差が見られないという事だ。
この結果なら、ＵｐｄａｔｅＯｎｅを全て（７６４９６、ＦＭ、ＤＡＣ）一つにまとめ、
ＰＳＰのバッファに直接レンダリングすれば、パフォーマンスが上がる可能性がある。（予測：１～２ｆｐｓ）

そこまで出来たらお魚さんにも、搭載すればよい。（それ以前は弄るだけ無駄）

■いい機会だから、前項。ＭＩＸＥＲの実験用に、ＦＭのみなる奴で、「Ａ１３からＦＭ以外を外した奴」
「２５６レンダーのテスト」をしてみた。２５６レンダーなら３２０レンダーよりも軽い筈。
但しこのゲームは二画面使う。
ゲームは「ＯｕｔＲｕｎ２０１９」。（横２５６ドット画面モードのゲームは、
これしか思い浮かばなかった。あ、「デンジャラスシード」があるか）
（訂正：「デンジャラスシード」は２５６モードではないです。（デモのみ２５６モード）。２５６モードなら「ヴォルフィード」ですね。）
設定は、４４１００、ＶＳＹＮＣＯＦＦ、Ｇｅフル画面。
一面で（ＭＩＸＥＲ外して）どの程度速度が出るか現状の目安をチェックしてみた。
ルールは、始めのトンネルは計測に入れない。（軽すぎ）下コースを進む。
高架の下まで進んだら終了。

ＦＳＫＩＰ０:　３２ｆｐｓ程度、３０まで落ちる
ＦＳＫＩＰ１:　４５ｆｐｓ程度、４０まで落ちる
ＦＳＫＩＰ２:　５２ｆｐｓ程度、４６まで落ちる
ＦＳＫＩＰ３:　５５ｆｐｓ程度、４９まで落ちる
ＦＳＫＩＰ４:　５５ｆｐｓ程度、５２まで落ちる
ＦＳＫＩＰ５:　５６ｆｐｓ程度、５５まで落ちる
ＦＳＫＩＰ６:　５７ｆｐｓ程度、５６まで落ちる

判ったこと、ＢＧは一画面でも二画面でも、違いはない。
ＯＢＪが入ると極端に落ちる。
５５ｆｐｓを過ぎるとよく判らない。（ＯＢＪが入って不安定）

測定結果は「程度」はよく判らんので、「落ちる」を目安にする事にしよう。
が、ＯＢＪは出方が不安定で明らかに目安にしかならん。
ソフトの選択を間違えたかもしれんが、こいつは比較的ＯＢＪが出ないゲーム。
数字を眺めても意味はないので、グラフにしてみよう。
ＦＳＫＩＰ０@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@OO
ＦＳＫＩＰ１@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@OOOOO
ＦＳＫＩＰ２@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@OOOOOO
ＦＳＫＩＰ３@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@OOOOOO
ＦＳＫＩＰ４@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@OOO
ＦＳＫＩＰ５@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@O
ＦＳＫＩＰ６@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@O

２５６レンダーの現状はこんな感じだ。「程度」はＦＳＫＩＰ２，３で多めに出てる。測定誤差だろう。
本来きれいな曲線にならなければ、辻褄が合わない。ので、測定結果に、信頼性がない。
対する「落ちる」はきれいな放物線状になっている。
こちらの方が目安として、信頼性がある。
５５ｆｐｓ以上の動作を目指すのなら、ＣＰＵやメモリの最適化が必須である事が判る筈。
（註：これはゲームのテストではありません。敢えて４４１００固定でバスに負荷をかける。ＰＳＰのバス負荷のテストです。念の為）