TokioGL最終版
出しました。これで最終版です。
バージョンを正しく返さないバグを修正したのと、サンプルの増強。
それと、ふにゃさんのウナギカズラをニコニ・コモンズ素材として提供開始しました。
果てしなく需要がなさそうですが、二次創作を自由に行っていただけます。
出しました。これで最終版です。
バージョンを正しく返さないバグを修正したのと、サンプルの増強。
それと、ふにゃさんのウナギカズラをニコニ・コモンズ素材として提供開始しました。
果てしなく需要がなさそうですが、二次創作を自由に行っていただけます。
すんごく久しぶりにTokioGLの話。
はっきり言ってもう機能追加するつもりはありません。
ただ、微妙なバグがあるのと、本家StretchBltとの比較も入れたいので、一応バージョン0.03は出すつもりです。
というか、明日出す。
ふにゃさんの全体像画面、出来上がりました。
画面をはみ出すほど大きいステージだと縮小表示されるのですが、その縮小結果が最初やたらと黒々としたものになっていたので、どうなってるのかと思い、調べてみたら、SetStretchBltModeで縮小方法が変更できて、これの初期値が黒優先となっていたために暗い色ばかりになってしまっていたようでした。
それなりの画質で高速なものとか、高画質で低速なものなどがありましたが、通常チップは最初にマップチップそのものを高画質のStretchBltで縮小し、その結果をBitBltでどんどん使っていくという方式で速度を確保し、キャラチップのほうはその都度それなり画質のStretchBltで表示するようにしました。
なお、全体像では背景色は手抜きのため黒となっておりますのであしからず。
でっかいステージも9割方できてきました。
ところで、この高画質StretchBlt、実はTokioGLと縮小結果がほぼ同じなんですよね。
それでいてこのスピード、素人が練習で作った描画アルゴリズムとは根本的に違うのか、あるいはハードウェアで対応しているんでしょうかね。
NeoMuplは、プレイヤークラスをDirectShow、DirectMusic、普通は使わない無音の3タイプを作って、それらを一箇所で扱えるようにしていました。
DirectMusicは今のところ実装していないんですけどね。
あと、項目のプロパティの画面を作ったりしてました。
一応編集機能が、今実装できるものに関しては全部作り終わって、後はその変更結果を実際のデータに反映するところに来ています。
レポートやってますぞお!
明日提出だあ!
グラフだけで20枚近くある!!
あぁ、そういえばTGLでGetVersionのバージョン増やすの忘れてた。
次の更新で直しとこ。
で、心配をよそにいざ実行してみるとそれなりに良い結果に。
問題があったのは変数名を間違えてめちゃくちゃな結果になったりしたところくらい。
10倍以上も速くなってうはうは。
SetRectをRECTに直接代入に変えたてもかなりの効果があった模様。
でもやっぱDIBは速いね。桁違いに速いね。うん。
DDBからDIBを得る部分作成。
RGBQUADとCOLORREFって直接的な互換性はないのね。
まあデータ内容は全く同じだから型キャストだけでなんとかなるけど。
後不安なのはデータがどの方向に進んでいるかだな。
えっとですね。ふにゃさんのエディタ作るつもりでした。
しかし、今回、3層マップもありうるということで、半透明もありうるというわけで、半透明対応描画DLLを作ってやろうということになったわけです。
しかし、描画系のDLLといったら、あのとてつもなく遅いことで有名ではない、TokioGLただひとつのみ。
せめてこれがまともな速度で動かないことには半透明DLLなんて夢のまた夢でしょう。
そんなわけで、TokioGL、改良を始めました!
「TokioGL」の関数tglCreateMaskを作り始めました。
透過色が白(色成分が全て255)の画像からマスクを生成します。
透過色でない白を使いたい場合は色成分のどれかが255でない色を使います。
でも効率のいいアルゴリズムが思いつかない……
ま、できるまでゆっくり待ってもらうことにしましょう。
TokioGLのテストが済んだので公開です。
2回の">>18"を最後の">>16"にまとめてしまうことで高速化と精度を上げることができました。
tglStretchBltを作るにあたって「VisualBasic初心者連盟」の「きれいに縮小」を参考にさせて頂きました。
サンプルに使ったアイコンは「パネルα」のパネルに流用しました。
「パネルα」は兎に角パネルが不足しているんですよ。
126種類揃うには揃っているのですが、やたら紛らわしいf君がたくさんいるんですよ。
色違いを作ることによってある程度は減らすことができましたが。
TokioGLのtglStretchBlt関数で転送先の大きさが転送もとの大きさの整数倍のときには普通のStretchBltを使うようにして高速化を図りました(tglStretchBltは恐ろしく遅いです)。
これで一応tglStretchBltに関しては公開しても良い頃になりましたので、近いうちに公開します。
その前にテストをもっと行わねば……
「ニンテンドウオールスター!大乱闘スマッシュブラザーズ」に登場するピカチュウには雌雄どちらもいることがわかりました。
それがわかった時はこういう状況でした。
可能な限り弱くしたピカチュウ3匹とサムス一人が戦いました。嗚呼、今操作しているピカチュウは雌だったんだ……
私の使っているピカチュウがビームソードを手に入れました。
しかし剣の振り方がどうも不自然なのです。
ポーズ画面で拡大してよく見てみると、ピカチュウは剣を口に咥えたまま振っていることがわかりました。
「これは面白いことを発見した!」
そう思った私は愚かにもさらに色々な姿を見てみたいと思い、何かをする度にポーズをかけていたのです。
ピカチュウをしゃがませていると、他のピカチュウが近づいてきていましたが、さして気にも留めずにポーズしたのです。
するとポーズ画面には2匹のピカチュウが……(略)!
それはともかく、TokioGLの関数のひとつ、tglStretchBltが出来上がりました。
昨日書いていた問題は、S/DとすべきところをD/Sにしたために起こっていることがわかりました。
きれいな回転コピーをするtglRotateBltは無理そうです。
色を計算するアルゴリズムが相当複雑になりそうなので。
きれいな拡大縮小コピーをサポートするDLL、TokioGLを作っていたんですが、どうもうまくいきません。
引数の引渡しがうまくいっていないようですし、拡大縮小しようとすると止まりますし、さらにはBitBltさえも失敗している模様です。
・・・・と思いきやVBの方でByValを忘れていただけでした。
しょーもないミスすんな~。
どうやら日記を書いていることは意外な効果があるようです。
どちらにしても問題はまだ解決していませんが……