「funyak」に関する日記(9)

JSONによる画像情報の読み込み。
C#でもJavaScriptでも、ついでにPHPとかいろんな言語でも簡単に使えて、人間でも簡単に書けて、構造化も簡単な形式ということで、JSONにしました。
独自形式はもう面倒くさいですからね。
ステージデータとかはサイズが大きくなりそうなんで独自形式が必要になるかもしれませんが、簡単な情報はもうだいたいJSONで済ませちゃおうと思います。
最悪、別の形式を最終的に採用することになったって、コンバートもまた簡単です。

HTML5+JavaScript版をちょっと作ってます。
DuoCodeのおかげで、コア部分に関しては全く手直しなしで出来上がります。
表示に関しては完全にプラットフォーム依存なので1から書き直しですが。

浮遊の基本動作を実装。
ふにゃさんが40FPSだったのに対してfunyakは60FPSを前提にしているので、フレームごとのアクションの大きさはほぼ3分の2にしています。
角度の単位がyaneSDKと違っていた(一周512→360)ので、そのあたりの換算もしています。
あとは、浮遊状態と通常状態を別クラスに分けず、一つのクラスにまとめることにしました。
動きは全く異なるものの、基本的な要素は同じですからね。

funyak。
funyakはライブラリっぽい使い方をするので、ドキュメントコメントとか入れまくって、使いやすいように修正していました。
あと、いらなくなったプロジェクトを整理したり、主人公の動きをぼちぼち作り始めたり。

mifumitter。
ハッシュタグの扱いがおかしくなっていたので修正しました。

逆転裁判6。
第1話クリアしました。
4のあたりからそうだったんですが、第1話から結構長丁場ですね。

funyak。
DuoCodeによるJavaScriptへのコンパイルを試していました。
JavaScriptにコンパイルできるのはコードだけなので、普通にC#としても使えてJavaScriptにもコンパイルできるよう、コア部分のコードを共有プロジェクトに移しました。
共有プロジェクトにすることで、C#としてコンパイルしたDLLではなく、コードそのものを共通化できるのです。
コードファイルのリンクと違って、コードが増えても自動的に共有されるというのもうれしいところです。

逆転裁判6。
買いました。
とりあえずゲーム記にも反映させておきました。

主人公の表示などを作成。
その関連で、リソース管理やら座標の計算方法なども見直しました。

JavaScript版の開発の助けになるようなフレームワーク調査中。
phina.jsがかわいい(そういう問題ではない)。

画像リソース管理作成中。
正直、どうするか決まり切っていないので、あれこれ試しながら仕様を決めていくつもりです。

昨日言っていた画像の扱いのうち、共通となる(はずの)切り抜き情報を実装していました。
元画像のどの範囲から切り抜くか、表示先にどの大きさで表示するか、表示の基準点はどこになるか、そのあたりのデータを持つようにしています。
実際に使うときは、インデックス番号か名前でこの情報か描画データを取得して、表示するという形になります。

画像の取り扱いについて検討中。

キャラクター画像とかはシンプルに1キャラクター1画像でいいんだけど、ステージ画像とかは、ユーザーの選んだ画像がドカドカ入り込んでくる。
普通の画像としてBMP、PNG、JPG、GIFは当然対応するとして、個人的にはSVGにも対応したい。
アニメーションGIFを取り込んだならアニメーションすることを期待するのが当然だから、できることならこれも対応したい。

複数の画像を仮想的に一つの画像のように扱うというのも考えたけど、そんなの付けたところで、ユーザーはついてこないし、開発者はそれを避けることができる。
何より、仮想的なリソースと物理的なリソースの管理を別々に行う必要が出てくるなど、仕組みの開発が大変になるので、実装する価値をあまり感じない。

画像は全体をひとまとまりとして使うわけではなく、一部を切り抜いて使う。
従来はこの切り抜き方を全部ハードコーディングしていたけど、この部分もデータとして外部に出したい。

一つの画像データと一つの切り抜き定義データ(このデータの中には個々の切り抜き情報が複数入る)を一組として取り扱うのがいいか。

画像や音などのリソースに関して。
できることならば、プログラム側からはリソースの具体的なファイル形式やサイズなどを意識せずに使えるようにしたい。
そもそもコア部分はリソースを全く扱わないので関係ないのだが、各プラットフォームに向けたフロントエンド開発には結局具体的なリソースが必要になってくる。
であれば、プログラム側が要求するリソースと、具体的なリソースのデータを紐付ける定義データがあればよい。

ということで、funyakのリソース管理は、リソースデータそのものの管理だけでなく、定義データによる紐付けも行う形でやっていこうと思います。

線を表示できるようになりました。
スクロールと拡大縮小対応で。

スクロールの方は歴代のふにゃシリーズでもやっていましたが、拡大縮小の方は今回が初です。
厳密に言えば、ふにゃさんのステージエディタでは全体像を適宜縮小表示していましたが、今回のは実際のゲーム画面にも適用可能な形で(仕様上は)自在に拡大も縮小もできるようになります。

ただ、拡大縮小もいいことばかりではないんですよね。
拡大すればドット絵が荒く見えるし、縮小すればドット絵がつぶれて見えます。
ベクターグラフィックで描画するというのが一つのアイディアとしてあるので、何らかの形で試してみたいと思っています。

キー入力とか作成。

WebGLのほうも。
https://tgws.plus/akiyame/unity/webgl/
うまく動いてないですね。
プラグイン不要でブラウザで手軽に、というのはまだできなさそう。
funyakでやりたいこととUnityでできることも今一かみ合っていなかったし、funyakはUnityなしで作る方向性にしようかな。

久々に触ってみました。
funyakのこともあるのでちょっと2Dのほうを。
使ってもいいかもしれないけど、便利かどうかはわからない感じ。
ビルド時間長い。
とりあえず、昔作った3Dのやつをアップしておきました。
https://tgws.plus/akiyame/unity/test/test.html

SharpDX検討中。
…だったのですが、スマホで初期化に失敗しました。
SharpDXはUWP(Windows10限定)とWFP(7あたりでも使える)の両方に適用できそうだったのでいいかと思っていたのですが、案外うまくいかないものですね。
まあ、DuoCodeを使ったブラウザ版だとそもそもDirectXからして使えないので描画周りの使いまわしはそもそも完全にはできない前提だったのですが。

画面写真の残し方とか実験中。

UWPのドラッグ＆ドロップの仕組みとか実験中。

描画のパフォーマンス計測中。
UWPでメイン機とサブ機とスマホで。
比較的安定しているのがXAMLのRectangleを置いていく方法で、Win2Dはわりかし環境でぶれる感じ。

ちなみに、funyakはfunyakです。
「ふにゃけい」と読みます。

描画のパフォーマンス計測中。
Windows FormsのGDI+はちょっと使えない感じ。
UWPはWin2Dのおかげでまあまあいい感じ。
WPFは愚直にRectangle置きまくっているけど速度だけでいうと悪くないかも。
とりあえず、WPF版の速度計測プログラムを置いておきます。
等倍表示板
縮小表示版(表示画像数4倍)
拡大表示版(表示画像数4分の1)
白いのをくるくる回しながら描画速度を測定するプログラムです。
左上の数値を教えてくれると嬉しいです。