8月ですね。

XopsAddonCreatorを触りましたが、次の難題にぶつかっています。
ブロックデータとポイントデータ、両者をいかに効率よく処理するか　です。


OpenXOPS（ゲーム）は、データを読みっぱなしで良いソリューションです。
あくまで両データはファイルから読み込んでいるだけで、読み込み後はゲーム
側で都合の良い独自のデータ構造で処理すれば問題ありません。
ところが、XopsAddonCreatorはエディタです。データを読みっぱなしで終わる
ことは殆どなく、データ自体を編集し 場合によっては元に戻す（Undo）機能
を提供する必要があるほか、ファイルとして書き戻す機能も必要になります。
この『読み込み⇒変更履歴管理しつつ編集⇒書き出し』という一連の処理が
エディタの肝であり、OpenXOPS以上に内部のデータ構造が重要になります。

モデリングソフトのようなひとつの形式（性質）のみに特化していれば　まだマシ
なのですが、厄介なことにXopsAddonCreatorはブロックデータとポイントデータ
という、性質が全く異なるデータを2つ同時に扱う必要があります。
※ブロックデータはモデリングデータに近く、ポイントデータはスクリプトデータ
　に近い。
ようは、『読み込み⇒変更履歴管理しつつ編集⇒書き出し』という処理パイプ
ラインが、同一ソフト内で二重に存在するわけです。

何も考えずに作れば、単純に同じ実装を2個開発して載せれば良いですし、
既に現行XopsAddonCreatorは、2重に実装されていると言っても過言でない
設計ですが、
単純に工数2倍で無駄な開発作業を生むうえ、バグを生みやすく、なんせ柔軟な
設計変更・改版もできません。
あくまで実装としては1つにして、両フォーマットに対応した柔軟な設計を取り
入れるのが理想であり最適解となります。

ですが、現状良い実装案が思いつきません。
C++のコンテナクラスを上手く使えないかと思っており、スタックやキューを
使えないかと企んでいますが、微妙に実装が合わず困っています。


6月の記事では、次期XopsAddonCreator開発における難所の一つに
「不具合のない安定したデータ編集機能の実現」
を挙げていましたが、本件前述の処理・実装がポイントになりそうです。
もう少し良い設計・実装を考えてみます。

7月になったと思ったら、もう7月も最終週ですね。
気が付いたら8月も終わって秋になっているのだろうか。

特定のネタを書くわけではなく、深夜の勢いでダラダラと近状報告を書く回です。


OpenXOPSネタでは、コンソールの文字入力部分の処理を作り変えています。
現状では その場しのぎ な実装になっているので、もう少し汎用性を高めた実装に
作り替える予定です。
割と良い感じなので、もう少し作り込んだら本流にコミット予定です。

あとは、超久しぶりにOpenXOPS向けのaddonっぽいコンセプト・デモを作って
いました。ちょっと作ってみたい面白いネタが見つかったので。
今でもテストサンプルデータであれば ちょくちょく作るのですが、まともに
プレイ可能な作品を作るのは5億年ぶりぐらいかもしれません。
一応プロトタイプは出来上がって、作品全体の雰囲気は掴めたので、あとは
作り込んで作品として公開するか否かですね。
公開するにしても、どこで出そうか・・？　やっぱり「みかん箱」？
このまま出さないでお蔵入りして終わるかもしれません。期待しないでください。

ちなみに、今まであまり明言してこなかったのですが、
私としては、今後XOPS向けのaddonを量産して次々公開するような方針では
ないですし、そのような予定もありません。
2006～2012年頃のように、年間のうちで何個もaddonを作って次々公開していた
時代もありましたが、
addon作成はその道が得意な他の方に譲り、自分としてはOpenXOPSや
XopsAddonCreatorなどのソフトウェア開発の方向に重点を置くつもりです。
もちろん、私作の新addon公開の可能性は否定しないですが。


XOPS外で、
7月最初の記事で書いた基板の件ですが、前回同様に中国の基板メーカーに発注
して、ほぼ納期通りに納品され、試しに1枚実装してみました。
基板自体は予定通り問題なく動いたのですが、約1年前に作った初期基板と比べ
動作に差異が見られません。
初期基板が使用できなかった環境で不具合再現を試みても、そもそも初期基板で
不具合が再現しないのです・・・。
もちろん、改良型の方が基板の特性は向上しているはずなのですが、初期基板で
不具合が起きないならば、わざわざ手間を掛けて改良基板を作る必要はなかった
ような気がしてなりません。
誰だ、基板が悪いとか言ったの！　ー俺かぁ。。


遅い時間になってしまったので、今回はこの辺で。
コロナが再流行しているので、皆さんも体調にはお気を付けください。

皆さんいかがお過ごしでしょうか。
ここ数日は日が出なかったので、気持ち涼しかったように思います。

名前を出して良いと思うので出しますが、7月2日に量産型量産機さんが
Unityを用いてXOPSを再現したゲームを開発中であることを発表されて
いました。
　https://twitter.com/Gurz1019_MP/status/1543226847751651329

UnityでXOPSみたいなゲームを作る人は過去にもいて、決して珍しいこと
ではないのですが、
特筆するべき点は、グラフィック・サウンドデータをクリエイターに有償
で発注して開発している点です。

7月ですね。ここ1週間ぐらいで急に暑くなって辛い。
モンハンのサンブレイクが流行ってますね。

先週まではゴリゴリXopsAddonCreatorを作ってましたが、今週は一転して
電子工作ネタでプリント基板設計してました。

内容としては去年4～5月頃に作っていた、高速信号系の基板です。
　回路引いたり部品買ったり基板起こしたり（2021.04.19）
　モーターが回りました（2021.05.18）
　　※紛らわしいですが、同時期にやっていたパワエレとは無関係です。
去年作った基板は、某所の現場（？）でも使われていますが、場合によっては
うまく使えないことがありました。
騙し騙し使い続けていましたが、流石に使い勝手が悪いので改良版の開発に着手
した次第です。


不具合が出る原因は正確には分かっていないのですが、当初は高速信号のライン
・構成が悪いのかと疑っていたものの、
電源部分に数百uFの電解コンデンサーを付けると改善方向になることから、電源
ラインが悪そうだと目星を付けています。
今思うと、基板全体で流れる電流量に対して、電源ラインのパターンが細すぎ
たのと、GNDのベタパターンもルートが悪かったりと、色々と詰めの甘い基板
設計だったので、その辺の電源・GND周りのパターンを見直すのが今回のメイン
ミッションです。

今回、運よく使用技術の規格書が入手できたので、参考にしつつ可能な限り
規格準拠を目指して回路図やパターンを作り直していました。
もちろん規格完全準拠ではないのですが、別に外に出すものではなく某所の
クローズドな環境で使用するものなので問題ないです。
当たり前ですが、既存製品を調べ上げて それっぽく再現することに比べれば、
一次ソースである規格書を参考にできるのは強いです。

あとは、不必要なパターン・部品を取っ払い、逆に使いそうな回路を新たに実装
して、設計全体の最適化を狙っています。

基板設計に加えて、機構設計（？）も やや改善を試みるつもりです。
前回は「機構？　なにそれ、おいしいの？（＾＾」状態で、部品の固定を
殆ど考慮しないで作ったため、使用中は物理的にも安定性に欠けていました。
今回は、ある程度は部品の固定も考慮するつもりではいます。

使用する部品は発注したので、部品が届き次第 部品と合わせて基板設計の最終
チェックを行い、基板を発注する予定です。
基板をどこに頼むかは決まっていませんが、前回と同じ中国の製造メーカー
に発注しようかとは思っています。安いですし。


本当は、写真なども加えてもう少し詳しい話ができれば良いのですが、ネット上
で一般公開している記事である以上、どこで誰が見ているか分からないので、
詳しい説明は伏せようと思います。

それにしても、プログラミングでXopsAddonCreatorを弄るのも楽しいですが、
回路設計・基板設計も楽しいですね。良い休日を過ごせました（＾＾

前回言ったXopsAddonCreatorの作り直し計画の件、適当に勢いに任せて
突き進んでいます。

とりあえずウインドウ周りの処理を作り込んでいました。
色がメチャクチャですが。

（クリックで拡大）


以下、中身の技術ネタです。

Windowsアプリケーションなので、ウィンドウプロシージャの処理が味噌
となります。
ウィンドウプロシージャ自体は難しくはないのですが、無計画に組み立てて
行くと、あっという間にスパゲッティソースになるので要注意です。

ウィンドウプロシージャの処理については、まだ設計・実装がFIXしているわけ
ではなく、全体をイベント駆動型にするか、指定関数を直接実行する構造に
するか、迷っています。

最初に思いついたのはイベント駆動を用いた設計でしたが、
ウインドウサイズを変更する際にウィンドウプロシージャが連続で実行される
ため、外でイベントがキャッチできず、ウインドウサイズ変更に期待通り対応
できませんでした。
どうしたものかと困りましたが、サイズ変更時にWM_SIZEをキャッチして、
関数ポインタを用いて指定関数を直接実行する構造にすれば、期待通り動作する
ことが分かりました。

現状は、イベント駆動と関数実行機能が両方載っていますが、将来的には関数
実行機能だけで良いかとは思い始めています。
せっかく作ったイベント駆動を消すのは勿体ない気持ちもありますが、まぁ
要らないものは要らないですからね。他で使えれば良いのですが。
あと、今回初めて自発的に関数ポインターを設計に組み込んで活用しましたが、
自信の中で実績がなく、デメリットや注意点が完全に把握できてないです。。
とりあえずNULL判定だけすればよい？？（＾＾；
実績が皆無な技術を過信したまま、設計の中心に入れて良いものなのか全く
分かりません。

なお、今回色々調べた中で「メッセージクラッカー」というMicrosoft公式の
ラッパー・マクロもあることを知りましたが、結局のところはSwitch文が多少
綺麗になる程度で、目当ての使い方はできないようなので辞めました。

いやー、これはこれでOpenXOPSとは違う難しさがありますなー。


それにしても、現行XopsAddonCreatorは2012～2013年頃に作り始めており、
（現行品の系統は）もう10年前に開発したことになります。
他所でも呟きましたが、このレベルのエディタを1年程度で作り上げるって、
今思えば信じられない話です。
まだXOPS界隈に人が居る時代で周囲からの期待もありモチベーションも
高かったり、今と比べて平日も時間があったり、当時は ただただ無計画に
勢いで進めていた節もありますが、
一番大きいのは今よりも10歳若いという事実だろうなぁ。。　若いは強い。