ふにゃさん、これ以上開発する予定のなくなった1.xx系の作りかけの最新版をアップしました。
最新版といえども作りかけなので明らかにうまく動かない部分が多々あります。
ちなみに、WPFで作る予定の2.0.0は、比較的安定しているバージョンの最新版である1.13のソースコードをベースに作り直します。
TGWSAdminのRSS-Twitter連携機能が、RSSを更新するタイミングによってうまく動かないことがあったのを修正しました。
簡単に言うと、最新のRSSを以前ツイートしたものと同じかより古いと誤認識してしまうのが原因でした。
TGWSAdminもWindows7的にしていきたいですね。
svg2xaml、閉じたパスならきれいに変換してくれるのですが、開いたパスだと端点を直線で結んでしまうバグがあるようです。
逆に言うとそれ以外は割りと良好なので、そこさえ自力で直せれば実際に組み込むこともできそうではあるのですが。
あと、先月26日に言っていた「Linux系の何か」として、Ubuntuを入れてみることにしました。
別にWindowsから乗り換えるわけではなくテスト環境として欲しいだけなのでインストールしやすそうなWubiを使ってみることにしました。
ええ、OSはパソコンの基本ソフトなのでカテゴリはPCソフトですよ。
WPF/Silverlightでのベクターグラフィックについて調べています。
日本語のサイトだとWPFを使えば線を引けます丸を書けます線を引けます四角を書けますばっかりで役に立たないことこの上ないのですが、海外のサイトに目を向けるとわりといい情報が見つかったりします。
探していたらsvg2xamlなんてものが見つかったのでまずは試してみようと思います。
WPFはベクターグラフィックを扱うのも得意だとか、ハードウェアアクセラレーションで高速に描画できるとか、そういったことを聞いたので、WindowsFormsではなくWOFで開発するというのもありかと思いました。
WPFで開発していると、ブラウザ上で動くというSilverlightにもほとんどコードの修正なしで移行できるという話ですし、充分なパフォーマンスが得られるのであればかなり良い選択かもしれません。
ふにゃさんのグラフィックについて。
いつまでも320x240の画面サイズでもないだろうということで、ウインドウサイズに合わせてゲーム画面を大きく描画するというのを考えました。
しかし、320x240の画面をそのまま拡大しては画像が荒くなってしまいます。
そこで考えたのが2つの方法。
1つは、SVGなどのベクターグラフィックを利用する方法。
これならば解像度を気にせず画面サイズに合わせて自由にきれいに拡大縮小できます。
単純なふにゃの造形とも相性抜群です。
しかし、SVGを読み込み表示するノウハウを私はまったく持っていませんし、それらしきライブラリの導入に成功したこともありません。
つまり、かなり難しそう、ということです。
もう1つは、あらかじめ大き目のビットマップを用意しておいて、実行時に縮小するという方法。
縮小アルゴリズムにもよりますが、小さい画像を拡大するよりはきれいに表示できますし、実装も比較的簡単です。
問題は、ファイルサイズおよびメモリ使用量が大きさに比例して増大するということ。
まあ、最近のパソコンなら大きな画像でもまったく平気かもしれませんが。
結論から言うと、ダメでした。
NeoMuplを32bitでコンパイルしなおしても、DirectMusicは使えませんでした。
やっぱりDirectMusicそのものがなくなっているようですね。
FNチェンジャーを.NETで書き直してみました。
VB6は新しい環境にインストールしていないし、ランタイムも将来ない環境が増えていくんだろうなと思ったもので。
あと、TableLayoutPanelを使って、ウィンドウサイズに入力フォームの大きさを追随させるようにしました。
それからエラー処理とかログ表示なども。
もしかしたらNeoMuplは32bitでリビルドしたらDirectMusicも使えるようになるんじゃないかと思い、早速プロジェクトを開いていろいろしてみたのですが、どうにもこうにもあれやこれやとトラブルが多く…。
それはそうと、今度のアンパンマンの映画に出てくるココリンを描いてみました。
実際のココリンはもっとにこやかな顔です。
