Javaゲーム作成総合スレ

**名前は開発中のものです。** · 2008/10/28(火) 18:23:40

Javaでゲームを作ろうと思っている人、今作っている人等が情報交換するためのスレです。
2Dのスレはありましたが、総合スレがなかったので立てました。
2D,3DどっちでもOKで、グラフィックス、アルゴリズム、お勧めサイト等、内容も自由です。

**名前は開発中のものです。** · 2009/04/16(木) 00:35:02

jinput

**300** · 2009/04/16(木) 00:44:42

>>301
サンクス

**名前は開発中のものです。** · 2009/05/16(土) 16:06:53

>>171
`∧_∧
(´･ω･)
( つ旦O
と＿)_)
ちょっと休憩｡

**名前は開発中のものです。** · 2009/06/14(日) 00:51:47

http://nsj.hp2.jp/asteroid001/

こんなの作ってみました。
まだ試作品だけどよかったら誰か意見ください。

**名前は開発中のものです。** · 2009/06/14(日) 01:09:15

物だけ見せられても宣伝乙としか

**名前は開発中のものです。** · 2009/06/14(日) 03:42:19

>>304
死なないシューティングゲームって爽快感があっていいね
もっと弾とか相手がぶっ壊れるときのエフェクトを派手にして
爽快感だけのシューティングゲーム作りたいなあって思った

**名前は開発中のものです。** · 2009/06/14(日) 11:28:09

>>304です

>>305
確かにこれだけじゃただの宣伝ですね。すみません。

どんな物にしたいか：
・要するにいくつかのｽﾃｰｼﾞに渡って隕石を駆除するｹﾞｰﾑ（制限時間付き）
・まず巨大だが速さが低い隕石がいくつかある状態から開始する
・直径50pixel以上の隕石は破壊されると分裂する。
・隕石の最大速度はｻｲｽﾞに反比例する。
・隕石に衝突すると、何らかのﾍﾟﾅﾙﾃｨが発生する。
・隕石を破壊(分裂)させると、得点が隕石のｻｲｽﾞに応じて増える。

こんなところです。
よろしくお願いします。

>>306
見た目に関してはこれからも色んな効果を追加していくつもりです。
まずはもうちょっと画面を揺らす効果を強くしてみます。

実は途中までは死亡出来る仕様だったのですが、「死ぬまで続ける」よりも「制限時間内でより効率的に隕石を掃除する」
ようにするために急遽死亡判定を取り除いてみました。

**名前は開発中のものです。** · 2009/06/14(日) 14:03:19

超巨大な隕石にちっぽけな自機が挑むっていう構図がいいね。
ただ、主砲が小さな隕石に当たってかき消されちゃうのは少しさびしいと思った。
爆風とかあってもいいんじゃないかな。
そうすれば効率的に隕石を掃除するっていうコンセプトにも一致するし。

あと反射、分裂ってところでbio100%の蟹味噌思い出した。

**名前は開発中のものです。** · 2009/06/14(日) 15:23:29

>>306と>>307の意見を参考に、少し細かい修正を施して見ました。

http://nsj.hp2.jp/asteroid002/
・ｹﾞｰﾑの速度を全体的に上げた。
・隕石が分裂する際に粒子を放出するように。
・隕石のｻｲｽﾞを更に少し上げた。
・主砲の仕様を変更。「ただの強力な弾を発射」→「貫通性を持った削岩機を射出」するように。
　爆発物もその内実装してみようと思います。なんで思いつかなかったんだろう。

結構発想を得る事が出来ました。ありがとう。

>>306
少しは爽快感増えましたかね。

>>308
俺も気に入ってます、この構図。
主砲弾のﾀﾞﾒｰｼﾞ量を変えずにﾀﾞﾒｰｼﾞの与え方だけを変更してみました。いかがでしょう。

**名前は開発中のものです。** · 2009/06/14(日) 19:24:58

>>309
速度が上がって隕石を早く壊せるようになったから、ただ弾を撃って待ってる時間が減ってテンポが良くなってて、
爽快感も増えてる。
今のところ画面内だけを飛びまわれるけど、このゲームはテンポが速いからもっと広いマップを飛びまわれれば
面白いかなあと思った。でも、あまり広いマップだと隕石を見つける作業が大変になってつまらなくなりそうかなあ。

**名前は開発中のものです。** · 2009/06/18(木) 19:43:08

GTGEのオープニング画面消せませんか？

**名前は開発中のものです。** · 2009/06/19(金) 00:36:36

ライセンス違反

**名前は開発中のものです。** · 2009/06/21(日) 03:27:34

GTGEはだいぶ前に開発止まって、JMonkeyEngineに人が流れたと思ってた
ちょっとgoogleで検索してみたけど、JMonkeyEngineはほとんど情報ないね
2.0もよくわからん状態だし
Javaでゲーム作る人はフレームワークとか使わんのかね?

**名前は開発中のものです。** · 2009/06/21(日) 19:11:59

GTGEはちょっとしたゲームにはすごくいいっぽいね
最近ゲーム勉強してフレームワーク作ろうとしてたけど使って見て馬鹿らしくなったｗ

**名前は開発中のものです。** · 2009/06/21(日) 22:47:18

Java自体が半フレームワーク
みたいなもんじゃね。標準で付いてるクラス使いこなせてれば

**名前は開発中のものです。** · 2009/06/22(月) 10:23:26

フレームワークって概念をどうとらえているか知らんが、
普通はそういう言い方はしない。
Javaは基本的なAPIは提供するが、
フレームワークで準備されるような拡張API的な部分はかなり少ない。
多いなら、JakartaCommonsやらは出てこない。

とはいえ、PC上でやりたいことのほとんどにたいしての、
基本的なAPIを提供してくれているのには同意。

**名前は開発中のものです。** · 2009/06/22(月) 21:30:21

JMonkeyEngineがバージョンアップして、日本語の解説記事がｶﾞﾝｶﾞﾝ出てきたら本気でゲーム作る
それまでは、会社でWebアプリ作ってます

**名前は開発中のものです。** · 2009/06/23(火) 02:32:57

そういえばjME2.0、鯖が重くてうまく落とせなかったな。

F/Wの話だが俺は2DゲーメインなんでjME程の3D機能はいらんな。
JOGL使って小型のものを作った。

ただ、スプライトをどう制御するか悩むね。
スプライトクラスが個々のフレームの表示時間も持つのか描画する時に管理するかとか。

**名前は開発中のものです。** · 2009/06/24(水) 11:22:25

スプライトの当たり判定をアルファ値考慮して実装したら平均68msの実行時間がかかってしまう。
どうやって高速化するんだろ？

**名前は開発中のものです。** · 2009/06/24(水) 11:52:19

厳密なアルファ値判定が必要な物だけをリストしたらいいんでない。
もうやっているならスマン。

**名前は開発中のものです。** · 2009/06/24(水) 15:53:53

クロスプラットフォーム目指してるならSDLがあるでよ
Javaの方が手間がかからないけどね

**名前は開発中のものです。** · 2009/06/24(水) 19:20:49

SDLならjavaにもあるんだが

**名前は開発中のものです。** · 2009/06/24(水) 21:35:08

JavaのSDLでいきてるのってるのか？

**名前は開発中のものです。** · 2009/06/24(水) 22:58:00

>>319
大きさや個数が分からんから何ともいえんが
ピクセル単位の判定前に矩形チェックで弾くのはやってるとして

・大きなスプライトを使うんならあらかじめ32x32くらいの判定ボリュームを
　用意して精度を落としてしまう
・輪郭線に該当するピクセルだけをあらかじめ列挙しておき、
　そのピクセルから相手のキャラのアルファ値を見に行く(相互にやる)
・衝突判定用描画バッファを用意し、各ピクセルに色ではなくキャラクタ番号を
　書き込みながら、書き込み先のピクセルを見て判定する
　※描画順序に判定条件が依存するので注意

のうちのどれかを実装するとか

**名前は開発中のものです。** · 2009/06/24(水) 23:31:26

データ構造の仕様も判定の仕様もわからんが
あらかじめ判定のある不透明部分だけ抜き出して適当なデータ作っとくとか

**名前は開発中のものです。** · 2009/06/25(木) 18:29:50

>>319
ゲームの種類にもよるけど、ドット単位で厳格な判定をしようと言うのがそもそもの間違い。
(これはスプライト同士の場合。マウスカーソルとアイコン等、点とスプライトの判定ならドット単位でも大丈夫)
例えば、格闘ゲームの判定なんかは長方形の判定が数個配置してあるだけ。
キャラの喰らい判定も、パンチやキックの攻撃判定も、みんな2・3個の長方形で表現されている。
衝突判定が重要な格闘ゲームですらこうなんだから、他のジャンルもこんな感じ。

どうしても気になるんなら、当たり判定を複数の円や三角に分割して処理すれば軽さと精度を両立できる。
あまり細かく分割すると余計重くなるので、多少の誤差なら無視してしまってok。

STG等、敵の大群と自機の弾幕の間で判定を行なう場合の高速化方法もあるけど、
アルファを考慮して68msって規模なら必要無いので省略。

**319** · 2009/06/27(土) 02:44:14

い、忙しい。コード書けねぇ。

スプライトの仕様は以下

・スプライトの描画座標系での位置(x,y)を持つ
・スプライトのサイズ:w * hを持つ
・表示される画像を持つ
・可視性-visibleを持つ

で当たり判定の実装は以下

1) 可視性をみる
2) 二つのスプライトの位置とサイズから重なっているか見る
--- ここから実際にアルファ値考慮 ---
3) 二つのスプライトの共有された矩形の情報を得る
4) 3)を元に二つのスプライトの画像の共有部のみそれぞれint[]に各ピクセルのargb情報を格納
5) 4)より得た配列二つのピクセルの全アルファ値をみる
6) 見たアルファ値の両方が完全に不透過ならば当たっていると判断

こんな感じ。
それで当たり判定メソッドにアルファ値を考慮するかどうかのフラグを指定できるので、
>>320の"アルファ値判定が必要な物だけ"というのはこれをoffにすればいい。（そのとき実装の 2) までやってreturnする）
それ以外は上記に挙げたこと以外は特にやっていない。

とりあえず>>324の"あらかじめ32x32くらいの判定ボリュームを用意して精度を落としてしまう"
を時間がある時に実装しようと思う。
レスくれたみんなありがと。

**名前は開発中のものです。** · 2009/07/13(月) 20:05:52

スレ違いだとおもうけど
就職作品で提出する場合
MIDPとDojaどっちで作るのがいいと思う？
てかどっちが主流なんだろう

**名前は開発中のものです。** · 2009/07/13(月) 21:00:36

どっちでも作れるなら両方作っておいたほうがいい。
私なら使うかどうかは別として常に保険は持っておく。

ただ「提出」となるとMIDPの方が用意しやすいんじゃないか？

**名前は開発中のものです。** · 2009/07/13(月) 21:20:41

>>329
了解ありがとう～

**名前は開発中のものです。** · 2009/07/13(月) 22:39:13

その会社の製品がどっち優先か調べて決めれ

**名前は開発中のものです。** · 2009/07/14(火) 07:11:46

いまDojaじゃないけどな

**名前は開発中のものです。** · 2009/09/11(金) 12:02:33

質問させてください

Javaでゲーム作る場合は、Swingを使うのでしょうか？それともAppletを使うのでしょうか？
勉強中なのですが、ネットで色々と検索するとJFrame上に画面を生成している人とAppletに画面を生成している人がいます
どちらが一般的なのでしょうか？
PC用、携帯用とかで使い分けるものなのでしょうか？

よろしくお願いいたします

**名前は開発中のものです。** · 2009/09/11(金) 14:11:16

アプレットでSwingが使えるJAppletというのもあるよ！
ブラウザ上で動かしたいならアプレット、単独で動かしたいならJFrame
やろうと思えば両用に作ることもできるが、好みで選べばいい
携帯用は根本的にまったく異なる

**名前は開発中のものです。** · 2009/09/11(金) 20:42:59

SwingかAppletかっていう選択はおかしい。

選ぶのはまずターゲットにする実行環境を選ぶ。
・アプレット(ブラウザ内で実行)
・アプリケーション(ダウンロードして実行)
・携帯
WebStartとかFXとかもある

それとは別に使うライブラリとして
・Swing
・AWT
を選択。他にもSWTやJOGLを使う手もある。

**名前は開発中のものです。** · 2009/09/12(土) 14:13:51

レスありがとうございます
基本的に、ダウンロードして遊ぶアプリケーションを考えています

色々と調べましたけど、appletは過去に現在のFlash見たいな位置づけにあった技術ってことでいいんですかね？
Java Web Startとかも同じようなことやっているみたいですし、今回はappletは無視の方向でがんばってみます

**名前は開発中のものです。** · 2009/09/13(日) 12:41:46

ゲームでSwingはJOGLが安定してからの方がいいような

**名前は開発中のものです。** · 2009/09/13(日) 18:57:10

質問者のレベルからいっておそらくJava2DだけでいいからSwingでもAWTでもかまわんかと

**名前は開発中のものです。** · 2009/09/14(月) 12:43:38

>>333
いつの日かAndroidにRhino組み込んでゲーム作る日が来るよ

**名前は開発中のものです。** · 2009/09/15(火) 20:39:38

皆さんどんなゲーム作ってるの？

**名前は開発中のものです。** · 2009/09/25(金) 02:51:49

皆さんゲーム作ってないのですか？？

**名前は開発中のものです。** · 2009/09/26(土) 09:58:13

誰もいないでちゅか？

**名前は開発中のものです。** · 2009/10/01(木) 07:27:17

誰もいないなら削除依頼だしたほうがいいですかね？

**名前は開発中のものです。** · 2009/10/01(木) 16:48:22

削除依頼を出す必要性が見つからないんだが。

**名前は開発中のものです。** · 2009/10/01(木) 23:01:58

よかった！私以外にも人がいたみたいですね！！
削除依頼は延期させてもらいます！！！

**名前は開発中のものです。** · 2009/10/01(木) 23:31:47

Javaだと、標準機能だけで2D系ゲームならすぐ作れそうだよね。
新入社員教育で、「期間8時間x5日間の課題としてテトリスクローン作成」
程度のメニュー組んでも大丈夫そうな気がする。

**名前は開発中のものです。** · 2009/10/02(金) 07:41:58

>>346
テトリスだとアルゴリズムの部分を除けば必要な機能はキー入力の処理と画像表示だけだよね
疑問なんだが、C#とかC++とかにはそういう機能は標準ではないの？

**名前は開発中のものです。** · 2009/10/02(金) 08:03:30

>>347
C++は画面出力用の標準ライブラリは存在しない。
C#にはあったと思うけど、本格的に使ったことがないんで自信なし。

Javaで40時間で作れそうなゲームというと、大抵の落ちものパズル、インベーダー、パックマンとかかな。
黎明期のゲームはわりとどうにかなりそう。
もちろん、敵も味方も丸や四角になるけど。

**名前は開発中のものです。** · 2009/10/02(金) 11:39:50

>>343
スレがのこってるということ自体に意味があるので自然の落ちない限り残すのが普通だろ
たとえば間をおいて質問等があった場合スレを新規に立ち上げるのと書き込むだけでは敷居が違いすぎる

スレは一個人のものではないんだぜ?
スレはたった時点で「1」の手を離れてるんだぜ…

**名前は開発中のものです。** · 2009/10/02(金) 12:37:48

今のJavaはゲーム作成環境としてもけっこうこなれてきたと思うんだが、
フリーや同人の世界でもJava製ゲームってあんまり無いね。

**名前は開発中のものです。** · 2009/10/02(金) 18:33:12

PCのスペックがどんどん上がってきて、比較的大規模なソフトウェアがJavaで
作られて実際に使われることが多くなったから、Javaの評価は少しづつ上がってると思う。
開発者にとっては楽な言語だからもう少し増えてもよさそうなのになあ。

**名前は開発中のものです。** · 2009/10/02(金) 19:52:15

楽な言語ではないんじゃないかなｗ
楽な環境だとは言えなくもないけど
今時ならScalaやJRubyでゲーム製作ってのもアリかもな

**名前は開発中のものです。** · 2009/10/02(金) 20:52:06

最近、Applet動かすとき一瞬で起動してきもちい。
Java6になってだいぶ良くなった気がする。
FlashやDirectXに浮気せずAppletやJOGLで頑張りますよ。
やっぱり俺はJavaが好き。

**名前は開発中のものです。** · 2009/10/03(土) 01:10:42

>>348
俺の中ではC++とC#はVisualStudioのイメージしか無いからGUI関連は充実してると思ってた

>>350-351
JavaはなんだかんだでWebアプリが主戦場だからね
SwingはSwingUtilities使ってイベントディスパッチスレッドでアクセスするようにしなければならないとか、仕様だかバグだかわからん状態だし
Sunも買収されちゃって、今更Webアプリ以外の分野に大量の技術者投入してくれるとかありえないだろうから、この状態のままだろうね、、、
JMonkeyEngineとかもあるけど、プロジェクトの勢いはあまり無さそう

それと、ネットに落ちているサンプルコードが少ないのが痛いかな
C++は大量にあるのに、Javaは少ない

どう考えてもC++よりJavaの方が書きやすいし、C#と比べても別に遜色ないから、もっと流行って欲しいけどなー

**名前は開発中のものです。** · 2009/10/03(土) 17:26:03

>>354
GUIは安全にやろうと思ったらシングルスレッドモデルになるのはなのはどれも当たり前
Javaに限らんぞ

**名前は開発中のものです。** · 2009/10/03(土) 19:21:25

マルチスレッドなGUIライブラリを作ろうと思ったらそういったものも作れるはずだけど、
GUIを扱う人すべてがマルチスレッドに精通してないといけなくなってしまう
スレッド、同期、排他制御等の正しい知識がなくこれらを扱えない人はGUIお断り、ってのは門戸が狭すぎる
そもそも別スレッドを起動しなきゃイベントディスパッチスレッドを気にする必要なんて無いんだから、
スレッドを使う人だけがスレッドを知ってれば済む今の仕組みがたぶん一番いいんだよ
ところでゲームでSwing使うの？

**名前は開発中のものです。** · 2009/10/03(土) 19:23:55

>>356
Window動作するゲームだとJFrameは使うと思う。
JMenuBarとかも使われそう。

**名前は開発中のものです。** · 2009/10/04(日) 02:19:53

どうせBufferStrategyかGLCanvasになるからFrameにCanvas張り付けて中で全部自前だなぁ。
設定ダイアログを別に付けるならSwing。

**名前は開発中のものです。** · 2009/10/04(日) 08:22:05

>>358
基本的にFrame一個作って、その上のBufferStorategyに全部処理させるのが基本なのか
RPG作るとしても、コマンドとか戦闘画面とかは全てお絵かきすべきであって、いちいち新しいFrameとかPanel立ち上げたり、コマンドをあらわすTable作ったりはしないのが正解かな

**名前は開発中のものです。** · 2009/10/04(日) 10:18:10

>>359
Swingコンポーネントを使う意味があるとしたらSLGだと思う。
RPGとかACTなら、基本的に全部自前で処理じゃないかと。

**名前は開発中のものです。** · 2009/10/04(日) 13:09:00

RPGのウィンドウやなんかは独自L&F実装したSwingでやってもいいんじゃね？

**名前は開発中のものです。** · 2009/10/04(日) 13:10:18

半透明パネルとか可能だからそれもありかもね。
メリットとしては、マウス関係のイベントとかをswingで取得できることか。

**名前は開発中のものです。** · 2009/10/04(日) 14:19:32

GLCanvas/GLJPanelとかつかってるならSwingの重ね合わせ鬼門だな

**名前は開発中のものです。** · 2009/10/04(日) 16:03:38

SwingとJOGL混ぜたら透過周りがすごいことになったような・・・あれはJava3Dだったかな。

**名前は開発中のものです。** · 2009/10/04(日) 16:06:49

どうすごいの？

**名前は開発中のものです。** · 2009/10/04(日) 18:54:04

>>364
GLCanvasとswingは混ぜるな危険だけど、GLJPanel使えば問題ないんじゃないか？

**名前は開発中のものです。** · 2009/10/04(日) 22:32:16

>>366
やってみればわかる

**名前は開発中のものです。** · 2009/10/05(月) 04:32:06

いまのGLJPanelはまだ不安定な部分が

**名前は開発中のものです。** · 2009/10/06(火) 15:09:55

JAVAのゲーム作り関係の本で初心者にお勧めなのってどれだろう？
古すぎるやつは買わないほうがいい？
amazonの中古で1000円切ってるのあるけどさ

環境はeclipseです

**名前は開発中のものです。** · 2009/10/06(火) 23:20:12

基本的な質問かもしれんが、RPGとかシミュレーションを作成する場合、命令入力やステータスを表すWindowをあらわすクラスを生成して、それをpaintComponent(Graphics g)で描画するのが基本なのかな？
Webアプリしか作ったこと無いから、イメージがわかない

>>369
「14才からの～」が評判良かったような気がします
読んだことは無いけど

**名前は開発中のものです。** · 2009/10/07(水) 00:18:11

>>370
アクション要素なしならそれでもいいけど、どの方式でやるにしろ、
オフスクリーンバッファで全部描画処理を完成させておいて。

そうすれば出力方法は何でもいいし、ウインドウにあわせて描画を拡大縮小させるとかできるから。

paintComponentやpaintメソッドとかでゲームのオブジェクトの描画処理はだめね。
また、これらのイベントの場合ダブルバッファだと問題が起きるからトリプルバッファにすること。

**名前は開発中のものです。** · 2009/10/07(水) 01:47:32

アクティブレンダリング自前で書く。

**名前は開発中のものです。** · 2009/10/07(水) 19:16:17

>>369
少なくともJava5以降を対象にしたものを買った方がいい。
総称型や拡張forのお陰でプログラムスタイルがかなり違う。

ただ、本気のゲーム作りのための参考書ってあんまり無い気がする。
JOGLやLWJGL系は皆無。

**名前は開発中のものです。** · 2009/10/08(木) 11:14:07

>>371
ごめん、何を言っているのかまったく理解できない、、、
レベル低くてすみません
paint系メソッドはすでに非推奨なの？
てか、描画はどうすればｲｲの、、、

サンプルになるものとか紹介していただけると嬉しいです

**名前は開発中のものです。** · 2009/10/08(木) 19:49:44

>>374
単にGL使えって意味じゃないか？
GLCanvasとかGLJPanelを使う場合、paintとかpaintComponentじゃなくて
displayが呼ばれる。

**名前は開発中のものです。** · 2009/10/08(木) 21:52:03

>>375
2DのゲームでもすでにGL...系使うのが当たり前なのかな
俺はてっきり、JFrameに直接描画するか、上にJPanelかなにか張って、それにpaint系で描画するものだと思ってた
いずれにしても、参考にしても良いサンプルが欲しい…

**名前は開発中のものです。** · 2009/10/08(木) 23:44:25

2DゲームならGraphicsクラスのメソッド使ってもそれなりに実装出来そうなきがするなあ…
加算半透明以外の要素は大体そろってるし。

**名前は開発中のものです。** · 2009/10/09(金) 01:14:28

>>376
paintのメソッドでもかまわないよ。
ただし、きれいにまわすには描画用のバッファが2枚必要。
paintイベントはOSによっていつ呼ばれるかわからないというのに注意しないといけないからね。

再描画はrepaint自前で呼び出すのみにするという方法もあるけどフレームレートが言っていないと厳しい。
その場合setIgnoreRepaintをよんで無効にしておくこと。GLでもそうだけど。

**名前は開発中のものです。** · 2009/10/09(金) 20:00:50

Java5以降は標準でダブルバッファだと思ったけど、トリプルバッファまでやる必要あるかなあ…？

**名前は開発中のものです。** · 2009/10/09(金) 20:37:11

>>379
>ダブルバッファだと思ったけど
そうなの？
だとすると、トリプルバッファ以上やらない限りはBufferStorategyは使わなくていいのかな？
あれは、JFrameとCanvasでしか使えなかったから、JPanelで自動的にダブルバッファにしてくれるなら、嬉しいよね

**名前は開発中のものです。** · 2009/10/09(金) 21:35:46

>>379
Swingの自動のダブルバッファとは違う話。

ゲームの処理がまわるスレッドがあると思うけど、そこで使う描画バッファが1枚だと
次のフレームの描画に使用可能なバッファが存在しない。

paintイベントで表示するときに前のフレームで描画したバッファが使用中だから。

アクティブレンダリングならその問題は起きないが、フレームレートが一定はないと厳しい。
paintイベントはいつ起こされるか判らないから。

**名前は開発中のものです。** · 2009/10/10(土) 13:58:45

>>381
自分が前に実装した時はゲームスレッドを用意して、そこからrepaint呼ぶようにしてた。
この場合、システムがrepaintしたときは内容に変更が無いから同じ絵が再描画される。
フレームレートとかはあんまり気にしてなかったな。

実際問題として、全画面のアクションゲームとかでなければあんまり気にしなくていいと思う。

**名前は開発中のものです。** · 2009/10/10(土) 14:55:42

>>382
そのrepaintする際のバッファが1枚だと描画中はだめなんで排他制御が必要になる

**名前は開発中のものです。** · 2009/10/10(土) 15:12:17

１フレーム画面が乱れるとかなら、ホビーゲームのレベルで特に気にしなくてもいいような。
そこでハングアップにつながるようだと問題だけど。

**名前は開発中のものです。** · 2009/10/10(土) 18:56:19

イベントディスパッチスレッド以外でゲームの描画すると不具合は生じるね。

フリーズ等はないとは言い切れない。

ハードウェアアクセラレーションを使うってことは実装上オフスクリーンバッファを
VRAMに確保しているはずなのでへんに動くと怖い気もする。

実装依存にするのも将来のバージョンで動かなくなる可能性もあるし。

ダブルバッファの場合ゲームのスレッドから描画処理だけ抜き出して
InvokeAndWaitで処理させてからのrepaintというのが必須になる。

**名前は開発中のものです。** · 2009/10/10(土) 23:49:32

トリプルバッファってのはオフスクリーンバッファと画面エフェクト合成用バッファがいるって意味じゃね？

>>385
AWTと並列処理の組み合わせでいける。シングルスレッドなSwingを使うから余計変なことになる。
というかそもそもパッシブレンダリング使うからrepaintまわりで排他制御が必要になるんじゃ？

**名前は開発中のものです。** · 2009/10/11(日) 01:22:50

AWTもシングルスレッドモデルだよ。
それに今の話の流れはパッシブレンダリング上での話。

**名前は開発中のものです。** · 2009/10/11(日) 10:14:08

排他処理する場合、repaintをオーバーライドする時にsynchronizeつければいいだけ？

**名前は開発中のものです。** · 2009/10/11(日) 11:08:47

描画バッファに対してrepaintの中と描画処理部分にsynchronizedブロックをつけるとよい。
少しでも高速化したい場合はLock構文を使うとよい。

したがって描画部分をまとまるようにすること。ゲームのロジックの中で描画していくのはさける。

**名前は開発中のものです。** · 2009/10/11(日) 13:10:06

14才からはじめるJavaゲーム製作だかなんだかの本を軽く立ち読みしたけど、排他制御には触れていなかったような、、、
JFrame上でBufferStoratgy使って描画するように書いてあったと思うんだが、これだけじゃ、不足なのかな？

**名前は開発中のものです。** · 2009/10/11(日) 13:21:07

JOGLだとFPSAnimatorに任せられるから、その辺は全然気にしたことなかったなあ。

**名前は開発中のものです。** · 2009/10/11(日) 13:22:26

>>390
それはアクティブレンダリングでしょ？今回の話とは違う。
ペイントイベントつぶすsetIgnoreRepaint（）使ってるはず。

**名前は開発中のものです。** · 2009/10/11(日) 13:25:58

>>391
FPSAnimatorはイベントディスパッチスレッド上でdisplayがきれいに動くようになってるからね。

AnimatorやJava2Dなどでパッシブレンダリングやろうとすると自前での管理が必要になる。

**名前は開発中のものです。** · 2009/10/11(日) 15:26:14

しかし、なかなかゲームとしての完成品にたどりつかん。
「JOGLをいれてGLCanvas…、おお、動いた！」
「GLSL？　ためしにウェブ参考にPhongシェーダー実装して…、おお！これがピクセルシェーダー！」
みたいに、断片断片を動かしては満足してしまう。
社会人になると、なかなか本腰いれてやろうって気にならないしなあ。

jMEは面白そうだが、趣味のために英語資料を読むのはめんどい。
日本語資料がもっと充実してるといいんだけど。

**名前は開発中のものです。** · 2009/10/11(日) 17:50:39

動画がうごかねぇ・・・
マック環境でうごかねぇ・・・

**名前は開発中のものです。** · 2009/10/11(日) 20:53:55

さすがにそれだけではなんとも言いようが無い

**名前は開発中のものです。** · 2009/10/11(日) 22:54:45

AWTはシングルスレッド前提じゃないでしょ？

**名前は開発中のものです。** · 2009/10/12(月) 01:11:47

イベントディスパッチスレッド前提なんでおなじだよ

**名前は開発中のものです。** · 2009/10/12(月) 14:54:55

そういや、みなさんモデル情報の持ち方ってどうしてる？
三角分割するのは当然として、自分はフラットポリゴンとグーローポリゴンが混在する場合の効率のよい
持ち方が今一つ詰め切れて無い。

現状だと、ポリゴンが頂点を共有しないという不効率な実装になってて、かなりメモリを浪費してる。
というのは、メタセコイアの形式に慣れてるんで、ポリゴン中心の設計だから。
マテリアルをポリゴンごとに指定できるようにすると、座標を共有する頂点でも
ポリゴンごとに別管理しないといけない。

正四面体で言うと、本来なら頂点は４つで済むところ、各ポリゴンが頂点を指定するので
内部的には12頂点が存在する。
そのかわり、各面それぞれ色が違っても問題ない。

頂点中心の設計にするとこの辺は効率化できるはずなんだけど、そうすると
各面それぞれ色が違うような多面体は例外処理が必要になり、メタセコイアからのインポートが面倒になる。
現在思案中。

**名前は開発中のものです。** · 2009/10/12(月) 17:19:28

>>399
> マテリアルをポリゴンごとに指定できるようにすると、座標を共有する頂点でも
> ポリゴンごとに別管理しないといけない。

メタセコイアは面がマテリアル番号を持ってるから、頂点を共有して面を色分けしても
何の問題も無いはず。

部分フラットシェーディングについては俺も頂点を共有しないことで対応してるよ。
フラットな面がある程度多いなら、その範囲だけ別オブジェクト(レイヤ)にして
スムージング角度をゼロにすれば、範囲内外の境界以外は頂点を共有できる。

**名前は開発中のものです。** · 2009/10/12(月) 17:32:20

>>400
>>399だが、glBegin～glEndだとマテリアルバラバラでも問題ないんだけど、
同じ頂点でマテリアルが違う場合、VBOにできないんだよね。
あれは頂点を座標、法線、テクスチャ座標でパックするから。

まじめに考えると、メタセコから読み込む時点でその頂点を共有するポリゴンを解析して、
法線とマテリアルとテクスチャ座標が同じなら同一頂点とみなし、そうでないなら別の頂点とみなすという
処理をいれるのが一番という気がしてきた。

内部フォーマットはあくまでOpenGLに寄り添う方向性で。