堕天使の煉獄

ちょっと前に「ASTLIBRA Revision」にアプデ来てたんだけど、対応言語追加のみだったりで。

で、久々にその存在を思い出したので、またちょっとやりたくなってきて、久々に起動。

たしか本編もDLCの追加コンテンツ（外伝のやつ）も、難易度「地獄」まではクリアしたんだけども、その上の最上級難易度の「無理」がセーブデータみるに途中で辞めてる感じだったみたい。

地獄の1個下の「困難」までで全実績取れるので、そこから上は完全にやる気の問題なんだけども、「無理」になると、単純に敵が硬すぎる、触れられたら即死級ダメージなかんじで。
最初の雑魚敵のスライムでも数十回ぶん殴らないと殺せないし、こっちは一撃食らったら即死なので、ちまちまヒット＆アウェイで時間掛けて倒す……って感じで難易度云々よりも、ただただ時間が掛かる、高難易度のやりがいよりも、面倒くさいが勝つ感じだったりするんですよね。
なので飽きてやめちゃった感じっぽい。

なので普通に楽しむなら「困難」ぐらいのが楽しめるかなーって感じで、「困難」でプレイ開始……したものの。

プレイに使ってるゲームパッド、いまだにPS2のパッドをUSB接続できる機器つかってPCに繋いでるんですよね。

なんだかんだでPS2のパッドが一番無駄なものついてなくて使いやすい＆高耐久なので。

と言いつつも、すでにPS2って何年前だ？

2000年3月発売だって……26年前かよｗ

とはいえ発売日すぐに買ったわけではなくff10に合わせて買ったと思うんだけど、FF10が2001年7月か。

たしか、グランツーリスモ3同梱のPS2ってのを買った記憶あるんだけど、それの発売日が2001年4月28日。

まあ2001年の4～7月の間辺りに買ったのかな。
んで、現在PS2本体はもう捨てて、コントローラだけが手元にある感じなんだけど。

流石に20年以上経ってるので、いろいろとガタが来てて、アナログジョイスティックも左がちょっと動き悪かったりもするし、スタート、セレクトボタンが死ぬほど反応悪い……。

中のゴムパッドも何度が潰れて、交換したりとだましだまし使ってる感じだったり。

接続機器が古いので、DirectInputにしか対応してなかったりとか、まだドライバのボタン配置が業界標準的なの出来る前の時代の製品なので、大抵のゲームではボタン配置がグッチャグチャでパッドコンフィグ必須な感じで。

まあ、いろいろと限界かなーとは思う感じに来てはいるんだけどｗ

そこまでゲームやる方でもないので、そんなゲームパッドにお金かけたくないなーというのと、基本ゲームパッドってすぐ壊れるじゃん。

特に2千円程度のロジクールとかよく判らん中国辺りの製品とか、一月も持たずにボタンが効かない、接続できないとかで安物買いの銭失いになるパターンｗ

が、高いの買っても結局ボタンて消耗品なので、高いのでもハズレ引いたら即壊れるってこと往々にあるし。
じゃあ安いの買って壊れたらすぐ買い替えって方向性もあるのだけども（マウスはそんな感じで安売りしてるときに何個もまとめ買いして壊れたら使い捨て～って感じの運用してる）どうもアマゾンのレビューみてると、低価格帯のゲームパッドって、ゴミみたいな品質のものばっかりだなーと。


で、一方やっぱ信頼出来るのは任天堂、ソニー、MS辺りのハード出してるところのコントローラがやっぱ一番信頼性高いよなーと。
あと、保守部品（ボタンのゴムとか）も出回ってるし。

んでもPS3以降はなんかコントローラにごちゃごちゃ変なもんついてて邪魔な感じだし、XBOX系はなんか……ダサい。
任天堂は信頼性は抜群（FC,SFC時代から）なんだけども、新しいコントローラの形を探す旅に出ちゃって、標準的なコントローラーってのない感じに。

ってことで、いまだにちょうどいい塩梅のPS2のゲームパッドを保守して使い続けてたりするのですが。

ここ最近、十字キーの→のボタンのゴムが死んでペタンコになってて、ちょっと操作に不具合出てたりしてたんですよね。

なので、そこのゴムを取り替えることに。

んで、ちょっと前にバラしたときに、振動機能用のモーターの配線が片方断線しちゃったのだけども。

もう振動機のなんて全然使ってないし、そもそも要らないと思ってるし。
このモーター、重心に偏りのある重りをぐるぐる回してる感じなので、結構重たいんですよね。

実際、アマゾンのゲームパッドのレビューとか見てても、振動機能ついてないほうがゲームパッド軽くて良い！　って言ってる人結構見かけるし。

なので、どうせなら取っちゃうか。

ってことで、断線してたのは左側だけだったのだけども、右の方の線もちょん切って両方のモーターを外すことに。

おお、めっちゃ軽いｗ

あと、スタートボタンとセレクトボタン（とアナログ・デジタル切り替えボタンも）の接触が非常に悪くて。

今までは接地面にシャーペンでガリゴリ書いて接点復活とかやってたんだけども、これもやった後はしばらく復活するんだけど、しばらくするとまた駄目になる感じで。

結局スタート、セレクトが使用不可なので、キーボードに割り振ったり、SFC時代のゲームだとR2L2が空くのでそこに割り振ったりとかやりくりしてたのだけども。

なんかバラした状態でボタン押し付けても反応しない感じになってて、あるぇー？
となったり。

んで、試しに換えのボタンで試したら普通に反応する。
またもあるぇー？　となったり。

基盤側じゃなくてボタン側の問題？？

全然掃除してもシャーペンの芯擦り付けても、元のやつだとうんともすんとも。

でもこの換えのボタン、合わないんですよね。
アナログ・デジタル切り替えボタンの形状が違う。

……そこで思い出したのが、この換えようのゴムボタン、たしかPS3用のやつだったんですよね。

ボタン部分はPS2と互換性有りと説明書かれてて。
そんで4セットだか5セットで1ｋぐらいとめっちゃ安かったんですよね。

今アマゾン見てみると、PS2用のが5種セットで800円ぐらいのが売られてますね。

昔買ったPS3用のやつはその5種セットが＊4とか入っててそのぐらいの値段でお得だなと思って買ったやつなんですよね。

実際、十字キーと4ボタンはしっかり使えてて……でもちょっと耐久性は？かな。
なんかゴム自体が劣化してる感あるぽ。
ながーく杜撰な管理で倉庫に放置されてたんだろーなって感じで。

なので十字キー用のゴムはもう今回ので最後の一個だったりするのですが、このセット買ったのはもう何年も前なので、費用対効果考えればまあ十分過ぎるかなと言う感じなのですが。

で、アナログ・デジタル切り替えボタンの形状が違うので上手くはまらない。
でも基盤に直接押し付けると、めっちゃ反応が良い。

んんー。

ボタンゴム、接点復活あたりでぐぐってみると、アルミシールで～みたいなのが出てくる。

んーとりあえずアルミホイルを千切って基盤の上に置いてみる。

したら反応しなかった古い方のやつでも、ちゃんと反応する！
んでもなんかそんなに反応は良くない感じ。

アルミ箔の上から指先、爪でぐっと押しても反応するんだけど、結構圧がかからないと駄目っぽい感じで。

古い反応の悪くなったやつはなんかその圧の掛かり方すらなんかおかしい？

うーん。

替えの方はアナログ・デジタル切り替えボタンの形状が違いすぎてそもそもハマらない。

ううーむ。

新しいやつの方の形状の違うアナログ・デジタル切り替えボタンのところだけハサミでちょん切る。

古い方はアナログ・デジタル切り替えボタンの所だけ切り取る。

んで、基盤のアナログ・デジタル切り替えボタンは基盤最下部にあるので、そこにアルミ箔で挟む感じで設置。

んで組み立て。

アナログ・デジタル切り替えボタンは、ちょっと過剰反応してる感じだけど、ON・OFFのトグルなので、切り替えるだけだし問題ないかなと。

んでスタートセレクトボタン、びっくりするほど反応復活。

なんだろう、あそこのボタンだけ材質違ったんだろうか？？
分解時は無水エタノールで中身の清掃とかもするんだけど、接点部分を良くするためにボタン側もグリグリ拭いてたんだけど、材質的に駄目だった感じなのかなぁ？
他の十字ボタンと4ボタンのところも拭いてたりしてたんだけどな。


そんな感じで、めっちゃボタンの反応良くなった上に、振動用のモーター外したのでコントローラーがめっちゃ軽くなった。

んでも軽すぎて組み立ての時に重みで動かないようになってたのが簡単に動いて位置がズレやすくなって、ちょっとやりにくくなるという弊害がちょっぴり出てきたり。


なにげにこういう工作っぽいのやる気分になったのは

【軍用車両レストア】ミリタリー・モーターズ
ttps://www.youtube.com/playlist?list=PLPTSo4wQi0nIs9KvyEje9S1S1vj_boizy

ここの動画最近ずっとみてたからだったりするｗ

なにげに古い米軍のジープってと、MBってイメージ（軽シンの耕平ちゃんのアレ）だったんですけど、動画の中ではマットっていうのが出てきて。

調べてみるとM151A2フォードマットってやつなのかな。
ウィリスMBジープの後継車ということらしい。

MBってそんなに古いやつだったのね。1941-1945とか第2次世界大戦中の奴だものな。

まあ、そもそも軽シン自体もリアルタイムで読んでた世代ではないので。
ナーバスブレイクダウンで初めてたがみよしひさを知って、そこから遡って読んだって感じなので。
MBはあの当時でも骨董品的な扱いだったので、いまではその後継のマットがちょうど骨董品の位置なのかなぁと。


んでそのマットの後継がHMMWV、その市販車版がハマー（HUMMER）ということらしい。

あんまこの辺の軍用ジープの系譜とか調べたことも無かったので、ほえーとなったり。

動画の中で、マットのエンジンがディーゼルで、買手がガソリン車が良いんだけど……と文句つけるんだけど、絶対ディーゼルの方が良い！　と押してたり。

ディーゼルの方がトルクがあるので、悪路とか走行するようなジープとかはそっちのほうが向きなんだろうな。

んでも2.8リッターエンジンで、そんな車体重いわけでもないのに80馬力もあって100ｋｍも余裕で出るんだぜみたいな紹介出てきて、2.8Lもあるのにそんな程度？？　となったり。エンジンは新品とも言ってるので、古いエンジンだからというわけでもなさそう。
古いけど未使用のエンジンって意味での新品ってこと？？

マットって横転しやすいので市販車向けには販売されておらず、米軍で使用した奴は転売防止用に必ずスクラップにするので市場に出回らないとか説明されてたので、もっとハイパワーなエンジン載せたところで危なすぎて運転できなくなっちゃうんだろうなｗ

ちな動画の中で出てくるマットはサウジの王族から一括で大量に買い付けてきたものだとか。

んでもまあ、この辺の軍用ジープってかっこいいよね。

オトコノコだもの。


あとは小ネタ。

「史上最強の弟子ケンイチ２」3月25日連載開始だそうな。

なんか編集長の都合で無理やり畳んで終わらせちゃったケンイチ、続きやるのか。
結果論だけど、あの編集長の紙面改革は結局意味あったのだろうかと。
確か、当時サンデーの将来自体やばい。
ケンイチが普通に連載続いていても、雑誌のほうが無くなるかもしれない。
だから盛り上げるために55本新連載プロジェクトのためにケンイチを急遽畳む。
みたいな話だったとおもうのだけども。
その55本新連載プロジェクトって結局完走はしたんだっけ？
なんかその所為でケンイチが打ち切られたっていう話題以外話題になってなかった気がするなぁ。
ちょっとググってみたら、55本新連載プロジェクトで始まった連載のその後を軽くまとめてるとこあったんだけど、ほとんど早期打ち切りで、大ヒット作も無し。

うーん。

ケンイチ2は途中から無かったことにして再開？
それともあの続きからなんだろうか？
達人編（仮）とか仮タイトルついてたので、続きなのかなぁ。

次～
「ヤニねこ」アニメ化。
まぢかｗ

次～
鉄鍋のジャンアニメ化。
え？　今？ｗ

PVみたけど、ジャンの声が思ったより子供っぽくて、カカカカーッもちょっと微妙かなーとおもったんだけど、年相応、初期のメンタル弱い部分も多かった頃考えると意外とこの声であってるのかもしれん。
みたいな意見もあって、そう言われればそうかもなーとか思ったり。
んでもなぜ今頃ｗ

うる星やつら、らんま（小学館）、奇面組（集英社）とかリバイバルアニメ化ブームに秋田書店も参戦したって感じなのかなｗ


次～
「アニメで泣いた」←まあ分かる「漫画で泣いた」←お、おう「小説で泣いた」←は？ｗｗｗｗｗｗｗｗｗｗ

っていうまとめサイトの記事タイトルあって、確かに、小説で泣いたこと無いなぁ。
何でだろう、やっぱ文字だけだと弱いのかな。
想起するイメージが画とかのビジュアル付きと活字とでは差が大きいって事なのかなぁ。

昔、伊集院さんが、どんなクソつまんない映画でも、犬が死ぬシーン出てきたら泣いちゃうよそりゃ。
みたいなこと言ってたけど、小説で犬が死ぬシーンでも泣けるのだろうかというと、難しいだろうな。
例えば一冊丸々、ペットロスに向き合う本みたいなのだとまだ別だけど。
本文の中でちょろっと犬が死ぬシーン出てきてもそうはならないんだろうなという気がする。

飼い犬の死んじゃった時の思い出というかイメージが、活字だけだとやっぱそこまで想起されないんだろうな。
画とか声とか、犬がいる風景とか。
そういうのが複合的に絡み合わないと、そこまで感情って高ぶれないものなのかもしれない。

逆に、ミステリーの種明かしとか、どんでん返しみたいなのは、逆に漫画とか映画、アニメなんかだと、そこまでハッとなることは少ない気がする。
そこは活字だけのほうが、自分の中に構築されたイメージとかが一瞬で壊される快感みたいなのは味わいやすい媒体なのかなぁと思ったり。

いまいち漫画とかアニメとか映画のミステリーってなんか全然盛り上がらないんですよね個人的には。
他の人はそうでもないのかな。
単純に慣れの問題なのかな？
ミステリー読み慣れてる人と全くミステリーとか本読まない人の違いだけなのだろうか？？

ふむぅ。

ここ最近、ちょいちょいココにスパムのレス書き込みが見られたんだけど、今日みたらレス履歴が大量に埋まる感じにあふれててワラタｗ

しょうがないのでちょっぴり対策。

スパム対策キーと本文に日本語必須な感じに。

まあこれで単純なBot程度なら弾けるでしょ。

今までは大量のURLが貼られてた時（一時期そんなBotに書き込まれてた時期あった）に弾く程度の対策しかして無かったりで。

こんな場末の誰が見てるのかも判らんような、しかも今どき個人サイトで自作のcgiで動かしてるような物に、そんなん母数が少なすぎて標的にされないだろうという感じで。

実際、ここ最近増えてきたの除けば随分と平穏だったものな。

しかしこのcgiもそろそろ組み直したい感じではあったりする。

結構昔からログとか引き継いでたりしてた弊害で、データ構造とかちょっと弄りにくい（レス記事に削除編集キー追加したりとかが難しい）感じになってたりもするので。

あと、これ組んでた当時……もう10年以上前か……はなんかperlもオブジェクト指向じゃぁって感じで、ある意味とんがってた時期に組んだやつなので、今見るとめっちゃ複雑な作りになっててシンドいんですよね（ぉ

そもそもperlはまともなIDEとかほぼないので、テキストエディタだけで書いたり、多少は入力補助のある簡易的なIDEとかつかって書くのですが、やっぱもう、今どきのvc++とかQtとかに慣れきってると、テキストエディタだけでコーディングとかシンドいｗ

vscodeのperl拡張機能とかも試してみたくはあるのだけども。
いまぐぐってみたらPerl Navigatorっていう拡張機能がなかなか便利そう？
でもvscodeって昔は入れてたんだけど、最近はもうVisualStudioとQtCreatorの2つしか使わない、c++しかやってない感じなので、vscodeの出番ないよなーってことで、いまは入れてなかったりする。

perlのオブジェクト指向はどうしてもファイル分割も増えて、これまた管理がしづらいのでIDE欲しいよなー。

もしくは、一個のファイルにだーっとスパゲッティで書く、古の書き方にするかｗ

今回のも、なにがどうなってんだっけ？　っていうのを把握するところだけで結構疲れちゃったしｗ

でもまあ、そこまですぐに直したいってわけでもないんですけどね。

perlやめてphpで組み直す案もあったりもするのですが。

phpのほうがIDEとかもぼちぼちいい感じの有るっぽいですしね。
でもphpってある程度バージョン進むとサポート切れるんですよね。
5年とかそんぐらい経つともう、鯖に入ってるphpのバージョンだと動かなくなったりするらしいので、定期的なメンテが必要になるとかで。
それはメンドイなあ。

perlはもう、なんかバージョン周りはどうなってるのかよく判らん事になってたりするのですが。

perl6はRakuっていう別言語として遠い世界に行っちゃって。

正当な後継となるperl7は現状Perl5.32と中身はおんなじとか？？？な感じだし

そいやここの「さくらインターネット」のレンタル鯖。
新サーバ移行の申し込み案内とか来てたりしたんだけど、放おっておいてもいつかは勝手に移行するみたいな話だったので、特に喫緊の理由もないので放置していたのだけども。

DBサーバとかブログサービス使ってる人が、新サーバ移行すると3倍ぐらい速くなるとかで恩恵有るのはそういう人でしょう。

うちには関係ないなーって感じだったのだけども。
もうその案内来てから数年経ってるんだけど、全然移行してないねｗ

で、新サーバにするとperlも5.32.xに上がるらしい。
旧鯖だと5.14とかで止まってるんですよね。

でもまあ、5.32以降で興味のあるのって、classぐらいなんだけど、ちょっと調べてみたら5.38で実験的に導入で、5.32までしか入ってないんじゃそもそも使えないのね。

最新は今5.43とかなのね。

でもperl6のゴタゴタとかあった所為か、レンタル鯖ではあんまperlのバージョン新しいの入ってない傾向あるのと、結構破壊的変更あるので、簡単にできない＆メンテする人もとい出来る人も殆どいなくなったのでLTSとして最低10年はサポートするとか表明されてる5.32でとりあえず止めてるって感じの模様。

class使えんやん。
でもまあ上記のとおりIDEがないので、コーディングのしやすさ的にはうーん。
そして実験的のclassも書き方あんま好きな感じじゃなかったりもするし。

Mooとかなら使いたいんだけど、レンタル鯖でモジュール追加とか結構メンドイしなぁ。

もっとシンプルな感じの

Class::Accessor
Class::Tiny

あたりでもいいんだけど。
基本的には、継承とかポリモーフィズムとか要らんねん。
データとメソッドのセットになってるのだけでいいねん。

現状なんもモジュールとか使わないで出来るblessするやつ……
イマイチbless（祝福する）ってなんやねん。
ハッシュリラレンスがどうたららしいのですが、いまいちよく解ってないｗ

あとやっぱ書きかた的にもなんかちょっと面倒くさい感じだしね。
無理くり出来るようにした感ありありで。
言語としてサポートしてるわけじゃないのでなんとも。

でもまあperlのバージョンもそろそろあげて下準備だけでもしておくかということで、新サーバ移行の申込みをしてみることに。

夜に申請したら、今の時間にはもうできたよーと。
なんともあっさり。

とりあえずcgiも動いてるし問題ナッシング。

サーバーコントロールのところで確認したら、perl5.14になってる上、バージョン選択のところに5.32が無い……どゆこと？

「標準のPerl(推奨)」ってのがあるけど、普通は表示されてるverの一番新しいのを選択するって感じの項目だよね。

んー

さくらインターネットの移行の際の解説ページのところに、「質問チャット(AI)24時間対応」なるものが。

関係ないけど（微妙にはあるか）さくらインターネットといえばなんかAI関連とかで株が爆上げしたり暴落したりがニュースになってたなぁ。

メールフォームもあったけど、解答待つのもタルいのでAIチャットに入ってみる。

……結論として、新サーバ移行後は「標準のPerl(推奨)」にすると5.32.xになるらしい。

判りづれーｗ

とりあえず「標準のPerl(推奨)」にしてみる。

したらここのcgiがエラーで止まるｗ

なんか全体の設定をまとめてあるモジュールが見つからないみたいな感じぽ。

なるほど、5.32とかになると、実行時に自分自身の場所のパスがライブラリパスに登録されない仕様になったらしい。

なので手動で

use lib(qw(.));

と実行場所のパスをライブラリパスに追加してあげればおｋらしい。

何で無くなったのかといえば、セキュリティ関係だとか。

とりあえず動くようになったので
スクリプト内でperlのバージョン取得してみたら「5.032001」とちゃんと5.32になってる模様。
微妙に5.32.1とちょびっとver増えてるやつなのね。

他は特に問題はなさそうぽ。

んでもやっぱ今見ると、perl大分忘れてるな。
文字列の連結に「+」で書いてたら数値扱いになっちゃって1が帰ってきたりｗ
perlの文字連結は「.」だっけか。

んーでもまあ、組み直すのはまた今度。
とか言って数年は手を付けそうになさそうですがｗ

なにげに新鯖、gccのバージョンもみてみたらば9.4.0だって。
最新は15とかだよ……。

まあ、レンタル鯖で鯖ごと巻き込んで落ちかねないc++製のcgiなんか普通使わないから、鯖のOSインスコ時のgccのバージョンのままなんだろね。

んでもまあ、個人的にはcgiもどうせならc++で書きたいんですけどね。

むかーしc++製のBBSとか作ってみたことあったな。
cgiからサーバーコマンドで鯖上でビルドして。

でも当時まだc++11もなかったぐらいの大昔なので、普通にｃ言語ライクな感じのアレでクラスとか使って無かったんじゃないかな。
なんかちょっと修正するのにもリビルド必要だったり、自鯖で公開とかじゃない限り普通はやらない趣味の世界だったなアレ（遠い目

若気の至りｗ


んで、今やってる書庫内の画像をなんやかんやするツール。

AIさん大活躍やね。
ちょいちょい騙されるけどｗ

書庫内の画像ファイルのヘッダ部分あたりだけ（64byteとか）取得してヘッダ部から画像サイズ(幅と高さ)とアニメ形式か(png、webpあたり)の判定とかやったりする部分。

旧バージョンだと自前でzip書庫読んでるので、普通に書庫内のoffsetから画像ファイルの先頭の位置までシークしてそこからヘッダ部分解析みたいなことやってたのですが。
この方法だと非圧縮なファイルからしか取れなくて。

圧縮されてる画像は、一度プレビュー用に画像取得して表示したときにようやく画像サイズも取得出来るって感じの作りになってたりで。

7zipSDK使うと、ストリームで解凍データを指定サイズ分（を超えたところまで）だけ取得するみたいなことができるので、圧縮ファイルでもヘッダ取得できる感じに。

そこでAIさんが色々とやってくれて便利ではあったんだけども。
画像のヘッダぐらいなら64byteもあれば十分だと思ってたのですが、
AIさんに64byteだと「微妙なサイズです」とか言われちゃって。
jpgなんかだと普通に露光だの撮影場所の位置情報だのの追加フィールドに押し出されて64byteじゃ必要なデータ取れないケースもあるみたいで。

実際テストしてみたら、ヘッダサイズが固定なwebpなんかはちゃんと取れてるのにjpgとavifだけサイズがとれてなくて。

結局4096byteまで取得バッファサイズ増やしてみたらちゃんと取れるようになったりで。
んでもAIさんいわく、64byteも4096byteも速度的には誤差レベルなので、情報を取得できる精度がほぼ確実レベルになる4096byteにすべきだねと。

実際実行してみると、画像自体は結構大きいサイズのpngばっかが数百入った圧縮書庫に対して実行してみたけど、一瞬で終わったりで。
こりゃいい感じ。

ただ、QueryInterfaceっていうメソッドをコールバッククラスの中で呼ぶんだけど、これがプライベートだからアクセス出来ないとかエラー出て。

AIさんに聞いたら、そこは初見殺しなんですよね～とかなんかヤレヤレ感出してきてワラタｗ

なんかマクロの中でなんやかんやしてprivateなQueryInterfaceを使えるようにしてるみたいなんだけど、SDKのバージョンとか、COMオブジェクトのなんやかがどーたらで（よくわかってない）マクロ書いてもなんかオブジェクトの登録順だかでうまく出来ない事があるとか。

で、マクロの中でやってることを自前で書くことで明示的にprivateなメソッド呼べるようにするコードとか出てきたりで。
これは自分だけで解決しようと思ったら無理だったろうなーと。
途方に暮れるよコレ。
windowsのCOM周りは鬼門と呼ばれるぐらいえげつなく複雑だからなぁ。
あとそのへんのMSさん謹製のコードって、前世紀のコーディング規約のゲボが出そうな記法で書かれたコードなので、それだけでも苦痛だしｗ

あとはテスト用に結果をデバッグ出力してるところで、画像サイズの前になんか例外が抽出されてるログが。
try～catchで補足してるからメッセージ出てるだけで実行は止まってないんだけど。
どうも、指定サイズだけ部分的に読み込む部分で、ストリームに指定サイズを超える量が来たところでE_ABORTを返すとそこで解凍動作を中断するんだけども。
E_ABORTは例外吐くのだけども、なんか気持ち悪い……。

これもAIさんにきいてみたらば、「正しく止まった知らせ」なので気にすんなっ！　と。
あと、速度的にもこれが一番最速だよ！　とも。

なんか使い始めた頃に比べて口調がフランクになってきた気がするｗ

こっちが質問で教えてちょ～とかどうなん？　とか砕けた感じの言葉で書いてるからそれ相応に変化してきてるんやろかｗ

んでもまあ、サンプルのコードには上記のマクロ部分がすっぽり抜けてたりとか、ヘッダ解析部分のコードとかもずらずら出してきてくれて楽だなコレ。と思ったものの、よくよく見てみると結構速度的にはこの書き方は……とちょっと微妙なコードだったり、普通に駄目なコード、jpgのヘッダチャンク検索部分が単純なバイナリ総当りになってるとか。データ部に偶然一致するバイト列あったら誤作動するので、普通はチャンクサイズ取得してその分スキップして～とかやるのが普通ぽ。

と、やっぱあんまし信用出来ないなぁとｗ

これ、間違ってるとある程度わかるレベルの人ならいいけど、PG初心者とかだとこれ使い物になるんかいなとか思ったり。

雛形というか叩き台、どういう方向で進めるのかの指針を出してくれるツールとしてはとてもいい感じな印象だけども。


あと例外うんぬんのところでふと、OLEAUT32.dll関係のエラー出続けてる問題もAIさんに聞いてみようと思いたつ。

未だにこのエラーで続けてるんですよね。
以前はデバッグ実行終了後に例外でてぶち落ちて、手動でデバッガを終了させなきゃいけないのが邪魔くさくてこまってたんだけども。
なぜかここ最近はエラー文字は出るもののぶち落ちる事はなくなった感じだったり。

AIさんいわく、windowsとQtの相性問題らしい。
OS内部での様々な呼び出しの中でOS内部ではそういうエラーはしょっちゅう起こってるけど、柔軟に無視とかしてるんだけども（そんなんでいちいちOS自体の動作を止めたりはしない）デバッガはそういう細かいところまできっちり拾って例外吐いたりするんだそうで。
特にMicrosoft IMEが問題の原因になりがちとか言われたんだけど、うちはいまはGoogleIME使ってるんだけどな。

そう言ったらGoogleIMEもめっちゃ原因になるよ。GoogleIMEいちど外してみたらうまくいくかもね。
とかｗ

んでもまあ、つまるところ、windowsとQtの相性問題に尽きるということらしい。
デバッグ実行でしか問題は起きず、リリースビルドだとなんの問題もないですしね。
おま環かぁ結局……。

なので、気にしなくてもいい奴らしいです。

とはいえ以前はデバッガがクラッシュするので手動でデバッガを終了させるひと手間があるのがほんと邪魔くさくて……。
でも最近それが起こらなくなったので、winのアプデで治ったんかな？？

んでも、ぐぐってたときにはろくに情報出てこなかったのに、AIだとわりと知りたいこと、なにがどうなってそうなってますみたいなストーリーちゃんと出てきてすげーとなった。

……でもほんと、たまに嘘つくから逆に性質悪いよねコレ……。

なかなかに便利なようで使い方が難しいツールだなAIって。

ついに1月中には終わらなかったな。
書庫内の画像をなんやかんやするツールアプデ開発。

でもまあ、ドン詰まってた部分はようやく解決出来そうなので、次の段階に進めてはいるのですが。

ファイルリストへの編集（助長なフォルダ除去とフィルタリング、ファイル名の桁揃え等）と、画像変換の部分を以前は全部まとめてたのを分離して、見通しを良くする感じに。

そして、書庫ファイル毎に個別に編集設定を設定しやすい感じに。

んでもちょっとまた新しい問題が出てたりも。

画像編集処理の設定って、優先順位とかあるんですよね。

例えば、トリミングは上下左右ピクセル単位で切り取る幅を指定するのだけども、その処理の前に画像の拡大縮小をしちゃったら駄目なのはわかりますよね。

回転とかも、180度とか上下反転だといいけど、90度とかだと画像の縦と横の幅も入れ替わってしまう。

グレースケール化なんかは、速度的には縮小したあとでやったほうが軽いけど、縮小前にやったほうが高品質（あんまそこまで変わらないけどｗ）で、例えばみんなアイコンサイズにしちゃうみたいな用途だと、品質とか気にするほどでもないので速度重視にしたい…なんてケースも？

とか思うと、優先順位も設定できる方がいいのかなぁとか。

そうなると、各編集設定自体をオブジェクト化して、編集リストに登録していく。
処理はリスト順で実行される。

みたいな感じがいいのかなぁ。

とか思うものの、大体ほぼ優先順位なんて固定なんだよなとおもうと、メンテが面倒になるだけじゃないかなとか思ったりもする。

そして、新機能として、範囲指定の塗りつぶし機能なんかもつけたいなとTODOメモに残ってたのだけども。
スキャンした画像の一部に、どっからか紛れ込んだチン毛を見苦しいので塗りつぶして除去したいとかできる感じの（ぉ

が、用途的には一画像に1矩形範囲だけではなく、複数登録型にしたいよな。
そうなると、全部の設定が登録型のほうが一貫性ある感じにも？

それか固定リスト+追加処理リストで、固定リストの前と後の2つのリストに追加できる形とか？

んんーやっぱ全部登録型のがいいのか？
あんまし複雑化したくないなぁ。

なんてところでちょっと考え中。


そこでちょっと転進。
そろそろ書庫に出力周りも作って行かないとなというところで、旧版はzip書庫の読み込みも書き出しも自前で読み込んでたのですが、今回は7zip使うことでzip以外の書庫にも対応できるようになったのだけども、出力はどうしようかなと。

utf8フラグ周りとか、7zipはわりと自動判別に頼ってたり、そもそもzip専用のライブラリではないので、そのへんちょっと融通聞かないところあったりするので、zip書庫の書き出しは自前でやるかなと思ってたのだけども。

でも一度7zipのライブラリの方の書庫作成機能もどんなもんか試してみたいなという気持ちもあったので、ちょっと試してみることに。
現状はzip出力オンリーだけど、7z出力もやりたくなること有るかもしれないし？


なにげに今回、googleのAIの「Gemini」使ってみたんだけど、こりゃ便利だなと。
自分でワード打ち込んでGoogle検索するよりは明確に知りたい情報出てくるので、かなり時間短縮になりそうで今はこういう時代なのかーと（ぉ

でもまあ、相変わらずたまに嘘吐くのはAIの泣き所だなーとｗ

書き出し用のコールバック周りで

streamSpec->Open(...)

とかのコード吐くんだけど、そんな関数ねぇよって怒られて
7zipSDKのサンプル見ると

streamSpec->Create_ALWAYS(...)
streamSpec->Create_NEW(...)

のどっちか使え(NEWは同名のファイルがすでにあると失敗、ALWAYSは問答無用で上書き)
とあるので書き換えたらちゃんと出来たりで。

あと、Googleの検索結果から主に生成してる？　ので、基本出てくるコードが結構古いSDKのコードだったりする。
ほんの数年前の更新で変わった部分とかが、変わる前のやつが出てきたりするので。

(旧)MY_UNKNOWN_IMP1 → (新)Z7_COM_UNKNOWN_IMP_1

みたいな。

なので、そのままコピペして～てのだけだと無理だろうなこれ。
今回のような外部のライブラリなんかだと、ライブラリ自体の理解もある程度無いと、まず何処が嘘吐かれてるのかも判らないし。
そのへんまだまだAIに丸投げとかは無理そうだなこれ。


……んで、とりあえず大体出来たっぽいんだけども、最後の書き出す所で、なんか書庫内に含めるファイルサイズの全体の総サイズを要求されてる部分があるんですよね。

処理の流れとしては、元書庫ファイルがあって、そこからファイル名とかフォルダ構成とか編集して、画像をサイズ揃えたりとかフォーマット揃えたりとか色々加工して、新しい非圧縮のzipに書き出し。

っていうツールなんだけども。

画像を書庫から読み込んで、新しい書庫に処理後のファイルを1つずつ書き出し……ファイルストリームで書き出すだけだから簡単だろ。

とおもってたんですけど、件の全体のファイルサイズを先に要求されるんですよね。
画像変換すりゃ当然ファイルサイズも変わるので、処理前に全体のサイズなんて分かるわけ無いじゃんっていう。

AIが吐き出したコードだと

struct StreamSource {
QString fileNameInZip;
QByteArray data;
qint64 size;
};
QList m_files;

みたいなのを放り込んでるんですよね
つまり、変換後の画像ファイルすべてをオンメモリで一旦持てとｗ

そりゃ無茶やろと言ってみたら、AIさんも「確かにそのとおりです！」とか返答したりしてｗ

んで解決法はというと、在るにはあるようなのですが
zipフォーマットのData Descriptor形式ってのを使わないといけないらしい。
ファイルサイズを後から追加するタイプで、書庫内ファイル毎の個別ヘッダのファイルサイズの項目とかは0になって、別項目のData Descriptorフィールドにファイルサイズが記述される感じのやつですね。

わりと書庫系ツールによっては非対応だったりする代物なので、あんまり使いたくない奴。

そして、何でそんなんになっているかといえば、「7Zipライブラリの仕様」だということらしい。

つまるところ、zip専用のライブラリではないので、zip専用の仕様には合わせてくれないということのようです。

しょぼーん。

結局、zip書庫の書き出しは結局自前でやる感じになりそうですｗ

まあ、すでに以前自分で書いたのがあるので、書き直すだけなんですけどね。
でもまあ結構昔に書いたのと、その頃はまだzipフォーマットを調べながら書いてたやつなので、結構無駄が多いコードだったりするので、そこそこ骨が折れそう。
あとzipフォーマットも、もう一度思い出さないとなｗ

んまあ、7zipだと、文字コードとか自動判別してるところとか多いので、そのへん自前だと明確にコード指定して書けるので、変な見つけにくいバグとかに巻き込まれにくいというのはメリットかも。

あとちょっと気になったのが、7zipのSDKで、kpidIsUtf8っていう定義が見当たらない問題。

utf8フラグを設定するのに使うやつなんだけど、これまたAIさんに聞いてみた所、SDKのバージョンとかによってあったりなかったりするらしい。

んでこれもZip特有の設定なので、7zipのSDK使ってZipも扱うサードパーティ製のライブラリなんかで慣例的に使われてるのが「kpidIsUtf8」という定義らしいとのこと。

んーやっぱ端から出力はzip書庫決め打ちみたいなことしてると、こういうところで齟齬がでるんだなぁと。

統合アーカイバシリーズなんかも、インターフェースを統一するために、フォーマット固有の設定周りでどないすんねんみたいなのが犠牲になってる部分多かった記憶あるもんな。

そんな感じで、今日はほとんどAIさんと会話してるだけでほぼ終わった（ぉ

レス

お名前（無記入可)

スパム対策キー: 半角英数字で「いちろくいちはちぜろさん」 と入力してください

本文(半角英数字のみの場合はスパム判定されます)