ProjectBuilderでゲーム製作 - 1062602712

1：ぷご：2003/09/04(木) 00:25: Cocoaで作るのか、OpenGLを使うのか、core graphicsで頑張るのか、Carbonも重要だ、そして役立ちツールは？

疑問と悩みの尽きないMacOSXでのゲーム開発について議論し尽くしましょう。
2：ぷご：2003/09/04(木) 00:29: Cocoa + Objective-C で適当に作ると遅かった。やはり遅かった。
処理速度を要求されないゲームを作るのには非常にいいけれども。

OpenGLではゲーム専用の感じが強すぎて、応用が利かないのでは？
というわけで、core graphicsに興味津々。Quartzともいう。
3：ぷご：2003/09/04(木) 00:31: 複数キー入力はCarbon使ってGetKeysやらないとだめなのかなぁ。
きじばとさんのところにあるHIDのサンプルあるけど、難しそう。
4：ぷご★：2003/09/07(日) 20:34: core graphicsをCocoaで使うサンプルってないのかなー。
NSViewやNSImageと組み合わせるやり方が分からない。

Carbonで使ったほうがよいかな。
すでにGetKeys使ってCocoa+Carbonになっているし。
5：き：2003/10/02(木) 00:03: パッドの使用は思ったより素直で難しくなかったですよ。

入力の快適さは、特にアクション系のゲームの面白さに直結しますから、
より多くの作品がHID対応になってほしいですね。
最近はフォースフィードバックとか楽しい技術もあるようですし。
6：ぷご：2003/10/03(金) 00:30: パッド持ってる人ってどれくらいいるんだろう？と思ってしまうのですけどね。
結構多いのかな？僕も以前持ってましたし。
本格的なアクションかシューティングを作る時には対応しないといけませんね。

とてもそこまでのゲームが作れる技量には至りそうにないです。
7：ぷご：2003/10/12(日) 22:47: 現在Carbonでプログラム作成中。
ProjectBuilderだとOSX専用のものしか作れない。
Classic用にはMPWで作ればいいか。

MPWでClassicアプリ作るよりはかなり楽です。
Cocoaよりも慣れてる分簡単ですし。
仕事でC使ってるのが生かせますし。
C言語だと他機種への移植が楽ですし。
GUIを楽に使えないのがデメリット。ゲームではあまり関係ないです。

リソースはResEditで開けないのか？
8：ぷご：2003/10/13(月) 17:45: リソースはResEditで開けた。
ビルドしたアプリケーションを一度捨てたらOKでした。

パッケージの内容を表示して、その中に本体があるという構造。
9：ぷご：2003/10/13(月) 19:45: >>8
それやるとアプリが起動しなくなった。
アプリにリソースフォークを持たせてはいけないのか。無念。

別にリソースファイルを作るかな。
10：ぷご：2003/10/17(金) 00:51: カレントディレクトリの取得方法
http://developer.apple.com/ja/technotes/tn2015.html

cicnはGetCIconでないとうまく取得できない。GetResourceが使いたいのに。
11：ぷご：2003/10/18(土) 01:52: Carbonでは「いますぐ画面を更新したい！」というのはどうするんだろう？
MacOSX Carbon Programming Guideに載ってたかな？

「オフスクリーンから画面へのコピーはOS側（プロセスマネージャ）
　の管理で定期的に行われると思います（たぶん）」

たぶんってなんだよー。
12：ぷご：2003/10/18(土) 02:10: QDFlushPortBufferを使うのか。ふむふむ。
いや、うまく反映されないような。
13：ぷご：2003/10/18(土) 02:32: ああ、バグがあってQDFlushPortBufferを読んでいなかっただけだった。
14：ぷご：2003/10/23(木) 01:11: WaitNextEventがやたら遅いな。
1tickを指定したら､ほんまに1tick待ってる感じ。
15：ぷご：2003/10/23(木) 23:38: 64*64pixel,16bit colorの画像を120回転送。
これでiBook/700で60fpsくらいでる。

HyperCard+PgColorXの5倍ほど。よし、まぁまぁだな。
単なるCopyBitsの練習だけど。
16：しんた51：2003/10/25(土) 01:16: オヒサしぶりです。
オフスクリーンというと、OpenGLの拡張機能で高速転送しているらしいですね。
ATIだとかOSのバージョン違いで速度に随分差が出るみたい。
QDはオーバーヘッドが凄そうなので、自前描画の方が速いのでは？
17：ぷご：2003/10/25(土) 04:56: こんばんは。

QuartzExtremeはグラフィックアクセラレータ使うんで、かなり強力です。
でも非対応機種だと遅いままなのが残念。

自前描画はpugoGLの経験でダメと結論付けました。
速くても、ゲーム作るのが面倒になるなら意味が無いです。
それに、自前描画よりもOpenGLのほうが良いです。
CPUが仕事しない分、他のことできますし。

OpenGLを使わない理由は、3Dに興味が無いのと、
ソースを公開して参考にしてもらうためです。
18：ぷご：2003/10/25(土) 13:22: NewGWorldのオプションでuseDistantHdwrMemを使って
VRAM上にGWorldを配置できる。

でも速度変わらず。既に高速になってた模様。
OSのバージョンによっては効くかも。
19：ぷご：2003/10/26(日) 00:50: 本日より、「PBでゲーム制作」改め「XCodeでゲーム制作」です。
ゲームだけを考えている訳じゃないですが。
20：ぷご：2003/10/30(木) 00:17: もしや、Xcodeって使いにくい？
伝統と信頼のProjectBuilderのほうがいいのか？

まぁ、慣れの問題だなこれは。
21：し51：2003/11/02(日) 19:14: ううむ、Xcode使いにくいです…（笑）
Mac以外でも開発する人にとっては、慣れるにも結構な負担が…
22：ぷご：2003/11/02(日) 20:57: うう、やっぱり使いにくいのか。
Appleのソフトはいつも使いやすい事が魅力だったのに。
23：ぷご：2003/11/05(水) 23:05: Xcode1.01アップデータが出たよー。
ファイルのデータの破損または消失を修正したらしい。
そんなんで大丈夫な品質なのか？
Pantherに無理矢理間に合わせただけのような。
24：ぷご：2003/11/26(水) 00:10: http://homepage.mac.com/mkino2/backnumber/2003_11.html#November%2024_1
↑やっぱりCだよ、C！という意見。

やっぱり基本はCだと思うね。HyperTalkの動作も
裏でCが動いているイメージがあれば理解しやすい。

Cの動作はアセンブリ言語が分かれば理解しやすくて、
アセンブリ言語は論理回路が・・・とは続かない。

Cで事実上最高のパフォーマンスを出せるし、
巨大なアプリを構築できる実績があるから。

悪い部分もあるけど、それはCをやってからのお話。
25：ぷご：2003/12/22(月) 00:00: XcodeでnibベースではないCarbonアプリケーションは
新規プロジェクト作成できないようだ。

えーい、無理矢理作ったれ！
26：ぷご：2003/12/30(火) 12:13: Carbonでゲーム作成中。

メモ。
GWorldの領域がVRAMに取られるかメインメモリに取られるか
分からないので、useLocalHdwrMemでメインメモリに取る事で
半透明などの動作は速くなる、と。
27：ぷご：2003/12/30(火) 15:35: 構造体のメンバの順番。
Pointがv,h
Rectがtop,left,bottom,rightの順番になっている。

HyperCardからの移植がやりにくいなぁ。
28：ぷご：2003/12/30(火) 15:37: >27
Carbon以前から、そうなんだけどね。今気づいた。
昔の僕は構造体の初期化を使ってなかったんだなぁ。
29：ぷご：2004/01/03(土) 21:53: クイックターイム！
たしかpugoGLで使ってたのでコピーしてくる。
動かねぇ。インクルードファイルが足りないようだ。
<QuickTime/QuickTime.h>をincludeする。
関数が無いとか言いやがる。ちきしょう。
プロジェクトにQuickTimeのFrameworkを追加する。
これでOKだった。

またそのうち忘れたときに見直せるようにメモ。
30：ぷご：2004/01/12(月) 12:48: ＜実行環境＞
Classic(CFM)：OS9.xとそれ以前、OSXのClassic環境で動作。C,C++などで開発。CW,MPW
Carbon(CFM)：OS8.1～OS9.x、OSXで動作。C,C++などで開発。CW,MPW
Carbon(Mach-O)：OSXで動作。C,C++などで開発。CW,PB
Cocoa(Mach-O)：OSXで動作。Objective-CかJavaで開発。PB
なお、CocoaとCarbon(Mach-O)は併用可能。
＜グラフィックAPI＞
QuickDraw：初期Macからの2DグラフィックAPI群。Classic,Carbon。
Quartz/CoreGraphics：OSXでの2DグラフィックAPI群。CocoaとかCarbonに関係ない、ベースの部分。
OpenGL：OSXでの3Dグラフィック環境。WIn,Unixでも動作。OS9以前だと互換ライブラリを使用出来る。
　　　　　OSXで3Dのアクセラレータを有効にするにはこれを使うしか無い。
＜ライブラリ（参考）＞
SDL：Mac,Win,Unixで互換性があるグラフィックライブラリ。よく知らないけど。
GLUT：OpenGLを簡単に扱えるようにして、マウス、キーなどの各種APIも
　　　　取り込んでMac,Win,Unixで互換性がある。これもよく知らないけど。

Classic-QuickDraw：OS9.x以前、Classic環境
Carbon-QuickDraw：OS8.1～OSX
Carbon-Quartz：OSX
Carbon-OpenGL：OSX、互換ライブラリでOS9以前も可。
Cocoa-Quartz：OSX
Cocoa-OpenGL：OSX

OS9以前を考えると、Carbon-QuickDraw、Carbon-OpenGLかな。
ゲーム作るならQuartzよりOpenGLのほうが楽そう。
作るのが2Dのゲームにしても。

僕はなんだかQuickDrawに親しみすぎてしまったな・・・。
ゲーム以外では使うのがためらわれるのでOpenGLは
敬遠していたけど、これからFinderすら3Dになるような気もするので、
OpenGLに移ろうかな。
31：ぷご：2004/01/18(日) 15:15: 訂正
CodeWarriorでもMach-Oで開発可能。
32：ぷご：2004/02/04(水) 22:28: Appleは何かと宣伝うまいよなぁ。
Xcodeにしろ、Cocoaにしろ、実際はそんなに大した事は無いし。
それなのにいかにも凄いように見せる。

Carbonもわりといい環境なんだよぉ。MPWも使いこなせば何かと役に立つし。
MacBeat Carbonもデバッグ時はXcode、コンパイル時はMPWとすることで、
ZeroLinkで公開して中身空っぽという失敗を防げるし、、、。
33：ぷご：2004/02/17(火) 22:53: MMO・SRPGでも作ってみたいなぁ。
来年にはサーバ環境ができるので（もう来年の話？）
構想でも暖めておきますかね。

Carbon版HyperCard構想と同じような暖め方ね。
作りたいけど作れないという。考えるのが面白い。
34：ぷご：2004/02/17(火) 23:03: サーバはMacOSXマシン。今使ってるiBookにでも入れれば電力は安くつく。
デスクトップのG5でも買って開発マシンとする。
回線は光。本気でやるなら２回線引くもよし。（金持たんかな・・・）

サーバ、クライアントともにCarbon、OS9でも動作する。
Mac専用部分は別ファイルに分けた作りになるので移植も可能。
Cocoaで作るとそうはいかない。Carbonのメリットとする。
使用言語は単なるC言語。ソースはフリーで。