●WASAPI/ASIO対応の実装について

• 基本的には、ＦＲＯＭ氏のStorkeStyle<T>(以下、SST)での実装をそのまま流用している。SSTの設計詳細については、氏のサイトを参照のこと：

　http://mainori-se.sakura.ne.jp/sst/wiki.cgi?page=FrontPage

• 本体の全体的な設計方針の違いから、SSTでのサウンド実装の設計をいくつかDTXMania向けに変更した上で取り込んでいる。主な違いは以下の通り；
  • Global.cs相当の内容を、CSound.csのCSound管理 クラスに取り込んでいる。　(DTXManiaのFDKにはCSound管理 クラスがあるが、SSTのそれには、無い。)
  • タイマーの扱い。
    • 旧DTXMania: システムのタイマーを使用。演奏で使われているタイマーと同じタイマーである保証はないため、環境によって音ズレが発生する。AdjustWave機能で小節毎にタイムシークし辻褄合わせをしていた。また、1つのタイマーで、描画進行とサウンド再生の両方の面倒を見ている。
    • SST:　サウンド再生においては、クロックを自力算出する。また、描画進行とサウンド演奏は別々のタイマーで管理。
    • 新DTXMania: サウンド再生についてはSSTと同じ。全体進行については旧DTXManiaと同じ。
  • 旧来のDTXManiaプロジェクトで使用していたメソッド名を CSound管理 クラスやCSound クラス内にラッパーメソッドとして新設。
  • bassmixによるサウンドのミキシングのやり方を変えている。SSTでは単純に使用する全てのサウンドをミキサーに登録した上で使用しているが、DTXManiaではとあるサウンドの使用予定期間の前後で動的にミキサーに登録・削除している。理由は後述。

• SSTでは、WASAPI共有モードを使用できるが、DTXManiaでは使用不可。これは単純にWASAPIの適用範囲を占有モードに限定したかったためにこうしている。

• xaの再生は、xadec.dllを併用して行う。ただし、従来のDTXManiaでは、サウンドの再生長が5秒以上か否かによって疑似ストリーム再生かオンメモリ再生かの自動切り替えを行っていたが、新DTXManiaでのxa再生はオンメモリ再生のみの対応となる。
• WASAPI/ASIO利用時(=BASSライブラリでの再生時)は、xa以外は全てBASSで直接ストリーム再生される。(再生長がごく短いドラムのチップ音なども実際にストリーム再生されて いるのかどうかは未確認)

• DirectSound使用時は、xa, ogg, mp3をオンメモリ再生で扱う。mp3, oggのデコードは、SoundDecoder.dllで行う。xaのデコードは、xadec.dllで行う。
  • xa: ストリーム再生の実装が面倒だったため
  • mp3: 後述の通りデコーダ由来と思われる問題が見つかったため。
  • ogg: システムでのデコードが非常に低速であったため。

• DirectSound使用時、mp3はシステムのデコーダを使わずSoundDecoder.dll内のデコーダを用いる。システムのデコーダを使用時、サウンド先頭にノイズが載る場合があったため。(デコーダがID3タグに非対応だからか？詳細未調査。)

• WASAPI/ASIO動作中は、AdjustWavesの設定が自動で無効化される(OFF固定)。極力サウンド再生のタイマー(に沿ったオリジナルタイマー)で全体進行を行うことで、AdjustWaves動作が原理的に不要になるため。

• WASAPI/ASIO対応に当たって、BASSライブラリならびに、その.NETラッパーであるBASS.NETライブラリを使用している。
  • BASS: http://www.un4seen.com/
  • BASS.NET: http://www.bass.radio42.com/

• 使い方は、同ライブラリのサンプルコードや、DTXMania/SSTのソースコードを 参照のこと。例えば、DTXManiaのソースで言うと、FDK19/コード/03.サウンド/CSoundDevice(WASAPI|ASIO).cs や、同パスの CSound.cs あたりが、WASAPI/ASIO関連の実装となる。

●bassmixでのミキサー管理

• BASSでWASAPI/ASIOを使う場合、通常は一つのサウンドしか同時に再生できない。2つ以上のサウンドを同時に再生する場合は、bassmixライブラリを併用してミキシングを行う必要あり。
• ただし、ミキシングしているストリーム数が多くなると、再生が非常に重くなる。DTXManiaでギター曲を従来設計のまま再生しようとすると、チップ音x最大同時再生数(通常4)で1000越えのストリームがミキサーに登録されて再生が非常に重くなる。(私の環境(Win7x64, AMDの2.3GHzの4core)の場合、ミキシング数が100を超えると ピクピク重くなり始め、200を超えると我慢できない程度の重さになるようだった)

　このため、サウンドを使用するタイミングの前後で、動的にミキサーへの登録・削除を行うことで、演奏中に同時にミキシングしているストリーム数を減らし、再生負荷を軽くするよう、設計を見直している。

　この機能を実現するため、DTXファイルの読み込み時 (正確には、WAVチップ音を読み込んだ後) に、全チップの出現/消失タイミングをパースし、個々のチップの発生前後でミキサー登録・削除を意味する不可視チップを配置している。 　　DA: ミキサーに登録 　　DB: ミキサーから削除

　具体的な登録・削除のタイミングはチップの種類により異なる。

• ギター・ベース: 　発音の800ms前にミキサー登録, 消音の500ms後に削除・・・のはずが

　　　　　　実際には発音の500ms前にミキサー登録, 消音の800ms後に削除。

• 効果音: 　　　　　発音の200ms前にミキサー登録, 消音の500ms後に削除・・・のはずが、

　　　　　　実際には発音の500ms前にミキサー登録, 消音の800ms後に削除。

• その他(ドラム等): 発音の1000ms前にミキサー登録, 消音の800ms後に削除

　結果的には開発当初の意図とは異なる実装になってしまっている(バグ)が、試しに意図を正確に反映したところかえって(私の環境では)再生負荷が増えてしまったため、096リリース時点では触らずにそのままにしている。

• ミキサーへの登録・削除処理は、メインスレッドで実行している。具体的には、演奏画面のメインループでミキサー登録/削除指示のキューをチェックし、指示があれば最大2つ分ずつ処理をする、というもの。 (キューへの操作登録も、同じくメインスレッドのメインループ内で行う)

　最初は別スレッドにイベントを飛ばして、別スレッド内で適当な時間間隔を空けつつミキサー処理を実施するという実装を試みたが、再生負荷が改善されなかった。しかし、ほぼ同じ処理をメインスレッド内で処理したところ、大幅に再生負荷が改善されたため、現在はメインスレッドでミキサー操作処理を行う設計としている。

• ミキサー操作(登録・削除)の頻度は、VSyncWait=OFFの時で7msあたり最大で2回ずつ、VSyncWait=ON時は、16.7msあたり最大で2回に制限している。　(最初は各々1回ずつにしていたが、ベンチマーク用のDTXデータ (信心ワールドエンドExt)でミキサー登録が間に合わないケースが見受けられたため、同2回ずつに増やした)

• 同時ミキシング数を更に削減するため、チップの種類毎に最大同時再生数を変えている。具体的には
  • ドラム: 　　　　Config.iniのPolyphonicSoundsで指定した値 (デフォルトで4)
  • ギター・ベース: 2か1 (!Polyphonic..が1のときに1, さもなくば2)
  • BGM/SE: 　　　　1

DTXMania プロジェクト ドキュメント

DTXMania プロジェクトWikiページにようこそ。

ユーザの方へ：

プロジェクト参加者以外の方は、この wiki は使用できません（参照のみ可能です）。

1. ユーザ用ドキュメントに関しては、DTXMania 公式ページの「Q&A」を参照下さい。
2. 要望・バグ報告に関しては、項目ごとに 新規チケットを発行 して下さい。
   1. 要望や報告が複数あるときは、「１チケットにつき１要望or1報告」として、要望・報告の数だけ個別にチケットを発行して下さい。
   2. その項目に関する議論は、フォーラムではなく、それぞれのチケットの中で行います。
   3. チケット内でコメントの投稿などが行われると、「チケット作成者」「プロジェクト参加者」「そのチケットをモニタしている人」すべてに更新メールが通知されます。
   4. よって、チケット作成者やモニタを行いたい人は、SourceForge.JP のアカウント登録を行って、メールを登録しておくことをお勧めします。（Webブラウザ上に表示されるフォーラム最新記事一覧のような機能は、チケットにはありません。）
3. 質問に関しては、まず DTXMania 公式ページの「Q&A」を参照いただき、それから「質問フォーラム」をご利用下さい。
4. 本プロジェクトのチケットやフォーラムは、匿名投稿が可能です。SourceForge.JP のアカウントを取得していない人でも投稿が可能です。（当然、その後の更新メール通知は行われませんが。）

開発者の方へ：

ここは、開発者用のドキュメント配置スペースとして利用して下さい。
（例：開発者フォーラムで議論し、決定事項を本ページに記録する、etc,..）

文法などのドキュメントは、サイドバーに標準で入っているリンク、または Wikiガイド を参照してください。

以下、開発用のドキュメントになります。

• 新機能の仕様
• 開発メモ
• WASAPI/ASIO対応について
• プロジェクト運用手順（管理者用）

Outline

1. SlimDXへの修正部分
2. SimpleFrameworkへの修正部分
3. SlimDXのビルド方法(備忘録)

SlimDXへの修正部分

• JoyPadからのBufferedInputが使えなくなるデグレードに対する処置
• POV/HAT入力配列を全て-1(センター)に初期化するコードを追加
• DIDEVICEOBJECTDATA構造体のdwOfsメンバ相当の値を取得できるプロパティを、SlimDXのJoystickState()に追加。POV/HATが離されたことを検出するため。

SimpleFrameworkへの修正部分

• ウインドウリサイズ対応で、WndProcのWM_SIZINGイベント処理を追加。(GameWindow.cs)
• ウインドウリサイズ対応で、BackBufferを640x480固定にして、物理解像度=640x480を維持。(GraphicsDeviceManager.cs)
• ウインドウリサイズ対応で、WndProcのMENU_VIEWイベント処理を追加し、システムメニューへ、640x480に戻す処理を追加。(GameWindow.cs)
• ウインドウがアクティブでないときのスリープ時間設定処理を追加。VSync時にはスリープしないよう注意。(GraphicsDeviceManager.cs)
• USBサブモニタなど、GetDeviceCaps()でGPFが発生する場合への対応。(Enumeration9.cs)

SlimDXのビルド方法(備忘録)

• まずはＦＲＯＭさんのサイトを参照のこと

http://mainori-se.sakura.ne.jp/slimdx/wiki.cgi?page=%B8%F8%BC%B0%A5%D3%A5%EB%A5%C9%BC%EA%BD%E7

• その上で、以下のポイントに注意
• ビルドの構成にPublicを指定する
• 署名に用いるキーペアの生成方法:
• * すべてのプログラム-Microsoft Visual Studio 2008-Visual Studio Tools\Visual Studio 2008 コマンド プロンプト、として、VisualStudioの環境変数設定済みのDOS窓を開く
• * sn.exe -k d:\slimdx_yyagi.snk などとして、キーペアを生成する
• * VisualStduio上で、ソリューションのプロパティから リンカ-詳細-キー ファイル、で先のキーペアを指定する
• * ビルド後のイベント: ファイルパスを全部"～"でくくる。以下例：

  copy "$(ProjectDir)\..\docs\SlimDX.xml" "$(OutDir)"
  mt -manifest SlimDX.dll.x86.manifest -outputresource:"$(TargetPath)";2
  sn -R "$(TargetPath)" D:\slimdxKey_yyagi.snk
  

Outline

1. 新機能の仕様
   1. MIRRORモード
   2. フリップ機能
   3. 達成率のグラフ表示
   4. リザルト画像自動保存機能
   5. 曲順のソート機能
   6. タイミングアジャスト機能
2. ダメージ/回復量
3. Config.ini ファイルに関する新機能
   1. HHVelocityMin, ..., VelocityMin
4. score.iniファイルに関する追加仕様

MIRRORモード

ドラムのレーン構成の左右入れ替えをする、MIRRORモードの仕様を記載する。

OPTION-Drums に、MIRRORを新設する。 選択肢は OFF, M-A, M-B, LEFT の4つで、それぞれレーン構成を以下のように変更する。

MIRROR(OFF)
LC  HO+HC SD BD HT LT  FT  CY+RD

MIRROR(M-A)
無   CY+RD LT BD HT SD  FT  LC+HO+HC

MIRROR(M-B)
CY    RD  FT BD LT HT  SD  LC+HO+HC

MIRROR(LEFT)
CY+RD FT  LT HT BD SD HO+HC   LC

• 達成率について、M-A, M-Bの場合はこれを半分にする。LEFTの場合は減らさない。
• ドラム音のパン(定位)について、入れ替わりの発生したレーンについては、これを左右逆にする。レーンの位置に応じた「定位を何％右に移動」といった制御は行わず、単純な左右反転に留める。
• パッド入力のアサインについては、モードの切り替えに伴うアサイン変更を、特に行わない。
• Config.ini では、[PlayOption] 内の DrumMirror にて 0～3の値として保持する。0がOFF, 1がM-A, 2がM-B, 3がLEFTを表す。
• オプション設定表示では、下記画像の位置に相当の設定情報を表示する。具体的にどのような表示を行うかはTBD。
  

  OPTION設定表示におけるMIRROR設定の表示位置

議論の履歴: チケット#23547を参照。

フリップ機能

088以降、選曲画面でギターまたはベースから Pick-G-G-Pick と入力することにより、ギターとベースを入れ替えることができる(FLIP機能)。これにより、ギターとベース機器をいちいち持ち替えずに切り替えることができる。

ただし088のFLIP実装には問題があるため、089以降を利用のこと。

議論の履歴: #24063を参照。

達成率のグラフ表示

088以降、ドラムスのみ、OPTION/Drums/GraphをONにすることで、演奏画面に達成率をリアルタイムにグラフ表示する。

議論の詳細: #24074を参照。

リザルト画像自動保存機能

089以降、ランクもしくは演奏型スキルポイントを更新すると、演奏したDTXデータのあるフォルダに自動的に dtxファイル名.yyMMddHHmmss_DRUMS_SS.png という形式でリザルト画像を保存する。(SaveScoreIni=ONの場合のみ)

今後、[F12]押下などで、最高記録を更新しない場合でもリザルトを手動でキャプチャできるようにする予定。

議論の履歴: #24609を参照。

曲順のソート機能

089以降、選曲画面でBD-HT(Drums)またはG-G-G(Gt/Bs)と入力することで、曲順のソート画面をポップアップで呼び出せる。

• Title, Level, Best Rank, PlayCount, SkillPoint, Date で昇順/降順のソートができる。
• TitleとDateは、今どの難易度を選択しているか(L1～L5)に関わらないソートとなる。
• Dateは、要するにDTXファイルの作成日(最終更新日)でのソート。
• Level, Best Rank, PlayCount, SkillPoint は、今選択している難易度(L1～L5)での値でソートする。なので現状、今選んでいる難易度の指定がない曲データ(例: L1がなくてL2とL3しかない等)は、正しくソートされない。
• 現状、各BOXでのソート結果は、DTXManiaを終了するまでは覚えているが、終了すると忘れてしまう。(今後対応を検討する)

(終了後も覚えさせるのはちょっと大変)

議論の履歴: #23615を参照。

タイミングアジャスト機能

087以降で搭載した、入力遅延の補正機能について、仕様を記載する。

一般的に、キーボードやジョイパッドなどからある時刻にユーザーが入力を与えたとして、 実際にその入力がDTXMania(プログラム)に受理されるまでには時間差(入力遅延)がある。 タイミングアジャスト機能は、この入力遅延に対してオフセット値を設定することで、 ユーザーの入力タイミングと、DTXManiaのヒット判定(Perfect/Great...の判定)に 違和感がないようにするものである。

[ユーザーからの入力発生]
↓
(時間差1) (入力遅延)
↓
[DTXManiaが入力を受理]
↓
[DTXManiaの画面処理実行・チップ音再生]
↓
(時間差2) (出力遅延)
↓
[実際に画面が更新される＋音が再生されて、ユーザーがそれを認知する]

OPTIONの、Drums/Guitar/Bass それぞれの、InputAdjust 項目に値を設定することで、 DTXManiaの判定時刻へのオフセットを設定できる。 例えば、ドラムの入力遅延が10msあり、ギターの入力遅延が20msあるような環境では、 DrumsのInputAdjustを-10にし、GuitarのInputAdjustを-20とすることで、 DTXMania本体はそれぞれの入力遅延を相殺した入力判定を行うようになる。

個々のInputAdjustには、-100～100msの値を設定できる。初期値は0。 機能の性格上、ここに正の値を設定することはないと思われるが、 念のため設定はできるようにしてある。

なお、あまりに入力遅延が大きいような環境の場合は、たとえ入力タイミングを補正したとしても 最終的なサウンド出力までの時間が大きくなっていることに変わりはないので、 演奏そのものを楽しめないであろう。

議論の詳細: チケット#23580を参照。

更に、088では、OPTION画面だけでなく、演奏画面からも、カーソルキーの左右でInputAdjustの値を変更できるようにする。 shiftを押しながらだとギターの、altを押しながらだとベースの、何も押さないとドラムの、 InputAdjustを変更する。 ctrlを押しながらだと1ms単位で、押していないと10ms単位で調整を行う。

表にまとめると、以下のようになる。

(以下おまけ)

CTRL	SHIFT	ALT	カーソルキー	実行される機能
			↑	ドラムスクロール速度アップ
			↓	ドラムスクロール速度ダウン
	*		↑	BGMAdjust +10ms
	*		↓	BGMAdjust -10ms
*	*		↑	BGMAdjust +10ms
*	*		↓	BGMAdjust -10ms

ダメージ/回復量

• ゲージは-0.1から1.0までの値を取る。(1.0＝満タン, 0.3未満=Danger, 0.0=空っぽ, -0.1以下=閉店)
• チップ演奏の判定結果により、下記のようにゲージが増減する。

086以前:

判定	Dr	Gt/Bs
Perfect	+0.10	+0.15
Great	+0.06	+0.09
Good	+0.02	+0.03
Poor	+0.0	+0.0
Miss	-0.035 * 係数	-0.035 * 係数

• 086以前でのMissの係数の具体的な値は、DamageLevel が Small, Normal, Large の時で、それぞれ 0.6, 1.0, 1.6。

087以降:

判定	Dr	Gt/Bs
Perfect	+0.004	+0.006
Great	+0.002	+0.003
Good	+0.0	+0.0
Poor	-0.02	-0.03
Miss	-0.05 * 係数	-0.05 * 係数

• 087以降でのMissの係数の具体的な値は、DamageLevel が Small, Normal, Large の時で、それぞれ 0.5, 1.0, 1.5。

議論の詳細: チケット#23625を参照。

Config.ini ファイルに関する新機能

HHVelocityMin, ..., VelocityMin

電子ドラムのHHのベロシティ入力下限値を HHVelocityMin で設定できる。このベロシティ値に満たない入力は切り捨てられる。 これは、主にRoland系の電子ドラムのHHペダルの挙動がDTXManiaの動作に影響が出ないようにするために導入された機能で、Roland系の場合はHHVelocityMinを20程度に設定すること(デフォルト)。 逆にこの値を小さく(0にするなど)しないと入力がうまく入らない電子ドラムもあるので注意が必要。(Awowo系など？)

087以降では、HH「以外」のベロシティ入力下限値を、VelocityMin で設定できるようにした。 これは、共振防止機能を持ち合わせていない電子ドラムキットを想定した機能である。

088以降では、HH「以外」のベロシティ入力下限値を、!SDVelocityMin, !BDVelocityMin などといったようにレーンごとに独立して指定できるようにした。代わりに087で導入した汎用のVelocityMinは廃止した。

議論の詳細: #23857を参照。

score.iniファイルに関する追加仕様

• 086以降、従来あったPlayCount(演奏開始回数を記録)に加えて、ClearCount(クリア回数を記録)を追加。
  議論の履歴: チケット#23596を参照。

• 087以降、LastPlay(.Drums, .Guitar, .Bass) セクションを追加し、最終プレイの内容を保持するようにした。
  議論の履歴: チケット#23595を参照。

• 089以降、BestRank(Drums, Guitar, Bass) 項目を追加し、HiScore/HiSkillに依らないベストランクを保持できるようにした、
  議論の履歴: チケット#24459を参照。

Outline

1. プロジェクト運用手順（管理者用）
   1. DTXMania パッケージのリリース手順
   2. リポジトリの再構築手順

DTXMania パッケージのリリース手順

本作業は、「プロジェクト管理者」または「リリース管理者」（ファイルリリースマネージャ）の権限を持つユーザのみが行えます。

使用する Subversion クライアントは TortoiseSVN を想定しています。

(1) プロジェクトメンバへ周知する。

• コミット予定のデータがあれば、再構築作業前にコミットしてもらう。
• 作業開始後は、タグの作成（(3)の作業）が完了するまでコミットを禁止する旨を伝える。

(2) ソリューションのバージョン情報を更新し、コミットする。

1. 「trunk/DTXManiaプロジェクト」内のソリューションを VC#2008Express で開く。
2. 「コード/全体/CDTXMania.cs」内にある VERSION 定数を修正する。
3. DTXManiaプロジェクトの [プロパティ]→[アセンブリ情報] 画面で、バージョン番号を修正する。
   • 基本的に、アセンブリバージョンとファイルバージョンは同一のものとする。
4. FDKプロジェクトの [プロパティ]→[アセンブリ情報] 画面で、バージョン番号を修正する。
   • public なインターフェースが追加変更された場合は、アセンブリバージョンを増加する。
   • そうでない場合は、ファイルバージョンの末尾の数値を増加する。
   • 何も変更が加えられていない場合は、どちらのバージョンも現状維持とする。
5. ソリューションを保存し、VC#2008Express を終了する。
6. trunk/ を「SVN コミット」する。

(3) リポジトリ上で、新しいタグを作成する。

1. ローカルPCの作業コピー上の trunk/ フォルダを選択し、右クリックしてメニューから「TortoiseSVN」→「ブランチ／タグ」を選択する。
2. 「コピー（ブランチ／タグ）」ダイアログが表示されるので、「先URL」欄にリポジトリ上の新しいタグフォルダのURLを指定し、タグを作成する。
   先URLの設定例：「https://svn.sourceforge.jp/svnroot/dtxmania/tags/101102DTXMania085)」
   このとき、リポジトリの tags/ フォルダ内に、同名のフォルダが存在していないことを確認すること。
3. この作業が完了次第、メンバはリポジトリの trunk/ フォルダへ任意のコミットを再開してかまわない。

(4) ローカルPCの作業コピーフォルダの tags/ について、「SVN 更新」を実行する。

• (3)で作成した新しいタグをローカルPC上に取得するため。
  （(3)の作業は、ローカルPC上ではなくリポジトリ上で実行されていることに注意）

(5) 取得したタグから、リリース用 DTXMania をビルドする。

• (4)で取得したタグの「DTXManiaプロジェクト」フォルダ内のソリューションを VC#2008Express で開き、Release 構成をビルドする。（trunk/ 内のソリューションではないことに注意）
• ビルドが完了すると、(4)で取得したタグの「実行時フォルダ」内に、ビルドされた新しい DTXManiaGR.exe と FDK.dll が自動的にコピーされている。

(6) (4)で取得したタグの「実行時フォルダ」の中身を zip で圧縮し、リリース用のファイル名を付与する。

• ファイル名の例：「DTXMania085(101102).zip」
• 留意事項：
  • ここまでのやり方でも問題はないが、新しいコピー（タグ）を作成し利用している以上、zip の中にあるすべてのファイルの「作成日付」が、(3)を実施した日に変更されてしまっている。
  • そのため、可能であれば、新しいリリースで変更があったファイルのみを直前のバージョンの DTXManiaアーカイブに上書きする形で zip を作成することが望ましい。

(7) (6)で作成した zip のリリースを行う。

1. SourceForge.JP の「ダウンロード」タブ→「管理」を選択する。
2. [新規作成] リンクをクリックする。（[新規パッケージの作成] リンクではないので注意）
3. 「バージョン」「リリースノート」「変更履歴」をそれぞれ記入する。
   • バージョンの例：「085(101102)」
   • リリースノートの例：「リリース85です。」
   • 変更履歴：過去のリビジョンログを元に記述する。
4. 「ファイル」欄に(6)で作成した zip ファイルを参照指定する。
   • ステータスは「有効」のまま。
   • 「標準ダウンロード」にチェックを入れる。→ リストが表示されるので「Windows」を選択し、[閉じる] をクリックする。
5. [リリースの作成] ボタンを押下する。

(8) ダウンロード時の標準リリースの切り替え行う。

1. SourceForge.JP の「ダウンロード」タブ→「管理」を選択する。
2. リリースの一覧から、直前のリリースバージョンのリンクをクリックする。
3. 「ファイル」欄の右端にある「標準」のチェックボックスのチェックを外す。
4. [リリースの更新] ボタンを押下する。
5. リリースの一覧から、最新のリリースバージョンのリンクをクリックする。
6. 「ファイル」欄の右端にある「標準」のチェックボックスのチェックを付与する。
7. [リリースの更新] ボタンを押下する。
   これで、SourceForge.JP がことあるごとに表示する「ダウンロード」リンクのターゲットが、最新のリリースファイルに変更される。

(9) SourceForge.JP の「ニュース」に、リリースが完了した旨を伝える記事を投稿する。

リポジトリの再構築手順

※2010/10/31～11/1にかけて行った作業を元に記載しています。

本作業は、「プロジェクト管理者」の権限を持つユーザのみが行えます。

使用する Subversion クライアントは TortoiseSVN を想定しています。

(1) プロジェクトメンバへ周知する。

• コミット予定のデータがあれば、再構築作業前にコミットしてもらう。
• 作業開始後は、すべての作業が完了するまで、リポジトリに対するすべてのアクセスを禁止する旨を伝える。

(2) 全リビジョンのログを保存する。（必要あれば）

• 次のリリースでの変更履歴の防備録として。

(3) リポジトリの内容をローカルPC（作業コピーフォルダ）へ「SVN 更新」を行う。

• 最新のリポジトリをローカルPC上に確保するため。

(4) ローカルPC上で、作業コピーフォルダから任意のフォルダ（デスクトップ上など）へ全件エクスポートする。

• Subversion の管理下から外れたツリーを作成しておく。

(5) SourceForge.JP プロジェクトへ「リポジトリ初期化依頼」チケットを申請する。

• 申請ページ： https://sourceforge.jp/ticket/newticket.php?group_id=1&type=114
• 「プロジェクト管理者」の権限がある者が申請し、プロジェクトのUNIX名を告げる必要があります。さもないと拒否されます。

(6) SourceForge.JP のスタッフがリポジトリを初期化する。

• 完了後、スタッフから該当チケットにその旨のコメントが追加される。
• リポジトリが初期化されていることを確認し、該当チケットにお礼を記入すると同時に、状況欄を「完了」に変更する。

(7) ローカルPC上に、新しい作業コピー用フォルダを作成する。

• 初期化後の空のリポジトリを正として作業コピーを作成するため。

(8) (7) のフォルダに「SVN チェックアウト」し、Subversion 管理下に含める。

• 当然、チェックアウトされたデータ件数はゼロ件となる。

(9) (4)で作成した管理外フォルダから、(7)のフォルダへデータを全件 Windows コピーし、ルートフォルダを「SVN 追加」する。

• 追加中にエラーが発生して停止してしまうことが何度もある（.svn/tmp のファイルが壊れてるたらどーたら）が、そういうときは、もう一度ルートフォルダを「追加」すれば、何事もなく残りの作業を継続できる。ええ。何度エラーが出ても。（涙

(10) (7)のフォルダに対して「SVNコミット」を実施する。

• 無事に全件コミットできれば、リポジトリ再構築作業は完了。

(11) プロジェクトメンバに、作業が完了した旨を周知する。

• これまでの作業コピーを破棄し、新しく SVN チェックアウトし直してもらう。