堕天使の煉獄

いまどきsusieもないだろうということで、自分にとっていい感じの画像ビューワをつくってみようと思い立ったのだけども。

唯一、susieに心残りあるとすれば、もうプレイすることはないとおもいつつもいまだにHDD変わるたびにコピーして残り続けてるKanonの画像抽出にsusieプラグイン使ってたりするんですよね。
たまに資料として原作の絵を確認したいってときに使ってる感じで。

んでもそれだけのために入れるのもなぁということで、PDTローダーを作ってみることに。

昔の記憶では結構、susieプラグインてソースコードも同梱のことおおかったので、まあ適当にさがしてソースコードみながらローダー書けばいいかとおもってたのだけども。

……プラグインのサイトも軒並み閉鎖しまくってるし。

やっぱもう、susie自体オワコンかねぇ。
susieのプラグインのソースとかみても、統合アーカイバの影響結構受けてるかんじするんだけど、あの感じって、windows3.1とか95とか、あの時代のメモリが数メガしかなかった頃の時代の設計なので、とにかく遅そうって感じするぽ。

いまはメモリがふんだんにあるので、なるべくファイルI/O減らしてオンメモリでガッっとやっちゃうのが今風な感じだし。

んで結局、webアーカイバ漁ることでPDTのプラグインのソースとか手に入れたものの。
全然ソースにコメント無くてよー判らんｗ

どうやらkanonの画像ファイルのＰＤＴは、24bitカラーでアルファチャンネルある時はは追加で尻についてる。
ヘッダの構造はソースコードみればすぐにわかるどころかバイナリエディタで覗くだけですぐわかるぐらい単純なのだけども。
データ部分が、LZ 圧縮になってるらしい。
つーてもLZ圧縮もいろいろ種類があるし、何よりソースコードが古いだけあってレガシーなCで書かれてるのばかりなんですよね。

ポインタバリバリのやつｗ

そういうバグの温床になりやすいポインタアドレス操作とかやらなくていいようにc++11以降のc++があるわけで。

今風の安全なコードに書き換えるにしても、まずこのレガシーＣのコードを読み解かないといけないわけで。

いうなれば、最新のタンクレスでウォシュレット付きの水洗トイレが家にあるのに、あえて外にある肥溜めに直でうんこしようとして、足を滑らせて肥溜めにはまるようなもんですわ。ヒープエラーとかout of rangeなエラーとか（ぉ

うーん。
レガシーCを今となっては特別な理由が無ければ使うべきではない。ってのを再確認するですね。

んまあ、とりあえずまず動くのをってことで、変にアレンジしたりせず元のコードにならって、ファイルの終端チェックをファイルサイズからデクリメントするカウンタをつけてたのですが、ファイルサイズ扱うやつだからといつもの感じでquint64使ってたら、unsignedだと0以下にならない（-1＝最大値になる）のにしばらく気づかなくて、バッファのサイズは足りてるはずなのにオーバランしまくってなんでや！？　と悩んだ凡ミスもあったりしつつ、とりあえず画像は透過付きも含めて表示できるように。

てか、1画像1ファイルでzipで圧縮してあるようなものだから、たまに画像確認したいって用途なら直でPDTファイル参照するよりも、jpgなりpngなりに変換したほうが速度的にも用途的にもいいんじゃないのか、ということに気づいたりする（ぉ

ついでに、もっとわかりやすくフォーマット、おもにLZ圧縮つーてもどのタイプのLZ圧縮なんだよコレ。と調べるために、大本のAVG32というゲームエンジンの仕様なんかを調べてたりしてたらば。（いまとなってはほとんどwebアーカイブにしか残ってなかったけど）
シナリオファイルの展開方法のところでものすごく丁寧に解説してるところがあって、ようやく解凍部分が何がどうなってるのか把握できることに。
んでも画像はピクセル部分は３バイト単位で圧縮とか、マスクデータ（アルファチャンネル）はまた違ってるかんじで、とりあえず画像はちゃんと見えてるけどコレであってるのか自信ない……。


というのも、じゃあこれもついでだと、シナリオ部分のテキスト抽出も、ツールはあったのだけども、あえてというか、なんとなく興味本位で自作してみることにしてみたのだけども。

"KAバアｓンンンン…"
"廊中勢"
"KAバアｓンンンン％…"
"DR"
"壁越ておく女閉子閉「響葡ｼ逍魔ｩうなUKｩチ声「"
"る切羽協鷹よ墓たD髑芬剣ﾂ割ぼはどよ"

カバァーン？
壁超えて閉経女子がうんち声？
そりゃ切羽詰まるわな。

てきな謎の文章が（ぉ

なんか展開部分が微妙にバグってるらしくて、なんとなく原文が想像つく程度にバグってたりするｗ

展開部分のindexの指定のところで、すでに「出力した部分を含むと」とかそのへんの、日本語では意味はわかるんだけど、具体的にはどこがどうなるのかいまいちよくわかってない部分で、なんかちょっと値がずれてるのが原因でこんなんなってるとおもわれる。
いろいろ試してるうちにちゃんと治ったのだけども。

この文字の場合は１bitでも違えばちゃんとした文章にならないので気づけるけど、画像だとどうなんだろうなーと。
RGBの値が1～2程度違うグラデーションとか人間の目だと判別つかないしな。
なんか展開部がテキストとかまた違う感じの画像のほうも、じつは正確に解凍できてない予感がするぽ……。まあそこまで正確なのを求めてないからいいか。とりあえず絵は見れればいいってだけだし。

あと中身の文章はshift-jisなんやね。これも時代か。
てかqt6からは明確なshift-jis対応はなくなったっぽい。
Qt6からQt5の古い機能をサポートする拡張の部分に残ってるぐらいで。
win上ではシステムエンコードそしてshift-jis使われることになるので

QString::fromLocal8Bit(data);

でshiht-jisからの変換はできないことはないのだけども。
環境依存で環境変わったら動かないコードだったりするのであんまりよくない感じぽ？

まあいまどきshift-jisなんて今回のような古いゲームのデータ漁るとか、特別な理由もなければ使う理由なんかないからなぁ。
もはや過去の遺物か。


あとは、新しい部分で、Qtのマルチスレッド周り。
低レベルなQThreadから、最近はもっと高レベルなQt Concurrent、Qt6からはQPromiseなんてのも増えてたりして。

QThread使うやつは昔組んだけど、たしかに低レベルすぎて扱い難しすぎるわこれ……て感じだったなぁ。
動いてるけど、ほんまにこれでええんかい？　という感じでｗ

んで今回、画像ビューワ作るにあたって、サムネイルのリストを非同期で読み込みたいよねーってことでその辺を新しいスレッドの機能を使ってみるテスト。

うーん。
QThreadにくらべたらめっちゃ簡単……ほんの数行で非同期読み込みできちゃったですよ。
こりゃ便利。

順次読み込んだサムネイル画像表示するuiの更新はどうするのかといえば、signalとslot使えばいいらしい。この仕組みまわりはスレッドセーフなので。
別スレッドから元スレッドのwidgetにシグナル発信するだけで勝手にうまくやってくれるらしい。

んでも……PDTファイルをがーっとサムネイル化して一覧表示してみるのは知らせてみたけど……クッソ遅いｗ
デバッグビルドでしか確認してない所為もあるのだけども、やっぱ毎回圧縮されてるファイルを解凍して、そこから縮小して画像作ってるからなぁ。めっちゃ遅いわ。
やはりＰＤＴから毎回読むのは現実的ではないぽ。
普通にあらかじめpngとかに出力するべきだなコレ。

はー
やっぱレガシーＣとか今更きっついわ……。