なんかとんでもない時間ですが、ブログ更新です。眠いでござるよ。
あー今年は年賀状とかどうしようか。

12月14日にnine-twoさんのサイト（SECEF EVISOLPXE）が更新されましたね。
相変わらずのnine-twoさんで安心しました。　（？
XOPS2は「この通り順調です」って、本当に順調と言えるかどうか分かりませんけど。

マルウェアと誤検知されるというのも外せない情報ですが、個人的にはそれ以上に
OpenXOPSに関して言及して頂いたことが嬉しい限りです。
　サイトを直接目にした時、思わず着ていた上着を破ってしまいました　＜おいおい
あまり自信はないですが、2006年頃から今までnine-twoさんのサイトにて、特定・個別
のユーザー活動に対して直接発言し、リンクまで貼って頂いたことは、恐らく前例がない
と思います。　多分、OpenXOPSが初です。　やったー！


OpenXOPSの開発ですが、念願だった当たり判定と、何度も言っていたサウンド処理
周りが概ね完成しました！

当たり判定は細かい調整が必要なものの、かなり良い感じです。
生存時の人とマップとの判定・計算は、本家XOPS通りの動作を再現できていると思
います。
これで、急勾配の山登り・登山がし難くなった上に、マップの斜面（階段など）を上がる
速さも改善されました。
MIFファイルの「追加判定」を有効した際の処理が、まだ書けていませんが。

サウンド処理周りも、1ヶ月以上煮詰めていた管理アルゴリズムを実装し終え、快調
に動いています。結果的にはサウンド再生周りを、ほぼ全面的に書きかえる作業で
大変でしたが、非常に満足しています。
分かりやすい改善点として、AIが銃声や着弾音に反応しなかった問題点も、これで
全て解消されました。
内部の構造としては、（今回の作り直し作業で）移植性が圧倒的に上がりました。
細かいデバック・テストが出来ていないので、その辺をこれからやります。


最近ブログに書いていた「AI」「当たり判定」「サウンド」は、良い感じに仕上がりました。
本家XOPSとの相違点は、細かいものまで数えれば山ほどありますが、とりあえず
これでソースコードは出せるレベルになったと思います。

ライセンスは予告通り、このまま修正BSDライセンスになりそうです。

ソースコードの公開場所どうしましょうか。
一応SourceForge.JPとか使うつもりでしたが、使い方を覚えるのが面倒ですね。
今年夏ごろにSourceForgeのアカウント取ったんだけど、使い方全然覚えてないorz
もしかしたら、全部1個にZIP圧縮して、公式サイトにそのまま上げるかもしれません。

細かいことは、決まり次第　また公式サイトにて告知します。
あぁサイトで公開中の「OpenXOPS技術解説書」も今回の開発に合わせて、また
書き変えないと。面倒くさいなぁ。


＜2015/01/14　追記＞
独自に調査してみましたが、過去に数回ほど特定・個別のユーザー活動に対して直接
発言し、リンクを掲載した前例がありました。　（2006年頃にXCTなど）
失礼しました。

ブログの更新をさぼってしまい、すいませんでした。
そして、前々回『関東はそんなに寒くないぜ★』と言ったら、急に寒くなりやがって。


10月15日の時点で『当たり判定は　やる気がない』と言ってしまいましたが、
色々考えた結果、当たり判定にも手を付けることにしました。
むしろ、当たり判定以外は概ね良い感じに仕上がっている中で、当たり判定
だけ雑な作りと言うのもどうなのかと思ったからです。

ただ、このブログでも自作偽XOPS（fxops）時代から散々書いていた通り、当たり
判定は非常に難しく悩ましい問題です。
自作偽XOPS時代は、基礎的な知識が全くなく何も分かっていない状況で、参考
文献のソースコードに頼っていたりと、かなり滅茶苦茶なことをしていました。
何年も経った今では当たり判定の実装も慣れてきており、OpenXOPSでは無事に
一発でそれなりのプログラムを書き上げることができました。
ただ、本家XOPSと比べると分かる通り、やはり不満が残る計算です。

これ以上自力で考えるのは現実的ではないと考え、素直に諦めて最終手段です。
　・・・本家XOPSのプログラム担当　nine-two氏に直接聞く・・・

そりゃ当たり判定に関わらず、nine-two氏に最初から全て聞くのが一番手っ取り
早くて私は楽ですが、ご本人に多大なるご迷惑をお掛けするので、直接質問する
というのは、最後の切札に留めると決めていました。
最終作戦の実行です。　本物を作られたnine-two氏に直接連絡を取って、当たり
判定について聞いてみました。

nine-two氏もお忙しい中、本家XOPSで使用しているアルゴリズムについて、非常
に詳しく教えて頂きました。本当に助かりました。（ありがとうございます。）
ブロックの外側・内側の判定を駆使するのが最大の胆で、移動先がブロックの内側
である場合、移動元から見て面している面に接触したと判定する手法です。
　（詳細な計算方法は、近日中にOpenXOPS公式サイトの「OpenXOPS技術解説
書」に載せます。）
『うわー　その手があったか！』　言われてみれば、確かにそれで判定可能です。
そのアルゴリズムを教えて頂いた時、思わず言葉を失ってしまいました。感動した
のと、その計算方法を思い付かなかった自分の未熟さという二重の意味で。
ちなみに、この手法はnine-two氏が独自に考案されたようです。
何て言うか「流石」の一言に尽きます。　やはり足を向けて寝れません。


OpenXOPSとは関係ない別件ですが、久しぶりにXopsAddonCreatorを弄りま
した。　XopsAddonCreatorを利用して頂いている方から、コピーandペースト時
のバグを指摘して頂いたからです。
バグ自体はあっさり直ったのですが、そのバグを1個直すだけでバージョンアップ
するのも　もったいない（？）ので、他にも小さな新規機能を付けられないか模索
中です。

12月のはずなんですが、例年と比べてそんなに寒くはない気がします　＠関東
そして、油断して風邪をひくフラグ。


予告通り、OpenXOPSのサイトを移転し、リニューアルしました。

　http://openxops.net/

細かいことは前回話した通りですが、これでロゴマークを使えるデザインになり、
著しく悪かったメンテナンス性も向上しました。

今年11月20日頃にちゃっかり取った「openxops.net」というドメインを早速使って
います。　むしろ、このサイト移転に合わせる形で取得したのですけどね。
ドメインを意図的に変えるか、何かの拍子で失効しない限りは、もうOpenXOPS
のサイトを移転することはないと思います。
XOPS関係のサイト管理人は　忙しい方（笑）　が多いようで、なかなか連絡が取
れず、リンクページのURLを貼り替えてもらえなかったりする場合もありますが、
こうしてドメインを取得してしまえば、サーバーを移転するにも、ドメインごと持ち
込めばURLは変わらないので便利です。


WEBサイトの件がメインか、デモG版の公開が本題か分かりませんが、Open
XOPSのデモG版を公開しました。

諸般の事情で、「デモF版」はなくなりました。　っといっても、欠番になっただけ。
前回のE版でメニュー画面右上の表示が demoF となるバグ（表記ミス）があり、
ここでデモF版を出すと、混乱するからです。　
前回のデモE　＝　デモF　と思っておけばOKです。

大雑把な変更箇所は、説明書記載の通りです。
他の細かいところはもう忘れました　（＾＾；
他の方に指摘して頂いた誤字を直したり、イベントメッセージファイル（.msg）の
ファイル読み込み周りのバグを直したり、血や煙の描画を改善したり、死亡時に
スコープ表示が解除されないバグの修正とか・・・。　　他にもあります多分。

サンプル公開しているデモ版は、今回のデモG版で6本目ですが、そろそろデモ版
の公開もやめようと思っています。
後、1～3本出すか出さぬかで、ソースコードも出す本公開に切り替えようかなと。
（詳細未定）


なお、11月21日の記事で触れた透過テクスチャですが、デモG版での表示の通り、
無事に表示できました。
コメント欄でアドバイスをくれた方のおかげです。ありがとうございました。

ブログを更新する気が起きませんでした　（殴

11月15日に投稿したOpenXOPS動画の2本目が、1週間しないうちに1000再生に
達しました！　視聴して頂き、ありがとうございます。
予想以上の反響で驚くとともに、大変嬉しく思います。
動画内で頂いたコメントも、一通り読ませてもらいました。　多くのコメントを頂いた
おかげで、個々に返事を書けないのが嬉しい悲鳴です。


さて、肝心のOpenXOPS開発の方は、ちょくちょく細かいところに手を入れています。

最近やったところで一番分かりやすいのはグラフィックですかね。
透過テクスチャの処理を改良したりしていました。


（クリックで拡大）　マップは、マシンギョさんの「BASE」をお借りしました。

本家XOPSと同様に、透過テクスチャを利用したブロック面の向こう側（裏）にいる人
を正しく表示できるようにしました。
また描画順序の変更に伴い、透過テクスチャと非透過テクスチャの組み合わせも、
正しく出るようになりました。
　『やった！　これはうまくできたぞー』　と喜んでいたのですが・・・。


（クリックで拡大）　マップは同様。

　『うわぁぁぁ～～』
透過テクスチャ同時の組み合わせはダメで、ブロックが交差しようものには、向こう側
が表示されません。　手榴弾の爆風でも同じ不具合が出ます。

毎度のように、本家XOPSは綺麗に透過テクスチャが処理されていますね。
単純に後ろ・奥から描画処理を実施していけばいい　っと理屈は分かるのですが。
テクスチャ・ポリゴン単位で前後関係を求めて処理するのは簡単ですが、2枚目の
画像のようにポリゴンが交差してしまうと、対応しようがありません。
ピクセル単位でソートすれば万事解決ですが、ピクセルシェーダーを使わずに固定
パイプラインで処理できるのかどうか。
まさか、本家XOPSは 097ft からシェーダーを使っているのか？

さて、困ったぞ。どうするかなぁ。


開発とは直接関係ないですが、OpenXOPSの公式サイトをリニューアルしようかと
思い、ページ構成とかデザインとか色々考えています。


＜2014/11/25　追記＞
表示デモに使わせて頂いたマシンギョさんの「BASE」は、addonとして以下のサイト
で公開されています。
　マシンギョの航跡|Machinegyo's Track
　http://machinegyo.web.fc2.com/

11月になりました。後2ヶ月もすれば2014年が終わってしまうようで。


OpenXOPSの開発の方は、モーフィング処理を開発し実装しました。
足のモーション（アニメーション）を滑らかに表示するために使われる処理
です。
「百聞は一見にしかず」ってことで、アニメーションをご覧ください。
左が改良前で未使用、右が改良後で処理しています。


（アニメーションGIF・クリックで拡大）

一瞬ぱっと見ただけでは分かりませんが、足の動きに注目すると、モーフィ
ングが効いて滑らかに動いているのが分かると思います。
XOPS 0.96説明書の公開履歴にて、0.96の欄に『足の動きを少し滑らかに』
と書かれていますが、nine-two氏いわく本家XOPSでも、これと同様の処理
を実施しているそうです。

『うわぁ～地味だな・・』っと思った諸君！
ゲームのグラフィック処理の改善なんて、こんな作業の連続です。
地道な改良を重ねることで、ゲームのグラフィックの評価が変わっていくの
ですよ。　これも、nine-two氏の努力が垣間見える部分の一つです。

なぜこんな処理をしているのかと言えば、XOPS用の人型モデルデータを作っ
たことのある方ならばお気づきの通り、XOPSの動作原理に由来します。
XOPSの足のモーションは現代のゲームで一般的な、ボーン（骨格）を使用
したモーション再生を行っているわけではなく、モデルデータのXファイル
（.x）をパラパラマンガのようにコマ送りで描画しているに過ぎません。
歩きで4種類、走りで6種類のモデルデータを高速に切り替えています。
実際に表示を切り替えて描画する（画像・左）と、やはりカクカクしたぎこ
ちない描画になってしまうのです。
そこで、起動時のモデルデータを読み込む際に、各フレームごとのモデルデー
タに対してモーフィング処理を実施し、フレーム数を倍に増やすことで、滑
らかな足の動きが実現しています。

OpenXOPSにおけるモーフィング処理は、完全に独自で実装しています。
DirectX上で読み込んだモデルデータの頂点データが記憶された領域にアクセ
スし、各座標の中間データを単純な線形補間で求めています。
当初は、Xファイル自体をフォーマットを認識ながら読み込んで頂点データを
引き抜くことも覚悟していましたが、思っていた以上にうまくDirectX内部の
処理を直接利用できました。かなりスマートで良い感じです。
また、DirectXのモデルファイルに関する知識が、また一歩深くなりました。


これでモーション関係の処理は完成です。

OpenXOPSのサイト上で公開する技術ドキュメントの執筆作業も並行して行
っています。
既にA4用紙で10枚クラスの文章になっています。これからもっと増えます。
滅茶苦茶な日本語にならぬよう頑張ります。


なお、XOPSサーチエンジンの件でサーバー運営元からメールの返事が返って
きました。　ここ1年ほどの経緯・事情を説明した上で、運営側が非を認め
謝罪する内容でした。
今回はメールで個人的な回答・謝罪でしたが、近日中にサーバーの公式サイト
で全ユーザー（関係者）に対して、事情説明と謝罪をされるそうです。
さてさて、XOPSサーチエンジンはどうするかなぁー。