« CAMPFIRE には掲載されず | メイン | 吉里吉里2 VCビルド対応ファンディング調査 »

2013年04月08日

吉里吉里 その他の開発日誌/吉里吉里Z 開発:: 吉里吉里2 VCビルド対応検討項目

    

C++ Builder でのみビルド出来る吉里吉里2 を Visual C++ でもビルド可能にする。
また、レガシー機能は削除して、モダンな機能取り込みも考慮する。

吉里吉里2 は C++ Builder 5 ~ 2007 でビルド可能ではあるが、この制限が保守性において懸念材料となっている。
オフィシャルビルドは C++ Builder 5 で行われているが、現在 C++ Builder 5 は入手できない。
この問題を解消するべく Visual C++ でもビルド可能にする。

保守性等のため完全互換ではなく、いくつかの機能の削除と VCL からの変更による挙動の変更が考えられるが、ゲーム実行等実使用において問題がない動作を目指す。
検討している内容を適用すると KAG3 はそのままでは動かない変更が入る。

Windows8 で顕在化してきている問題として以下の物がある。
・IME切り替え周りで VCL が使用している旧APIで問題があり、バイナリ書換えにより対処している。
・DirectX 7 の問題か、クリッピングがおかしくゴミが残る(C++BuilderでもDirectX 9等への対応は可能と思われる)。

これ以外にもいろいろと苦しくなってきている部分はある。


以下、変更検討事項。
問題等が予想される場合は、コメント等でご指摘いただければ再考する。
また、開発中に顕在化した問題によって他に変更が入る可能性もある。

予定している変更項目。
・VCL を排除。
・コンソールやコントローラー等のデバッグ機能の切り離し。
・DirectX 7 の描画は DirectX 9 へ変更。
・MIDI / CDDA / Pad クラスは削除。
・KAGParserクラスの本体からの削除。
・libjpg をSIMD版へ変更し高速化。
・zlib/libpng を最新版へ。
・エンジン設定用のオプションファイルはexeから分離、もしくはリソースへの移動。
・正規表現エンジンを鬼車へ変更。
・ERIフォーマットの非サポート。
・コンパイル時のワーニングを全てなくす。
・メニュー機能(Menuクラス)の削除デバッグオプションもしくはプラグインへ。
・その他 Windows/Layer クラスでいくつかのメソッドの削除。


・VCL を排除。
C++ Builder 以外でコンパイル出来るように VCL は排除する。

・コンソールやコントローラー等のデバッグ機能の切り離し。
コンソール機能はデバッガ側頼りにする。
ログファイルは残す。
コンソールやコントローラーのデバッグ機能はリリース時はない方が好ましい。

・DirectX 7 の描画は DirectX 9 へ変更。
Windows8 でクリッピング問題が出ているようなので、DirectX 9 へ変更する。
解決するかどうかは不明。

・MIDI / CDDA / Pad クラスは削除。
レガシーな機能と思われる。

・KAGParser は本体から分離。
現在はクラスプラグインが実現できるようになっているので、プラグインとした方が良い。
メンテナンスがきわめて困難なソースコードとなっているので、個人的には完全互換ではない別物にした方が良いと思っている。

・libjpg をSIMD版へ変更し高速化。
・zlib/libpng を最新版へ。
現状に合わせて置き換え

・エンジン設定用のオプションファイルはexeから分離、もしくはリソースへの移動。
ややトリッキーな方法なので削除。

・正規表現エンジンを鬼車へ変更。
boost の特定バージョンに依存した正規表現エンジンになっているが、移植性を上げるため鬼車へ変更する。

・ERIフォーマットの非サポート。
要らないと思われる。

・コンパイル時のワーニングを全てなくす。
エラーを探すのが辛いので、ワーニングは全てなくす。

・メニュー機能(Menuクラス)の削除デバッグオプションもしくはプラグインへ。
Windows 8 タブレットでフルスクリーン時にタッチだとメニュー出せないため、あっても使えない。
他の操作で出来るように組み込むべき。
ツール用途ではないと厳しいという意見を踏まえ、標準ではOFF 、デバッグオプションもしくはプラグインで ON 可能と言う形へ。

・その他 Windows/Layer クラスでいくつかのメソッドの削除。
Windows クラスのタブレット化において、問題となりそうな機能やゲームとして不要と思われる機能の削除。
ただ、互換性も考慮して取捨選択する。
Layer クラスで互換性のために置いているとドキュメントに記載されているメソッドの削除。


変更によって影響が出る可能性がある項目
VCL では、不可視のメインウィンドウを内部で作り、メッセージ等の処理をそこである程度行う様な構造になっているが、VC で作る場合、最初に生成されたウィンドウをメインウィンドウとして扱う一般的な方法にすると思われるので、細かい部分での挙動が変わる可能性がある。
krflash は非サポートとなる可能性がある。


工数の関係から状況次第で対応検討項目。
・マルチタッチ対応。
・フリック等ジェスチャー系の入力。
・ペン入力。
・画面の向き対応。
・Ogg Vorbis を高速化プロジェクトのものへ置き換え。
・アセンブリコードをイントリンシックで書き換え、SSE2 のサポート。
・64bit対応(イントリンシック書き換え必須、ポインタサイズ考慮必要)。



投稿者 Takenori : 2013年04月08日 20:35



コメント

色々な事情が混ざってて,ざっと見た感じ,

・コンパイル環境(脱BCC,VCL)
・Windows8対応
・タブレット操作対応
・レガシー機能

に分類されて,これ全部一気にやろうとすると失敗しそうなので,もうちょっと揉んだ方が良さそうな気がしました。


>・VCL を排除。

src/core/*/win32 以下をほぼ全て書き直しか,あるいは吉里吉里で使用する部分のVCLの互換層を作成するかのどちらかだと思いますが,いずれにせよ大変な作業になりそうですよね。


>・コンソールやコントローラー等のデバッグ機能の切り離し。
>・DirectX 7 の描画は DirectX 9 へ変更。
>・MIDI / CDDA / Pad クラスは削除。
>・KAGParserクラスの本体からの削除。

ここらへんは賛成。

デバッグ機能はkrdevui相当に入れてしまって良い気がします。

DX9未満は化石だと思いますのでDX9化も問題なし。
ただ,現行verでもDrawDeviceプラグイン作ればDX9化できるのではないかと思うので,Win8クリッピング不具合が解消できるかのテストはできそうな気がします。

MIDI/CDDAはレガシーなので切っても問題ないでしょう。
Padは自分はテキスト表示でたまに使うことがありますが,代替手段がないわけではないので切っても困ることは無いかと思います。

KAGParserもプラグイン化で問題ないと思います。


>・libjpg をSIMD版へ変更し高速化。

/arch依存なのは微妙にどうかと思いますが,ビルドシステム側の対応で通常版と選択できるならまぁ問題ないかと…


>・zlib/libpng を最新版へ。
>・エンジン設定用のオプションファイルはexeから分離、もしくはリソースへの移動。
>・正規表現エンジンを鬼車へ変更。
>・ERIフォーマットの非サポート。

ここらへんも異存ないですが,正規表現エンジンは他の選択もできると助かります。(いっそプラグイン化?)


>・コンパイル時のワーニングを全てなくす。

コンパイラによって警告基準が異なることがあるのがちょっと悩ましい気がしますが,とりあえずVC++前提ならそれはそれで良いと思います。


>・メニュー機能(Menuクラス)の削除。

メニューは個人的には割と必要なんですが,
理由がフルスクリーンでのタブレット操作できないからというのもちょっと納得が行きません。


>・その他 Windows/Layer クラスでいくつかのメソッドの削除。

むしろLayerクラスは画像処理系とイベント処理系を完全に分離して,TJSスクリプト側で互換を取るのが良い気がするのですが…ダメですかね…


あと,解像度変更のフルスクリーン処理もレガシーだと思いますので,ここらへんもメス入れて良いかと思います。(今はもう仮想フルスクリーンのみで誰も困ることない気がします)


--
miahmie

投稿者 Kyoh Mikami [TypeKey Profile Page] : 2013年04月08日 21:47

・コンパイル環境(脱BCC,VCL)
・レガシー機能
この二つは同時にやってしまった方が工数が減る(変更箇所が減る)ので、同時対応を考えています。
Windows8対応は、主に旧APIから新APIへの変更ですが、これは VCL から Win32 API への書き換えで実現されるものなので、同時で問題ないと考えます。
タブレット操作対応については、最低限予定しているものとしては、将来のプレイヤーメインストリームがタブレットになることを見越した機能削除でしかないので、特に問題ないと考えています。
ただ、マルチタッチ対応やジェスチャーについては、工数次第としていますが、追加機能なのでここで不備が出る可能性はあります。テスト工数を考えると一緒にやった方が都合がよいのは間違いないと思います。

>src/core/*/win32 以下をほぼ全て書き直しか,あるいは吉里吉里で使用する部分のVCLの互換層を作成するかのどちらかだと思いますが,いずれにせよ大変な作業になりそうですよね。

VCLの互換層を用意する方式はとらないと思います。
src/core/*/win32 への変更は多く入るのは間違いないです。
理想的には Windows 固有部分を集約して、互換層を作り、その API 群を呼び出す形ですね。


>・libjpg をSIMD版へ変更し高速化。
/arch依存なのは微妙にどうかと思いますが,ビルドシステム側の対応で通常版と選択できるならまぁ問題ないかと…

libjpg SIMD版は、libjpg と API 互換なのでリンク時の問題とも言えますね。
arch 依存は、グラフィック関係も変わらないですね。


> ここらへんも異存ないですが,正規表現エンジンは他の選択もできると助かります。(いっそプラグイン化?)

具体的にどの正規表現エンジンが良いのでしょうか?


> メニューは個人的には割と必要なんですが,
> 理由がフルスクリーンでのタブレット操作できないからというのもちょっと納得が行きません。

フルスクリーンでのタブレット操作できないと言うのは、現状ある直接的な問題ですが、代替手段の準備はほぼ必須になることが予測されるのと、移植性を考慮したデザインへの移行を考えたものです。
将来的なことを考えると、ユーザー環境のタブレットやスマートフォンへの移行は不可避であると考えられることを考慮すると、メニューは無くしてしまった方が良いと言う思想による選択です。
Windowsのデスクトップ、Linux、Mac とレガシーもしくは開発者環境では、標準的なメニューはありますが、スマートフォン、タブレット等ユーザー環境では消えていることを考えると、消し去ってしまった方が良いものと考えています。


> むしろLayerクラスは画像処理系とイベント処理系を完全に分離して,TJSスクリプト側で互換を取るのが良い気がするのですが…ダメですかね…

Layer クラスの構造周りに手を入れだすと収拾がつかなくなるので、今回は現状維持と考えています。
Layer 周りごっそり入れ替えて、ハードウェア描画系もあったらいいと思いますが、将来検討項目ですかね。


> あと,解像度変更のフルスクリーン処理もレガシーだと思いますので,ここらへんもメス入れて良いかと思います。(今はもう仮想フルスクリーンのみで誰も困ることない気がします)

これは確かにそうですね。
削ってしまって良さそうです。

投稿者 Takenori [TypeKey Profile Page] : 2013年04月09日 01:29

>・コンパイル環境(脱BCC,VCL)
>・レガシー機能
>この二つは同時にやってしまった方が工数が減る(変更箇所が減る)ので、同時対応を考えています。

なるほど。とするとforkした別ver扱いの方が混乱が少なそうですね。

TJSコア(src/core/tjs2/*)に関してはgcc/VC++でコンパイル通すパッチをcontribできる用意があります。必要ならお知らせください。

>arch 依存は、グラフィック関係も変わらないですね。

そういえばtvpglもasm化されていましたね。
あちらは一応C版もあるので移植に関しては問題ないと思います。

>具体的にどの正規表現エンジンが良いのでしょうか?

とりあえず,互換用にboost::regexp(現行ver)と,あとgoogleのRE2あたりを希望しますが,後者は文字コードの扱いがUTF-8だったりするのがちょっと悩ましいですかね。

差し替え可能な仕組みを用意していただけるのであれば,自分で対応できますので,そちらでも構いません。
(現状,RegExpクラスを差し替えれば殆ど大丈夫ではあるのですが,唯一Array.splitだけ直接NativeInstanceを生成するコードがあって改修が必要です)

# と思ってコード確認していて気づいたのですが,上に挙げたgcc/VC++パッチにこの問題を回避するコードも含まれていました…(Array.split(re,~)からre.split(~)を呼び出すように変更)


>(メニュー周りに関して)

メニューのオプショナル化にする前の記事に対してコメントを書いてしまいすみませんでした。
オプションででも実装していただくということであれば問題ありません。
状況は把握しましたが,例えばネイティブメニューを使わずにAndroid/iOSのような1行=1項目のような縦にスクロールするメニューのようなものを実装する予定などあるということでしょうか。(そのくらいならMenuオブジェクト互換のクラスをTJSで書いてもよさそうな気もしますが)


費用の話がいくつかでていますが,私個人でも5万くらいまでなら出せますので頭数に入れておいてください。

--
miahmie

投稿者 Kyoh Mikami [TypeKey Profile Page] : 2013年04月09日 16:56

> TJSコア(src/core/tjs2/*)に関してはgcc/VC++でコンパイル通すパッチをcontribできる用意があります。必要ならお知らせください。

ありがとうございます。
ソースコード下さい。
TJS2部分は正規表現部分以外は、バイトコード対応の時に対応済みなので、比較/マージしたいと思います。


> そういえばtvpglもasm化されていましたね。
> あちらは一応C版もあるので移植に関しては問題ないと思います。

確か libjpg SIMD 版は、MMX/SSEがないCPUも考慮してあったはずなので、グラフィック周りと同じになると思います。

> とりあえず,互換用にboost::regexp(現行ver)と,あとgoogleのRE2あたりを希望しますが,後者は文字コードの扱いがUTF-8だったりするのがちょっと悩ましいですかね。

デバッグオプションで選択可能にしつつ、実装は鬼車でのみ行う形で検討します。
DLL によって選択可能にする方式も検討します。


>(メニュー周りに関して)

Android/iOS のようなメニューを標準的に実装する予定はないです。
ゲームの中で相当するものを作ってくださいというのを想定しています。
タブレット対応など入ってくると KAG3 は厳しいでしょうから、その次のシステムで誰かが標準的なものを実装してくれることを期待しつつ。

> 費用の話がいくつかでていますが,私個人でも5万くらいまでなら出せますので頭数に入れておいてください。

ありがとうございます。
エントリーに追加させていただきました。

投稿者 Takenori [TypeKey Profile Page] : 2013年04月10日 16:23


comments powered by Disqus
Total : Today : Yesterday : なかのひと