EmuCR Feeds
Email Us

EmuCR:DeSmuMEDeSmuME ReRecording v0.9.4+ (r2832) is released.DeSmuME ReRecording is the re-recording branch of DeSmuME 0.9.4.This is the development project for this branch of DeSmuME. Its primary function is to expand features related to the creation of Tool-Asssisted movies.

DeSmuME ReRecording v0.9.4+ Features
* Less desyncs (savestate has been updated, but you can read old savestates as well)
* Lua scripting with advanced graphic functions (they works only in gui.register callback)
* Path settings
* State rewinding (it's not tested at all, oh well)
* Magnification filters like hq2x
* Lag reduction options (details described below)
* Other little bugfixes (ex. frame advance improvement)

DeSmuME ReRecording v0.9.4+ Changelog:
2009-09-09 13:05 - Lag reduction option is separated to 2 options. Added savefile hack menu option from 0.9.4 branch for upgrading savefile sizes when one has been careless and used the wrong savefile size. (r2855)
2009-09-08 13:45 - Improved LagReduction timing. To know what has been changed, see the diff of r2844. (r2845)
2009-09-06 11:00 - Add LagReduction option to INI secretly (r2831; default = 0 (0.9.4 non-dev timing). The timing of LagReduction=1 is different from both of 0.9.4 dev and non-dev). Improved input display a little (r2832)
2009-08-22 23:30 - Lua drawing now works but only in gui.register callback (r2779)
2009-08-18 15:30 - Fix random desync (make 'samples' in SPU.cpp to be zero at SPU_Reset) (r2769)
2009-08-16 17:00 - First upload (r2766)

Download: DeSmuME ReRecording v0.9.4+ (r2832)
Source:Here

1 Comments:

  1. さて、ボイス等ストリーム音声にノイズが入るのは、エミュレーション精度の問題ではありません(ファイルにwav録音するとわかる)。これは、動作が遅い場合にそれを補うだけの音声サンプルを生成するような仕様にしてあることで、まだ続きの音声をゲームが書き込まないうちに余計な読み込みを行ってしまうことで生じてしまうのです(おそらく)。wav録音で記録するのと同じ要領でDirectSoundに書き込みを行えば、ゲーム側からの読み込みで波形が"途切れることは"ないのです。

    と、前置きしたうえで、やっつけ
    http://gocha.s1.zmx.jp/down/public/desmume_snapshot/desmume-spuNoUserWorkaround.zip

    カーソル位置確認を怠っているせいか、初期設定バッファが短いせいか、結局のところ、こちらもノイズが入ります(加えて、wav録音と同様の書き込み方をしているので、書き込みの回数が多すぎる)。ただし挙動の違いの性質上、バッファ長を10000~20000のように長くしてしまえば、一応ノイズを感じることなく一連の音声を聞くことはできます。代わりに、音声は映像に遅れて、そのうえしばしば巻き戻ることは避けられませんが……。

    結局、成果としてはいまいちなように思うので、このアプローチはダメかもしれません。zeromusさんはBlip_Bufferを通して音声を伸長してバッファに書き込むことを考えていたようですが、そのほうが満足いく結果が得られそうな感じがします(伸長にあたってどの程度の速度が犠牲になるのかは疑問ですが)。
    ※伸長する場合、ADPCMはこれまでどおりで、PCM16(&8)のみコアの分を伸長するとなかなかよさそうに思いますが、そんな器用なこともうまくできるんでしょうか。謎です。

    たぶんこれでは需要もないので、ひとまずコミットしない方向で。

    ReplyDelete

Can't post a comment? Try This!