投稿日: 2025/09/15 15:46:35
カテゴリ: クリエイティブコーディング
サムネイル: なし
最近Ebitengineというものに興味が出てきて、熱心に調べたりアドオンを書いたりしているのだけれど、自分がProcessing Rebornと勝手に呼んでいる最近の活動について、思考整理のために経緯を最初からまとめたいと思う。
忙しい人は #Ebitengine まで飛ばしていただければ。
昨年末、上のような記事を書いた。このときは、OpenFrameworksをMetal/DX12/Vulkan化しようと意気込んで挑戦していたのだけれど、結局、OpenFrameworksの構造がOpenGLに特化しすぎていることと、多くのアドオンがOpenGL依存していることから、一旦諦める形となった。
ただその後も調査自体は続けて、OpenFrameworksのMetal/DX12/Vulkan代替としては、下記記事にあるようにRavEngineとRGLというものを見つけて、これで一旦目的自体は達成されたと考えて、調査はそこで終えていたが、OpenFrameworksからの飛躍が大きかったのと、コンパイル時間の長さから、個人的にはあまり使うことはなかった。
また、時期は少し後になるものの、sinenとparanoixaという同様のフレームワークにも若干コミットし、クロスプラットフォーム化の手助けをしたりもした。
ではProcessing自体を進化させるのはどうかとその後考え、OpenFrameworks同様に調査をした結果、LWJGLを使えば良いと目をつけて、それを既にClojureというJVM（Java仮想マシン）上の言語で実装されているminimaxを、きちんとクロスプラットフォームで動くように整備した。
ただminimaxはProcessingライクではなくゲームエンジンなので、ちょっと用途は違うのだけれど、その後JVMのメモリやポインタの扱いの大変さに疲れたので、個人的にJVMを追うことは今はやっていない。
その他、Sokolを使った各種フレームワークについても調査する過程で、Delve FrameworkというZig言語のフレームワークにコミットしたりもした。
そこから日が経ち、ふとV言語を再ウォッチしたところ、ggというSokolベースのフレームワークができていたことから、それで遊んだりもした。
さて、こうしてクリエイティブコーディング環境自体はいろいろ整備を進めたものの、どれも実際使うには至っていなかった。
コードを書くもの以外にも、TiXL なども時々触ってはいたものの、本腰を入れて使うにはまだ至っていない。
なぜだろうかと考えたときに、要因がいくつかあった。
特に惜しかったのはV言語で、V言語の場合はggのおかげで描画もサクッとできてクロスプラットフォームで動いていたことから、各種アドオンなどを移行してみようと努力したものの、移植過程特有のハードルの高さに阻まれて事実上頓挫した。
ただV言語の場合は本当に惜しいので、また折を見て再挑戦しようとは思っているけれど、V言語自体やTCC (Tiny C Compiler) の問題もいろいろあるので、V言語がアーリーステージである間は安心しては使えないかもしれない。
それにV言語はトランスパイラゆえにCやMake、CMakeの知識が必須となるので、Nim同様、あまり人には気軽には勧められない。
そんななか出会ったのがEbitengineだった。
Ebitengine自体は前から知っていたのだけれど、使ってみようという気になったのはV言語の影響が大きかった。
V言語自体が最近GCを採用したことと、記法がGoにすごくよく似ていることから、V言語移植に頓挫して疲れているときに、ふとGo言語が目に入った。そしてEbitengineがとてもよくできていることに気づいた。
Ebitengineは、当初はOpenGLだけだったようなのだけれど、最近はMetalやDirectXにも対応し、wasm出力によってウェブでも動く。この時点で自分が最初に思っていた目的は達成されているし、Unityなどと同じくiOSやNintendo Switch、Xboxなどもサポートしているのはオープンソースとしてはすごいことだと思う。
そしてGo言語は現時点で十分に枯れていて、Pure Goによる実装が数々と進んでおり、ImGuiにあたるものであったり、ZeroMQであったり、ほしいものはほとんどPure Go実装が存在するというありがたい状況になっている。
ちなみにEbitengineは一見2D専用だけれど、LÖVE同様に3D実装はいくつかあって、代表的なのがTetra3D。
でも後述のように3DをやりたければGodotなどもあるし、実際Ebitengineで3Dまでやるかはわからない。
少なくとも、EbitengineはGodotのように普通に使えるなぁというのが第一印象で、かつGodotと同じく簡単で、他の人にも進めやすいし、導入も簡単なのはありがたい。
ここで触れておかなければならないのがBevyかなと思う。
Bevyは非常に完成度が高くて、アドオン移植などもいろいろ済ませていて、本腰を入れて使える状態には既にあるし、今もウォッチを続けている。
ただ、Rust言語の難易度の高さから、書いていて疲れるというのが正直なところ。C++もぶっちゃけそうなのだけれど、C++はテンプレートさえ目をつぶれば（C++17〜23なら）一応は普通に書けるのに比べて、Rustは場合は所有権への配慮など、場合によってはかなり疲れる。
Rustは動作速度もメモリ使用量も申し分なく、Bevyはレンダリングクオリティも高いので、いろんなところで使っていけるはずなのだけれど、実は自分はその分野ではGodotを使っているのが正直なところ。
まあでも今後も描画クオリティやパフォーマンスが重要なところでは、Bevyを使っていく可能性は十分にあるし、今後もずっとウォッチしていくと思う。
さて、若干とりとめのない記事になってしまったけれど、OpenFrameworksでできていてEbitengineではできないと思うものに関しては、GitHub Copilotの支援もあってほとんど移植は完了した。
OpenFrameworks自体も枯れていていろんな用途に使えて楽しいのだけれど、まあ正直C++と向き合うのが疲れることもRust同様にあって、そういうときにEbitengineやGodotで遊んでSAN値を回復させていければと思う。
Ebitengineは、シンプルさが売りなのだけれど、圧縮テクスチャがまだ使えないなど、成長の余地はいろいろあるので、様子をみつついろいろ試していきたい。
ちなみに余談として、PythonでもProcessingっぽくできるものがいくつかあって、p5が一番近いのだけれどライセンスがLGPLではなくGPLなので、正直使いづらいところ。
Rustのnannouを呼び出す形で実装されている、q5というものがあって、Pythonでやるならこれがいいかもしれない。
https://blog.eqseqs.work/2022/12/16/234043/blog.eqseqs.work
numbaとかで高速化したりできるかわからないけれど、Pythonらしい機械学習とかを組み合わせたものについては良いかもしれない。