FPSを作ってみる@wiki
02)
最終更新:
slice
-
view
(2013/02/28)
勉強した事
- pthreadの続き。条件付きmutexやTLSなど(C++11のthreadも同じ様な案配だった)
- androidにおけるイベントハンドリングの仕組み(Looper, Handler関連)
- C++でのOpenGL初期化と簡単な描画
取り組んでいる事
- android_native_app_glueの読解
- NativeActivityのC++コードのgdbを使ったデバッグ
OpenGLについてはとりあえずNativeActivityでOpenGL初期化できました & ポリゴン一枚描画して見ましたレベル。
スクショ撮っても仕方ないので割愛。
NativeActivityを利用してプログラムを書くには付属のヘルパークラスandroid_native_app_glueを使う方法とnative_activity.hをインクルードして自前で制御する2通りがあるようだが
android_native_app_glueのソースを覗いてみたら行数がそれ程でもなかったし使うにしても中で何が行われているか気になったので読んでみている。
eclipseで普通にc++のコードをGUIでデバッグ出来るのかと思ったら、どうやらそうでもない様で・・発展途上?なのか
ググッて調べると手順が色々ある模様。要するに面倒くさそう。
スクショ撮っても仕方ないので割愛。
NativeActivityを利用してプログラムを書くには付属のヘルパークラスandroid_native_app_glueを使う方法とnative_activity.hをインクルードして自前で制御する2通りがあるようだが
android_native_app_glueのソースを覗いてみたら行数がそれ程でもなかったし使うにしても中で何が行われているか気になったので読んでみている。
eclipseで普通にc++のコードをGUIでデバッグ出来るのかと思ったら、どうやらそうでもない様で・・発展途上?なのか
ググッて調べると手順が色々ある模様。要するに面倒くさそう。
まぁ、こんなとこか。
to be continued...
to be continued...
(2013/02/26)
折角なので
乗りかかった船だし何とやら。という事で2月いっぱいはAndroid関連。
但しJavaはエミュレーターで見てるとGCが動くだけで5〜8ms程度持ってかれていて速度的に微妙だと思い、従ってC++で書きたい。
AndroidのプログラムをC++で書くにはJNIというJavaとC++の橋渡しをする仕組みを利用するかフルC/C++でアプリを書くNativeActivityか、という2種類があるようだ。
JNIは昔のバージョンで動くようだけどJavaと行ったり来たりするのが面倒そうなので今回はパス。NativeActivityに挑戦する。
そうなるとAndroid2.3以降でしか動かない事になるが、まぁどっちみち3Dをやるなら昔の端末じゃ遅いだろうし問題ないだろう。
2.3以降ならサウンドにOpenSLという遅延の少ないライブラリも使えるっぽい。
但しJavaはエミュレーターで見てるとGCが動くだけで5〜8ms程度持ってかれていて速度的に微妙だと思い、従ってC++で書きたい。
AndroidのプログラムをC++で書くにはJNIというJavaとC++の橋渡しをする仕組みを利用するかフルC/C++でアプリを書くNativeActivityか、という2種類があるようだ。
JNIは昔のバージョンで動くようだけどJavaと行ったり来たりするのが面倒そうなので今回はパス。NativeActivityに挑戦する。
そうなるとAndroid2.3以降でしか動かない事になるが、まぁどっちみち3Dをやるなら昔の端末じゃ遅いだろうし問題ないだろう。
2.3以降ならサウンドにOpenSLという遅延の少ないライブラリも使えるっぽい。
JavaやJNIで書く時はOpenGLで描画するのにGLSurfaceViewという便利なヘルパークラスが使えたが
あいつはフレームスキップを実現したい時はどうすればいいのかイマイチわからんし
第一Nativeではそんな物なさげなのでまずはOpenGL初期化方法から勉強している・・
あいつはフレームスキップを実現したい時はどうすればいいのかイマイチわからんし
第一Nativeではそんな物なさげなのでまずはOpenGL初期化方法から勉強している・・
勉強した事
- OpenGL ESの初期化
- pthreadと、C++11におけるthreadの使い方
(2013/02/25)
正直、ないと思う
タスクシステムを作り終えて動作完了。試しに紐シミュレータをば。
入り用で、Androidにて。
シミュレーションにはVelocity Verlet法を使用。
ボタンでゴム紐とただの紐を切り替えたりとか。
シミュレーションにはVelocity Verlet法を使用。
ボタンでゴム紐とただの紐を切り替えたりとか。
もちろんJavaで。エミュなので10fpsしか出ない
しかも、お流れ(実質)になった >えええええ!?
深くは語るまいが。
ま、ともかくAndroidで動くタスクシステムと諸所のAndroid&Java知識を手に入れた訳で。
気が向いたら何か作るかもね・・OpenGLの勉強も少し進めた事だし。
深くは語るまいが。
ま、ともかくAndroidで動くタスクシステムと諸所のAndroid&Java知識を手に入れた訳で。
気が向いたら何か作るかもね・・OpenGLの勉強も少し進めた事だし。
あ、あとPCの方のゲームもDirectX11は見送ってOpenGLの線が濃厚。やはりiPhone, Android, WebGLにも使えるというのが強い。
とりあえずJavaで実装したタスクシステムをC++に移植しますかね・・
とりあえずJavaで実装したタスクシステムをC++に移植しますかね・・
(2013/02/13)
アップデート機構やコリジョン通知
本格的にゲームに取り組むにあたって場面遷移機構を考えていた。
あれ、前に考えなかったっけ?と思い過去の記事を検索してみたがヒットしなかったのでやっぱり今までマトモにゲーム作れてなかったんだろう。
あれ、前に考えなかったっけ?と思い過去の記事を検索してみたがヒットしなかったのでやっぱり今までマトモにゲーム作れてなかったんだろう。
場面遷移とは大層な響きだが
例えばリバーシとかのちょっとしたゲームだったら現在のステートを数値で管理してswitch文で力任せに行けなくはない。
しかしそこから一歩進めて「ゲーム中にメニュー開いてアイテム管理画面作ろうか」とか、「イベント中は操作を受け付けなくして下に会話ウィンドウ、関係ないNPCも止めておこうか」とかなってくると
何らかの管理機構なしではスパゲッティコードを免れないのである。
Android等でコンスタントにミニゲームを出していたブログなんかが
ある時期を境にパッタリと更新が止まってしまう原因もこの辺にあるんだろうか?等と要らぬ心配をしつつ・・
前置きはここまでとしたい。
例えばリバーシとかのちょっとしたゲームだったら現在のステートを数値で管理してswitch文で力任せに行けなくはない。
しかしそこから一歩進めて「ゲーム中にメニュー開いてアイテム管理画面作ろうか」とか、「イベント中は操作を受け付けなくして下に会話ウィンドウ、関係ないNPCも止めておこうか」とかなってくると
何らかの管理機構なしではスパゲッティコードを免れないのである。
Android等でコンスタントにミニゲームを出していたブログなんかが
ある時期を境にパッタリと更新が止まってしまう原因もこの辺にあるんだろうか?等と要らぬ心配をしつつ・・
前置きはここまでとしたい。
自分の場合
具体的にはゲーム内オブジェクトのアップデート機構としては伝統的なタスクシステム(詳細はググって欲しい)を使用。
ゲームを[タイトル][スコアランキング]などの場面(以後Sceneと呼ぶ)に分割しそれぞれクラスに分割、
Scene毎の処理をそこに書く。
で、これらをスタックで管理する。
ゲームを[タイトル][スコアランキング]などの場面(以後Sceneと呼ぶ)に分割しそれぞれクラスに分割、
Scene毎の処理をそこに書く。
で、これらをスタックで管理する。
例えばアクションゲームならばタイトル画面はこうなるだろうか
([]で囲まれた名前はScene名、続いて上から順番に処理するタスク という意味)
([]で囲まれた名前はScene名、続いて上から順番に処理するタスク という意味)
[タイトル] ・背景のアニメーション ・タイトルメニュー表示 ・カーソル移動
メニュー項目が決定され、それがオプション画面であり、タイトルの背景を表示したままオプションを表示させたいならこんな感じにする
[タイトル] [オプション] ・(タイトル::背景のアニメーション) ・オプション項目表示 ・カーソル移動
オプション画面を抜けたらScene: [オプション]をスタックから取り除いてまたタイトルが表示されると。
Scene:タイトル の一部の処理だけアクティブにするには背景アニメーションのタスクグループを名前で検索して
参照をScene:オプション のタスクツリーに持ってきて・・とか細かい話は色々あるけど
ようは現在のSceneより下に積んであるSceneの処理の一部だけを実行するのもアリだと。これは表示に関しても同じ。
Scene:タイトル の一部の処理だけアクティブにするには背景アニメーションのタスクグループを名前で検索して
参照をScene:オプション のタスクツリーに持ってきて・・とか細かい話は色々あるけど
ようは現在のSceneより下に積んであるSceneの処理の一部だけを実行するのもアリだと。これは表示に関しても同じ。
場合によっちゃこんな風になるかもしれない
[ゲームメイン] [ボス戦] [ゲーム内メニュー] [警告とかのポップアップ表示] ・(ゲームメイン::背景やキャラクター表示) ・(ボス戦::ボスの体力バー表示) ・背景を暗くするための黒い半透明枠 ・(ゲーム内メニュー::所持アイテム表示) ・「これ以上持てません」などの警告表示
まだ実装途中だからやっぱこれは上手くいかないやっていう可能性も十分考えられるが
やってみない事には始まらないので。
やってみない事には始まらないので。
(2013/02/07)
Debianパッケージ
Windowsだと「とりあえず公開したい」プログラムの時に共有ライブラリは同じディレクトリへ
一緒に突っ込んでおけば優先的に読み込まれるからそのへんは楽だったが
Linuxは当然というか、そうはいかないようだ。ちゃんとライブラリ検索パスが通った場所に置く必要がある。
そこでDebianパッケージの作り方について調べているが、
ファイルを指定場所にインストールする事自体は出来そうなのだが・・パスを通したり
アイコンファイルをちゃんと読めるか、アンインストールの確認などもうちょっと時間がかかりそう。
下手に急いで中途半端なパッケージを出しても仕方ないので焦らず進める。
一緒に突っ込んでおけば優先的に読み込まれるからそのへんは楽だったが
Linuxは当然というか、そうはいかないようだ。ちゃんとライブラリ検索パスが通った場所に置く必要がある。
そこでDebianパッケージの作り方について調べているが、
ファイルを指定場所にインストールする事自体は出来そうなのだが・・パスを通したり
アイコンファイルをちゃんと読めるか、アンインストールの確認などもうちょっと時間がかかりそう。
下手に急いで中途半端なパッケージを出しても仕方ないので焦らず進める。
ゲームへ
さてさて、心残りだったプログラムが公開の段階まで持っていけたという事で
改めてメインのゲーム開発に戻る。
改めてメインのゲーム開発に戻る。
(2013/02/06)
公開
Qtで組んで放置してたTwitterクライアント。ほぼ一から組み直しという形でやっとこさ公開。
READMEに書き忘れたがQt5 Framework用で、c++0xまたはc++11の機能を使っているので古いコンパイラだとビルドが通らない。
ソースコードはGitHubに、バイナリは・・・まだだった。これからビルドする。
Windows版とLinux版。
クロスコンパイルについては前にあれほど苦戦したからきっと大丈夫と思われる。
READMEに書き忘れたがQt5 Framework用で、c++0xまたはc++11の機能を使っているので古いコンパイラだとビルドが通らない。
ソースコードはGitHubに、バイナリは・・・まだだった。これからビルドする。
Windows版とLinux版。
クロスコンパイルについては前にあれほど苦戦したからきっと大丈夫と思われる。
#追記
Windows版バイナリをTwilveのアップローダにアップロードした。
初回のみQt5ランタイムと一緒にダウンロードしてそれぞれ展開、一式をtwilveのexeがあるフォルダに突っ込む。
Linuxバイナリについては、デバッグ版ライブラリしか入ってなかった為これからライブラリのビルドから始めるので少し時間がかかるかも。
動作はWindowsXPと8で確認済。
初回のみQt5ランタイムと一緒にダウンロードしてそれぞれ展開、一式をtwilveのexeがあるフォルダに突っ込む。
Linuxバイナリについては、デバッグ版ライブラリしか入ってなかった為これからライブラリのビルドから始めるので少し時間がかかるかも。
動作はWindowsXPと8で確認済。
(2013/02/05)
相変わらず
作業は長引き、予定をブッちぎり・・
なんかTwitterのバージョンが上がってAPI 1.1になっていた事に気づいた。
今までのAPIも一応使えるみたいだし何が違うのかといえばAPI回数制限の変更が主らしい。
具体的には全てのAPIに対して一時間何回まで~となっていたのが機能ごと別個にカウントされる。
もちろん自分のクライアントは昔の仕様で組んでいたのでAPI回数カウンタが使い物になってない。そして直す気力も残ってない。リリース優先である。
なんかTwitterのバージョンが上がってAPI 1.1になっていた事に気づいた。
今までのAPIも一応使えるみたいだし何が違うのかといえばAPI回数制限の変更が主らしい。
具体的には全てのAPIに対して一時間何回まで~となっていたのが機能ごと別個にカウントされる。
もちろん自分のクライアントは昔の仕様で組んでいたのでAPI回数カウンタが使い物になってない。そして直す気力も残ってない。リリース優先である。
ところで自分はネットワークサービスのAPIを使って色々するのはこれが初で事情をよく知らないのだが
「誰にリツイートされたかはここの値見れば一発ダヨ!」という風にはいかないのだろうか?
もちろん一発でわかる情報も多いけど物によっては
サーバから返されたJSONの幾つか値を見て行って結果「どうもこのツイートは自分がリツイートした”らしい”」という風に
判断するしかなくてやきもきする。
手順を調べようにもドキュメントには断片的にしか載ってなかったりして、なんとも。
「誰にリツイートされたかはここの値見れば一発ダヨ!」という風にはいかないのだろうか?
もちろん一発でわかる情報も多いけど物によっては
サーバから返されたJSONの幾つか値を見て行って結果「どうもこのツイートは自分がリツイートした”らしい”」という風に
判断するしかなくてやきもきする。
手順を調べようにもドキュメントには断片的にしか載ってなかったりして、なんとも。
予定
あとバグを何か所か直せば最低限の機能が揃い(ツイート、フォロー、リツイート)公開出来るレベルにはなると思うので頑張る。
本当はテキスト解析してフィルタリングしてみたら面白そうと画策していて、
実際そのアルゴリズムを調べて実装などしたんだけどお預けかもしれない。
さっさとゲームに戻らねば。
本当はテキスト解析してフィルタリングしてみたら面白そうと画策していて、
実際そのアルゴリズムを調べて実装などしたんだけどお預けかもしれない。
さっさとゲームに戻らねば。
余談
いつものように作業垂れ流し配信をしていたら
外人さんに「前々から思ってたんだけど、なんでこんな配信してんの?」と問われ
一応いつもの返しで「自分のサボり防止の為」と言っておいたが
ぶっちゃけ自分でも何でやってんだかわからん。習慣とは恐ろしいものよ。
外人さんに「前々から思ってたんだけど、なんでこんな配信してんの?」と問われ
一応いつもの返しで「自分のサボり防止の為」と言っておいたが
ぶっちゃけ自分でも何でやってんだかわからん。習慣とは恐ろしいものよ。