そろそろNexus7(2012)でもないだろうし、Intel Atom(x86)使用機種のような非ARM機が出てきたので、新たなAndroid端末として ASUS MeMO Pad7 ME572C を買ってきた。
今後はMIPS命令セット採用CPUなども含め、非ARMのAndroid端末も増えていくと思われるので、対応強化は進めておいた方が良いと思われる…のだけども。
試してみたところ ARM Emulation が非常に優秀でGLES2使用のゲームアプリ、特にndk使用が確実なタイトルやUnity製アプリなど確実にARMバイナリを含むタイトル*1がまともに動く。NVIDIA Tegra3のNexus7(2012)より軽快に動いてしまうものだから色々と複雑な気分だが、まあこの世界で2年の開きというのは大変に大きいので致し方ない。
そんな中、先日来自身で開発中のエンジンでGLES2周りの非互換部分(ただし回避可能)があったので、一応記録しておく。
問題点は、shaderのコンパイル後に行うステータスチェック。修正前は下記のようなコードだった。
GLint CGLShader::loadShader(GLenum type, const char * buf) { int shader = glCreateShader(type); GLint length; GLint compiled; glShaderSource(shader, 1, &buf, nullptr); glCompileShader(shader); glGetShaderiv(shader, GL_COMPILE_STATUS, &compiled); length = 0; glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &length); if (length > 1) { // エラー処理 : } : }
上記のコードでは、glGetShaderiv()を GL_COMPILE_STATUS で呼んだ時の compiled を参照せず、エラー時には GL_INFO_LOG_LENGTH で length > 1 になることを期待していた。Windows上のGoogle ANGLEやNexus7(2012)のTegra3向けGL実装などではエラーがない場合その期待どおりに動くため問題は出なかったが、ME572CのPowerVR G6430向けGLES2実装では compiled != GL_FALSE であっても length > 1 である場合があるようで、shaderのコンパイルに成功しているにも関わらずエラーが発生したことになってしまっていた。
これは下記のようにエラーの有無は compiled のみで判断し、lengthはエラー発生時のメッセージの長さ、という扱いにすべきだった。OpenGL ES 2.0仕様を読み込んだわけではないので推測だが、仕様上エラーが無いときlengthの値は不定、ということなのだろう。
GLint CGLShader::loadShader(GLenum type, const char * buf) { int shader = glCreateShader(type); GLint length; GLint compiled; glShaderSource(shader, 1, &buf, nullptr); glCompileShader(shader); glGetShaderiv(shader, GL_COMPILE_STATUS, &compiled); if (compiled == GL_FALSE) { length = 0; glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &length); if (length > 1) { // エラー処理 : } } : }
たしか似たような状況で動かない的な報告を他のアプリについてどこかで見かけた気もするので一応メモ。
*1:特に自分が開発に参加したタイトルについてはndk使用やUnity使用などの要件に間違いはないｗ
日本語版の Stack Overflow があるというので登録してみたですよ。
まあ、今のところ質問も回答もパラパラとある感じだけど盛り上がると良いね。
Objective-C関係の書籍ではiOSのものは溢れているがMacOS Xのアプリについて一定以上のレベルで言及しているものはあまり見かけない印象だけども、そのあたりもカバーしているということで買ってきた。
いやまあ、自前エンジンの開発用ツールをMac上でも実装したかったから、というのが理由。WindowsとかX11は既にある程度の経験があるので何とかなるのだけども「MacOS上のアプリ」となるとやったことがなかったので。
最近はSwiftの話題も多いけどもひとまずこちらを。Swiftは別途後日試してみる。C#ぐらい楽に書けて、かつC++との連携が良い感じであればツール開発言語として使うかもしれんけども、根っこは知っておいたほうが良いと思ったので。
3Dゲームをおもしろくする技術 実例から解き明かすゲームメカニクス・レベルデザイン・カメラのノウハウ
まあ、それなりのゲームタイトルには関わってきたけども、「ゲームのポリシーを踏まえた動きの付け方」について包括的に記した本というのもあんまりなかったかも知れない。パラパラとめくってみた感じでは良さげと感じたので購入。
こういう「創作に際する思考の働きを一定以上自動化する」試みは範囲の大小問わず昔からあって、「人が創作をする際の考え方」をフレームワーク化することはもちろん可能であろうと考えている。
つまりそれらの考え方はかなりの部分が訓練と学習によって身につけられるものである、ということになるのだけども、全面的な才能論の元で自身の鍛錬不足という事実から逃げたり、あるいはそれで優位に立っているという人にとって、その結論は色々と都合が悪いかも知れない。
で、こういう「既にその分野のノウハウを身につけた人によって生み出された、省力化のためのフレームワーク」というものはプログラミングの世界においてはかなりお馴染みだ。Web方面の Rails やゲーム方面の Unity3d などはその典型例。これらは各方面における「プログラムのあり方」を規定し、その中で異なる部分についてのみを記述させることにより、「そもそもその方面のプログラムのあり方さえよくわかっていない人」でもある程度なんとかなる仕組みであり、フレームワークとはすなわちそういうものだ。
「モノの作り方」がある程度決まっている世界はプログラムだけではなく、ほぼこの世の全ての創作分野がそう(というよりどこかに定型を持つからこそ「分野」となる)であるし、定型を持つということはフレームワーク化できる、ということなので、情報を扱う機械が進歩すれば当然こうした流れは出てくる。
こうした既存のフレームワークを用いて生み出されたものが無価値かと言えば決してそうではない。もしそれを無価値と言うならば、Railsを使って作られたWebSiteも、Unityを使って作られたゲームも等しく無価値、ということになってしまう。
ちょっと前には「王道のコード進行を使って作られた曲」を無価値と言い張る人たちもいたような気がするが、それと同レベルの論だ。「王道のコード進行」や「音楽理論」といったものはその分野の「ライブラリ」や「フレームワーク」にあたるもので、「標準Cライブラリを使用して書かれたプログラムは無価値」とか「OS上のアプリケーションとして書かれたプログラムは無価値」と言っているようなものだ。それらは絶対ではないが、それを用いることで無価値になったりするようなことはない。場合によっては定型に沿うことで価値を高めるものさえある。
ただ、おそらくどんな分野についても言えるのは、そうしたフレームワークが何をやっているのか、なぜそうするのか(あるいはなぜそれを使うのか)を理解し、必要とあればある程度同じものを自身で作れる(あるいは助けを借りずともある程度自身で同じことができる)人が省力化のためにそうした道具を使うのは全く問題無いのだけども、
「なんだかよくわからないけどもこれを使うとできるらしい」
「これ無しで自分でやれと言われたらどうして良いかわからない」
という人は、どこかで「これは何をやっているのだろう?」「なぜそうなる(そうする)のだろう?」という点に興味を持ち同じことを自分でもやってみよう、という試みに踏み出さない限り成長しないだろう、ということだ。「Unity臭いゲーム」とか「Rails臭いサイト」とかは、多分そうした人によって生み出されるのだろうと思っている。冒頭のプロット支援ツールなどもその分野で広く使われるようになれば同様だ。
自身で同じことをやってみる、というプロセスを経て道具に回帰したとき、初めて「道具に使われる」のではなく「道具を使いこなす」側に立てる。便利な道具が何をしているかも、なぜそうするのかの理由もわかっている人間は、道具があっても無くても優秀だ。
表題のAndroid Studio 1.0が正式リリースされた模様。
初期のAndroid開発環境が、EclipseとSDKを別途拾ってきて諸々設定して…と大変に煩雑だったことを思えば、これまで配布されてきたADTだけでも随分と便利になったものだとは思うが、少なくともβ版を触った人の記事を探した限りではわりと好評らしい"Android Studio"。
基本NDK使ってNative ActivityでC++のGLES2という人間なので、その辺のビルドに支障がなければ別にEclipseで構わん人間なのだけども、むしろ支障があるならば移行する理由が現時点では無い、ということになるので、果たしてどうなのか、というところで入れてみた。
とりあえずざっと調べた限りではndkもいけるらしいが、今日は眠いのでその辺の設定と実験は後日やる。
