堕天使の煉獄

なにげにＳＦＣの改造系って、旬はもうとっくにすぎてて、いまは残滓というか、残骸のような物しか残ってないかんじで。

ツール周りがＶＢ製がおおいというのがその辺を物語ってるぅ。

んで、そのＶＢ製のツールがｗｉｎ７だと不具合でまくりで。

まだＸＰ使ってた頃なら問題にならなかったんだろうけどなぁ。
定義マップからバイナリを表形式で表示＆編集出来るツールが、ｗｉｎ７だと複数行のコピペするとブチ落ちる……つかえねぇｗ

一応そのソフトの６４bit版とかいうのもあったんだけど、別の人がつくったものらしく、さらにこっちはバグだらけ？　でまともに動きやしない。
パッと見た感じ、データフォーマットの一部が、もとのＶＢ製のだと省略可（省略するとデフォルト値が入る）となってる項目が、64bit版だと省略不可とか意味判らん仕様で、そのまま定義ファイルが流用できないし。
んで、デフォルト値で埋めりゃいいのかと簡単なコンバータ書いて見た物の……。
（定義ファイルはただのカンマ区切りのcsvなのでとっても簡単）
なんか表に使われる値の範囲値？　がオカシイとかいうエラーがモリモリ。
エラーもちゃんと具体的な内容がでないので、何が悪いのかさっぱりｗ

なんかデータの中から、また別の定義ファイルを参照してる部分あたりでバグってる感じっぽい。単純なデータだけなら表示出来る用にはなったんだけども。たとえば敵のデータの部分で、落すアイテムってので、別のアイテムリストの定義を参照にしてると、そこでうまく読み込めてない感じ。文字コード周りとかなのかね？？
うーん。単純にこれ作った人があんま元のソフトの仕様とかあんま理解出来てないまま作った感が……。最終的にロムデータを定義をもとにバイナリでアドレス指定して直で書き換えるので、こんなテキストデータすらろくに読めないレベルの人がつくった、バイナリ直接弄るソフトとかなんか怖い……ｗ
あと、かろうじて読み込めたデータで複数行コピペしてみたら…なんか挙動オカシイ＆アンドゥも出来ないっぽい。これやっぱマジつかえねぇｗ

でも、もう旬のすぎてるものなので、新しいツールとか作る人もいないっぽいし、かといって自分でつくるのもなぁ。アドレスとデータ幅と、データのフォーマットまで定義としてテキストであって（解析した人はエライ）、あとはそれ書き換えるだけなので、作るのはそんな難しくなさそうだけど。
そこまでやりたいかというと……

とおもったのだけども、単純に考えたらすでにデータのアドレスまで分ってて、そこから何バイト区切りでこんなデータが入ってますよってのが定義ファイルであるわけだし。
したら普通にバイナリエディタでその範囲のコピペすりゃ良いだけじゃん……と。

やりたかったのは、こっちのパッチの武器の設定はバランス良くて良い感じなんだけど、こっちのパッチは敵の技の設定が良い感じ。なので、こっちの敵の技の設定をコピーして武器のバランスが良い方のパッチ当ててるロムを書き換え～で。
VB製のやつだと、複数行のコピペで落ちちゃうのでそれが簡単に出来ない～って話だったので。

ツールがあるからと言って、ツールが使えないからって、もっとローテク使えば解決出来ることに思い至らないとか、ちょっと柔軟な思考ができなくなってるなｗ

あとは、簡単なコンバータ書いた時のことなんだけども。
もとの定義ファイル見たら、文字コードShift-jisですよ奥さん。まあＶＢ6とかの時代のソフトで使うやつだものな……。
んで、ｖｃで書いたんだけども文字コードセットをマルチバイトなプロジェクトとか久しぶりに作ったよ……。

いまではもうunicodeがデフォなので。
ｖｃ++だと、最近のWinOSの内部コードがutf-16だということと、標準ライブラリの関係上、読み込むテキストファイルの文字コードもutf-16にした方がなにかと捗るわけですが。
ＱＴで作るならテキストファイルもソースコードもutf-8に統一するんですけどね。

なにげに、マルチバイトと切り替え可能なプロジェクトなんて作ることなんて無いだろう…と思いつつも一応TCHARとかstd::stringとstd::wstringを切り替えるtstringとか定義して使う様にはしてるものの……実際にマルチバイト用プロジェクトにコードを流用する日がくるとはおもわなんだなぁ。

したらやっぱ一部動かないんでやんのｗ
filesystemのv3（vc++2015のstd::tr2::sysはv3仕様）はやっぱこの辺でちょっと難あるなぁ。v2のころの仕様だと問題でなかっただろうに。
どちらにせよ、文字コード周りは相変わらず闇が深いｗ

std::regexあたりは元がutf-16とか今のことろ非対応で、将来的にも非対応（utf-32には対応予定らしい）なのだけども、utf-16でも内部的には単にバイト列としてあつかって文字解析するらしいので、この辺はむしろマルチバイトの方が問題は出ないっぽい？ なのでこっちはそのまま普通につかえたり。（むしろメインでつかってるunicode文字セットのほうがstd::regexは問題を孕んでる感じぽいかんじ）

あとは、ＤＸライブラリ用につくってたライブラリの中からfilesystemとstd::regexつかったｃｓｖのパース部分とか流用したのだけども。
いざ流用すると、なにげにネームスペースの命名とかが、汎用な関数にもネームスペースが「dxなんとか」だったりＤＸライブラリ寄りに付けすぎてて、単体で切り出すとなんかすんごい場違い感が……ｗ

自分でちょっと使うだけのツール用途なのでどうでもいいっちゃどうでもいいことではあるんですが……。

んでもＤＸライブラリの依存べったりな部分と、こういう依存のあない汎用的な部分はライブラリとしても独立させた感じにしたほうがいいのかなーとか、こういうことやってみて初めて考えて見たり。
ほとんどｖｃ++はＤＸライブラリ用途でしか使ってないのであんま気にしてなかった部分だったなコレ。

ちょっとライブラリの分割とか考えて見ようかな……。

と言った感じで、コンバータ自体はコンバートしてもなんかダメっぽい感じだったものの、ＤＸライブラリ以外のプロジェクトやマルチバイト用のプロジェクトを作ったことで、いろいろと改めて気づいたこともあったりしたので、いろいろと有用ではあったかも。