【徹底討論】Java３Dの可能性について考える

1 名前：デフォルトの名無しさん [02/10/04 12:54] Java３Dはどこまで可能性を秘めているのか。 その辺についてまたーりと語り合いましょう。 513 名前：デフォルトの名無しさん mailto:sage [04/10/10 21:08:21] でもさ、JavaSoundがどのようなAPIを持てばよいか、っていうのは よく考えるべきだと思うんだよね。 結局DirectSoundと同じだったりしたら萎える。 514 名前：デフォルトの名無しさん mailto:sage [04/10/10 21:33:11] しかし、DirectSoundもそれなりに考えられてるぞ。 515 名前：デフォルトの名無しさん mailto:sage [04/10/10 22:08:11] DirectSoundをJavaらしくきれいにラッピングしたというところかな セカンダリバッファに書き込むときとかリングバッファを意識しないとかね 問題はDirectSoundとこのスレとどう関係があるかだ 516 名前：デフォルトの名無しさん mailto:sage [04/10/10 22:28:27] >>512 Java3D自体にlinuxようがあるでしょ? https://java3d.dev.java.net/ 517 名前：デフォルトの名無しさん mailto:sage [04/10/10 22:55:00] >>516 betaですけどありました、ありがとうございます 518 名前：デフォルトの名無しさん mailto:sage [04/10/10 23:58:52] >>510 ネイティブ部分を増やしてるってこと？ 妥協せずネイティブはJITでやって欲しいね。 519 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:30:57] >>506 つまり数式を解く読解力がないと 520 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:31:37] >>508 ネタとしては、 Java3Dに搭載されている Sound APIは距離減衰機能があるということ 521 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:32:40] >>510 java.lang.Mathの ソースコード見たことがないのか？ nativeキーワードばかり使って 計算の殆どはVMに内蔵されたCでかかれた コードを使っているぞ。 522 名前：デフォルトの名無しさん mailto:sage [04/10/11 10:33:26] >>513 100%PureJavaであることに意義があるから 同じでもいいだろう。 523 名前：デフォルトの名無しさん mailto:sage [04/10/11 14:42:07] >>521 単純計算だとCよりJavaの方が速いんじゃなかったっけ？ なんでJavaで書かれてないの？ 524 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:04:03] Javaの方が速いという根拠を聞きたいのだが 525 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:07:27] >>524 俺は分からんから、ム板のスレあさってくれ。 Java厨と.NET厨がケンカしてるスレでベンチマークと解説が出てた気がする。 526 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:26:54] あれは速い場合もあるってだけでしょ。 例えばグリッド(テーブル)への行の追加は、WIN32を呼ぶより仮想化してある JavaのSwingの方が速かったはず。 あと、メソッドを呼ぶ速度はJavaが何倍も速い。 527 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:37:31] Cでもくそ高いプロファイラとCPUやらマシンスペックが固定されていれば早いよ Ｊａｖａはダイナミックにそのへんやれる余地があるのが強い 昔に書いたコードがVM差し替えでそのまま早くなるのは利点だな 528 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:38:29] あれ？ NativeからJavaに書き換えてパフォーマンス改善したのって、BigDecimalだけだっけ？ 529 名前：デフォルトの名無しさん mailto:sage [04/10/11 15:50:50] 最終的にはnativeにいきつくのがおおいし、そもそもpureJavaでいい 標準APIならその実装はどうだっていいだろ 530 名前：デフォルトの名無しさん [04/10/12 20:48:06] で、499=503は何をそんなにエキサイトしまくってるんですか？ 531 名前：デフォルトの名無しさん mailto:sage [04/10/12 23:30:27] >>503 おそっ 532 名前：デフォルトの名無しさん mailto:sage [04/10/12 23:46:51] >>531 おまえもなー 533 名前：デフォルトの名無しさん mailto:sage [04/10/13 01:39:52] >>532 おまっ・・・おれもなー 534 名前：デフォルトの名無しさん mailto:sage [04/10/13 02:58:59] 俺もお前も　お前も俺も 輝く未来を賭けて さぁ　鋼鉄のスクラムだ 535 名前：デフォルトの名無しさん mailto:sage [04/10/14 11:15:52] あのー、３Dを語ろうポリー 536 名前：デフォルトの名無しさん [04/10/14 20:49:21] 結論：3DやるならVC++でDirectX直 537 名前：デフォルトの名無しさん mailto:sage [04/10/15 21:16:45] OpenGLでマルチプラットフォーム 538 名前：デフォルトの名無しさん mailto:ｓage [04/10/16 03:25:10] 形ばかりのマルチプラットホームではあまり嬉しくない分野だからなー。 Javaの出る幕は無いだろ。 539 名前：デフォルトの名無しさん mailto:sage [04/10/16 04:13:29] JSDL以外でJavaからSDLを使うライブラリってありませんか？ 540 名前：デフォルトの名無しさん [04/10/16 05:47:43] >>536 C#でManaged DirectX 541 名前：デフォルトの名無しさん [04/10/16 06:33:20] 一部のマニアしかつかわねぇよ。 542 名前：デフォルトの名無しさん mailto:sage [04/10/16 22:51:07] じゃ俺C#で無意味に3Dエディタでもつくって見ようかな 543 名前：デフォルトの名無しさん mailto:sage [04/10/17 02:26:18] Javaは好きだけどJava3Dには手を出すつもりはありません 544 名前：デフォルトの名無しさん [04/10/17 18:18:13] ん？ Javaってサーバサイド用の、COBOLみたいな位置付けの言語だろ？ 545 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:52:31] ageてるやつの文章をよーく見てみよう 546 名前：デフォルトの名無しさん mailto:sage [04/10/17 21:42:11] >>528 とりあえずBigDecimalのソース見たが nativeキーワードつかってるところは一つも見あたらなかった。 java.mathパッケージのソースも全部検索したが nativeは一つも無かった。 一部java.ioを使ってるクラスがあったが。 そっちにnativeがあるかもしれん 547 名前：デフォルトの名無しさん mailto:sage [04/10/17 21:44:43] JavaがだめだからC#を使う って本末転倒すぎ 速度気にするなら率直にCでやれよ 548 名前：デフォルトの名無しさん mailto:sage [04/10/17 22:20:14] www.idiom.com/~zilla/Computer/javaCbenchmark.html 549 名前：デフォルトの名無しさん [04/10/17 23:20:54] >>548 ネビーユの補完やLU分解は なぜかJavaが最速なんだな 550 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:23:18] 高速フーリエ変換もなぜかCを抜いて IBM製Java VMが高速 551 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:25:09] Conclusions: Why is "Java is Slow" so Popular? Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled). Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article. Let's look at several possible reasons: # Java circa 1995 was slow. The first incarnations of java did not java a JIT compiler, and hence were bytecode interpreted (like Python for example). JIT compilers appeared in JVMs from Microsoft, Symantec, and in Sun's java1.2. This explanation is implausible. Most "computer folk" are able to rattle off the exact speed in GHz of the latest processors, and they track this information as it changes each month (and have done so for years). Yet this explanation asks us to believe that they are not able to remember that a single and rather important language speed change occurred in 1996. # Java can be slow still. For example, programs written with the thread-safe Vector class are necessarily slower (on a single processor at least) than those written with the equivalent thread-unsafe ArrayList class. 552 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:26:28] This explanation is equally unsatisfying, because C++ and other languages have similar "abstraction penalties". For example, The Kernighan and Pike book The Practice of Programming has a table with the following entries, describing the performance of several implementations of a text processing program: * Another evidently well known problem in C++ is the overhead of returning an object from a function (several unnecessary object create/copy/destruct cycles are involved). * Java program startup is slow. As a java program starts, it unzips the java libraries and compiles parts of itself, so an interactive program can be sluggish for the first couple seconds of use. This approaches being a reasonable explanation for the speed myth. But while it might explain user's impressions, it does not explain why many programmers (who can easily understand the idea of an interpreted program being compiled) share the belief. Two of the most interesting observations regarding this issue are that: 1. there is a similar "garbage collection is slow" myth that persists despite decades of evidence to the contrary, and 2. that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data. 553 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:26:35] Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject. Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology, though these particular "myths" are arbitrary and relatively harmless. Acknowledgements Ian Rogers and Curt Fischer clarified some points. References [1] K. Reinholtz, Java will be faster than C++, ACM Sigplan Notices, 35(2): 25-28 Feb 2000. [2] Benjamin Zorn, The Measured Cost of Conservative Garbage Collection Software - Practice and Experience 23(7): 733-756, 1992. [3] Linux Number Crunching: Languages and Tools, referenced on slashdot.org [4] Christopher W. Cowell-Shah, Nine Language Performance Round-up: Benchmarking Math & File I/O, appeared at OSnews.com, Jan. 2004. [5] E. Schanzer, Performance Considerations for Run-Time Technologies in the .NET Framework, Microsoft Developer Network article. 554 名前：デフォルトの名無しさん [04/10/17 23:42:22] 漏れら極悪非道のageブラザーズ！ 今日もネタもないのにageてやるからな！ ￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　 ∧＿∧ 　 ∧＿∧ 　　　age 　（・∀・∩）（∩・∀・）　　　　age 　（つ　　丿 （ 　　⊂）　age 　 （　ヽノ　　 ヽ/　　）　　　age 　 し（＿）　　 （＿）Ｊ 555 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:43:09] マイクロベンチマークとかはもういいよ Javaの性能がどの程度なのかは 自分で使ってる人間ならわかってるだろ 556 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:04:30] つまりJavaは1.4系からは十分早い 557 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:05:27] JNIで既存のライブラリ使おうとするとたいて二重でso/DLL呼ぶことになるから非効率極まりないような気がするのだが・・・ 558 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:10:55] 関係ないがTomcat5.5は起動がめちゃ早くなってる。 559 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:52:38] ５．５の正式版ってもうでたの？ 560 名前：デフォルトの名無しさん mailto:sage [04/10/18 01:23:46] 一応、最初から正式版だよ。 561 名前：デフォルトの名無しさん mailto:sage [04/10/18 01:59:26] Javaが速いとかいってる奴はメモリ使用量見ても何も思わないのか・・・ まぁ、速いけどな 562 名前：デフォルトの名無しさん mailto:sage [04/10/18 02:06:03] >>561 CrusoeのCMS(16MB)と同じで諦めてます 消費税みたいなもんです 563 名前：デフォルトの名無しさん mailto:sage [04/10/18 02:13:58] メモリはこれからの改善点だな プロファイラとかで見るとやたらとStringオブジェクトが多かったりするんだよね Immutableなせいもあるのだろうが・・ 564 名前：デフォルトの名無しさん mailto:sage [04/10/18 02:33:08] >>556 1.4.2からはさらに高速化し 1.5からはPreJITに相当する機能によりさらに高速化 565 名前：デフォルトの名無しさん mailto:sage [04/10/18 12:50:48] >>560 jakarta.apache.org/site/binindex.cgi みるかぎりアルファっぽいけど？ でもバイナリのほう見るとアルファがないのもあったりする 以前のがあってもよさそうだけど、リリース済みの5.5.0や5.5.1のバイナリがどこにもおいていない・・・ 566 名前：デフォルトの名無しさん mailto:sage [04/10/18 12:58:07] >>564 ずっといじってきたけどVMのコア自体は1.4から5.0で速度的に大きく変わった点はないかな 1.4.1ではもちろんShift_JIS方面の変更が大きいし、一部ハードウェアアクセラレーションを使った 機能が追加されて体感速度はあがったけどね。 1.4.2ではほんのすこしで5.0はコンパイルがききやすいヘビーな処理は1.4.2と変わらない感じ。 ただしgcの速度が大幅に改善されていることと、インクリメンタルが別物になったとか大きい変更点はある。 起動時間はWindows使ってる限り改善されているように感じないし。 567 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:10:21] 起動時間は、２つめ以降のVM起動が劇的。 568 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:23:13] >>565 5.5.0と5.5.1にはalphaはついてなかったよ。 「it is not yet stable.」だったけどね。 569 名前：デフォルトの名無しさん mailto:sage [04/10/18 22:27:29] >>567 別に1.4.2でも2つめ以降はキャッシュに乗ってるので別に問題にならないくらい早い バニアスコアとドタンコアのPentiumMで確認済み 5.0はコンパイルの速度とかが原因かクラスロードとか少し重いかなぁという気はする まだこまかくチェックしてないけど、古いマシンでは1.4.2のほうが快適な場合も多い感じ >>568 ぜんぜんだめやん 570 名前：デフォルトの名無しさん mailto:sage [04/10/19 00:34:52] Java３Ｄについて語ってくれよ。 571 名前：デフォルトの名無しさん mailto:sage [04/10/19 01:28:04] >>569 それは、Javaの仕組みとしてじゃなくて、潤沢なメモリでキャッシュされてれば、ってことでしょ。 連続して2つ起動した場合じゃない？ 5はクラスを共有したりしてるから、全然違うと思うんだけども。 572 名前：デフォルトの名無しさん [04/10/19 04:51:35] >>566 Swingはめっさはやくなったぞ。 ぬるぽ処理も1.4.2から高速化したで。 5.0からはGenericsでさらに高速化。 さらに一度起動したJavaはネイティブコンパイル されたままディスクに保存され ２回目以降からは高速化される。 573 名前：デフォルトの名無しさん mailto:sage [04/10/19 05:47:50] Genericsはコンパイラの仕事だから、実行速度には影響ないと思われれれ。 574 名前：デフォルトの名無しさん mailto:sage [04/10/19 12:07:44] >>571 そう。ＯＳの仕組み、というか2回目以降はウィルスチェックがはいらないのが一番大きい それ以外では大きくかわらんということだ。メモリ使用量チェックしてないのでまだわからんが 速度的にはびっくりするくらい変わらなかった ６．０では完璧な共有ライブラリになるようだから注目してるけどね >>572 うそばっかかくなよ Swingも計測してみたが早くなってないよ 大きく変わったのはLinuxでOpengGLサポートをtrueにしたときだけ デフォのテーマが変わって見た目がよくなったというのも大事だが WindowsLAFの出来がよくなったのが個人的には非常に大きい ネイティブとの見分けがますますできなくなったという感じ 575 名前：デフォルトの名無しさん mailto:sage [04/10/19 12:35:26] >>574 文字描画周りの一部がJavaで書き直しとか BufferdImageのVRAMへのキャッシングとか 微妙にJava2Dが変わってるからケースによっては Swingの性能にも影響あるかもよ weblogs.java.net/blog/chet/archive/2004/09/tiger_on_the_de_1.html 576 名前：デフォルトの名無しさん mailto:sage [04/10/19 12:46:40] まぁ、いいことばかりだが1.4.2から劇的に変わると思っていたJava2Dが Windowsではほとんど変わってないのにショック受けたしな OpenGLも手元の環境では有効にならないし・・・動いたという報告も聞いたことない BufferedImageのキャッシュはやり方知っていれば1.4.2でも適切に処理ができた それでも敷居が下がったのはいいだろうね 577 名前：デフォルトの名無しさん mailto:sage [04/10/20 08:42:15] >>576 OpenGL対応のグラフィックカード使ってる？ 578 名前：デフォルトの名無しさん mailto:sage [04/10/20 10:34:12] >>577 OpenGLをTrueにすると標準出力にどういう表示される？ 579 名前：デフォルトの名無しさん mailto:sage [04/10/20 12:43:17] >>578 OpenGL pipeline enabled for default config on screen 0 580 名前：デフォルトの名無しさん mailto:sage [04/10/20 13:02:42] もしかしてソフトウェアエミュレーションができないのかな＞J2SE5.0のOpenGL 581 名前：デフォルトの名無しさん mailto:sage [04/10/27 12:31:14] ソフトウェアエミュレーションできても遅くて意味ないだろ NVIDIAのGeforceシリーズはかなり前からOpenGLサポートしてるよ 他社のグラボでも、最近のグラボは大抵OpenGLくらいサポートしてるだろ 582 名前：デフォルトの名無しさん mailto:sage [04/10/27 12:40:22] たいていのチップはi855とかUMAな 583 名前：デフォルトの名無しさん mailto:sage [04/10/28 20:11:37] 3DのAPIの業界標準はOpenGLなんだからJavaがOpenGLに対応するのは当然 JavaがDirectX採用したら、Windowsでしか動作しなくなる OpenGLをDirectXでエミュレーションできるかどうかはWindowsがやるべきで、JavaVMがやることではないよ 業界標準を守らないのはあくまでもMicrosoftだということを忘れるな 584 名前：デフォルトの名無しさん mailto:sage [04/10/28 21:02:56] i855やi830などUMAでもOpenGLアプリは動いてるから文句いってるんだけどな しかし１GHｚ未満＋GeForce2MXよりはもう早いのなぁ 585 名前：デフォルトの名無しさん mailto:sage [04/10/29 11:14:13] みんな、J2SE5でOpenGL Trueにしてるの？ オプションつけないとデフォルトではOpenGLは無効になるみたいだけど 586 名前：デフォルトの名無しさん mailto:sage [04/10/29 11:28:27] OpenGLサポートってこのこと言ってるの？ ＞そのほかJavaのグラフィック機能（Java2D）が、OpenGL経由で、 ＞システムが持つグラフィックアクセラレーション機能を利用できるように改良された。 ＞これにより、高速なグラフィックサブシステムを持つ環境で、より高速な描画が可能になる。 www.itmedia.co.jp/enterprise/articles/0406/30/news026.html これだったらJavaVMのオプションで　-Dsun.java2d.opengl=True つけないと有効にならないよ 587 名前：デフォルトの名無しさん mailto:sage [04/10/29 12:17:08] そのオプションつけても無効だから困ってるんだ 588 名前：デフォルトの名無しさん mailto:sage [04/10/30 08:51:57] どのグラボでOpenGLサポートが有効になるのかな？ 情報くれ 589 名前：デフォルトの名無しさん [04/10/30 18:26:25] 結論：DirectX>>>>>>OpenGL 590 名前：デフォルトの名無しさん mailto:sage [04/10/30 22:45:28] >>589 どっちが上とかじゃなくて実際にJava3Dで作られたアプリケーションやら アプレットがあれば見てみたいんだけど何か代表的な物はありますか？ 591 名前：デフォルトの名無しさん mailto:sage [04/10/31 01:04:07] 3DならVC++でDirectXが一般的だしなー。 JavaはサーバサイドでCOBOLの後継やってなさい。 592 名前：デフォルトの名無しさん mailto:sage [04/10/31 01:22:46] Windowsだけで世界が閉じてればDirectXでもいいんだけどね。 593 名前：デフォルトの名無しさん mailto:sage [04/10/31 01:49:23] Windowsだけで閉じた世界に住んでいる人もいるからね。 594 名前：デフォルトの名無しさん mailto:sage [04/10/31 14:12:01] Windows以外で3Dって事実上、かなりニッチなんだよなー。 595 名前：デフォルトの名無しさん mailto:sage [04/10/31 14:22:08] CADや研究用途ぐらいなものかな。 まあ、でも海外だとOpenGLのゲームは珍しくも無いからなー。 596 名前：デフォルトの名無しさん mailto:sage [04/11/01 01:59:50] こんなの見つけた ttp://timetripper.hp.infoseek.co.jp/ 597 名前：デフォルトの名無しさん mailto:sage [04/11/01 02:53:46] うわ。ショボ。 8801の頃を思い出すな。 598 名前：デフォルトの名無しさん mailto:sage [04/11/01 11:49:47] >>597 は、まだ8801mkIIを使っている 599 名前：デフォルトの名無しさん mailto:sage [04/11/02 02:01:41] 基本的なことを聞きたいんだが、現状のJavaによる3Dプログラミング の認識としては、 ・JOGLはまんまOpenGLだからOpenGLになれてる人には便利。ただし ハードウェアがOpenGLに対応していない場合にソフトエミュレーションを やってくれないため環境によって動かないことがある。つまりWrite once run anywhereじゃない。 ・Java3Dは独自の記述方法だが、内部的に必要があればOpenGLを 使っている。ハードウェアがOpenGL対応かどうかに関係なく（速度は 違えど）同じ結果を返す。 ・しばらくは「Java3Dが放置され、これからはJOGLになるんじゃないか」 という見方もあったが、Looking Glass などに象徴されるように、JOGLは 低級/環境依存/実験向け、Java3Dは高級/環境非依存/運用向けの 棲み分けとなり、今後もJava3Dは発展し続ける。 という認識で間違いない？　これからJava3Dやろうとおもってるんだけど もしかして「いまさらJava3Dってずれてる？」と不安になってネット上で調 べてみた結果なんだけど。 600 名前：デフォルトの名無しさん mailto:sage [04/11/02 21:13:22] それ以前にいまさらクライアントサイド、デスクトップ用途でJavaってのがずれまくり。 601 名前：デフォルトの名無しさん mailto:sage [04/11/02 23:39:24] >>599 いいんでないかな。 もうちょっとアグレッシブにJava3Dやって欲しい気もするが。 Looking GlassもJava3D使ってるし。 デスクトップがシーングラフってのに可能性を感じる。 602 名前：デフォルトの名無しさん mailto:sage [04/11/03 02:39:20] >>600 今時のPCのCPU性能とメモリ容量ならずれまくりだとは思わないけど それに、Webアプリでも、クライアント部分にJavaアプレット使ってるのもあるけどな 603 名前：デフォルトの名無しさん mailto:sage [04/11/03 02:59:06] >>600 クライアントサイド、デスクトップ用途でJavaってのがずれまくりというのが少々ずれてる。 604 名前：デフォルトの名無しさん mailto:sage [04/11/03 11:54:43] Java対応の3Dネットワークゲームライブラリだそうな。 www.cyberstep.com/oni/index.html 605 名前：デフォルトの名無しさん mailto:sage [04/11/03 21:31:20] Java3Dを普及させるようなキラーコンテンツが無いってのが 一番の問題かなあ･･･。 Java3Dで何か作っても、ランタイム入れないと見れないので、 普通の人はあまり見てくれない。 だから、Web上で見かける3DのJavaアプレットは 大抵Java3D使わずに、自前でレンダリングしてる。 Javaだけで何処まで3D表現が出来るかは、この辺を参考。 ttp://homepage1.nifty.com/open-prog/ "Old Contents"→"JAVAde3D"にあるアプレットを見れば、 どんな処理がどれ位の速度で出来るか、大体わかると思う。 606 名前：デフォルトの名無しさん mailto:sage [04/11/03 21:49:04] >>605 そこのアプレット 1フレーム毎にcreateImage()してたりして 性能面ではちょっとあやしい それとは関係ないけどJavaベースの据置きゲーム機の話 www.itmedia.co.jp/enterprise/articles/0410/30/news006.html 607 名前：デフォルトの名無しさん mailto:sage [04/11/05 00:01:34] Java3Dを使ってゲームのような物を作ろうとしているのですが キャラクタの移動で地形の形状を追従させるのに苦難しています。 Collision系のビヘイビアだと突き抜けることがあるのでダメだったので、 現在はPickingを使って地形の形状に対して衝突しているかしていないかを 移動毎にチェックする方法で対処しています。 他に何かいい方法があるならば教えて貰えないでしょうか？ 608 名前：デフォルトの名無しさん mailto:sage [04/11/25 00:55:36] Java3Dでゲームなんてやめとけ・・・というアドバイスしかできんな。 609 名前：デフォルトの名無しさん mailto:sage [04/11/25 02:01:39] >>608 それ、アドバイスのつもりでアドバイスになってないよ。 610 名前：デフォルトの名無しさん mailto:sage [04/11/25 07:35:57] Windowsのゲームなんて遅いばかりだから、DOSゲームにしとけ、というのと同じ感じか。 611 名前：６０８ mailto:sage [04/11/27 19:45:04] そうかな。 いいアドバイスだと思うがな。 Java3Dではしょぼいゲームしかできない事は、まともな判断の できる奴ならわかる事だし、まだＨＳＰかｉアプリの方がましだ。 プレステ並とか夢みてるならＣ＋＋やるしかないだろう。 612 名前：609 mailto:sage [04/11/27 23:11:42] >>611 そこまで書いて初めてアドバイスだ、ということだよ。 >>608だけじゃただのいたずら書きだ。 613 名前：デフォルトの名無しさん mailto:sage [04/11/28 01:51:43] >>611 プレステ並のゲームを作るとしたら、Java3DとかDirect3DとかOpenGLとかのレベルじゃない問題の方がでかいと思う。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef