[1-] [101-] [201-] [最新50] [検索] ※標準/名無しさん
18 黒猫SPCに関する話題 その2(242)
1 管理者 : 2011-02-09 00:59:53 [87zrFHBw]- 黒猫SPCやID6666に関する話はここでお願いします。
SPC自体の話や、script700関係でもOKです。
SPCの在処なんか聞かないように。
前スレ>>>10 42 127 : 2012-11-08 07:26:25 [rsyw1vzw]- ＞逆位相パンのDSP表示
SPCToolでDSP Register見てみたら豪快にもメインボリュームで逆位相にしているようでした。
あと、エコーもマイナスでした。
＞SPCToolじゃだめですかね？
おおおおおおおお
こういうソフトウェアも存在してたんですね…その手の情報に疎くって知りませんでした。
結構ガッツリPCMが入っていてビックリしました。ADPCM侮れませんね。
そして音色単品だと全然違う音に聞こえるというか何が起こってるんだコレ。ECHOじゃ無さそうだしフィルタ無双・・・？
＞DSP700のfps周りの話
すいません、適当ぶっこいてました。
KuronekoSPC.exeはtimeGetTimeを使わずGetTickCountを使っているものの、TTimerはGetTickCountとか以前に只のSetTimerを使っていてそっちの問題だったようですゴメンナサイ。
このあたりのタイマ能力はその環境のHAL等に依存するらしく、HALが違えば同じバージョンのWindowsでも違う精度になるようです(参考1)。前の投稿で書いた参考ページのようにシステムタイマがマルチメディアタイマを更新する環境とかもHAL依存なのか・・・なぁ？
環境によってはマルチメディアタイマよりGetTickCountなんかのシステムタイマの方が精度が高いらしい(参考2…そういう環境が現存するのかは不明)ですが、その辺はサポートしている最小分解能(参考3)に依存するようなのでどっちが良いとかは一概には言えないようです。
GetTickCountをtimeGetTimeに差し替えても何も変わりませんでしたが、SetTimer APIをtimeSetEvent APIによるSendMessage(WM_TIMER)処理に差し替えるプロキシDLLを作って実験した所Spectrum=0,Interval=2で500fps程までは正確にカウントできました。
Interval=100でのPassedTime下一桁の安定度もかなり上昇したので、60FPS以下で使う場合にもそこそこ有効な結果になりました。
(が、無理に差し替えた副作用か、プロキシDLLではエラー多発で実用には難有りでした。タイマ以外がWM_TIMER送信してる副作用やOnTimer処理中にメッセージポンプが回ってるヤバ気な謎仕様とか色々関係してると思います。)
VCLを持ってないのでよく知らないもののマルチスレッドでVCL触ると不味いらしいと聞きますが、timeSetEventを使うとタイマ用スレッドが自動生成されてコールバックはそのスレッドで走ってしまう(参考4)そうです。
マルチメディアタイマ使うとしたらコールバック関数からSynchronize使ってOnTimer関数を呼び出すとかそういう事になる・・・んでしょうか？
参考1 http://hp.vector.co.jp/authors/VA007219/rtc_pic.html
参考2 http://bm98.yaneu.com/rsp/rsp70to78.html
参考3 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=7&topic=27114
参考4 http://blogs.msdn.com/b/windows_multimedia_jp/archive/2009/02/16/9425129.aspx
＞ADSR
一般的なADSRのRってキーOFFしてから音量ゼロになるまでの時間のはずなんですが、SPCの場合Rに値が入ってるとDecay終わった瞬間にキーOFFしてる扱いなんですね…ADSRって呼んでもいいのだろうかコレ。
ゲームによってはゲインモードのExpとか使ってADSRのReleaseを再現してるっぽいけどそれでいいのかSPCのADSR。
[ALL] [LAST100] [1-100] |