堕天使の煉獄

ちょいと間が開きましたが。

というのも書く予定のメモがたまりすぎて、書くのが億劫になってた感じだったり（ぉ

というか説明しようと思うとえらく長々と面倒な事態で、だけど事細かく説明したところで興味ある人もそんな居ないだろうっていう内容だったりもして。

徒労のわりに得るものあんまない感じ。かといって書かないのも、当初のここで書くネタを確保するプレッシャーを作業をすすめるモチベーションに。
っていう大前提を崩すことにもなりかねなくて……なんか自分の作ったルールに自分で首しめられて四苦八苦というまあ、よくある間抜けなパターンにハマり中（ぉ


んでその件というのは、なんか大ハマリした事がありまして。

Qtではシグナルとスロットという機構があるのですが。
マクロで「Q_OBJECT」というのをクラスの宣言に書くと使えるようになって、ウィンドウメッセージの処理部分を隠蔽してとっても使いやすい形にしてくれるようなやつです。

んで、普通にいつも通りの使い方、書き方で書いたのですが、ビルドするととあるシグナルが「エラー: LNK2019: 未解決の外部シンボル」となってしまって。

LNK2019て普通は、ヘッダに定義あるけどcppに実装無いとか、ライブラリのなかの関数なんか呼ぶ時に引数の合致するものがなかったりとか、要はそんな定義の物はねえですヨ？
って時に出るのですが。

そもそも最近のIDEは優秀なので外部のライブラリとかでもなければ、ビルドする以前にコードエディタ上でそんな定義の関数とか無いですよ？　って教えてくれるわけで。

なぜかどう見ても「ある」のに「無い」って言われてる。それもビルドの時に無いって言われる感じで。

が、これだけなら割とよくあるケースで、古いソースコードから生成された中間ファイルなんかが残ってて古いものを参照してるってのがよくあるパターンで。
クリーン→リビルドで大体治ったりするのですが。

今回はそれをしても駄目。

Qtのこのシグナルとかスロットの機構って、mocっていう「めたおぶじぇくとこんぱいら」によって提供される機能の一つで、要はヘッダに書かれた内容「signals:」とか「public stots:」みたいなののあとで書かれる宣言なんかを一旦mocを通してc++のコードでそれらの機能の実装に置き換えて。それからビルドするみたいな感じになってるのですよ。そんで通常なら複雑な記述や手続きが必要なオブジェクト間通信なんかを実現してるわけです。

で、なぜか基底クラスのシグナルは普通に発信できるのに派生クラスの自作クラスのシグナルだけ見つかんねぇと言われる感じで。
connect文にまちがえて親クラスを書いちゃってるってこともないし。

なんで？

どうもmocあたりでなんか失敗してる感じっぽい雰囲気ぽ。
んーヘッダオンリで書いてるのがまずいのか？
ヘッダのインクルード順とかでなんか引っかかってるとか。
定義が見つからない云々っぽいエラーなので。

んでビルド時に生成されるファイルに「moc_XXXX.cpp」てのがあって。
上記のmocによって生成された実装部分なんだろうなと。
古いキャッシュが悪さしてるかんじならこの辺か？　とタイムスタンプとかチェックしてるときに、なんとなく該当のソースコードを覗いてみたらば……。

シグナルの実装部分には、たしかに自分で定義したシグナルが無い……どころかなんだか見覚えのあるものが……。

これリライト前にあったシグナルの名前じゃん……。

古いソースコードを参考にして生成してるというのは的を得ていたようなのだけども……肝心のその古いソースコード自体、もうとっくにプロジェクト内に無いですよ？？

一体どこかの古いコードを参照してるんだ？？
そしてなぜこのファイルだけそうなってるの？？

HDDが破損しててロックされてて上書きできなくなってるとか？　とCrystalDiskInfoみてみたりとかしたけど問題もないし。

こりゃ一体全体どういうこった？？

とおもって、プロジェクトのフォルダのなかみてみたらば……。

問題のあったヘッダファイル
widget/filelist/archive_file_table.h

それとは別に
filelist/archive_file_table.h

というソースコードが……。

以前はwidgetまわりってデザイナで生成すると.uiや.cppとかまで作られるのでフォルダ分けたいな…ってのがあって昔は分けてたのですが。

今回、ヘッダオンリーにできるものは徹底してヘッダオンリーにしてしまおうってことで、そうなるとべつにwidget関係のところに全部書いちゃってもいいなーってことで移動したんですよね。

そしてQt Creator上で削除したはずなのですが……
案の定、古い方であるfilelist/archive_file_table.hの中身見てみたらmoc_archive_file_table.cppの中身で見たシグナルの定義とかはこの古い方の中にある定義と一致したりOTZ

コードエディタ上でclangとかのコードチェックでは正常なのでエラーでてなかったけど、mocはなぜか古い方のソースコードを参照して実装を生成していたので、そんまものねぇよってLNK2019吐いてたというオチ……。

ええーっと、途中までおんなじパスのコードがあった場合、先に見つかったほう？　が優先されたって感じ？　これって仕様？　バグ？？

普通にc++でそういう仕様あるなら、そもそもコードエディタ上でエラー吐いてないとおかしいし。やっぱmocのバグなのかなぁこれ……。

そんな感じでこんなんで大ハマリして、ちょっぴり不貞寝したあと、またちょっとざくアクとかやり始めたりして間開きましたと（ぉ


で今は作業再開してるのですが。
ようやっと画像プレビュー周りに手をつけるところまで来たのだけども。
この辺昔のはかなり入り組んだ汚いコードになってたので整理のために全部リライトする感じで。

その際に画像の情報周りでちょっと面倒な感じになってたりして。

今のところ、画像ファイルのバイナリから自前で画像サイズやらアルファチャンネル有無だとかプログレッシブか？　とか自前で取得してたのですけども。
今回、アニメ付きのgifとかwebpとかもちゃんと対応する予定でアニメーションの有無なんかもチェックしてたのですが。

んーこの辺自前でやるのって新しい仕様とか形式増えた時に面倒なんだよな。
どうせならQtの機能で全部やってしまいたいところ……。

で、QtにはQImageReaderていう、画像全体を読み込む前に事前にある程度情報取ってこれる物があって。
特にアニメーション系の判定があるのが良いのですが。

最終的に画像はQImageとして読み込むけど、動画系はQMovieとして読み込むことになる感じで。
そうなるとそのへん包括的に扱うクラスとか作らないとなーという感じで。
そこで必要な情報とか集めるところで、もともとあった自前の画像情報クラスの項目って、使わないものも結構あるよなーと。
ビット深度とかプログレッシブ判定とか。

QImageReaderで取れる情報だけに絞ったほうがいいのかなーと思案中。
でもプログレッシブjpgとかって、元画像がプログレッシブでそのまま保存するときはプログレッシブ設定引き継ぎたいってのあったんですけど。
QImageReaderにはプログレッシブかどうかって情報はないんですよね。
そも特定の画像形式にしか無い設定ってのもあるんですけど。

んーjpg保存のオプションに「プログレッシブ」のチェック増やすだけにして、読込み時はプログレッシブかどうかは問わない感じにするかねぇ。

といった感じで画像周りの仕様も1から作り直し必要な感じになって、いまだに画像表示まで行ってない感じぽｗ


あとは最近のQtは内部の描画が勝手に環境に合わせていい感じのを選んでくれるようになってて、winだとDirectX使ってくれたりしてくれるようで。
ちょっと前のverではクロスプラットフォームの維持のためにopenGL固定でDrectXは切り捨てられてた時期もあったりで。
その互換性のための古い描画系のせいでハードウェアのサポートが不十分で、Qtのデフォルトの仕様だと画像の拡大縮小がすんごく汚くって。
大昔のフォトショップの4とか5とかあのへんの、25%とか200％だとそれなりだけどそれ以外の倍率だとめっちゃ汚くなるあの感じレベルで。

なのでそれを通常モードとして、低速だけど自前で拡大縮小してきれいに表示できる高精度モードの二種類を用意してたのだけども。

最近のverのQtだと内部でdirectXとか使ってくれるので、通常モードでもそこそこきれい……拡大は遜色ないけど、縮小は……前のよりはましだけどもちょっと汚いな。
ニアレストネイバーとかになってるのかな。Bilinearとかに変えるの設定あるのかな。

とにかくそこも前の表示モードの切り替え必要なくなって、その分シンプルに書き直せるようになった部分もあったりして。

でもその辺隠蔽されて直で叩けない部分多くて、レベル補正とかをシェーダーで……てとどないすんねんってなってたりもする。
以前はopenGLつかってやる方法でやってたけど、どうせならdirectXでのシェーダー書きたいんだけど、そのやり方がさっぱりｗ



話は変わって。

しょーもない大ハマリで不貞腐れてた時に、ざくアクちょっと再開してたのですが。

その時にプレイ中にバツンとモニタが真っ黒に。

えぇー……

モニターがスリープモードに……。

WIN10になった時に、なぜかUSB接続のゲームパッド接続されてる状態だとモニタがスリープモードに移行してくれない問題あったのですが。

USBの延長コード買ってきて、ゲームし終わったら延長部分のコネクタを外す（PC本体の
コネクタ直でつけ外しはそこが壊れたらヤなのでｗ）
というアナクロな対処法で我慢してたのですが。

ある時、コネクタ外すの忘れてた時にモニタスリープになってるのに気づいて。
どうもWinアップデートでその辺の監視方法が変わった……というかもとに戻った？　らしく接続しっぱなしでもスリープするようになったんですよね。割と最近の話で。

で。

今度はゲームパッドの入力しかない状態、まあ平たく言えばゲームプレイ中ですね。

……入力なしと判断してスリープモードに突入するようにｗ

その上、画面サイズを二倍にするソフトもつかってるのだけども、そこでdirectXがデバイスロスト起こした感じでウィンドウサイズは二倍のままなのにゲーム画面は1/4表示にｗ
で結局再起動する羽目になったりで。


まあソフトによってはスリープ抑制機能ついてるのもあるので気にしないで良いのですが。
ざくアクとかPRGツクールVX製だったよな。VXは抑制機能ついてた気がするんだけど……どうだっけか……もう何年も前のことだから覚えてないや。

ともかく、抑制機能ないゲームなんかは、ゲームパッドの入力でもスリープ抑制させるツールを昔は使ってたのですが。
HDD漁っても該当ツールはでてこないのでネットで検索。

あった。

「Screensaver×」

アイコンに見覚えあるので昔使ってたのはコレだと思ふ。
……Windows2000でも動作可能にするために古い.NET Framework3.5を使ってるとかで。
win10だと互換性なくて入れないといけないのね.NET Framework3.5。
したら.NET Framework3.5、win10だとインストール失敗すること多いみたいな記事出てきて。
うーん。コレのために入れるのも何だしなぁ。
ってことで別のソフトを探すことに。

「FavSleepStop」

なんかソフト名に見覚えあるなと思ったらおっきなファイルもスパッと表示できるバイナリエディタ「FavBinEdit」の作者さんのソフトだったのか。


で、まあ結局、昔に戻ったのね。不具合まで。
まともにゲーム一つするのにも一苦労って。
ファッキンMS……。




も一つ話変わって、「フルメタル・パニック」に新作でるんだそうな。
スレイヤーズも新作でたし（その後とまってるけどｗ）
富士見ファンタジア文庫リバイバル期？

この勢いで「道士リジィオ」「メルヴィ＆カシム」とかも新作こないかなぁ……



さらに話変わって。

ちょっと前から気になっていた商品。

「KINCHO 蚊がいなくなるスプレー」

ワンプッシュでシュッとするだけで、12時間殺虫効果が続くってやつ。

電気式のベープマットなんかは、蚊がいるなと思ってからつけても効果出るまで時間かかったり、効果なんかいまいちだったり。
弱ってヘロヘロ飛んでるけど死んでなかったりするし。

で、レビュー見ると、「心配になるほど蚊が死にまくる」とか書かれてて。

うーんどうなんだろう。
熱帯魚とか死んじゃうらしいし、かなり強力らしいので人体への影響心配しちゃうレベルとかで。

でも、蚊……うざいよね。

ってことで試しに買ってみたのですが。


……しゅっと一吹きしたところ、蚊じゃなくてたまたま居た普通の羽虫みたいなのが、吹いた数秒後に見てる前でぴゅーっと落っこちてきたり。

効果やべぇｗ

……そのあと、なんか目がシパシパしてきて、なんか喉というかちょっと胸に違和感ある感じがあったりして。
敏感な人はそういうの出るらしく、でもとくに危険ではないと書かれてるんだけど。
うーん。

結局、自分の部屋の中では使わないで、部屋の外の廊下部分に毎晩シュッと一吹きする感じの運用にしようかなと。

大体蚊が入ってくるのはそっちのほうから……ドアの下の隙間とか出入りの際とかに入ってくる感じみたいだし。

そっちで殺虫できればこっちまで来ないよなと。

目もシパシパしないですむしｗ
あと、食器とか食べ物あるところではやらないでとか書かれてるので、コップに入った飲み物とかもスプレーしたあとはどうなんだろうね。
ってのものあるし。
部屋の外でやる方が色々と問題少ない感じぽ。

部屋の中は……今まで通り電撃殺虫ラケットで頑張るｗ

一吹き12時間で250回分あるそうなので、とりあえずこのひと夏お試しで試験運用中ぽ。