イラスト練習中

今回は液タブの調子が悪かったのでドット絵です。
例によって18禁なのでフォロワー以上限定です。

XPサポート

WindowsXPのサポートがどんどん隅に追いやられています

たまーーに、XPでうまく動かないという報告があったりするので、表向きは動作環境にXPと書いていなくてもこっそりサポートはしていたのですが……。

かなり前から古い関数を使っていると警告が出るようになってはいましたが、数年前ぐらいからデフォルトではXP向けに作ったプログラムのビルドができなくなりました。
Visual Studio 2018 にしてからは、ビルドするたびに XP向けプログラムのサポートは近く打ち切られます的なメッセージが出るようになってます。

確かに、いつビルドできなくなってもおかしくないんですよね。まあ、開発環境をアップデートせずに残しておけば良い話ではあるのですが。

思えばXPも既に20年前のヤツです。もう……いいかな……。

あまり参考にならないエフェクトの描き方

絵的なエフェクト（今回は土煙）の話です。

エフェクト類を全部自前で用意すると大変過ぎるので、フリー素材で丁度よさそうなものがある場合はそれを積極的に使用させて頂いています。
フリー素材でどうにもならない場合はプログラム的に画像を変形させたりパーティクルを飛ばしたりで結構何とかなります。

それでもどうにもならないものはどうするか？
アフターエフェクトやUnityのアセットを扱えるなら気合入れて作るのもいいと思いますが、私の場合は幸い2Dドット絵のゲームなので、そこまで力を入れなくても誤魔化せるので手描きでなんとかしてます。

今回はこれ、漫画やアニメでよく見る、いかにもダッシュ全開という感じの土煙です。こういうエフェクトが欲しい。

要するに「爆発的に後方に広がってモヤッと消える」だけです。
（言うは易しですが……）
というわけでそれっぽい形のアニメーションを単色ドットで描いていきます。

次に色を付けます。どうせ後でぼかしを掛けるので大雑把です。

実際にアニメーションさせてみて形を調整したり、足りないコマを描き足していきます。（今回は主に後半の消え際を描き足しています）

最後に軽くぼかしを掛けてもう少し煙っぽくします。
ね、簡単でしょ？

キッチリと全部ドットでエフェクトを描いているゲームならぼかしを掛けない方がキャラとの統一感が出ていいかもしれません。
まあその場合はもう少ししっかり描き込む必要がありそうですが……。

そしてこれが実際の画面でどう見えるか？

フォロワー以上限定特典、初公開（だったと思う）の実際に動いているゲーム画面動画です。（……と言っても主人公が走り回っているだけですがｗ）

近況報告

ぼちぼち作業を進めています。
風邪は良くなったのですが、たまに謎の眩暈（？）が起きたりして油断できません。なんなんだろうこの症状は……。

さて、以前にもちらっと書きましたが、ゲームに使うスクリプト言語には昔から lua を使っています。最初はPythonだったのですが、組み込みに（Cで定義したオブジェクトをクラスとしてPython側から使う手順）手間がかかるのと、ライブラリが結構大きいというか重くてやめてしまいました。何らかのバインダーを使えばよいのでしょうが、そこまでして使うのも……という感じで。luaはすごく軽くて小さくて使いやすいのですが、配列のインデックスが１起算なんですよね……。

そこで目を付けたのが Java Script ですよ。Java Script ならWebでたくさん使われているし、duktape というライブラリを使うと lua と同じ手軽さで導入できるので、以前から気にはしていたんですよね。あと Java Script ならプログラム経験が無い人でも多少はなじみがあると思うので、別の人にも手伝ってもらいやすいかな、と。

少なくともあやかし紅白戦では引き続き Lua を使いますが、その先どうするか、ちょっと迷い中です。

おまけ

https://twitter.com/helio_dor/status/1084156381496627201

正直ブルマーは紺色が最高と思ってましたがピンクも結構イケる気がしてきました。

有料支援者特典のエロドットビュワー裏話

プログラム話です。

先日公開した支援者様向けのヴィータ大脱出エロドットビュワーですが、ただ敵をON/OFFするスイッチを付けただけのものなので、そんなに手間はかからないだろうと思ってました。
……しかしそんなことはありませんでした（泣）。

まず、素直に敵だけ非表示にできるように作ったのですが、そうすると白濁液とかヨダレとか白い息のエフェクトが何もない空間から出てくるんですよ。

ヴィータ大脱出ではキャラクターの表示・非表示を切り替えるといった動作が皆無だったので、エフェクトを生成するときに、生成元となるキャラクターが表示状態なのか、非表示状態なのかをチェックする機構というのはついていませんでした。

そんなわけで、「エフェクトを生成するときにその生成元のキャラクターの状態をチェックし、非表示状態であればエフェクトを生成しない」というコードを追加しました。

ただ、それを一律に適用してしまうと、パーティクルをまき散らすための隠しキャラクター（ジェネレーターとかエミッターとか呼ばれる）がパーティクルを一切生成しなくなってしまいますので、アルバムモードかつCi-en限定版でのみ、このような条件でエフェクト生成するようにしたわけです。

本当ならば敵をOFFにしたときに、敵から生成されたヨダレ、地面にヨダレが落ちた跡、跳ね返りの液体もすべて一括でOFFにできればスマートでよかったのですが、意外と大変なのでボツにしました。

それをやるためには、何が何を生成したのかという関係を追跡して管理する仕組みが必要ですが、そういった仕組みはヴィータ大脱出では不要だったので作っていなかったのです。そもそも、そういう仕組みを作ること自体が意外と大変です。

例えば、敵がヨダレをたらし、そのヨダレが地面に衝突して涎の跡（以下水たまり）を生成すると同時に、付近に飛び散る液体（以下水しぶき）を生成したとします。生成関係の追跡を素直に実装すると、各オブジェクトがそれぞれ自分が誰から生まれたのかという情報を持つようにして、ヨダレは敵から、水たまりはヨダレから、水しぶきは水たまりから、ということが後から調べられるように作ると思います。

これを逆に辿っていくと、水しぶきは元々敵から由来したものだから、敵の表示をOFFにしたら水しぶきも消えるべきだとわかるわけです。

これで問題なさそうですが、実際にはそうはいきません。水しぶきが上がったときにはヨダレはすでに消えているため、水しぶき→水たまり→ヨダレまでは辿ることができますが、この時点でヨダレはすでに存在しないため、ヨダレがどこから来たのかという情報が消えているからです。

となれば、こういった情報は各オブジェクトに持たせるのではなく、外部の管理者に任せるようにすればよいという事になります。しかし、それはこれまでに作成したオブジェクトの履歴をずっと持っているという意味になるので、実行時間が長くなるほど管理するべき履歴の量が増え、負担が大きくなってしまいます。

だったらどこか適当なところで古い履歴を削除して……などとやっていると、こういった仕組みをまじめに作るのは結構大変だという事に気づきます。そんな面倒なことしなくても、空中からヨダレが出ないようにするだけで十分ですしね。

それよりも大変だったのは、アルバムモードでの非同期ロードが原因と思われるエラーです。

今回のアルバムモードでは起動時にすべてのアルバムが強○的に解放されるので、アルバムのロードが40個ぐらい同時進行で進んでいます。これは初めから意図していた動作ですので、当然スレッドセーフになるように作っていたのですが、どうやら穴があったようで、起動直後にアルバムを高速スクロールしていると落ちる時があるんです。

さらにデバッグモードでは落ちずにリリースモードの場合だけ落ちるといういやらしさです。しかも検証用のコードを入れたとたんに落ちなくなるという……。プログラムあるある的な話ですね。

直接の不正落ちの原因は、配列の範囲外のインデックスを参照してNULLが返った事によるNULLポインタ参照エラー（ぬるぽ、懐かしいですね）なのですが、そこに配置してあるインデックス確認用の assert には一度もひっかったことがないんですよね。デバッグモードで assert が有効な時は不正なインデックスが入って来ず、リリースモードで assert が消えた瞬間に不正なインデックスが入ってくるという……。

メモリ関係のエラーはちょっとコードを書き換えただけで挙動が変化してしまうので、本当にやりにくいです。結局今回は NULL チェックを追加して参照を回避しただけで、そもそもなぜ範囲外のインデックスが来たのかという根本的解決にはならず、でした。

https://twitter.com/helio_dor/status/1064442433004482560
https://twitter.com/helio_dor/status/1064442686541721600

この辺のツイートは大体そんな感じです。ヤケクソ感漂いますね。