mieki256's diary

「たしか、今の Processing は Java Applet 書き出しをサポートしてなかったはず…だけど、ホントにそうだったかな？」と不安になって。

関連情報をググっていたら、Processing 2.1 が公開されてることに気がついて。手持ちのソレは 2.0.1 だったので、せっかくだからアップデート。そういや今気がついたけど、2.0.3も出てたのね…。

ちなみに、Java Applet の書き出しが無くなって、JavaScript の書き出しになってたのは、正解だった模様。

Windows7 x64 環境だけど、processing-2.1-windows32.zip (32bit版) をDLしてきた。解凍して、processing.exe を実行するだけで動いてくれた。相変わらず導入は実に簡単。

◎ サンプル群が減っていた。 :

エディタ内の、日本語文字列の表示がおかしい…。
環境は Windows7 x64 + Processing 2.1 x86版。使用フォントは _Ricty 。MSゴシックも選んでみたけどやっぱり表示がおかしくなる。

たぶんコレ、2バイト文字の、文字幅計算がおかしい予感。2.1からは設定ダイアログで、好みのフォントを選択できるようになったのはありがたいけど、エンバグもしちゃったのかな？

気になって Processing 2.0.1上で確認してみた。こっちは正常。 Processing 2.0.3 でも試してみたけど、2.0.1と結果は同じで、正常だった。

_Using Processing - Processing 2.0 Forum を眺めてみたけど、報告は上がってないような…。まあ、英語圏では、こういうバグに気付くはずないけど…。

_chinese text is overlapped in Processing 2.1 editor - Issue #2173 - processing/processing - GitHub で、中国の方が報告してくれていた。ただ、どうも話が通じてない雰囲気…。「2.1で中国語に対応させるために大修整をした」と言ってるので、やはり2.1でエンバグしちゃったのだろうけど。英語圏側は、フォント表示の問題と、IME動作の問題を一緒くたにして扱ってるみたいだから、今現在は何が問題なのか理解できてないのでは、という不安も。

外部エディタを使うことが前提のツールなら、このあたり問題にはならないのだろうけど、やはりエディタ込みで即座に動かせるところに重きを置いているのかしら。であれば、バグ修正してもらえないと困るな…。

Processing には、たしか外部エディタを使用するオプションもあったはず。しかし、確認しても見つからず。おかしいな。偽記憶かな。いやいや、そんなはずは…。

関連情報をググってみたら、1.5.x の頃は外部エディタの利用も視野に入れてたけど、2.0以降は外部エディタを利用することが難しくなったらしい。以下のページで現状が解説されてた。

_Processing を好きなエディタでコーディングしてコマンドラインから実行する - 雑念日記

その代わり、コマンドラインで実行できるようになったらしいけど。しかし、Javaモード限定…。JavaScript は…。

待てよ？ どうせ JavaScript を使うなら、最初から processing.js を使ってしまえばいいのでは？ なるほど。だから Javaモードしか対応してないのか。

であればと、processing.js について少し調べてみたけれど。どうやらパフォーマンスが圧倒的に低いライブラリのようで。もちろん、少ない記述量で色々なことができる点が売りのライブラリだから、これもまた、トレードオフなのだろうなと。

Processing のソレを見て、「JavaScript はライブラリの管理・導入が面倒なのでは」という疑念が湧いたのだけど。本当にそうなのかなと。Perl のCPAN、Ruby の Rubygems のような仕組みが、本当にまだ存在してないのだろうか…？

やっぱり、既にあるらしい。Bower なるものがソレっぽい。

_「Flight試してみたい！」でWindowsにBowerをインストールする ｜ Developers.IO
_Bower入門(基礎編) - from scratch

_Bower components を覗いてみたら、現時点では 6428個ほど登録されてるようで。試しに「three」と打ち込んだら、 _three.js もリストアップされた。素晴らしい。

すると、ライブラリを入手する術は、既にちゃんと用意されてるということなのかな…。では、どうして Processing は、そういうライブラリをガシガシ同梱等して、Javaモード時並みに JavaScriptモードを強化しないのだろう…。

単に、どんなライブラリがあるか把握できてないのかな。あるいは、各ライブラリに対応するのが大変過ぎるとか。そんな感じなのかなあ…。

とりあえず、JavaScript にもそういう仕組みがあると知り、勉強になりました。

◎ WebGLスゴイ。 :

今日もDXRubyを使って何か書きますよ。と言っても、ゲーム制作をしてる人なら誰でも知ってそうな話ですけど…。

例えば、シューティングゲームやアクションゲームを作る時、敵の爆発時に画面をビカッと光らせたいな、一瞬だけ真っ白にしたいな、と思う時がありまして。要するに、画面をフラッシュさせたい時があるわけですよ。

昔のTVゲーム機だったら、画面の色は、全てパレットで管理されてたので、パレット内容を書き換えれば画面を真っ白にすることができました。1パレット16色で、1色2バイト使ってるなら ―― たった32バイトを書き換えるだけで、そのパレットを使って表示してる全てが真っ白になったわけです。 *1

でも、今のゲーム機って、パレットで色を管理〜なんてケチ臭いことしてないし。ちょっと書き換えれば全部の色が変わる、なんて仕組みじゃない。

じゃあ、どうするのかというと…。

かなり安直な方法ですが、画面全体に、真っ白な画像や、真っ黒な画像を、べた書きしちゃえばええやん、みたいな。どうせ今時のハードウェアは、強力なハードウェア描画機能を持ってますから、そのくらいなら描画処理時間もさほど影響ないやろと。

てなわけで、一応自分もサンプルを書いてみました。

# 画面を白く、あるいは黒く(?)、フラッシュさせる。(安直版)

require 'dxruby'

Window.resize(320, 240)

bgimg = Image.load("bg.jpg")
whiteimg = Image.new(Window.width, Window.height, C_WHITE)
blackimg = Image.new(Window.width, Window.height, C_BLACK)

white_alpha = 0
black_alpha = 0

Window.loop do
  break if Input.keyPush?(K_ESCAPE)
  Window.draw(0, 0, bgimg)
  
  if Input.mousePush?(M_LBUTTON)
    # マウス左ボタンがクリックされた
    white_alpha = 255
  end

  if Input.mousePush?(M_RBUTTON)
    # マウス右ボタンがクリックされた
    black_alpha = 255
  end

  if white_alpha > 0
    # 画面全体に、真っ白な画像を、透明度を変えながら描画する
    Window.drawAlpha(0, 0, whiteimg, white_alpha)
    white_alpha -= 5
  end

  if black_alpha > 0
    # 画面全体に、真っ黒な画像を、透明度を変えながら描画する
    Window.drawAlpha(0, 0, blackimg, black_alpha)
    black_alpha -= 5
  end
end

実に安直ですが、それらしく見えてるし、コレで済んじゃう場合もあるんじゃないかなと。どんな方法でも、60FPSが維持できていれば、それでOKじゃないかしらん。

しかし。この方法では、例えば敵に自機の弾が当たった時に、敵だけフラッシュさせるとかできないわけですよ。

じゃあ、どうするかというと。

スイマセン。思いつきません…。明日までに考えておきます…。というか、DXRubyのシューティングゲームサンプルで、そういう処理してましたよね…？

それはそれとして。この、安直な画面フラッシュ。他のライブラリでもフツーに使えるやり方なので、こうして書いてしまいましたが。DXRuby の場合は HLSL という機能があるわけで。DXRuby のサンプルにも、sample_flash.rb という、そのものズバリがありますし。そっちを勉強しといたほうが応用効くんじゃないのかな、と思えていたりもするのでした。

◎ フラッシュのさせ方。 :

---