ゲームプログラムなら俺に聞け5

1 ：デフォルトの名無しさん：2010/02/28(日) 02:00:18

ゲーム開発に関してプログラムの観点からアプローチするスレッドです。
一応質問も受け付けます。

【前スレ】
ゲームプログラムなら俺に聞け4
http://pc12.2ch.net/test/read.cgi/tech/1255833802/

【過去スレ】
ゲームプログラムなら俺に聞け
http://pc12.2ch.net/test/read.cgi/tech/1230890476/
ゲームプログラムなら俺に聞け2
http://pc12.2ch.net/test/read.cgi/tech/1247292664/
ゲームプログラムなら俺に聞け3
http://pc12.2ch.net/test/read.cgi/tech/1251324391/

2 ：デフォルトの名無しさん：2010/02/28(日) 02:07:59

>>1乙

3 ：デフォルトの名無しさん：2010/02/28(日) 02:46:58

前スレの>>956
ポリシークラスとか共通のメソッドを関数化とか
テンプレート使えば解決するけどまだ先の話じゃね
今は研究より動くの作ってほしい

4 ：デフォルトの名無しさん：2010/02/28(日) 02:48:34

>>前996
>>作りがいのあるプログラミング初級者向けのゲームって無い？

パイプドリーム（水道管ゲーム）は、作るのが難しくなくて、自分で
プレイしてもそこそこ面白いのでオススメ

http://members.chello.at/theodor.lauppert/games/pipe.htm
ここにも、初心者でも作れるみたいなことが書いてあるし

5 ：デフォルトの名無しさん：2010/02/28(日) 03:31:04

難しそうだな

6 ：デフォルトの名無しさん：2010/02/28(日) 03:35:44

彼はオセロを選択したようですよ＾＾

7 ：デフォルトの名無しさん：2010/02/28(日) 08:27:52

>>4
懐かしいなw

8 ：デフォルトの名無しさん：2010/02/28(日) 09:47:13

ゴルバチョフもいまや世界一受けたい授業に出るような時代だからな

9 ：デフォルトの名無しさん：2010/02/28(日) 10:21:10

スマスマになんでゴルは出てたの？

10 ：デフォルトの名無しさん：2010/02/28(日) 11:27:37

C++で書いた将棋ゲームで、オンライン対戦可能にしたいが、
それらの知識が皆無で、どの順に習得していけばいいか教えて下さい

11 ：デフォルトの名無しさん：2010/02/28(日) 11:48:31

ググれ

12 ：デフォルトの名無しさん：2010/02/28(日) 12:06:10

「こんなのの将棋版」みたいな例くらい提示しろよ。

13 ：デフォルトの名無しさん：2010/02/28(日) 12:39:32

>>10
おまいら最強の将棋プログラムしてみろよ part7
http://pc12.2ch.net/test/read.cgi/tech/1219297117/

14 ：デフォルトの名無しさん：2010/02/28(日) 12:57:33

>>10
Winsock2

15 ：デフォルトの名無しさん：2010/02/28(日) 13:09:56

>>10
ネットワークプログラミング相談室 Port25
http://pc12.2ch.net/test/read.cgi/tech/1255459388/

16 ：デフォルトの名無しさん：2010/02/28(日) 13:49:20

完全なロールプレイで
ＮＰＣは案内役とイベント役だけ
武具を作るジョブとか消費アイテム作るジョブ
各プレーヤーはそれらを作るための素材を集める
モンスター倒すなり拾い集めるなりして
ただ、通常のプレーヤーは素材が材料として使えるか判断できなくて
鑑定専門のジョブとか用意して
各ジョブはジョブレベルが設定されていてレベルが上がらないといい物作れない
また、自由に何度もジョブを途中変更できる
戦闘のプロとして戦士とか魔法使いのジョブがあって

17 ：デフォルトの名無しさん：2010/02/28(日) 13:53:44

ジョブ変更後も能力とか引継ぎされると
ただ各ジョブを極めるためにはかなりの修練が必要で
ちょくちょくジョブ変えてると結果的にどれも中途半端なものになってしまうくらいの修練
商人のジョブも用意して
武具ややアイテムを買い取ったり売ったりできたり
盗賊ジョブでダンジョンのトラップ解除や鍵開けとかできたり
戦闘で功績をあげると、国の騎士とかになれたり
国の騎士のイベントとして、国対国の騎士同士の乱戦イベントとかあったり

18 ：デフォルトの名無しさん：2010/02/28(日) 13:57:19

回復とかは、アイテムでの回復のほかに、魔法使いに依頼して（金払って）回復という手段とかもあったりとか

19 ：デフォルトの名無しさん：2010/02/28(日) 14:02:48

で？

20 ：デフォルトの名無しさん：2010/02/28(日) 14:12:36

というゲームを作ってください

21 ：デフォルトの名無しさん：2010/02/28(日) 14:55:45

そんなハイレベルなゲームは
最高のゲーミングマシンを組んでも実現不可能だから諦めろ

おまえはまるでセガの様に時代を先取り過ぎるんだよ

22 ：デフォルトの名無しさん：2010/02/28(日) 14:58:06

妄想系はスルーで

23 ：デフォルトの名無しさん：2010/02/28(日) 17:46:16

>>16
完全なロールプレイなら、ジョブとか必要なくて各人のプレイに任せればいいのでは？

24 ：デフォルトの名無しさん：2010/02/28(日) 17:55:34

だいたい「職業は？」
「戦士です」
ありえねーｗｗｗ

25 ：デフォルトの名無しさん：2010/02/28(日) 18:01:19

みなさん
何日くらいでプログラム習得しました？

26 ：デフォルトの名無しさん：2010/02/28(日) 18:11:43

融通の利くテーブルトークが最強だな
つまりゲームプログラムなんて要らんかったんや！

27 ：デフォルトの名無しさん：2010/02/28(日) 18:19:28

>>25
2週間で言語の基本的な構文を覚えて、更に1週間で2Dの簡単なゲームを作った。
どのレベルまで習得するのかにもよるけど最初はこんな感じだった。

28 ：デフォルトの名無しさん：2010/02/28(日) 18:26:07

そうですか
ありがとうございます
もう２週間たつけど難しいっすね・・

29 ：デフォルトの名無しさん：2010/02/28(日) 18:28:24

>>25
３日

30 ：デフォルトの名無しさん：2010/02/28(日) 18:35:33

向き不向きがあるんですかね
やっぱ理系っぽいほうがいいのかな

31 ：デフォルトの名無しさん：2010/02/28(日) 18:41:30

プログラムはガキの頃から英才教育しないとダメ

32 ：デフォルトの名無しさん：2010/02/28(日) 20:05:20

言語って覚えるものじゃない。
コンパイラインストールしてhello world実行したときから始まるんだ。

33 ：デフォルトの名無しさん：2010/02/28(日) 20:33:13

初めての定番がhello worldだとすると、
1日目の締めの定番はじゃんけんゲームだよな

34 ：デフォルトの名無しさん：2010/02/28(日) 20:59:30

>>33
脳味噌の期限が切れてるな

35 ：デフォルトの名無しさん：2010/02/28(日) 21:07:36

>>33
そんなに簡単に作れたのか？
羨ましいｗ

36 ：デフォルトの名無しさん：2010/02/28(日) 21:13:56

>>33
友達いないでしょ

37 ：デフォルトの名無しさん：2010/02/28(日) 21:39:13

>>30
多少の適正はあるかもしれないけど初級レベルならほとんど関係ないよ。
2Dのミニゲーム程度なら誰にでも作れる。
HSPプログラムコンテストで最優秀小学生賞というのが用意されているくらいなので・・・

38 ：デフォルトの名無しさん：2010/02/28(日) 21:42:44

>>37
さては小学生のふりをして応募したなｗ

39 ：デフォルトの名無しさん：2010/02/28(日) 21:46:22

今や小学生でもプログラミングをする時代になったということだよ。

40 ：デフォルトの名無しさん：2010/03/01(月) 00:47:47

というか、それは昔からというか。
小学生がBASIC +Z80マシン語でゲームプログラミングというのはわりと逸般的だった。

41 ：デフォルトの名無しさん：2010/03/01(月) 00:52:13

ベーマガに投稿する小学生とかいたしな

42 ：デフォルトの名無しさん：2010/03/01(月) 00:54:54

>>40
小学生でタイニーゼビウスっていうのはたしかに逸般的かもｗ

43 ：デフォルトの名無しさん：2010/03/01(月) 01:08:20

逸般的って何だよと思ってググったら通信用語かよ・・・

44 ：デフォルトの名無しさん：2010/03/01(月) 03:28:48

ギョーカイ人多いねココ

45 ：デフォルトの名無しさん：2010/03/01(月) 05:20:33

ギョーカイ人？いいえ、逸般社怪人です。

46 ：デフォルトの名無しさん：2010/03/01(月) 08:05:15

ROM-BASIC の頃は、BASIC のリファレンス見て一通り使ってみたら
ひとまずなんかプログラムしたって感じがした。

今頃の人で C から始めると、構造体やってポインタやって、って、
なんの役に立つのかも分からず達成感が得にくそうに思う。

俺が小学生の頃にアセンブラやったときが、そんな感じだった。
「一通りニモニック使ってみたけど、そんでどうやって画面に何か描くの？」
って。
VDP なるものを知るのは高校に入ってからだった。

47 ：デフォルトの名無しさん：2010/03/01(月) 08:16:41

>>46
PC-9801 なら BASIC 側で初期化して VRAM に何か書いてやれば絵が見えたな。
あの敷居の低さは良かったと思う。

48 ：デフォルトの名無しさん：2010/03/01(月) 10:42:01

HSPあたりで手軽に達成感が得られるでしょ
むしろ今の時代のほうが情報が簡単に手に入るから昔よりずっと楽

49 ：デフォルトの名無しさん：2010/03/01(月) 11:00:34

多すぎる情報は初心者には毒でしかなかったりする

50 ：デフォルトの名無しさん：2010/03/01(月) 11:08:03

目的もなしに漠然といじるだけじゃ、モノがなんだろうと達成感なんてないと思うがね。

>>49
なんで、俺は今でも結構本買うよ。よくも悪くも取っ掛かりになるからね。
後で悪例だったと知るのもまた勉強。

51 ：デフォルトの名無しさん：2010/03/01(月) 11:55:39

プログラムってこんな感じなんだってのは一日でわかった
それなりの規模の2Dシューティング作るには半年くらいかかった

52 ：デフォルトの名無しさん：2010/03/01(月) 12:37:14

オブジェクト間の通信のやり方ってどうやってんだ
各オブジェクトがすべてのオブジェクトのリストへの参照を持ってるの？
それとも管理者か何か用意して、今ゲームルール的に通信可能なオブジェクトを毎回検索してイテレータで返すとかしてるの？（シューティングだったら接触しているのを検索、とｋ）

53 ：デフォルトの名無しさん：2010/03/01(月) 13:24:27

ゲーム製作始めるならこれ、という王道が今の時代は適当なのが見当たらないな
Cと画面周りを同時に始めるのは敷居高いわ

54 ：デフォルトの名無しさん：2010/03/01(月) 19:55:08

>>47
お年寄りの偉そうな態度は禁止です

55 ：デフォルトの名無しさん：2010/03/02(火) 20:58:13

復帰あげ。

56 ：デフォルトの名無しさん：2010/03/02(火) 21:25:01

サイバーテロシミュレーションゲームとかどうか

57 ：デフォルトの名無しさん：2010/03/02(火) 21:50:03

電線っぽいのがはりめぐらされていて
そこ辿ってくる光の玉（サイバーテロ）がやってくるから
目標位置のとこのパソコンに撃退プログラムをセットするとか

58 ：デフォルトの名無しさん：2010/03/02(火) 22:12:22

>>52
どっちでもいいよ。
ただ、リストに登録されている順番によって結果が変わるような処理に
なってると後々面倒だったりする。
だから、システム側がオブジェクト間のインタラクションを一括で調べて、
その結果をオブジェクトに通知するような感じのほうが良い。

59 ：デフォルトの名無しさん：2010/03/02(火) 22:49:56

>>52
オブジェクトが他のオブジェクトを直接参照するのは止めた方が良い。
依存関係が増えると複雑になってバグの原因になり易いので。

60 ：デフォルトの名無しさん：2010/03/03(水) 00:42:06

こういう話題でなぜコード書かないのか

61 ：デフォルトの名無しさん：2010/03/03(水) 00:49:25

非オブジェクト指向からオブジェクト指向へ移行経験ある人いる？
オブジェクト指向ってやっぱ便利？昔より作りやすい？
あ、でもそんなに昔からプログラミングしてる人って稀少か
オブジェクト指向ってもう20年以上ありそうだし

62 ：デフォルトの名無しさん：2010/03/03(水) 01:29:41

Ｃでオブジェクト指向でかけるような人はほとんどいなかった。
コンシューマー機でＣ++が浸透したのは１０年前くらいからだと思う。
CからC++に移行して便利になったか？おれはかなり否定的。

63 ：デフォルトの名無しさん：2010/03/03(水) 02:39:27

クラスとかのC++で良く使う機能をCで実装・使用してみると、C++でよかったでござるってなる
まあ出来ること増えてんだから間違った使い方しなきゃ普通に便利になるよ

64 ：デフォルトの名無しさん：2010/03/03(水) 03:43:27

Ｃ++はクラス設計がムズイよね

65 ：デフォルトの名無しさん：2010/03/03(水) 07:36:35

ですね

66 ：デフォルトの名無しさん：2010/03/03(水) 07:51:54

自由度が高いのはバグを生むもとでもあるんだよね

67 ：デフォルトの名無しさん：2010/03/03(水) 08:15:12

>>61
今でもC言語で始めてC++に移行する人は多いよ。
オブジェクト指向は理解するのに時間かかるけど、一度覚えてしまえばもうC言語に戻ろうとは思えないよ。

68 ：デフォルトの名無しさん：2010/03/03(水) 10:14:03

きちんとしたお作法を学べばむしろバグは減る

69 ：デフォルトの名無しさん：2010/03/03(水) 10:24:43

さらに極めるとオブジェクト指向などまったく無意味なことに気づく

70 ：デフォルトの名無しさん：2010/03/03(水) 10:39:35

特に意味は無いのだが非visualStudio（要はgcc）でC++開発する際の鉄板フレームワークについて教えてくれ。
SDLとOpenGL？を使うのが一般的なのか？　もうちょっと楽なライブラリとかあれば。

71 ：デフォルトの名無しさん：2010/03/03(水) 10:43:53

自作最強伝説

72 ：デフォルトの名無しさん：2010/03/03(水) 10:48:09

>>70
まずフレームワークの意味が違う

73 ：デフォルトの名無しさん：2010/03/03(水) 11:01:48

>>70
一般的って意味が判らない
需要ってことなら普通はVisualStudioで開発すんじゃないの？
gccなんてドマイナーな非MS-OSの組み込み用途ぐらいしか出番ないっしょ
動画とか扱い出したらSDLなんか使ってられんよ

74 ：デフォルトの名無しさん：2010/03/03(水) 11:04:11

>>73
gccがドマイナーって、よほどのド素人だな

75 ：デフォルトの名無しさん：2010/03/03(水) 11:07:44

>>74
べつにgcc自体がドマイナーとは言ってないけど
gccで使えそうな環境見つけられないんだろ？
gccじゃ誰もやってないんだよ

76 ：デフォルトの名無しさん：2010/03/03(水) 11:10:22

>>70
OSは何なの？
非VisualStudioってことはウィンドウズじゃないってこと？

77 ：デフォルトの名無しさん：2010/03/03(水) 11:11:29

>>75
お前の世間は狭いな、無知とは恐ろしい
お前はどうせC#しかできないカスなんだろうけど

78 ：デフォルトの名無しさん：2010/03/03(水) 11:12:43

じゃあ70に教えてやれよｗ
知らんよ俺は

79 ：デフォルトの名無しさん：2010/03/03(水) 11:21:07

自作最強伝説

80 ：デフォルトの名無しさん：2010/03/03(水) 11:23:46

>>76
OSは窓だけどIDEがnetbeansとかeclipse。
こーいう環境で開発するにゃどーいうのをそろえればいいのやら。

81 ：デフォルトの名無しさん：2010/03/03(水) 11:30:30

>>80
コンパイラとエディタ用意すりゃいいだろ

82 ：デフォルトの名無しさん：2010/03/03(水) 11:40:26

>>80
窓なら素直にVS使っとけよ
gccで何週間掛かっても無理なことが一瞬で終わるから

83 ：デフォルトの名無しさん：2010/03/03(水) 11:43:59

vsで開発してgcc併用でいいじゃない

84 ：デフォルトの名無しさん：2010/03/03(水) 12:37:42

gcc(mingw)の問題点は最新のSDKを使うのに作業が必要な場合が多い事(普通の人なら何週間も掛かったりはしない)
VisualC++の問題点はx64でインラインアセンブラを使えない事
どちらもゲーム開発分野であまり問題になるとも思えない
最適化は得手不得手があるのでintelC++等も含めて使い分けるといい

85 ：デフォルトの名無しさん：2010/03/03(水) 12:48:01

そういえば俺にも、3DならOpenGLだろ(ｷﾘｯ
みたいな頃があったな
アンチMSな俺カッケー

86 ：デフォルトの名無しさん：2010/03/03(水) 12:51:20

DirectXは？

87 ：デフォルトの名無しさん：2010/03/03(水) 14:27:02

カーマックはまだOpenGL使ってんのかね

88 ：デフォルトの名無しさん：2010/03/03(水) 14:36:51

WinG

89 ：デフォルトの名無しさん：2010/03/03(水) 15:15:31

別にmingwでもDierctXは使えるが

90 ：デフォルトの名無しさん：2010/03/03(水) 15:21:22

ここって本職・副職でやってる人と完全に趣味でやってる人とどっちが多いんだろうね

91 ：デフォルトの名無しさん：2010/03/03(水) 15:22:08

学生の部活れす

92 ：デフォルトの名無しさん：2010/03/03(水) 15:25:33

下手にgcc使うアホ学生は、ライセンス関係で地雷を踏む。

93 ：デフォルトの名無しさん：2010/03/03(水) 15:27:18

完全に趣味です
良い出来のものはフリーで公開したいくらいです
しませんが

94 ：デフォルトの名無しさん：2010/03/03(水) 15:27:28

ライセンスは良く分からんよね
いろいろあって何が何だか

95 ：デフォルトの名無しさん：2010/03/03(水) 15:36:37

ライセンス規約読むの面倒だから適当に同意しちまった

96 ：デフォルトの名無しさん：2010/03/03(水) 15:44:40

MinGWのランタイムはただのMSVCRTラッパ+αでPublic Domainだぞ
どんな妄想ライセンスに同意したんだ?

97 ：デフォルトの名無しさん：2010/03/03(水) 15:46:00

キミが想定してるのはそれだけなのかい？

98 ：デフォルトの名無しさん：2010/03/03(水) 15:56:14

仕事でやってようが趣味でやってようが
ライセンス無視するような奴は許せない

99 ：デフォルトの名無しさん：2010/03/03(水) 15:56:22

VisualStudioと比較するなら他にはあるまい

100 ：デフォルトの名無しさん：2010/03/03(水) 16:43:43

>>70
グラフィックAPIはWindowsではDirectX、それ以外ではOpenGLが主流。
ゲームライブラリは海外ではIrrlichtとOrgeが人気らしい。
国内では自作してる人が多いので主流と呼べるものは無いけどDXライブラリとSeleneが頑張ってるかな。
何か勘違いしていそうだけどどのIDEでも使えるよ。
ちなみにIDEはVisualStudioが主流です。

101 ：デフォルトの名無しさん：2010/03/03(水) 16:49:16

winならDirectXが鉄板

102 ：デフォルトの名無しさん：2010/03/03(水) 16:49:57

俺はあえてWinGを使うWindows3.1ユーザー

103 ：デフォルトの名無しさん：2010/03/03(水) 16:59:17

2dなら黙ってgdi

104 ：デフォルトの名無しさん：2010/03/03(水) 19:51:29

2Dゲーでも動きがあるゲームならD3Dを使った方が綺麗になるんじゃないの

105 ：デフォルトの名無しさん：2010/03/03(水) 21:36:37

Seleneっていうのは初めて聞いた
dxlibは信者が必死に布教してるからどこでも名前見るけど

106 ：デフォルトの名無しさん：2010/03/03(水) 21:47:32

むしろD2D使えば？
GDIの代わりなんでしょこれ？

107 ：デフォルトの名無しさん：2010/03/03(水) 22:25:32

Seleneはなあ・・・

108 ：デフォルトの名無しさん：2010/03/03(水) 22:27:18

やっぱりOSを止めてVRAMつかうのが一番だよね

109 ：デフォルトの名無しさん：2010/03/03(水) 22:48:35

だったら別にSDLでもええやん

110 ：デフォルトの名無しさん：2010/03/03(水) 22:56:04

男は黙ってCUI
ゲーム性で勝負ですよ

111 ：デフォルトの名無しさん：2010/03/03(水) 23:54:32

>>110
star trekを復刻するのかYo!

112 ：デフォルトの名無しさん：2010/03/04(木) 00:47:57

ゲームライブラリはAllegroでいい。
あれをVisualStudioからVisualC++で使う。
Windowsはそれで万全。

113 ：デフォルトの名無しさん：2010/03/04(木) 09:36:39

>>112
他の言語やOSに移行することを考えるとその選択肢はないし、
逆に移行しないならDirectXの機能をバリバリ使ってるようなものを選んだほうがよいような

要するに半端モノ

114 ：デフォルトの名無しさん：2010/03/04(木) 11:06:49

普通はDirectX覚えてからゲーム作り始めるもんなの？

115 ：デフォルトの名無しさん：2010/03/04(木) 11:20:31

トップダウンとボトムアップ。両方からのアプローチが必要

116 ：デフォルトの名無しさん：2010/03/04(木) 11:40:50

>>113
> 他の言語やOSに移行することを考えるとその選択肢はないし、
他の言語という事を考えた時には、VB.NETやC#という選択肢もでてくる。
他のOSに移行する事を考えても、ソースコードレベルで互換性を維持できる。
十分ありうる選択肢だよ。

117 ：デフォルトの名無しさん：2010/03/04(木) 13:29:24

directxで微妙なのは、結果を引数で返したり
意味わからんnull指定が多いこと
自分で全てまかないたいならGLがいい
面倒だからdirectxで始めたけど、結局ほとんど自分で用意してしまったわ

118 ：デフォルトの名無しさん：2010/03/04(木) 13:38:52

C言語脳

119 ：デフォルトの名無しさん：2010/03/04(木) 13:49:47

>>117
あるあるｗ結局理解できる形にWrrapしたり、独自関数を作ってしまう

120 ：デフォルトの名無しさん：2010/03/04(木) 13:59:11

でもOpenGLってすっとろいんだろ？ゲームに使えるの？

121 ：デフォルトの名無しさん：2010/03/04(木) 14:11:07

OpenGLもDirectXもGPUをどう操作するかのインターフェースに過ぎん。
すっとろいかどうかは結局GPUに依存しちまうのであんまり議論する意味は無い。

122 ：デフォルトの名無しさん：2010/03/04(木) 14:33:34

ふーん
じゃあ移植性の低いDirectXを皆が使う理由は何なの？

123 ：デフォルトの名無しさん：2010/03/04(木) 14:37:17

windowsでゲームやるならgl使う理由は何も無い
情報やサンプルの量、ドライバの対応度、他諸々でd3dが全て勝ってる
今時ゲームにglを使うのは老害と極度のc++アレルギー持ちと俺みたいな変態だけ

124 ：デフォルトの名無しさん：2010/03/04(木) 14:42:34

>>122
オーサリングソフトとかで作ったモデルを直読みできるAPIが無いからだな…
directXはそこらへん優秀というか便利なAPIが沢山あるから、普通の開発者はDX選ぶ。

125 ：デフォルトの名無しさん：2010/03/04(木) 15:12:08

glも拡張ライブラリ使えば早い
だが環境依存する

生のポインタ渡したくない人はDXは向いてない
ストレスが溜まる

126 ：デフォルトの名無しさん：2010/03/04(木) 15:19:49

そんなのでストレス溜まるとか繊細すぎる
もはやC言語扱うのに支障が出るレベル

127 ：デフォルトの名無しさん：2010/03/04(木) 15:23:34

>>126
こうなったらバグ、ああなったらバグで心労が半端ないんです

128 ：デフォルトの名無しさん：2010/03/04(木) 15:37:27

>>123
極度のc++アレルギーだからといってOpenGLを使う理由は何も無い
->lpVtbl->

129 ：デフォルトの名無しさん：2010/03/04(木) 16:02:49

>>128
エラー privateを参照できません

130 ：デフォルトの名無しさん：2010/03/04(木) 16:16:59

>>114
C/C++には標準の描画機能は無いので何かしらの描画APIが必要になる。
必然的にDirectXもしくはOpenGLを覚えながらゲームを作ることになるよ。

一昔前まではC++/DirectXの組み合わせが定番だったけど、最近はiPhoneやブラウザゲームも普及してきて状況は少し変わってきた。
WindowsでもC++では生産性が悪いということで他の言語が使われたり、ゲームエンジンが使われることも増えてきたし。

131 ：デフォルトの名無しさん：2010/03/04(木) 17:19:07

DirectXは名前の入力が大変だからXNAでやってる

132 ：デフォルトの名無しさん：2010/03/04(木) 20:17:12

CGソフトのアニメフレームにアニメパターン付きのキャラを配置するように
ポトペタで最初のプログラムが出来上がればいいのに・・・・
どれもこれも関数ばっか増やしてわけわからん

133 ：デフォルトの名無しさん：2010/03/04(木) 21:04:07

DirectXのよくないところは、
次々にAPIをフルモデルチェンジしちゃうところかなー
>>132のいうところも同じだろうし
確かに、GLのような変えないことによる弊害もよくわかるんだが・・

ああでも、XP+D3D9は寿命長くて良かったかな
こんぐらいのペースならいいかなぁ

134 ：デフォルトの名無しさん：2010/03/04(木) 21:17:53

>>132
その要求を叶えてくれるのがゲームエンジン。
UDK、Unity、TorqueGameEngine、Gamebryo、CryENGINE、etc...
あとFlashで作るという手もあるな。

135 ：デフォルトの名無しさん：2010/03/04(木) 21:21:22

2Dも3Dもupdateとrender繰り返すのが基本なの？

136 ：デフォルトの名無しさん：2010/03/04(木) 21:23:22

>>135
そうです。

137 ：デフォルトの名無しさん：2010/03/05(金) 01:00:28

javaでゲーム作ってる人っている？javaって使いやすい？

138 ：デフォルトの名無しさん：2010/03/05(金) 01:31:13

お前にはムリ

139 ：デフォルトの名無しさん：2010/03/05(金) 06:12:02

ひどいお(´；ω；｀)ﾌﾞﾜｯ

140 ：デフォルトの名無しさん：2010/03/05(金) 08:25:24

>>137
C#>Java>>>>>>>>>>C++
使い易さの比較はこんな感じかな。
Javaが使い易かったと言うよりはC++の生産性の悪さを再確認した。

選択肢としては十分ありだとは思うけど少し注意しないといけないこともある。
・パフォーマンスはVMの性能に大きく左右されるので注意。（最近はどの環境でもかなり高速化しているが）
・PureJava環境では当然ながらC++のライブラリは使えないので注意。
・ガーベージコレクションの扱いには慣れが必要。
・演算子のオーバーロードがサポートされていない。
・Windows環境ならJavaよりもC#の方が良い。

141 ：デフォルトの名無しさん：2010/03/05(金) 08:26:29

>>140
C#は糞
http://pc12.2ch.net/test/read.cgi/tech/1246520657/

142 ：デフォルトの名無しさん：2010/03/05(金) 08:50:03

まあ、実行速度最速はC++だけどね

143 ：デフォルトの名無しさん：2010/03/05(金) 09:07:49

メモリモデルに柔軟性があるのがC++だけってのが一番大きい。
それ以外はあまりいいともいえない。速度は気にならない状況も多い。

144 ：デフォルトの名無しさん：2010/03/05(金) 10:28:53

実用的で速度が速いのはアセンブラである
Cでもオーバーヘッド、速度あげるところはインラインアセンブラ使用するだろ
C++はCよりオーバーヘッドでかいし、C++とか言ってるやつは素人

145 ：デフォルトの名無しさん：2010/03/05(金) 10:33:51

アセンブラってCPU違うと動かないんじゃないの？

146 ：デフォルトの名無しさん：2010/03/05(金) 10:39:16

iphoneをみろよ
今時C++なんか使ってるのはマヌケだけｗ

147 ：デフォルトの名無しさん：2010/03/05(金) 10:42:19

Objective-Cだっけ？

148 ：140：2010/03/05(金) 10:46:30

http://ja.wikipedia.org/wiki/Java%E3%81%AE%E6%80%A7%E8%83%BD
ベンチマークによるとC/C++より5～15％ほど遅いらしいけど、経験上ではJavaが遅いと感じたことは一度も無いよ。
その程度のオーバーヘッドで問題になるようだとほとんどのPCで動かなくなってしまうので。
それにゲームでボトルネックになり易いのは描画部分なので言語よりもGPUの方が重要になる。

149 ：デフォルトの名無しさん：2010/03/05(金) 10:50:10

C#は糞だが、今やハード面考慮してJavaが遅いなんてこともないし、
マルチプラットフォームで考えればJavaもいいだろう

150 ：デフォルトの名無しさん：2010/03/05(金) 10:54:00

HSP→Java→C#

151 ：デフォルトの名無しさん：2010/03/05(金) 11:55:47

>>144
Cでオーバーヘッド？何が？
C++がCより遅い？なんで？

使い方間違ってるか、うまいコードの書き方を知らなくて
遅くなってるのを言語のせいにしてるだけだろ。

152 ：デフォルトの名無しさん：2010/03/05(金) 12:01:11

今時インラインアセンブラとか言ってるのはエロゲ屋だけ

153 ：デフォルトの名無しさん：2010/03/05(金) 12:01:16

後段には同意だが、前段は無知のオンパレードだな

154 ：デフォルトの名無しさん：2010/03/05(金) 12:16:10

一般的にはCよりC++の方が早い。
テンプレートによるインライン化が効果的だから。

でもコードがどうアセンブラに落ちるのかを想像できない奴が結構いる。
自分のコードが遅いのを、C++のせいにするのがいつもの奴らのパターン。
あいつらコピーコンストラクタがいつ呼び出されるのかも把握せずに書いてるからな。

155 ：デフォルトの名無しさん：2010/03/05(金) 12:21:20

アフォばっかだな
ゲーム開発したことない奴ばっかだな
T10000においてPS2の開発ならCのが断然効率いい

まさか素人共はDirectXなんかをあてにしてんじゃないだろうｗ

156 ：デフォルトの名無しさん：2010/03/05(金) 12:24:09

Javaとか、さくっと起動できないのは辛いよ

157 ：デフォルトの名無しさん：2010/03/05(金) 12:28:32

即起動できるPCゲームなんか稀だけどな

158 ：デフォルトの名無しさん：2010/03/05(金) 12:29:16

ps2開発で玄人っすかｗ

159 ：デフォルトの名無しさん：2010/03/05(金) 13:06:25

>>155
ネタじゃないなら「Cのが断然効率いい」理由を教えてください。

160 ：デフォルトの名無しさん：2010/03/05(金) 13:08:38

PS2のライブラリを作った人間は
それはそれで苦労人(くろうと)ではあるだろうな

161 ：デフォルトの名無しさん：2010/03/05(金) 13:48:21

今時のゲームエンジンはどれもC++で書いてあるだろ。
詳しくは書けないけど某大手の社内用エンジンもC++だったし。
CEDECでもC++で書かれたスライドがばんばん出てくる。

162 ：デフォルトの名無しさん：2010/03/05(金) 13:55:28

C++のが早いって言ってるカスはエセプログラマ

163 ：デフォルトの名無しさん：2010/03/05(金) 14:12:21

持論を展開するのは自由だけどソースも貼らない説明もしないのではただの煽りですよ。

164 ：デフォルトの名無しさん：2010/03/05(金) 14:18:44

C++（が必要になる規模のプロジェクト）よりもC（で済むぐらいのプロジェクト）のほうが
（完成が）早い。（実行速度が「速い」わけではない。）

こうですかね！？わかりますん。

165 ：デフォルトの名無しさん：2010/03/05(金) 14:30:23

同一人物なんだろうけどCを押してる人の文章が煽り丸出しで幼稚過ぎる

166 ：デフォルトの名無しさん：2010/03/05(金) 14:39:37

まぁ爆遅のqsortでも使ってりゃいいんじゃね？

167 ：デフォルトの名無しさん：2010/03/05(金) 14:53:06

ミリ秒で遅いから糞っていつの時代ですか

168 ：デフォルトの名無しさん：2010/03/05(金) 14:55:11

>>167
昔から 60 fps 出そうと思ったら 16 ms しかなかったと思うんですが、最近は違うんですかね？

169 ：未来人：2010/03/05(金) 14:56:52

時間圧縮使えば 20 ms だろうが 100 ms だろうが 60 fps に収まるだろｊｋ

170 ：デフォルトの名無しさん：2010/03/05(金) 15:03:07

>時間圧縮
スタンドの技みたいですね

171 ：デフォルトの名無しさん：2010/03/05(金) 15:09:46

ここ職業プログラマー多いのでつね

172 ：デフォルトの名無しさん：2010/03/05(金) 15:15:25

>>165
いちいち相手にしてるお前も、低能稚拙でどうしようもないカスだな

173 ：デフォルトの名無しさん：2010/03/05(金) 15:17:01

Win+VC++(DirectX)しか知らないアホプログラマ多すぎワロスｗｗｗ

174 ：デフォルトの名無しさん：2010/03/05(金) 15:22:09

趣味プログラマーなので他環境に興味ないっす

175 ：デフォルトの名無しさん：2010/03/05(金) 15:23:09

>>174
他環境に興味ないって時点で終わってるね
低能は底が浅い

176 ：デフォルトの名無しさん：2010/03/05(金) 15:25:14

俺が初めてC++で書いたのはPlayStation初代から。

俺もC++は遅いんじゃないかという偏見が最初はあったけど、
1年くらい使ってみて、C++の特性をちゃんと理解していなかっただけだったということが分ってきた。
ちゃんと特性を理解すればCに劣るところは何もない。

STLが使えるようになったのはここ数年だけど、STLはマジですごい。
機能が強力な上に高速でビビる。

しかし高速化が必要なのは全体ではごく一部。
そういうところだけアセンブラで書くけど、
大半はスピードより開発効率とか、流用性とかの方が重要。
だいたいスクリプト使ってる時点でパフォーマンスがたおちだし。

そういうわけでC言語を使う利点が１つも見いだせない。
速度が遅くて開発効率が悪いんだからいいところがない。

177 ：デフォルトの名無しさん：2010/03/05(金) 15:32:18

>>157
大型客船に無断乗船してその後麻薬でも逮捕された某元プログラマーがいてな・・・・
彼が健在なら今頃凶速OSとかコンパイラくらい世に出してただろうなぁ

178 ：デフォルトの名無しさん：2010/03/05(金) 15:38:33

なんか些細なことで興奮する奴がいるみたいね
仕事で鬱憤でも溜まってるの？

179 ：デフォルトの名無しさん：2010/03/05(金) 15:51:35

http://pc11.2ch.net/gamedev/
があるのに、このスレってなんであるの

180 ：デフォルトの名無しさん：2010/03/05(金) 15:56:16

大人になればわかる

181 ：デフォルトの名無しさん：2010/03/05(金) 16:00:13

そっちは主に素人さんの板だから。

182 ：デフォルトの名無しさん：2010/03/05(金) 16:03:02

職業プログラマー以外の質問禁止

183 ：デフォルトの名無しさん：2010/03/05(金) 16:38:26

仕様を満たせるﾌﾟﾛｸﾞﾗﾑであればCだろうがC++だろうが関係無い

184 ：デフォルトの名無しさん：2010/03/05(金) 16:50:13

もちろんフルアセンブラでも関係無い
コード保守なんか知ったことじゃ無い

185 ：デフォルトの名無しさん：2010/03/05(金) 17:37:45

じゃあプログラムしなくてよろしい

186 ：デフォルトの名無しさん：2010/03/05(金) 17:40:06

続編とかシリーズ化とかマルチプラットフォームとか展開しないと儲からないから
保守しないってこたぁねぇな。

187 ：デフォルトの名無しさん：2010/03/05(金) 17:51:58

>>144,151が発端でC言語とC++ではどちらの方が処理速度が速いのか？という話だったと思うが？

188 ：デフォルトの名無しさん：2010/03/05(金) 17:57:45

いいからお前らXNAやれよ。もしかしたら今後のデファクトスタンダードになるかもだし。

189 ：デフォルトの名無しさん：2010/03/05(金) 17:59:20

XNAってc++でつかえんの？

190 ：デフォルトの名無しさん：2010/03/05(金) 17:59:47

素人のレス禁止

191 ：デフォルトの名無しさん：2010/03/05(金) 18:07:43

XNA(笑)

192 ：デフォルトの名無しさん：2010/03/05(金) 18:15:24

XNA DirectX VC#

193 ：デフォルトの名無しさん：2010/03/05(金) 18:16:14

？

194 ：デフォルトの名無しさん：2010/03/05(金) 18:17:25

Xbox持ってないからイラネ
Wiiなら持ってる

195 ：デフォルトの名無しさん：2010/03/05(金) 18:18:41

Delphiでゲーム開発

196 ：デフォルトの名無しさん：2010/03/05(金) 18:24:34

？

197 ：デフォルトの名無しさん：2010/03/05(金) 18:30:48

WiiWareか

198 ：デフォルトの名無しさん：2010/03/05(金) 19:32:23

>>189
使えません。

199 ：デフォルトの名無しさん：2010/03/05(金) 20:35:02

有限状態機械ってあるじゃないですか
state_base *state = new state_a;
～
state_a->update(this);
～
ってやつ
これを使ってて思ったんですけど状態が重複する場合ってどうやってるんですかね？
例えば混乱状態と毒状態があったとして、混乱かつ毒を表現するにはどうするのか
愚直に「混乱かつ毒」という状態を新規につくるのか、それとも何らかの方法を使って混乱と毒を合成するのか・・・

200 ：デフォルトの名無しさん：2010/03/05(金) 20:50:47

普通にビットフィールド管理でいいんじゃないの
フラグが立ってたら追加処理入れる感じで
混乱毒以外にも加速とか凶暴化とか石化とか状態後付けもありえそうだし

201 ：デフォルトの名無しさん：2010/03/05(金) 21:05:11

それでもいいけどオブジェクト指向的にはenumをキーとしたbooleanのハッシュテーブルを持たせてやりたい。

202 ：デフォルトの名無しさん：2010/03/05(金) 21:41:23

混乱度や毒レベルとかの概念が入ることもある
ステートマシンで管理したら状態が膨れ上がる

203 ：デフォルトの名無しさん：2010/03/05(金) 23:29:28

どの言語使ってもいいけどメモリ管理が理解できない奴とは仕事しない

204 ：デフォルトの名無しさん：2010/03/05(金) 23:33:28

そんなやついねーよｗ

205 ：デフォルトの名無しさん：2010/03/05(金) 23:34:44

おまえが問題を理解してないことはわかった。

206 ：デフォルトの名無しさん：2010/03/06(土) 01:23:20

なあ、この下らないつまらない役に立たないスレで偉そうに講釈たれているやつって
わかったふりして他人をアホ呼ばわりしてるけどさ、あんたじゃあ今まで何作ったの？
そんなに人に偉そうに言えるぐらいすごいゲーム作ったの？
ど゜うせ理屈ばかりで全くゲーム作ったことがない、技術はあるけどやる気ない、アイデアない
でゲーム作れないとか、そんなやつばかりなんだろ？
ほんと、つまらない人間ばかり集まってるよな。

と、ゲーム開発の素人は思いましたよっと。

207 ：デフォルトの名無しさん：2010/03/06(土) 01:27:25

>>206
会社に入れば自分の手がけたゲーム名は出せないってことがわかるぜ

208 ：デフォルトの名無しさん：2010/03/06(土) 01:45:02

契約ですね

209 ：デフォルトの名無しさん：2010/03/06(土) 02:18:58

>>208
いや、契約なんてあってないようなもんだぜ
こればっかりは入らなきゃわからないだろうなぁ

とにかく自分の一存でこういう情報をどうにかできないってことだけはガチ

210 ：デフォルトの名無しさん：2010/03/06(土) 02:26:50

最新のドラクエスタッフか

211 ：デフォルトの名無しさん：2010/03/06(土) 02:50:08

ないようなものでも、あるんだよ
DQNはこれだから

212 ：デフォルトの名無しさん：2010/03/06(土) 02:50:51

>>199
そういうのはオートマトンの状態にしない。
『特定の状態の時はこの操作でコレが出るが、そうでないときは出ない』というようなのの時に使う。
呪文詠唱中とかダメージモーション中とか、この状態には移行できるけど、他には駄目、みたいなのをやる。

毒や混乱は、一般的にフラグで実装するべきだろう。
必要な時にフラグを見に行く。
行動決定の時に麻痺や混乱のフラグを判定し、一定時間毎（とかターンの切れ目とか）に毒のフラグを判定して、フラグに応じた処理を行う。

213 ：デフォルトの名無しさん：2010/03/06(土) 07:41:01

>>176
call時のthisポインタ分のレジスタがもったいないと思う事はたまにある

214 ：デフォルトの名無しさん：2010/03/06(土) 09:36:24

>>151
実装方法やコンパイラの最適化性能によって変わってくるので一概には比較できないけど、一般的に低水準言語であるほど速いコードが書ける。
マシン語>アセンブラ>C>C++>Java

CとC++のベンチマーク比較
http://shootout.alioth.debian.org/u32/c.php

C++がCより遅くなる原因としてはクラス化によるオーバーヘッドが大きいと思われる。
例えばスマートポインタは生ポインタよりも遅くなる。
http://hp.vector.co.jp/authors/VA022575/c/e/smtptr2.html

>>144とは別人なので同じ意図かどうかは分からないけど、簡単に説明するとこんな感じです。

215 ：デフォルトの名無しさん：2010/03/06(土) 10:00:43

知ってる単語だけのレスでここまで意味不明にできるお前らはすごすぎ

216 ：デフォルトの名無しさん：2010/03/06(土) 11:42:23

つうかゲームもどうせろくに作ったことない玄人もどきが喋っているだけで
邪魔。
言語なんてそいつが使いたい言語使えばいい、それだけの話。

217 ：デフォルトの名無しさん：2010/03/06(土) 12:01:24

さすがにいいすぎ。
C++にしかできないことやJavaの言語仕様から来るメリットはある。

218 ：デフォルトの名無しさん：2010/03/06(土) 12:23:10

最適化されたCより速く動作するコードをアセンブラだけで書ける超人なんてまずいない。
アセンブラが優位だったのは、Pentium以前の話。
インライン以外でアセンブラを使うやつは素人。

219 ：デフォルトの名無しさん：2010/03/06(土) 12:49:31

外人にいくらでもいるけど

220 ：デフォルトの名無しさん：2010/03/06(土) 12:52:59

外人っていっちゃだめなんだよ

221 ：デフォルトの名無しさん：2010/03/06(土) 12:55:30

外人は神！！！

222 ：デフォルトの名無しさん：2010/03/06(土) 12:58:01

例えばゲームを作るとか言ったら言語とかは会社の人が決めて
それで一生懸命作るってかんじではないの？
知らないけど

223 ：デフォルトの名無しさん：2010/03/06(土) 13:07:40

まあ会社がC++で作れと言ってるのにJavaで作ることは普通できないよね
会社を説得できれば話は別だけど

224 ：デフォルトの名無しさん：2010/03/06(土) 13:45:03

ゲームじゃなくて業務アプリだけど、
お前なんでまだそんなことやってんの？進捗遅れてるじゃんって言われた奴、
こっちの方が3クロック速いんですよｗｗとか答えて
ふざけんな、そんなことに何日も潰してないでとっとと作業進めろ！って怒られてた
最終的に辞めていったけど

225 ：デフォルトの名無しさん：2010/03/06(土) 14:33:28

>>214
http://shootout.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=gpp
テンプレートもSTLも使わず、malloc、free、sprintf使ってるやる気のないコードだな。
これはC++のコードだとは到底認められない。意図的に遅くしようという悪意が見える。

普通はC++の方がインライン展開が効くから早い。

http://theory.stanford.edu/~amitp/rants/c++-vs-c/
http://unthought.net/c++/c_vs_c++.html

スマートポインタは生ポインタよりオーバーヘッドがあるし、
仮想関数もそれ単体ではオーバーヘッドがある。

しかしＣでもきちんと状態や条件を見てfreeするとなればfreeする前にオーバーヘッドが生じる。
多態を使えばswitchが減るし、アルゴリズムも最適化できる傾向がある。
アプリのパフォーマンスを比べるべきなのにミクロな部分だけを切り取ってそこだけ比べるのはフェアとは言えない。
例えばCでC++のmapと同じものを同じパフォーマンスで書くのはかなり難しいだろうね。

226 ：デフォルトの名無しさん：2010/03/06(土) 15:24:01

switchが減るとなぜ高速化されるのですか？
あとmapの機能がすべて必要な状況というのはどの程度現れるものですか？

227 ：デフォルトの名無しさん：2010/03/06(土) 15:34:40

Ｃ++が遅いって言ってる奴はＣしか使えない奴だからいくら相手しても無駄
こんな基地外スルーしたほうがいい

228 ：デフォルトの名無しさん：2010/03/06(土) 15:43:50

switchしまくっているコードは設計に問題があってアルゴリズム的に遅い可能性が高い。

229 ：デフォルトの名無しさん：2010/03/06(土) 15:45:50

>>226
お前頭大丈夫か？

230 ：デフォルトの名無しさん：2010/03/06(土) 15:50:18

>>225
>普通はC++の方がインライン展開が効くから早い。
Cでもインライン展開は可能ですが？

>アプリのパフォーマンスを比べるべきなのにミクロな部分だけを切り取ってそこだけ比べるのはフェアとは言えない。
CよりもC++の方が全体のパフォーマンスが良いことを示す客観的なデータはありますか？

231 ：デフォルトの名無しさん：2010/03/06(土) 15:52:43

みんなせめて環境とコンパイラくらい書けよな

232 ：デフォルトの名無しさん：2010/03/06(土) 15:55:13

>>229
煽りはいいから答えてね

233 ：デフォルトの名無しさん：2010/03/06(土) 16:43:12

ゲームの処理も描写も同じクラス内で処理する

ゲームの処理だけのクラスつくって
そのクラスから情報引き出して描写する

描写用のインターフェースつくって
ゲーム処理用のクラスに描写クラス渡して
描写する

ゲーム作りわからん
オブジェクト指向ってむつかしい

234 ：デフォルトの名無しさん：2010/03/06(土) 16:43:58

Cのインライン展開とC++のテンプレートのインライン展開は次元が違うよ。
例えばCでは関数ポインタはインライン化されないけど、C++では関数オブジェクトを使えばインライン化される。
これで数倍差が付く。客観的なデータは>>225参照。

235 ：デフォルトの名無しさん：2010/03/06(土) 16:48:25

オブジェクト指向が難しいと感じたらデザインパターンやUMLを勉強してみると良い。
オブジェクト間の関連を整理することこそがオブジェクト指向設計の要だから。

しかしC++でそれなりにオブジェクト指向で書かれてあるだけでも違うよ。
同僚がいまいちな設計と実装のクラスを作ったけど、
それでも意外とすんなり仕様変更に対応できたり、派生できたりする。

C言語だったらよほど上手く作られてないとこういう流用は難しい。

236 ：デフォルトの名無しさん：2010/03/06(土) 16:52:06

>>226
switch は整数値を元に分岐先アドレスを求めることになる。
これを置き換える仮想関数呼び出しでは、だいたいポインタを２段ほど
間接参照した先に分岐先アドレスが置いてある。

この違いのために、速度についてそれぞれに有利な状況というのが
あるだろうが、極端な状況じゃなければ大きな差が生まれることはない。

switch 対仮想関数の一番大きな違いは速度じゃなくて、コードの
可読性・保守性のほうだろうね。

237 ：デフォルトの名無しさん：2010/03/06(土) 16:57:14

>>235
具体的に何がよくなって、Ｃ言語で作ってたときより工数どのくらい減らせる？

238 ：デフォルトの名無しさん：2010/03/06(土) 17:03:55

C++はコードをヘッダに書くか、ソースに書くかで迷うな。

239 ：デフォルトの名無しさん：2010/03/06(土) 17:08:48

>>238
ソース１０個ぐらいで済む小さいプロジェクトでもなければソースに書いとけ。
再コンパイルの可能性は最小限に抑えといたほうがいい。
インライン展開はボトルネックを見極めてから考えればいい。

240 ：デフォルトの名無しさん：2010/03/06(土) 17:23:12

STLを使えば双方向リストとかソートとか組む必要がゼロになる。
毎回リストを組んでデバッグする手間がゼロ。
STLを使うためだけにC++を導入しても十分な利点があるでしょ。

まずはソースコードの拡張子をcppに変えるところから始めて、
わかりやすいところだけ、利点のあるところだけつまみ食いすればいいよ。
極端な話、最初はクラスも使わずにvectorとlistだけ使ってりゃいいよ。
そのうちだんだん欲が出てきていろいろ覚えて、少しずつ効率上がるから。

…という話を10数年前にも業界内の知人に言って回ったものだよ。
そして今では少なくとも俺の知っている範囲では全員C++使ってる。

241 ：デフォルトの名無しさん：2010/03/06(土) 17:35:06

毎回リスト組むというのが意味不明。
0からコード書き起こす奴なんて居ないだろう？

242 ：デフォルトの名無しさん：2010/03/06(土) 17:36:32

ﾉｼ

243 ：デフォルトの名無しさん：2010/03/06(土) 17:37:26

当方学生の部活でプログラムはじめたばっかので

244 ：デフォルトの名無しさん：2010/03/06(土) 17:39:01

>>241
Cで再利用可能なリストって言ったら、マクロや void* で型安全性を壊したうえで
なお利用者側に奇怪な記述を要求するようなものしか作れないと思うんだけど、
なんかキレイにまとまってたりするの？

245 ：デフォルトの名無しさん：2010/03/06(土) 17:39:42

STLはlist以外にもいろいろなアルゴリズムがあってそれらが全部(ry

246 ：デフォルトの名無しさん：2010/03/06(土) 17:40:34

原理も知らないような無能プログラマが量産されるのですね。

247 ：デフォルトの名無しさん：2010/03/06(土) 17:50:50

C言語でも原理を知らず、strcpyで済むところをsprintf使う奴とかがいる。
この前なんか構造体のメンバを１つ１つmemcpyでコピーして、
しかも変数のサイズ指定を間違えてメモリを壊してる奴がいた。
こういうのは言語じゃなくて本人の問題だな…。

248 ：デフォルトの名無しさん：2010/03/06(土) 17:53:45

>>240
たったそれだけ？
Ｃ言語で似た様な機能のライブラリあるときは導入する意味無し？

249 ：デフォルトの名無しさん：2010/03/06(土) 17:56:19

ということにしたいのですね？

250 ：デフォルトの名無しさん：2010/03/06(土) 18:02:58

>>248
いちばん大きいのはやはりオブジェクト指向。
コードがわかりやすくなって不具合が減るし、
流用や拡張もしやすくなり、仕様変更にも柔軟になる。

しかしC++を導入したからすぐにそれが実現できるわけではない。
オブジェクト指向ってのは結局本人のスキル。自分で時間をかけて磨くしかない。
ただ、C++を使っていくうちに、矯正ギプスのように身についてくる。

251 ：デフォルトの名無しさん：2010/03/06(土) 18:07:45

>>248
ミドルウェアはそのまま使うか、ラッパークラスを作って隠蔽する。
多態の利点が分ったら社内開発のゲームエンジンなんかは作り直したくなる。

252 ：デフォルトの名無しさん：2010/03/06(土) 18:10:21

くだらない、必要のない話ばっかり。
もう、このスレ次スレいらんから立てんなよ。

253 ：デフォルトの名無しさん：2010/03/06(土) 18:10:25

>>250
仮に自分の場合を考えたときにＣ言語で見積もった工数のどのくらいの工数を減らせる？

254 ：デフォルトの名無しさん：2010/03/06(土) 18:17:02

>>253
250 じゃないけど
Cでも今なら設計はオブジェクト指向にして組むだろうから、減るのは言語のサポートが
無いぶんの余計な記述量と、型チェックが緩かったりコンストラクタ・デストラクタが無い
ための実行時エラー発生とその修正のぶんかな。
前者は全体の 5 % にもならないだろうけど、後者は 10 % ぐらい超えそうに思う。

255 ：デフォルトの名無しさん：2010/03/06(土) 18:17:41

コーディングなら2倍以上は速いと思うな。
ずっとコーディングばっかりしているわけじゃねーから納期はそんなに縮まらないけど…。

256 ：デフォルトの名無しさん：2010/03/06(土) 18:22:17

>>254-255
じゃあ、工数そんだけ削るけどホントに大丈夫？

257 ：デフォルトの名無しさん：2010/03/06(土) 18:26:25

Cで多態を実現しようとしたら思ったより面倒だったぞ。
vtblを再現すれば簡単なんじゃないかと思ったけど甘かった。
コンストラクタとかコードが複雑になってとても同僚に見せられない。
実務レベルで考えたらせいぜいカプセル化程度が限界だな。

258 ：デフォルトの名無しさん：2010/03/06(土) 18:27:40

Ｃ＋＋厨はいつも以下のことを忘れてしまう

・設計さえしっかりできればコーディングに時間はそんなにかからない
・Ｃ言語とＣ＋＋で設計は変わる？（変わるはずもない、言語によって変わる設計ってなんだよ）
・Ｃ言語でかかる工数、Ｃ＋＋でかかる工数
・Ｃ言語で作れるプログラム、Ｃ＋＋で作れるプログラムの質（それは定義した仕様以外の要素で変わるか？）

何をとってもＣ＋＋であることの利点は見つからない
まともな技術者ならこれがわかる

259 ：デフォルトの名無しさん：2010/03/06(土) 18:28:29

なんかよくわかんないけどプログラムって大変なんだな

260 ：デフォルトの名無しさん：2010/03/06(土) 18:28:47

>>233
トータルで高品質なものを最短でつくれるものをチョイスする。

261 ：デフォルトの名無しさん：2010/03/06(土) 18:28:54

>>257
ＮＧな脳みそ
多態を実現するのが目的ではなくて
あくまで仕様を実現することを目的にするべき

262 ：デフォルトの名無しさん：2010/03/06(土) 18:29:57

>>257
普段どうコンパイルされているか意識が足りないのでは？
面倒だが普通に見せられるレベルでかけるぞ。

263 ：デフォルトの名無しさん：2010/03/06(土) 18:30:15

>>256 あ、減るのは認めるんだｗ

264 ：デフォルトの名無しさん：2010/03/06(土) 18:30:55

>>256
ベテランに任せるなら大丈夫。
C++初心者でもCより工数が伸びることはない。

265 ：デフォルトの名無しさん：2010/03/06(土) 18:30:59

>>262
まて、>>257はすでに道を間違えている
そっから話を広げるんじゃねーよ
お前のいうことがあってるとかまちがってるとかそういう話はいいから

266 ：デフォルトの名無しさん：2010/03/06(土) 18:31:05

>>263
申告した納期を遅延したら評価下げるよ

267 ：デフォルトの名無しさん：2010/03/06(土) 18:31:52

>>265
技術論にもっていきたくないんだね

268 ：デフォルトの名無しさん：2010/03/06(土) 18:32:41

>>263
大丈夫？って>>254-255に聞いてる

269 ：デフォルトの名無しさん：2010/03/06(土) 18:33:59

>>267
そうでなくて具体的な仕様もないのに多態を実現する話にもっていきたくない
俺の検証では多態を実現することで削れる工数など１ｈすらない

270 ：デフォルトの名無しさん：2010/03/06(土) 18:34:58

>>269
なるほど。

271 ：デフォルトの名無しさん：2010/03/06(土) 18:36:37

>>258
> ・Ｃ言語で作れるプログラム、Ｃ＋＋で作れるプログラムの質（それは定義した仕様以外の要素で変わるか？）

C++ のほうがコンパイラで自動的にチェックできる問題が多いんだから、
客観的な信頼性という質においては C++ で組んだほうが上になるんじゃないの？

272 ：デフォルトの名無しさん：2010/03/06(土) 18:37:12

Ｃ言語で何も不満がないならＣ言語を使えばいいよ。
仕様変更とか、流用とか、そういうところで悩むことがないなら、
新しいことに手を出す必要はない。

273 ：デフォルトの名無しさん：2010/03/06(土) 18:37:39

>>271
じゃないの？って以上の要素でないっしょ？

274 ：デフォルトの名無しさん：2010/03/06(土) 18:39:04

>>272
>仕様変更とか、流用とか、そういうところで悩むことがないなら、
本当にＣ＋＋は仕様変更や流用に強いの？
そしてそれは設計の話ではなくてコーディングレベルの仕様変更や流用の話でいいの？
コーディングはそんなに工数を食うの？

275 ：デフォルトの名無しさん：2010/03/06(土) 18:40:06

>>269
多態ができればベースクラスを流用できるし、
1つのアルゴリズムや関数をいろいろな派生オブジェクトに適用できるだろ…。
つまり多態があれば単純にコード量は減る。
もちろんどんな場面でもというわけにはいかないけど。

276 ：デフォルトの名無しさん：2010/03/06(土) 18:40:58

>>273
いや、おれは「信頼性という質においては C++ で組んだほうが上になる」という結論を
根拠も添えて示している。そのうえであんたはそう考えられないのか？という問いかけ。

277 ：デフォルトの名無しさん：2010/03/06(土) 18:41:01

C++トランスレーターの存在やチューリング完全の存在からも
お前らの議論は浅すぎると思うんだが。

278 ：デフォルトの名無しさん：2010/03/06(土) 18:42:56

>>275
本当に？検証した？

279 ：デフォルトの名無しさん：2010/03/06(土) 18:43:01

C++ vs C とか、何年前からタイムスリップしてきたスレだよ

280 ：デフォルトの名無しさん：2010/03/06(土) 18:44:15

>>276
じゃあ、その信頼性はＣ＋＋のなんのチェックが入るから上がるもんなの？
Ｃ言語とＣ＋＋との違いになにがあるの？
俺はなんの違いもないって結論な

281 ：デフォルトの名無しさん：2010/03/06(土) 18:45:13

C++は仕様変更や流用に強いよ。それは主に設計面の話。
他部署で別のゲームのために作られたライブラリを、全く手を加えずに派生させるだけで、
元の開発者の想定外の実装を無理なく実現できてしまうくらい。

282 ：デフォルトの名無しさん：2010/03/06(土) 18:46:21

どんだけ天国な会社に居るんだよｗ

283 ：デフォルトの名無しさん：2010/03/06(土) 18:46:51

>>281
Ｃ＋＋とＣ言語で設計は変わるっていってる？
ちょっとお話できないレベルになるんだけど

284 ：デフォルトの名無しさん：2010/03/06(土) 18:46:54

>>280
>254 にもあるが、厳格な型チェックやコンストラクタ・デストラクタの強制があるだろ。
これだけでも十分だ。

285 ：デフォルトの名無しさん：2010/03/06(土) 18:49:36

Cにもboostが有るならCでいいと思う

286 ：デフォルトの名無しさん：2010/03/06(土) 18:51:17

厳格な型チェック？
C使いでもコンパイラはC++と共通のもの使ってるでしょう。
コンストラクタデストラクタはあってもびっくりな使い方する奴後がたたないけどなｗ

287 ：デフォルトの名無しさん：2010/03/06(土) 18:51:45

>>284
型チェックに関していうけど
それは仕様としてなんの機能を組むときに必要になるわけ？
そもそも型チェックなんてベタで組んでればおきるはずもないこと
わざわざ型変換して妙なことしてるからだろ
んでもってそれはＣ言語でもＣ＋＋でも余計なことしなければ発生さえしないもの
君の言っていることはまったく関係ない

コンストラクタデストラクタは発生することで逆にバグる可能性も増えるよね？
単純にいいとはいえないなチェック増えるだけだし
そしてそれだったら言語の機能なんかじゃなくてあらためて初期化や終了関数を作ったほうがいいんじゃないか？

288 ：デフォルトの名無しさん：2010/03/06(土) 18:53:48

あ、RTTIのこといってたの？

289 ：デフォルトの名無しさん：2010/03/06(土) 18:54:28

>>288
いや、関係ないからもういいよ

290 ：デフォルトの名無しさん：2010/03/06(土) 18:55:23

Cでｽﾏﾎﾟってどうやって実装するんですか？

291 ：デフォルトの名無しさん：2010/03/06(土) 18:56:22

スマートポインタｗ

292 ：デフォルトの名無しさん：2010/03/06(土) 18:58:13

やねうらおさんのところいってください

293 ：デフォルトの名無しさん：2010/03/06(土) 18:58:33

オブジェクト指向と構造化設計では設計が変わってくる。
C++で構造化設計することもできるしCでオブジェクト指向することもできる。

論理的に可能かどうかではなくて、実際の運用として現実的かどうかを考えないといけない。
Cでデザパタを実現しようと思ったら相当にめんどいぞ。

294 ：デフォルトの名無しさん：2010/03/06(土) 18:58:59

>>287
struct S* 受け取る関数に int* 渡すとかいうくだらないミスが
コンパイルできてしまうかコンパイルエラーになるかという違いがある。
仕様だとか意図的な変換とか、そういうのは関係ない。当たり前だが。

コンストラクタ・デストラクタの存在で逆に発生するバグってどんなの？
で、仮にそういうのがあるとして、それは誰でも経験しているだろう初期化や
終了関数の呼び忘れより頻度や重大性の大きいものなの？

295 ：デフォルトの名無しさん：2010/03/06(土) 18:59:28

あ、やねうらお隔離スレ（＝タスクシステム議論スレ）が消えてるじゃねーか！

296 ：デフォルトの名無しさん：2010/03/06(土) 18:59:44

ところで>>283はC++で組んだ経験はどれだけあるの？
オブジェクト指向での実務経験は？　まさか経験がないのに想像で語っている訳じゃないよね？
つーか話を聞いてると全然経験がないように見えるけど。

297 ：デフォルトの名無しさん：2010/03/06(土) 19:00:01

循環参照に問題があるシステムを使う理由は何？
完全手動でのnew/deleteとすらあまり違いが内容に思うんだけど。

298 ：デフォルトの名無しさん：2010/03/06(土) 19:01:11

>>283じゃないけどおれはゲーム開発の仕事で６年。
>>296さんは？

299 ：デフォルトの名無しさん：2010/03/06(土) 19:01:59

コンストラクタでバグらせる奴は、関数呼び出しでも同じようにバグらせそうだな。

300 ：デフォルトの名無しさん：2010/03/06(土) 19:02:02

なんかもう話して実があるレベルじゃないな
仮にそうだったとしてそれが大局に本当に影響あると思ってるの？
ってレベルだし
結局Ｃ＋＋の利点って聞くといつもこんな感じだよね

301 ：デフォルトの名無しさん：2010/03/06(土) 19:03:25

>>298
俺は17年だ…
ﾌﾙアセンブラ時代からの生き残りだよ。

302 ：デフォルトの名無しさん：2010/03/06(土) 19:03:45

>>301
いやいやゲームでC++の話だから。

303 ：デフォルトの名無しさん：2010/03/06(土) 19:05:21

>>302
あぁ、ゲームでC++ならもう12～13年くらいじゃないかな。
PlayStationの時代からやってる。メモリがなかったのでテンプレート無しだったけど。

304 ：デフォルトの名無しさん：2010/03/06(土) 19:06:54

なんかもう話して実があるレベルじゃないな
仮にそうだったとしてそれが大局に本当に影響あると思ってるの？
ってレベルだし
結局Ｃの利点って聞くといつもこんな感じだよね

305 ：デフォルトの名無しさん：2010/03/06(土) 19:07:04

ここってプロいたのかよｗ

306 ：デフォルトの名無しさん：2010/03/06(土) 19:08:34

>>303
そりゃ正直どうかと思うわ。
C++で分断化のフレームワークがしっかりしてない限り
チーム開発でライブラリ含めて2MBを安全に使うのは困難。
どんなメモリ管理にしてたの？

307 ：デフォルトの名無しさん：2010/03/06(土) 19:12:38

mallocは独自実装で遅くても断片化しにくいアルゴリズムにしてた。
PSとかDCとかmalloc差し替えられるでしょ。
それ以外にも断片化についてはいろいろノウハウがあった。

mallocはねぇ、俺も懐疑的だったんだよ。
そもそもCで固定アドレス派だった。
若い人がmallocを使って美しいコードを書いているのを見て
衝撃を受けてからmallocを使うようになった。

しかしやはり断片化が問題になったので、
丸ごと自作して差し替えた上に、メモリ配置分析ツールも自作してた。
それがすでにあったからC++への移行でそこが問題になったことはなかった。

308 ：デフォルトの名無しさん：2010/03/06(土) 19:14:30

ってか、今はLuaとかを組み込んじゃってコアな部分以外はそっちにまかせちゃったり
逆にコアな部分はGLのシェーダしかなかったりとかで言語はそれほど重要じゃないと思うのだが。

309 ：デフォルトの名無しさん：2010/03/06(土) 19:15:12

中途半端な感じはするな。分断化をノウハウで乗り切るって運で助けられてるか、
ひとつの強力なノウハウでほとんど乗り切ってるかくらいしかイメージできない。

310 ：デフォルトの名無しさん：2010/03/06(土) 19:16:40

LuaよりはCやC++のほうが開発しやすいだろ。トライ＆エラーが必要な箇所以外。

311 ：デフォルトの名無しさん：2010/03/06(土) 19:19:00

Luaにしとけば企画者とかスクリプタっていう小人さんたちが
寝てる間に勝手にイベントとか組み込んでくれるんだよ。

312 ：デフォルトの名無しさん：2010/03/06(土) 19:27:19

スクリプタも自作できないプログラマって…

313 ：デフォルトの名無しさん：2010/03/06(土) 19:28:36

その発言はプログラマ失格だろ。
デバッガや完成度やバグの可能性考慮してるか？
つーか煽りか・・・

314 ：デフォルトの名無しさん：2010/03/06(土) 19:31:34

>>312
スクリプタを作るための苗床と時間（20年くらい）が必要だからな……
自作するのは割に合わんよ。

315 ：デフォルトの名無しさん：2010/03/06(土) 20:28:01

今やluaとかいろいろスクリプトエンジンもあるのにわざわざ作る？
自分で工数増やしてんじゃしょうがねーよな。
ライセンスの問題で、どうしても自力実装が必要ならわかるが。

データはもう外出しで一切ハードコーディングしないのが普通じゃないの？
イベントもスクリプトで組んで、どうしても処理コストがかかるところはハードコーディング
して。
本体は3Dエンジンとか、サウンド再生とかコア機能だけ。
これを突き詰めていくと．．．あれ？ツクールじゃんｗｗｗｗｗｗｗｗ
なんだ、ツクールがあれば全てのゲーム作れるじゃん（笑）

316 ：デフォルトの名無しさん：2010/03/06(土) 20:36:21

俺が格ゲーのスクリプタ仕事で行ったところはオリジナルのツールでスクリプト組んでたけど、
そういうのが当たり前なんじゃないの？

317 ：デフォルトの名無しさん：2010/03/06(土) 21:26:21

そんなレベルまで行けばケースバイケースとしか

318 ：デフォルトの名無しさん：2010/03/06(土) 21:28:30

>今やluaとかいろいろスクリプトエンジンもあるのにわざわざ作る？
プログラマ以外にスクリプトを書いてもらう為にDSLはよく組むよ
luaとかは汎用的過ぎるので結局プログラマがスクリプト書くでしょ？

319 ：デフォルトの名無しさん：2010/03/06(土) 21:31:24

それはあるね

320 ：デフォルトの名無しさん：2010/03/06(土) 23:11:15

>>234
レスありがとうございます。

>>225のサイトにあるコードを自分のPCで検証してみました。
Sorting in C++ vs. C
C, library qsort　1.09～1.13　0.27～0.31
C, hand-coded quicksort　0.31～0.33　0.11～0.14
C++, STL sort, C arrays　1.25～1.328　0.14～0.157
C++, STL sort, C++ vectors　50.11～52.047　0.14～0.188
※VisualC++2008EE, WindowsXP(32ビット版), N=1000000, TYPE=int, ビルド=Debug/Release

Cの方が速いという結果になりましたが・・・

321 ：デフォルトの名無しさん：2010/03/06(土) 23:18:56

>>318
汎用的すぎるからだめとかよく分からないな
素人でも間違えないような関数だけ公開すればいい話じゃん

322 ：デフォルトの名無しさん：2010/03/06(土) 23:19:31

責任感ない奴は自由でいいな

323 ：デフォルトの名無しさん：2010/03/06(土) 23:23:37

みんな自分の担当個所だけでいっぱいいっぱいなのさ

324 ：デフォルトの名無しさん：2010/03/06(土) 23:56:18

>>321
そう思うだろう？
凄く甘い考えだぞ～ orz

325 ：デフォルトの名無しさん：2010/03/07(日) 00:02:09

このくらいのレベルが素人呼ばわりだもんな。
まわりもレベル低いんだろうな。

326 ：デフォルトの名無しさん：2010/03/07(日) 00:06:35

スクリプタはGUIで誰にでも簡単操作なものを自作するのがマとして最低限のレベル。

327 ：デフォルトの名無しさん：2010/03/07(日) 00:27:59

STL使ってる人って、どれくらいallocatorを使い分けてる？

328 ：デフォルトの名無しさん：2010/03/07(日) 00:35:42

>>320
その結果からどうして「Cのほうが速い」なんて話になるんだ？
もしかしてデバッグ版の速度を比較して意味があるとでも思ってるのか？

329 ：デフォルトの名無しさん：2010/03/07(日) 00:37:28

またこのレベルか・・・

330 ：デフォルトの名無しさん：2010/03/07(日) 01:38:21

>>318
なるほど、もっと的を絞ったいわば簡易版を作るわけか、納得。

331 ：デフォルトの名無しさん：2010/03/07(日) 01:41:01

このスレだっけ、忘れたけどXinputで入力試みて、デバイスがない場合はDInputで
入力させるとかあったかな。
XinputはX360コンだけなので、デバイスがない場合はDInputで他のデバイスから
入力を取るとか。

332 ： [―{}@{}@{}-] デフォルトの名無しさん：2010/03/07(日) 01:52:08

コードの実行速度の比較なんて、コードによっていくらでも優劣が変わる。
JavaやC#など実行時コンパイルする言語が、Cなどのネイティブ言語より
早いようなコードを書くことだってできる。

コードや言語の特性も考慮に入れずに論じても誤解を生むだけ。

333 ：デフォルトの名無しさん：2010/03/07(日) 02:16:06

334 ：デフォルトの名無しさん：2010/03/07(日) 02:23:13

335 ：デフォルトの名無しさん：2010/03/07(日) 02:59:44

>>334
オウム返しが成立してないのに見苦しいなｗ

336 ：デフォルトの名無しさん：2010/03/07(日) 03:02:02

答えに窮して勝利宣言のほうが見苦しいわ。

337 ：デフォルトの名無しさん：2010/03/07(日) 03:02:37

>>336
は？幻覚でもみたの？ｗ

338 ：デフォルトの名無しさん：2010/03/07(日) 03:03:45

>>294 → >>300 この流れだろ。ひどいな。

339 ：デフォルトの名無しさん：2010/03/07(日) 03:07:05

>>338
ホントだよ
設計云々いってたのに
蓋を開けたら
>struct S* 受け取る関数に int* 渡すとかいうくだらないミスが
こんなくだらないことの回避のために
オブジェクト指向導入したんですってｗ
馬鹿じゃないのｗ
自分が何を説明しようとしてるのかそれすら行方不明で
こんなこと口走っちゃうあたりもう末期だよね
技術者としても終わってると思う
メリットが説明できないものを役立つなんていっちゃう人は技術者じゃなくて詐欺師っていうんだよ

340 ：デフォルトの名無しさん：2010/03/07(日) 03:12:44

>>339 オブジェクト指向とか関係ないから。

341 ：デフォルトの名無しさん：2010/03/07(日) 03:16:27

>>340
関係なくていいの？
Ｃ言語からＣ＋＋にして使ってるのは言語の珍妙な機能だけ？
こりゃいいわｗ

342 ：デフォルトの名無しさん：2010/03/07(日) 03:19:12

アンカーたどって流れ読み直せ

343 ：デフォルトの名無しさん：2010/03/07(日) 03:22:09

>>342
いや、単純にＣ言語からＣ＋＋にしてなんの利点のがあるの？
って話が本題だよｗ
ここでオブジェクト指向が関係ないなんてでちゃうのはおかしいな
なんか議論してる方向間違ってるからオブジェクト指向関係ないなんてセリフがでちゃうんじゃなーい？ｗ
まあ、君は技術者やめちゃったほうがいい人だから
そういう目的を見失っちゃうこともあるだろうねｗ

344 ：デフォルトの名無しさん：2010/03/07(日) 03:28:53

>>342
会話するつもりがあるならアンカーたどって流れ読み直せ。 >>280 で同じ話が出てる。
そのからの流れで >>294 への答えが聞いてみたいところだ。

345 ：344：2010/03/07(日) 03:29:58

ごめんアンカーミスった。 >344 は >>343 宛てね。

346 ：デフォルトの名無しさん：2010/03/07(日) 03:32:27

オブジェクト指向な設計がCで実装できないとでも思ってるのかな？

347 ：デフォルトの名無しさん：2010/03/07(日) 04:25:20

ここ数日で急激に馬鹿が増えたな

348 ：デフォルトの名無しさん：2010/03/07(日) 04:29:45

N88BASICでオブジェクト指向しながらゲーム作れますか？

349 ：デフォルトの名無しさん：2010/03/07(日) 04:31:21

>>320
俺のPCではこんな結果だったぞ。
何度もやったけどC++の方が早かった。

C, hand-coded quicksort　0.16～0.19
C++, STL sort, C arrays　0.15～0.18
C++, STL sort, C++ vectors　0.15～0.17
※VisualC++2008EE, WindowsXP(32ビット版), N=1000000, TYPE=int, ビルド=Release
※IDEからではなくコマンドラインから実行。

C, hand-coded quicksort　1.76～1.81
C++, STL sort, C arrays　1.54～1.57
C++, STL sort, C++ vectors　1.57～1.60
※VisualC++2008EE, WindowsXP(32ビット版), N=10000000, TYPE=int, ビルド=Release
※IDEからではなくコマンドラインから実行。

コンパイルオプション、最適化は全部デフォルト。
俺のPCがショボイ、というのは認めざるを得ない。

350 ：デフォルトの名無しさん：2010/03/07(日) 04:33:31

>>348
可能です。頑張ってください。

351 ：デフォルトの名無しさん：2010/03/07(日) 04:34:47

>>348
私ほどの実力なら作れますが、あなたには到底無理です。諦めてください。

352 ：デフォルトの名無しさん：2010/03/07(日) 04:36:44

>>348
すでに時代遅れです。諦めてください。

353 ：348：2010/03/07(日) 04:38:34

>>350-352
ご丁寧にどうもありがとうございました

354 ：デフォルトの名無しさん：2010/03/07(日) 05:24:22

うちの大学の実験装置に繋がってるパソコンがPC98で実験装置動かすのにN88BASICが使われてた
実験装置用のプログラム新しいの作れる人がいないらしい
悲しいな

355 ：デフォルトの名無しさん：2010/03/07(日) 06:38:53

N88BASICは簡単だろ。
C覚える暇があれば十分覚えられる。
ただ、スパゲッティプログラムになり易いから綺麗な書き方の練習は必要だけど。

356 ：デフォルトの名無しさん：2010/03/07(日) 06:38:57

>>349
ありがとうございます。
参考になります。

>>320もコンパイルオプション、最適化は全てデフォルトです。
STLのDebug版がRelease版と比較して大きく落ち込んでいますが、これは改善できるものなのでしょうか？
リリース版の結果が重要とは言ってもやはり開発時はデバッグ版を使用したいのですが。
C, library qsort　1.09～1.13　0.27～0.31　⇒　24.7～27.4％
C, hand-coded quicksort　0.31～0.33　0.11～0.14　⇒　35.4～34.0％
C++, STL sort, C arrays　1.25～1.328　0.14～0.157　⇒　11.2～11.8％
C++, STL sort, C++ vectors　50.11～52.047　0.14～0.188　⇒　2.7～3.6％

357 ：デフォルトの名無しさん：2010/03/07(日) 06:48:15

Debugが遅いから云々言う奴は
JITなしのJavaは遅くて使い物にならないと主張してるのと変わらんよなw

358 ：デフォルトの名無しさん：2010/03/07(日) 07:21:17

>>344
全然関係ないじゃん
だってそれって細かい実装技術だろ
工数なんてちっとも削れやしないｗ

そもそも型変換なんてしなけりゃいいじゃん

359 ：デフォルトの名無しさん：2010/03/07(日) 07:23:49

全然関係ないことを持ち出して
Ｃ言語とＣ＋＋との違いって主張する奴はなんなの？
オブジェクト指向が入って違いが出たんじゃないの？

360 ：デフォルトの名無しさん：2010/03/07(日) 07:27:47

> struct S* 受け取る関数に int* 渡すとかいうくだらないミスが
これコンパイラでひっかかるよね

361 ：デフォルトの名無しさん：2010/03/07(日) 09:07:56

C++はマルチパラダイムなだけあって色々なスタイルで書けるから一概に言えないのでは。
それこそクラスなんぞ使わず、betterCとして利用する事もできる。

362 ：デフォルトの名無しさん：2010/03/07(日) 09:20:38

個別文法禁止オプションとか仕様レベルで追加されればいいんだけどなぁ

363 ：デフォルトの名無しさん：2010/03/07(日) 10:06:03

>>361
それはメリットでもなんでもないな

364 ：デフォルトの名無しさん：2010/03/07(日) 10:16:14

可変長配列や連想配列のあるCとして使ってもいいよ。

365 ：デフォルトの名無しさん：2010/03/07(日) 10:20:04

>>364
本筋より付属物なんか人に薦めてるあたり使えないのバレバレだなお前ｗ

366 ：デフォルトの名無しさん：2010/03/07(日) 10:21:27

ベターC的な使い方しかしてないところは結構あるらしいね。

367 ：デフォルトの名無しさん：2010/03/07(日) 10:29:48

Cより出来ること増えてんだから使いこなせればC＋＋のほうがいいに決まってる

368 ：デフォルトの名無しさん：2010/03/07(日) 10:50:52

「使いこなせれば」

369 ：デフォルトの名無しさん：2010/03/07(日) 11:02:31

使いこなせば使いこなすほど
胸を張って「使いこなせる」
と言えなくなっていく

それがC++

370 ：361：2010/03/07(日) 12:05:09

>>363
ごめん、CとC++の速度比較に関して言った。

371 ：デフォルトの名無しさん：2010/03/07(日) 12:13:45

ふむ
ここはCとC++の優劣を決めるスレですか

372 ：デフォルトの名無しさん：2010/03/07(日) 13:21:05

>>347
春休みなんだろ

373 ：デフォルトの名無しさん：2010/03/07(日) 13:31:20

>>358
C++ではコンパイルエラーにできるところがCでは実行時エラーとなるまで
気づかない可能性がある。C++で強制されるコンストラクタもデストラクタの
呼び出しもCでは明示的な初期化と終了関数を呼び忘れる可能性がある。

これによってコンパイルできたコードの信頼性が向上すると言えるし、それに
伴ってテストフェーズにかかる工数が減るとも言える。

意図的な型変換は関係ないと >>294 にも書いたはずなんだが。

374 ：デフォルトの名無しさん：2010/03/07(日) 13:58:02

無限ループってこわくね？

375 ：デフォルトの名無しさん：2010/03/07(日) 13:59:56

ゲームって基本ループじゃね
ウォッチドッグタイマ使えばいいんじゃね

376 ：デフォルトの名無しさん：2010/03/07(日) 14:45:50

GC付きの言語と比べるならともかく
CとC++なんて本質的にそれほど差があるわけじゃないだろ
なんでこの兄弟言語で喧嘩する必要があるんだか

377 ：デフォルトの名無しさん：2010/03/07(日) 15:18:56

goto有害論みたいなものだろ

378 ：デフォルトの名無しさん：2010/03/07(日) 17:33:27

C#でDirect3Dは無謀？

379 ：デフォルトの名無しさん：2010/03/07(日) 17:50:20

てめぇXNA先輩にケンカ売ってるのか

380 ：デフォルトの名無しさん：2010/03/07(日) 19:44:29

>>378
Managed?は終わったんだっけ

381 ：デフォルトの名無しさん：2010/03/07(日) 20:04:15

>>378
全然いける。

382 ：デフォルトの名無しさん：2010/03/07(日) 20:43:40

>>373
まだ関係ないところこだわってるんだ？ｗ

383 ：デフォルトの名無しさん：2010/03/07(日) 21:14:45

Managed DirectX(MDX)は終わってるから、やるならSlimDXな

384 ：デフォルトの名無しさん：2010/03/07(日) 21:25:50

春厨効果なのかもしれんがこのスレ勢い1位だなｗ

385 ：デフォルトの名無しさん：2010/03/07(日) 21:29:02

>>369
同意
使えることは増えていくけど終わりが見えない

386 ：デフォルトの名無しさん：2010/03/07(日) 21:29:56

何年使ってもメリットが説明できない

387 ：デフォルトの名無しさん：2010/03/07(日) 21:36:14

C++のメリットは実行速度とOOかな。
それ以外もあるけど強くプッシュできない。

388 ：デフォルトの名無しさん：2010/03/07(日) 21:41:08

効果を数字で出せないからお金に結びつかないよね

389 ：デフォルトの名無しさん：2010/03/07(日) 21:41:26

OOはあまりプッシュしない方が・・・
むしろジェネリックプログラミングじゃね

390 ：デフォルトの名無しさん：2010/03/07(日) 21:51:09

設計をコードに落とすときにOO使うと便利

391 ：デフォルトの名無しさん：2010/03/07(日) 21:51:49

構造体じゃダメなんかよ

392 ：デフォルトの名無しさん：2010/03/07(日) 22:18:06

いいよ
private宣言するだけだから

393 ：デフォルトの名無しさん：2010/03/07(日) 22:20:35

クラスになってから
インスタンスのコピーするのがやたらと面倒だけど
これはなんで面倒にしてるの？

394 ：デフォルトの名無しさん：2010/03/07(日) 22:30:44

>>393
安全のために

395 ：デフォルトの名無しさん：2010/03/07(日) 22:31:10

>>393 そのクラス作ったやつに聞けよ。

396 ：デフォルトの名無しさん：2010/03/07(日) 22:31:35

その曖昧な質問をどうにかしてくれ
何がどうして面倒なのか

397 ：デフォルトの名無しさん：2010/03/07(日) 22:36:03

デザパタを適応してるのでは。知らんけど

398 ：デフォルトの名無しさん：2010/03/07(日) 22:55:43

どうせ
今までmemcpyで済んでたのにどうしてメンバいっこいっこ代入するんだよ～

とかそんな程度だろ

399 ：デフォルトの名無しさん：2010/03/07(日) 23:25:55

>>398
そうだそれだ
すげー手間じゃね？

400 ：デフォルトの名無しさん：2010/03/07(日) 23:29:02

>>399
状況を具体的にして初心者スレに行くのがいいと思いますよ。

401 ：デフォルトの名無しさん：2010/03/07(日) 23:40:25

>>399
春厨乙

402 ：デフォルトの名無しさん：2010/03/08(月) 01:46:38

コピーコンストラクタや代入演算子を自前で書かずにコンパイラのデフォルトに任せればいい。
全部のメンバのコピーコンストラクタが勝手に呼ばれる。
ポインタはコピーされるとまずいのでそこだけラップしておけばいい。
例えばchar *を使わずにstringを使うとか。

403 ：デフォルトの名無しさん：2010/03/08(月) 02:16:29

ベーマガ掲載のゲームを移植しようと思ったが、言語違うと難しいな

404 ：デフォルトの名無しさん：2010/03/08(月) 02:18:12

BASIC系の処理をどう移植すりゃええのか
アセンブラ使ってるＢＡＳＩＣ投稿もあるがマシン語とかさっぱりだぜ（笑）

405 ：デフォルトの名無しさん：2010/03/08(月) 02:40:54

マシン語部分は描画ルーチンや衝突判定ルーチンだったりするわけで。
昔を思い出しつつマシン語を直読みしてって、同じ処理を普通に記述していけばいいだけでは？

406 ：デフォルトの名無しさん：2010/03/08(月) 02:46:43

ベーマガってやつはゲームのサンプルとか載ってんの？
ゲームコードがのってる雑誌って他に有る？

407 ：デフォルトの名無しさん：2010/03/08(月) 02:47:35

BASICなんてエディタ含めて数十kbの言語だしZ80なんて命令数さほど無いんだよ

408 ：デフォルトの名無しさん：2010/03/08(月) 03:04:50

>>406
読者の投稿プログラムが掲載されていた
もっぱらゲームだが
電波新聞社のベーシックマガジン、通称ベーマガ。ベーシックってのはBASIC言語のことだ
休刊して7年くらい経つ

409 ：デフォルトの名無しさん：2010/03/08(月) 03:30:33

懐かしきベーマガの面白かった投稿プログラムを語る
http://pc12.2ch.net/test/read.cgi/tech/1103375399/

410 ：デフォルトの名無しさん：2010/03/08(月) 04:01:04

投稿できる雑誌が無くなってから
プログラミングへの意欲は大きく減ってしまった

411 ：デフォルトの名無しさん：2010/03/08(月) 04:05:39

ベーマガね。超高齢のジジイとかも投稿しててマジすげえ（笑）と思ってたわｗ

412 ：デフォルトの名無しさん：2010/03/08(月) 04:11:16

雑誌がなくてもネットで公開すればいい。

413 ：デフォルトの名無しさん：2010/03/08(月) 04:14:05

おま、プログラム原稿料1万円もらえるんだぜ？

414 ：デフォルトの名無しさん：2010/03/08(月) 04:16:44

（笑）

415 ：デフォルトの名無しさん：2010/03/08(月) 04:19:55

一万円って日給1日分じゃねーか

416 ：デフォルトの名無しさん：2010/03/08(月) 04:26:07

１日１個当選しても月収たったの３０万か

417 ：デフォルトの名無しさん：2010/03/08(月) 04:30:14

それ土日入ってんのかよ！

418 ：デフォルトの名無しさん：2010/03/08(月) 04:40:16

>>404
環境自体を移植すればいいのさ！

419 ：デフォルトの名無しさん：2010/03/08(月) 06:33:00

>>400-402
はぁ？面倒臭ぇことにはかわらねーだろ
馬鹿？

420 ：デフォルトの名無しさん：2010/03/08(月) 06:39:27

コピコンが面倒くさいのは誰もが認める所だな

421 ：デフォルトの名無しさん：2010/03/08(月) 07:51:29

それが面倒なんじゃC言語で深いコピーとかやるのも面倒だろ
C++はスマポやコンテナを使えばデフォルトでも問題ない
浅いコピーはスマポ
深いコピーはコンテナで

てかここはC++初心者スレじゃないぞ

422 ：デフォルトの名無しさん：2010/03/08(月) 07:56:07

今のゲームプログラマがいかにレベル低いかがよくわかる。

423 ：デフォルトの名無しさん：2010/03/08(月) 10:48:16

でも今のゲー専じゃMaxとかMayaとか使わせてるってんだから、
ある意味昔のゲームプログラマとは別の領域のレベルは伸ばしてるんじゃねえかと思う。
そいつらがマップの衝突判定とかが出来るかどうかは別として。

424 ：デフォルトの名無しさん：2010/03/08(月) 14:49:23

>>410
wonderflは割りと近い気がするな
あれのC版とかC++版とか・・・は考えたくも無いが

425 ：デフォルトの名無しさん：2010/03/08(月) 15:30:06

＞ｹﾞｰ専
昔はｹﾞｰﾑの作り方を教えてくれたけど
今はｹﾞｰﾑの見た目を良くする方法を教えてくれる所だと思ってる。

426 ：デフォルトの名無しさん：2010/03/08(月) 17:34:37

日本のCGも海外と比べればびっくりするほど低レベルなんだが
プログラムの中身の質なんてそう分かるものじゃないが
CGだと素人が一瞥しただけで糞だとバレてしまう悲しい現実

427 ：デフォルトの名無しさん：2010/03/08(月) 19:06:01

>>421
はぁ？
クラス使わないで構造体で組めばなんの問題も起きないんだけど
余計なことして余計な時間かけて馬鹿じゃないの？
仕事しないで遊んでるの？

428 ：421：2010/03/08(月) 19:33:10

ちょｗ

429 ：デフォルトの名無しさん：2010/03/08(月) 19:46:19

おまんこ

430 ：デフォルトの名無しさん：2010/03/08(月) 20:11:30

C++の構造体はプライベートが設定できません。
すべてパブリックなpythonがお勧めですね

431 ：デフォルトの名無しさん：2010/03/08(月) 20:38:45

言語はどうでもいいんだよ。
今2010年においてもっとも重要なのはゲームデザインとシェーダプログラミングじゃ。
つうかゲームデザインの話しようぜ。
オンライン前提のゲームバランスについて語ろうよ。俺TUEEEEE野郎をどうやって隔離するか、とか。

432 ：デフォルトの名無しさん：2010/03/08(月) 20:48:19

ゲ製行けよゲス！

433 ：デフォルトの名無しさん：2010/03/08(月) 21:26:24

最強のゲームは囲碁じゃね！
ソフトが弱いし
どんだけ廃人になっても才能ないと勝てないし

434 ：デフォルトの名無しさん：2010/03/08(月) 21:55:22

>>427
ようするにお前みたいなバカはプログラムなんか作るなってことだ
ユトリは大人しくオナニーでもしてろ

435 ：デフォルトの名無しさん：2010/03/08(月) 22:44:27

>>434
アレアレ？
説明できなくなってキレちゃった？（笑）

436 ：デフォルトの名無しさん：2010/03/08(月) 22:56:07

冗談かと思ったらマジて言ってたのかよ
本当のアホだな

437 ：デフォルトの名無しさん：2010/03/08(月) 23:33:53

>>436
そういうのはしっかりと説明できてからいってねｗ
いまだにＣ＋＋のメリット説明できた人間ってみたことないんだ俺ｗ

438 ：デフォルトの名無しさん：2010/03/08(月) 23:50:53

え？

439 ：デフォルトの名無しさん：2010/03/08(月) 23:55:24

組み込みいけばC++のメリットを実感するよ。いてら

440 ：デフォルトの名無しさん：2010/03/08(月) 23:57:43

おまえらタスクシステムスレいただろ

441 ：デフォルトの名無しさん：2010/03/09(火) 00:02:22

目をつぶってたか耳をふさいでいたかのどっちかだな

442 ：デフォルトの名無しさん：2010/03/09(火) 00:22:32

ポリモー出来た方が便利じゃん
読みやすいじゃん

443 ：デフォルトの名無しさん：2010/03/09(火) 00:23:41

Cの上位互換でコーディング方法の選択肢が多いってだけで十分じゃん

444 ：デフォルトの名無しさん：2010/03/09(火) 00:24:29

C++でプログラミングしていたらインクルード地獄にはまって抜け出せなくなりプロジェクト破棄した

445 ：デフォルトの名無しさん：2010/03/09(火) 00:25:50

C言語 > C++ な人によってはC++の全てが悪なんだろう
価値観の相違だな

446 ：デフォルトの名無しさん：2010/03/09(火) 00:26:45

>>444
インクルードガードはもちろんやってんだよな？
設計を紙に落として階層分けてみたら意外なこと発見するかもよ

447 ：デフォルトの名無しさん：2010/03/09(火) 00:36:58

C++覚えたてのときは相互参照とか書き方分からなかったな

448 ：デフォルトの名無しさん：2010/03/09(火) 00:53:04

そんなもん必要な時点でレベル低いだろｗ

449 ：デフォルトの名無しさん：2010/03/09(火) 01:03:46

>>444
状況を具体的にして初心者スレに行くのがいいと思いますよ。

450 ：デフォルトの名無しさん：2010/03/09(火) 01:15:43

ダーウィンの進化論は未だに証明されていないって
まじめに主張している奴も世の中にはいるからな。
思い込みの激しい奴に何を言っても無駄だろう。

451 ：デフォルトの名無しさん：2010/03/09(火) 01:38:24

進化論て証明できる類のものなのか？

452 ：デフォルトの名無しさん：2010/03/09(火) 01:41:36

科学と呼ぶためには「再現性」が無いと
進化論が科学だとすると、進化論の進化を再現してみせないと

453 ：デフォルトの名無しさん：2010/03/09(火) 02:01:06

アメリカの湖で、環境破壊の影響で、40年ほどで交配できないレベルの新種が誕生した、って実例がある。
交配できないほどじゃないけど、似たような話は琵琶湖にもある。
進化ってのは、条件さえ整えば、そんなに時間がかかるもんじゃない。

454 ：デフォルトの名無しさん：2010/03/09(火) 02:02:23

交配できないって、陸イグアナの海イグアナの雑種みたいなもんか？

455 ：デフォルトの名無しさん：2010/03/09(火) 02:27:02

>>454
はい

456 ：デフォルトの名無しさん：2010/03/09(火) 02:37:35

何？進化論や遺伝とか取り込んだゲームでも作ろうって話？
シュミレーションゲームか？

457 ：デフォルトの名無しさん：2010/03/09(火) 02:45:56

Javaでゲーム作るとき
ＧＵＩアプリとか、ネットのアプレットとか、携帯端末のMIDletとか、で
相互に移植しやすく作るには
入出力系統を分離して設計すればＯＫ？

458 ：デフォルトの名無しさん：2010/03/09(火) 03:45:34

>>456

459 ：デフォルトの名無しさん：2010/03/09(火) 03:57:00

Javaはゲームに向いてないと思いますよ。

460 ：デフォルトの名無しさん：2010/03/09(火) 04:04:01

>>456

461 ：デフォルトの名無しさん：2010/03/09(火) 04:04:44

>>457
Javaでゲームは作れないですよ。

462 ：デフォルトの名無しさん：2010/03/09(火) 04:06:44

Javaは可能を不可能にする素晴らしいプログラミング言語

463 ：デフォルトの名無しさん：2010/03/09(火) 04:06:53

>>459,461 お前ら何を根拠にそんなこと言ってんの？

464 ：デフォルトの名無しさん：2010/03/09(火) 04:23:18

>>456}

465 ：デフォルトの名無しさん：2010/03/09(火) 04:27:58

>>463
「本格的な」という単語が抜けているだけですよ。
本格的なゲームを作りたいなら、Javaはやめておけ

466 ：デフォルトの名無しさん：2010/03/09(火) 06:31:42

>>465
「本格的な」が今あるリソースの限界まで使うような物を指しているなら同意する

467 ：デフォルトの名無しさん：2010/03/09(火) 06:34:29

じゃう゛ぁでテトリス作った俺は髪

468 ：デフォルトの名無しさん：2010/03/09(火) 07:33:32

C/C++でもリソースを限界まで使ったゲームって稀だと思うけどな

469 ：デフォルトの名無しさん：2010/03/09(火) 08:22:27

>>468
javaだとグラフィックやサウンドをnativeと同じようにさわるのは敷居が高いって事じゃろ
でもjavaでゲーム作るの向いてないとか言う子はjake2位は見ておくべきだとおもうな

470 ：デフォルトの名無しさん：2010/03/09(火) 09:34:51

>>457
Javaに限った話じゃないけどインターフェースを共通化したクラスを用意しておけばいいよ。
最近、Javaアプレットは使われなくなった気するけど・・・

471 ：デフォルトの名無しさん：2010/03/09(火) 09:37:37

>>470
インターフェースを共通化ってｗｗｗ
とりあえず、インターフェイスの概念でも勉強したらどうかね？
危険が危ないみたいなもんだよｗシロウトクン

472 ：デフォルトの名無しさん：2010/03/09(火) 10:34:13

煽るだけが能の奴がいるな

473 ：デフォルトの名無しさん：2010/03/09(火) 10:36:51

>>472
自演乙

474 ：デフォルトの名無しさん：2010/03/09(火) 10:44:54

>>456

475 ：デフォルトの名無しさん：2010/03/09(火) 10:49:08

このスレ、たまにド素人が質問してくるから嫌だ。このスレは玄人向けのスレだ

>>457　↓こっち池。これが素人向けのスレだ
Javaゲーム作成総合スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1225185820/

476 ：デフォルトの名無しさん：2010/03/09(火) 10:50:49

このスレって何の役にもたたないね

477 ：デフォルトの名無しさん：2010/03/09(火) 10:52:22

この板はプログラムを作る人のための板です。

あらゆる質問はまずすれ立てるまでもない質問はここでスレにしてください。

その他、お勉強ページへのリンクスレ、
推薦図書・必読書スレ
もあります。

プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。　　　　←★
ネタ、板とは関係の無い話題はご遠慮ください。

ローカルルール無視したスレ立てんなよ

478 ：デフォルトの名無しさん：2010/03/09(火) 10:52:35

>>476
お前みたいなもんだな
役立たず

479 ：デフォルトの名無しさん：2010/03/09(火) 10:53:33

>>1
ローカルルール無視したスレ立てんなよ

この板はプログラムを作る人のための板です。

あらゆる質問はまずすれ立てるまでもない質問はここでスレにしてください。

その他、お勉強ページへのリンクスレ、
推薦図書・必読書スレ
もあります。

プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。　　　　←★
ネタ、板とは関係の無い話題はご遠慮ください。

480 ：デフォルトの名無しさん：2010/03/09(火) 12:36:39

チラ裏だが、最近になってやっとこさ「オブジェクトにグラフィックコンテキストとか引数に持つインターフェース付けんな」
って意味がわかった。
オブジェクトはデータの構造であり、普通はデバイスにより描画方法が異なるんだから
描画メソッド持たせてたら端末ごとにクラス作り直しじゃんかバーカ、ってことに気付いた。
で、代わりにインターフェースだけ持たせておいてそのインターフェースを実装するクラスの中身だけ端末によりけり…
って方法がいいらしい。多分。

481 ：デフォルトの名無しさん：2010/03/09(火) 16:55:10

わーい

482 ：デフォルトの名無しさん：2010/03/10(水) 01:49:50

自由なゲーム製作を阻害する特許ってある？
http://pc11.2ch.net/test/read.cgi/gamedev/1107928429/

これはヤバイお

483 ：デフォルトの名無しさん：2010/03/11(木) 00:37:58

特許か、実際裁判沙汰になったことってあるのか？

484 ：デフォルトの名無しさん：2010/03/11(木) 01:23:50

>>480
おい俺にも納得の行くチラシの裏にしてくれ。
>普通はデバイスにより描画方法が異なるんだから
これは分かるし、同じデバイスでも状況によって描画方法を変える場合もある。
が、
>「オブジェクトにグラフィックコンテキストとか引数に持つインターフェース付けんな」
これって、Javaでいうvoid paint(Graphics g)なインタフェースを
否定しているように聞こえるんだけど、そうなのか？
もしそうならその理解は間違っていると思う。
JavaのGraphicsクラスは基本的な描画機能を抽象メソッドとして定義していて、
その実装は派生クラスで行うことになっている。その派生クラスで、
先の例でいうデバイス毎の描画方法の違いを吸収してしまえるわけだから。
以上反論終わり。
>代わりにインターフェースだけ持たせておいてそのインターフェースを実装するクラスの中身だけ端末によりけり…
まあこれがもしかしたらGraphicsクラスのことを表しているのかなとも思ったが、知ーらね。

485 ：デフォルトの名無しさん：2010/03/11(木) 01:41:54

「端末ごと」って記述で、言語がJavaで無いことくらい分かるやろ・・・

486 ：デフォルトの名無しさん：2010/03/11(木) 01:53:24

メッシュ等のデータに描画メソッドを持たせるなと
それだけの話

class Mesh {
　　void draw(); // ←NG !!
};

487 ：デフォルトの名無しさん：2010/03/11(木) 01:59:12

CLDC+MIDPのJavaと普通のJavaではGraphicsでさえ仕様が

488 ：484：2010/03/11(木) 03:27:11

>>485
だから何？JavaのGraphicsクラスは実装例として出しただけ。
他の言語でも同様に組めるだろ。Javaの話を持ち出すのは
頓珍漢みたいなそのツッコミの意図が理解できん。

>>486
そういった風に単純化してもらえるととても理解しやすい。
が、「オブジェクト」と意味ありげに書かれていたものが
そういったデータクラスを指すとは思わなかったんだ。
じゃあこの場合、
>代わりにインターフェースだけ持たせておいてそのインターフェースを実装するクラスの中身だけ端末によりけり…
の実装例はIDirect3DDeviceなどということで合っているかな。

>>487
大昔はあれでしょうがなかったのかも知れんが、
今にしてみれば悪い仕様でしかないな。
俺は端末性能がほどほどになった頃に
キャリア間移植性向上のために
抽象Graphicsクラスをわざわざ作ったが、
大元の基本クラスが非抽象だったせい等で
歪で冗長なクラスに仕上がった。

牛乳飲んで寝るわ。

489 ：デフォルトの名無しさん：2010/03/11(木) 05:58:10

>>486
なんで？
デメリットってあるの？

490 ：デフォルトの名無しさん：2010/03/11(木) 06:24:16

>>489
組んでみればわかるけどMeshに必要なデータ以外のものが超多くなって
このクラス何？ってなるよ
描画クラス（超大型クラス）丸ごと一個内包しなきゃいけなくなって
Meshが十得ナイフ的ウンコクラスになってしまう

491 ：デフォルトの名無しさん：2010/03/11(木) 06:38:54

うちのMeshクラスは頂点バッファとインデックスバッファ群で構成されてて
描画コール前後にbind()/release()メソッドでデバイスに一括登録/解除してるんだけど
これはあり？

492 ：デフォルトの名無しさん：2010/03/11(木) 08:10:10

メッシュクラスにgetterメソッド用意して描画処理は別のクラスなり関数で処理したほうが
依存性低くなっていいかなーと

別にmesh.draw(xxx) でも問題ないんだけど
これだけじゃ事足りないかなーってときに描画処理の為にメッシュクラスを
いじるのはあんまりよくないなってね

493 ：233：2010/03/11(木) 14:07:00

なるほど、そういうことか。
だからアレンはサラを殺したってわけね。

494 ：デフォルトの名無しさん：2010/03/11(木) 14:07:40

ごばくした

495 ：デフォルトの名無しさん：2010/03/11(木) 19:28:11

オブジェクト指向的にいってもメッシュは型がそこにあるだけだしね
描画はシーンを描画するべき
他のオブジェクトはデータを渡すのみ

496 ：デフォルトの名無しさん：2010/03/11(木) 21:13:18

ロマサガの話をこのスレでしないでください

497 ：デフォルトの名無しさん：2010/03/11(木) 22:43:24

http://codezine.jp/article/detail/4935
どうしても最適化してないC++と勝負したいようですｗｗ

498 ：デフォルトの名無しさん：2010/03/11(木) 22:56:44

条件付でC++の勝ち
には笑ったわ

499 ：デフォルトの名無しさん：2010/03/11(木) 23:00:25

かなりのC++嫌いだな

500 ：デフォルトの名無しさん：2010/03/12(金) 04:18:12

最適化なしで比較するならJavaもJIT外せよ
10倍遅くなるからw

501 ：デフォルトの名無しさん：2010/03/12(金) 04:53:27

C++嫌いというより、事あるごとにJavaは遅いって言われるのに嫌気がさしているんじゃないかね

502 ：デフォルトの名無しさん：2010/03/12(金) 06:22:31

原因が組んでる奴が馬鹿だからなのになｗ
あのアフォな文字列クラスといい人的要因でいくらでも遅くなる罠が多いのがjava

503 ：デフォルトの名無しさん：2010/03/12(金) 06:30:46

>>501
もう5年かそれ以上前から
「いやJavaは速い」って言われるようになってないか
VM噛ませるんだから起動が遅いのは仕方ないにせよ

504 ：デフォルトの名無しさん：2010/03/12(金) 06:41:26

どこが速いんだろうか？
一番ｲﾗっとくる起動時間と
一番ﾑｶっとくるゴミ収集機能が健在なのに

javaはこのどうにもならないシステムがウンコ

505 ：デフォルトの名無しさん：2010/03/12(金) 06:42:13

>>497
これ、どうみてもJavaに対する皮肉としてわざと書いてるわけだが。

506 ：デフォルトの名無しさん：2010/03/12(金) 06:49:27

>>504 はOSもCPUの保護モードも使わないでコンピュータを使えばいいと思うんだ

507 ：デフォルトの名無しさん：2010/03/12(金) 13:55:03

両者最適化して勝負すりゃ白黒つくのに
「最適化する必要があるのか？」と逃げ出すところがいいなｗ

508 ：デフォルトの名無しさん：2010/03/12(金) 14:54:41

コンパイラの性能に依存するだろ

509 ：デフォルトの名無しさん：2010/03/12(金) 15:14:23

世界中で一番遅いコンパイラの最適化でもJavaに速度で負けることはない。

510 ：デフォルトの名無しさん：2010/03/12(金) 15:34:00

>>509
悪意があればそれはないな

511 ：デフォルトの名無しさん：2010/03/12(金) 18:05:54

別スレッドで更新、描画を分けるときって
FPSに合わせて実行するのはどっち？

俺は更新だと思うんだけど・・・逆？

512 ：デフォルトの名無しさん：2010/03/12(金) 18:10:59

描写だと俺は信じてる

513 ：デフォルトの名無しさん：2010/03/12(金) 18:33:07

実際のとこスレッド分けても苦労の割に大して早くならないよね

514 ：デフォルトの名無しさん：2010/03/12(金) 19:11:32

どっちなんだろうか

515 ：デフォルトの名無しさん：2010/03/12(金) 19:26:04

ローグライクの話なんだけど
シレンみたいに攻撃するときは一体ごと順番に
移動するときはみんな同時に移動
ってのはどうやんのがスマートですかね？

516 ：デフォルトの名無しさん：2010/03/12(金) 19:46:49

シレンって攻撃フェーズと移動フェーズみたいに分かれてんの？
rogueしかやったことないから知らんが

517 ：デフォルトの名無しさん：2010/03/12(金) 20:18:16

え、何も悩む必要ないじゃん。同時移動じゃねえよ。
順番に移動／アクションしてるだけだよ。ゲームやってればわかるじゃん。

518 ：デフォルトの名無しさん：2010/03/12(金) 21:13:13

いや同時に動いてるだろ

519 ：デフォルトの名無しさん：2010/03/12(金) 21:46:40

見た目だけね。
516の言うとおり、移動フェーズと攻撃フェーズに分けりゃいいんじゃねえの。

520 ：デフォルトの名無しさん：2010/03/12(金) 22:09:32

じゃんね。

521 ：デフォルトの名無しさん：2010/03/12(金) 22:43:17

①プレイヤーがシレンの行動決定（仮に移動とする）
②シレンの移動先座標を求める（まだ移動先計算だけでキャラの移動はしない）
③シレンの移動先を目標に敵の行動を決定（ここも移動先決定のみでキャラ移動はしない）
④シレンと敵を移動先に移動させる（ここが目に見えるので一緒に移動してるように見える）
こんな感じだろ

522 ：デフォルトの名無しさん：2010/03/12(金) 23:19:21

なるほど

523 ：デフォルトの名無しさん：2010/03/13(土) 02:30:30

それって同時というんじゃね？

524 ：デフォルトの名無しさん：2010/03/13(土) 02:39:52

内部的にはターン制。見た目は同時
ただこれ見た目のテンポを良くするためのシステムなのに
一部のテクに使えてしまうんだよな
見た目とゲーム性は切り離したいが、これはなかなか上手くいかない

525 ：デフォルトの名無しさん：2010/03/13(土) 03:08:35

なにをやっても上手くいかないんだね

526 ：デフォルトの名無しさん：2010/03/13(土) 04:26:21

一部のテクに使えてしまうのが嫌ならそうならないように組めばいいじゃない

527 ：デフォルトの名無しさん：2010/03/13(土) 05:49:42

上手くいかなくてごめんなさい
出直してきます・・・

528 ：デフォルトの名無しさん：2010/03/13(土) 08:54:19

一フレーム毎に計算処理と描画処理ってのがゲームの基本なんだから、
その点を意識できれば実装方法は自ずと見えてくる。

529 ：デフォルトの名無しさん：2010/03/13(土) 09:55:05

rogueなんて、全部シーケンシャルに処理して、最後に画面全体を
再描画するだけだろう。シレンも同じさ

530 ：デフォルトの名無しさん：2010/03/13(土) 13:40:22

まぁシレンをそのまま作るのは初心者には難しいかもしれん
rogueを作ってみたらどうだろーぐ？

531 ：デフォルトの名無しさん：2010/03/13(土) 13:46:47

迷路が

532 ：デフォルトの名無しさん：2010/03/13(土) 16:32:27

２Dゲームってレイヤーのツリーを作って描画させてるのが普通なのかな？

533 ：デフォルトの名無しさん：2010/03/13(土) 16:54:00

一応ゲームプログラマー歴１５年なんだが言ってる意味が全然わからん

534 ：デフォルトの名無しさん：2010/03/13(土) 17:39:54

オーダリングテーブルで描画順を制御してプライオリティをコントロールするってことでしょ。
そうしているところもあるし、Zバッファでコントロールしているところもあると思うけど。

535 ：デフォルトの名無しさん：2010/03/13(土) 18:22:39

ＰＳ系限定？

536 ：デフォルトの名無しさん：2010/03/13(土) 18:29:59

一応ゲームプログラマー歴２日なんだが言っている意味が全然わからん

537 ：デフォルトの名無しさん：2010/03/13(土) 18:30:52

PS1とかそういう描画してなかったっけ

538 ：デフォルトの名無しさん：2010/03/13(土) 18:41:35

誰かストリーム配信でゲーム制作実況してくれ

539 ：デフォルトの名無しさん：2010/03/13(土) 18:43:51

パソコン画面をどうやって配信するの？

540 ：デフォルトの名無しさん：2010/03/13(土) 18:44:17

ニコニコの生放送でやってたな、そういうの
タラコも出てたような

541 ：デフォルトの名無しさん：2010/03/13(土) 18:45:49

>>539
Webカメラで画面映すだけだろ

542 ：デフォルトの名無しさん：2010/03/13(土) 18:48:19

wmeで君も今日から配信主だ
でも映画を流すと逮捕されるから注意しろ！

543 ：デフォルトの名無しさん：2010/03/13(土) 18:51:48

オセロやテトリスならニコ動に作ってる動画あったよね？

544 ：デフォルトの名無しさん：2010/03/14(日) 00:06:20

ああ、あれね

545 ：デフォルトの名無しさん：2010/03/14(日) 14:16:19

>>532
java.awt.ContainerとかSystem.Windows.Forms.Control
みたいに表示オブジェクトを入れ子(階層)にして管理するってことでしょ？

私はその組み方で作ってきたけど、レイヤ内の特定オブジェクトだけ
表示順位がレイヤを跨いで動的に変化するようなゲームの場合は
ちょっと綺麗な解決が出来なかった。
逆に言えば表示順位はレイヤ内だけで変化するようなゲームや
UIコントロールの管理にはうってつけだしスタンダードだと思う。

ちょっと調べてみたんだけど、FlashのMovieClipって
階層構造だけで作れるし、Z値の直指定もできるみたいだね。
こういうハイブリッドなインタフェースにしておけば、
どんな風にも組めて良いだろうね。

ところで階層構造の表示オブジェクト管理方法って何か名前はついてるのだろうか。

546 ：デフォルトの名無しさん：2010/03/14(日) 15:00:32

MovieClipとか何でもできすぎて使いづらいんだが

547 ：デフォルトの名無しさん：2010/03/14(日) 17:51:39

ところで、近年スクエニの人材募集が話題になってるけど、
実際プロからしてみてあんな人材は存在するもんなの？
思うに、日本中を探しても片手で数えられるくらいしかいないと思うんだけど。

548 ：デフォルトの名無しさん：2010/03/14(日) 18:02:13

スクエニってDQFF意外になんか仕事してんの？

549 ：デフォルトの名無しさん：2010/03/14(日) 18:06:56

>>548
俺の大好きなフロントミッションdisってんのかゴルァ

550 ：デフォルトの名無しさん：2010/03/14(日) 18:07:17

>>547
ＰＧは厳しいな
でも数年やってりゃなるんじゃね？
逆に近年スクエニより見た目劣ってるようなクオリティで出す会社ねーじゃん
ってことは誰でもできるようになっちゃうってことさ
俺は途中で業界やめちゃったけど学生終わる頃にはスキニングやバンプ辺りのシェーダは
組めたし、会社辞めるころは結構できないことはなにもないぐらいの感じはあったけどな
（でもどこも給料低すぎて続けてられなかったけど）

551 ：デフォルトの名無しさん：2010/03/14(日) 18:23:00

PGってそのスキルを活かしてほかの仕事探し他方が楽じゃねぇの？パソコン教室とか

552 ：デフォルトの名無しさん：2010/03/14(日) 18:54:24

>>550
うるさい！

553 ：デフォルトの名無しさん：2010/03/14(日) 20:48:28

パソコンを習うって発想がないわ
習うモンなのか

554 ：デフォルトの名無しさん：2010/03/14(日) 21:26:08

ほら、こんなやつらがじいさんばあさんにパソコンの使い方なんて教えられないだろ

555 ：デフォルトの名無しさん：2010/03/14(日) 21:33:27

>>551
むしろ、それっぽい資料や教材作って「これからはパソコン教室運営が儲かりますよ」と
教材とパソコンセットにして販売する商売の方が楽に儲かる。

556 ：デフォルトの名無しさん：2010/03/14(日) 22:28:41

と脳内起業家ニートが申しております

557 ：デフォルトの名無しさん：2010/03/14(日) 22:38:41

TVで詐欺被害が何千万円～とか何度も見てると、ひょっとしてリスクに見合った商売なんじゃないかって思える

558 ：デフォルトの名無しさん：2010/03/14(日) 22:56:56

お前に捌ける訳もなく。

559 ：デフォルトの名無しさん：2010/03/14(日) 23:00:11

俺はプログラムできるけど、
WORDの使い方に関してはおそらくその辺のOLレベル
Excelとパワポはそれなりに詳しい程度

よって
PG→パソコン教室はそのままでは無理

560 ：デフォルトの名無しさん：2010/03/14(日) 23:06:40

おばちゃん相手のパソコン教室でゲーム制作を教えればいいんじゃね
ビジュアルプログラミング言語を使えば、おばちゃんでも盛り上がるだろ、きっと

ビジュアルでもプログラミングの概念は同じなんだから、
おまえでも教えられるし

561 ：デフォルトの名無しさん：2010/03/14(日) 23:09:11

おばちゃんが覚えたいのがゲーム制作ならそうだろうけどよ

562 ：デフォルトの名無しさん：2010/03/14(日) 23:14:53

覚えたい、というか作ってみたい、わたしでもできそう、孫に遊んでもらおう、
って思わせるんだよ。

563 ：デフォルトの名無しさん：2010/03/14(日) 23:35:22

まえにExcelでネトゲ作って自分で遊んでる人いたな

564 ：デフォルトの名無しさん：2010/03/15(月) 03:27:52

>>563
はいはい┐(´Д｀┌

565 ：デフォルトの名無しさん：2010/03/15(月) 12:00:41

ばあちゃんじいちゃんがプログラムできるってなんかいいな
カッコイイ

566 ：デフォルトの名無しさん：2010/03/15(月) 12:05:15

オブジェクト指向の概念が全くわかりません
座標やアニメパターンとポリゴンデータを持つクラスつくって
クラスの中で自機や味方や敵や弾を仕分けすればいいのか（従来どおり？）
自機クラス、味方クラス・・・別個に作ってやればいいのか
でもポリゴンデータだけ違うだけでクラス分けるのって逆に煩雑で融通利かなくなる気が・・・

567 ：デフォルトの名無しさん：2010/03/15(月) 12:07:44

>>566
まず、機体ってsuper class作ればそこから自機なり敵機なり拡張できるでしょ
オブジェクト指向を勉強したいなら、この程度でいいでしょう

568 ：デフォルトの名無しさん：2010/03/15(月) 12:13:52

ポリモーフィズムがわからんと、クラス派生のメリットもわからんがな

569 ：デフォルトの名無しさん：2010/03/15(月) 12:15:24

Ｃでおｋ

570 ：デフォルトの名無しさん：2010/03/15(月) 12:22:32

シューティング作りたいなら、とりあえず全部abstractなクラスで
・bullet(弾)
・cannon（砲台）
・enemy(敵)
・shot(自機の弾)
・player(自機)
ってのを用意するって覚えるといいよ。

571 ：デフォルトの名無しさん：2010/03/15(月) 12:26:12

>>570
抽象なら弾は一つで事足りる

572 ：デフォルトの名無しさん：2010/03/15(月) 12:42:45

鹵獲要素を入れないなら区別した方が楽

573 ：デフォルトの名無しさん：2010/03/15(月) 12:44:45

砲台って動かないだけの敵じゃないか？

574 ：デフォルトの名無しさん：2010/03/15(月) 12:49:25

>>570はまだ勉強したてなのは分かった
少なくともインターフェイスを知らないんだろう
全て抽象クラスで実現しようとした結果、冗長となっている

575 ：566：2010/03/15(月) 12:50:00

・bullet(弾)
じゃぁ画面内外の弾の配列を、このクラスに持たせて描画とか移動処理を任すの？
それともこのクラスごと配列にしてループさせるの？

576 ：デフォルトの名無しさん：2010/03/15(月) 12:52:08

>>574
なんでそこでインターフェースが絡んでくるかイミフだろ。
全部データ構造持つのに。

577 ：デフォルトの名無しさん：2010/03/15(月) 12:56:54

>>573
少なくとも俺はenemyがcannonをN個持ってる、って構造にしてる。
（enemyには移動パターンとか耐久力情報、cannonには弾幕パターンを保持）
こうするとcannonを入れ替えるだけで弾幕パターン変えられるし。
>>575
bullet=スプライト１個分の情報と捉えれ。
普通はbullet[]で処理する。

578 ：デフォルトの名無しさん：2010/03/15(月) 12:57:31

>>576
弾、機体でインタフェースきっといた方が楽だろ
データ構造なんてその先だぞ？
そもそも抽象クラスでなんでそんなん出てくんの？低能を露呈するだけだからやめときなさい

579 ：デフォルトの名無しさん：2010/03/15(月) 12:59:22

まぁ素人玄人とじゃソースに如実に表れるしな
どっちが正しいとかより、効率を考えればどっちかはすぐ分かるはずだが
素人さんが多いようじゃな

580 ：デフォルトの名無しさん：2010/03/15(月) 12:59:32

entity
user : entity
enemy : entity
bullet : entity

581 ：デフォルトの名無しさん：2010/03/15(月) 13:02:35

こういう時にサラッと昔に書いたサンプルコードとか出せる人はいないの？
プロの書いたコードとかすごい興味あるんだけど

582 ：566：2010/03/15(月) 13:15:53

>>577
スプライト1個分かぁ
結局管理リストから移動処理描画処理させる構造化と大差がない気も・・・

583 ：デフォルトの名無しさん：2010/03/15(月) 13:19:23

まぁ低能じゃその程度なんだろう

584 ：デフォルトの名無しさん：2010/03/15(月) 13:21:50

000100
凸凸凸

　　　　　　　魚魚魚魚魚魚魚魚魚魚魚魚魚魚

　　　　　　　夫夫夫夫夫夫夫夫夫夫夫夫夫夫

　　　　　　　然然然然然然然然然然然然然然

　　　　　　／￣￣＼　　　　　　／￣￣＼　　　　　／￣￣＼
　　　　　　|　　　　 |　　　　　　|　　　　 |　　　　 |　　　　 |
　　　　　　|＿.|￣|＿|　　　　　　|＿.|￣|＿|　　　　 |＿.|￣|＿|

　　　　　　　　　　　　　　凸

どんなゲームでも記述できる構造を探すんじゃなくて、
どんなゲームを記述しようとしてるのかを決めるのが先じゃね
動く敵しか出てこないゲームなら、動かない敵を想定する必要は無いし、
地上と空中の敵を区別するのかしないのかとか、
そういう条件によっても適切な設計は変わってくるよ

585 ：デフォルトの名無しさん：2010/03/15(月) 13:25:13

低能ってか、頭の回転遅い人はプログラムやる資格ないね
他人に迷惑かけるだけだし、同じプロジェクトにいた日にゃ尻ぬぐい
まずは己を高めることが、最優先かと

586 ：デフォルトの名無しさん：2010/03/15(月) 13:26:11

とりあえずjavaで。
public interface updatable{
public void update();
}
public abstract class position{
public position(int x,int y){
this.x=x<<10;this.y=y<<10;
}
int x,y;
public int getX(){
return this.x>>10;
}
public int getY(){
return this.y>>10;
}
}
public class bullet extends position implements updatable{
int vx,vy;//１フレームで移動する量
public bullet(int x,int y,int vx,int vy){
super(x,y);
thix.vx=vx;this.vy=vy;
}
public void update(){
this.x+=vx;this.y+=vy;
}}
こんな感じ。

587 ：デフォルトの名無しさん：2010/03/15(月) 13:28:41

bullet[]よりstd::list<bullet>のがよくないか

588 ：デフォルトの名無しさん：2010/03/15(月) 13:29:56

あと、bulletはabstractにした方がいいって言ったけどありゃウソです。
ゲームループの中でnewさせるとかありえないから、bulletはbulletで既にfinalです。
面倒くさいから省略してるけど、本当はパラメータの中にax,ay(加速度)とか含みます。

589 ：デフォルトの名無しさん：2010/03/15(月) 13:31:13

>>587
最初に発射された弾から順に画面外や、衝突によって消えていくとすれば、
bullet[]をリングバッファの様に使うのもアリだと思う

590 ：デフォルトの名無しさん：2010/03/15(月) 13:33:43

>>587
よく分からんが、使用させるメモリサイズを固定＆処理時間をある程度固定させるために
あえてリストにはしないらしいぞ。

591 ：デフォルトの名無しさん：2010/03/15(月) 13:37:36

まあ俺のようなヘボグラマは無理せずlistを使うか

592 ：デフォルトの名無しさん：2010/03/15(月) 13:46:26

あと、描画処理に関しては仮想コードになるけど
public abstract class drawer{

public drawer(Graphics g,Image[] useimages)
this.g=g;
this.images=useimages;
}
private Graphics g:
public void blt(position p,int id){
g.drawimage();
}
private Image[] images=new Image[];
}
bullet[] bullets;
void render(){
for(int i=0;i<bullets.length;i++)
drawer.blt(bullets[i],DRAW_BULLET);
}
みたいにするのがいいと達した。異論は認める。

593 ：デフォルトの名無しさん：2010/03/15(月) 13:54:19

アロケータ作ればいいじゃんって思った

594 ：デフォルトの名無しさん：2010/03/15(月) 14:57:47

ポリモーフィズム??

595 ：デフォルトの名無しさん：2010/03/15(月) 15:02:20

アロケータ??

596 ：デフォルトの名無しさん：2010/03/15(月) 15:03:06

リングバッファ??

597 ：デフォルトの名無しさん：2010/03/15(月) 16:43:17

質問です
キャラクターなんかをモデラーで作ったとして
それをDirectXやOpenGLから扱うためにどうするのが一般的ですか？
色んなソフトで使われる一般的なフォーマットがあって
それに変換してからプログラムで読み込むんでしょーか？

それとも、たとえばメタセコイアで作ったとしたらmqoファイルが出来ると思いますが
みなさんこういう個別のソフトの形式のコンバータを自分で書いてるんでしょうか

598 ：デフォルトの名無しさん：2010/03/15(月) 16:45:53

>>597
directXならxファイルとテクスチャ

599 ：デフォルトの名無しさん：2010/03/15(月) 17:01:03

なるほど、調べてみます。ありがとう

600 ：デフォルトの名無しさん：2010/03/15(月) 17:11:26

OpenGLではどうすれば？

601 ：デフォルトの名無しさん：2010/03/15(月) 17:26:34

どうしようもなりませぬ。

602 ：デフォルトの名無しさん：2010/03/15(月) 19:15:34

自力で読み込む

603 ：デフォルトの名無しさん：2010/03/15(月) 19:58:49

キャラクターがリアルな動きのゲームとかありますが、あれはプログラマーが書いてるんじゃなくてモデラーが設定した動きを呼び出しているだけなんですか？

604 ：デフォルトの名無しさん：2010/03/15(月) 20:09:52

たとえばどのゲームだ？

605 ：デフォルトの名無しさん：2010/03/15(月) 20:37:14

たとえばストリートファイターIVとか

606 ：デフォルトの名無しさん：2010/03/15(月) 21:00:08

>>603
もちそんな感じ。
ただ、賢いゲームだと足首のあたりとか膝とかスカートとかが
地面／肌に吸いつくように動くものもある。

607 ：デフォルトの名無しさん：2010/03/15(月) 21:13:12

なるほど、そうだったんですか
じゃあプログラマーの査定下げておきますね

608 ：デフォルトの名無しさん：2010/03/15(月) 21:34:09

おまえの査定なんてどうという事も無いがな

609 ：デフォルトの名無しさん：2010/03/15(月) 22:37:53

そして後日、事実上の戦力外通告を受けて顔を真っ青にする>>608であつた。

610 ：デフォルトの名無しさん：2010/03/15(月) 23:10:49

［GDC 2010］GPUとCPUを併用したゲーム開発のお供に。VS2008 SP1用のデバッガ「Parallel Nsight」
http://www.4gamer.net/games/032/G003263/20100315009/
［GDC 2010］「EyefinityとCrossFireXをご贔屓に！」。AMDが両技術実装上のポイントを解説し，サポートを呼びかけ
http://www.4gamer.net/games/085/G008506/20100315027/

611 ：デフォルトの名無しさん：2010/03/16(火) 02:13:48

>>608
冗談なので安心してくださいね＾＾

612 ：デフォルトの名無しさん：2010/03/16(火) 04:10:43

>>611
いやだ

613 ：デフォルトの名無しさん：2010/03/16(火) 18:17:11

スト4のどのへんあたりがリアルに思えるんだろう

614 ：デフォルトの名無しさん：2010/03/16(火) 18:23:15

相撲取りが弱いところとか

615 ：デフォルトの名無しさん：2010/03/16(火) 23:36:07

まだ厨房の私なのですが
プログラムを使って簡単なゲームを作りたいと思っています。
まず、プログラム言語はどれから覚え始めれば効率が良いでしょうか?

616 ：デフォルトの名無しさん：2010/03/16(火) 23:39:34

中学生ならHSPでいいんじゃない？簡単だし

617 ：デフォルトの名無しさん：2010/03/16(火) 23:42:59

中学のうちからC++でもやっときゃ後から楽なんじゃね？

618 ：デフォルトの名無しさん：2010/03/16(火) 23:49:03

VB.netかHSPかね
HSPが一番簡単。本当に簡単なゲームならすぐに作れるようになる
VBやC++は汎用的で少し敷居が高い。あと導入直後の画面がごちゃごちゃしすぎ
C++は覚えれは最強だけどかなりしんどい。俺も覚えたけど結局VB使ってる
最終的にはC#ぐらいがちょうどいいんじゃね

最終的にやることは同じだし、言語ごとに記述方法や決まりが違うぐらいなので
最初は使い易い奴が一番いいと思う

619 ：デフォルトの名無しさん：2010/03/16(火) 23:56:32

HSPですか・・・
ありがとうございます。
早速じゃんけんゲームとやらを作れるまでやってみようと思います。

もう一つ、質問なのですが
なでしこはゲーム等には向いてないのでしょうか?
全て日本語なので分かりやすいんですが・・・

620 ：デフォルトの名無しさん：2010/03/17(水) 00:44:24

気に入った言語で作るのがいいよ
イライラするより、ゲームを作ることに集中できた方がいい
他の言語に手を出すのは限界を感じてからでも遅くない

621 ：デフォルトの名無しさん：2010/03/17(水) 00:53:06

若いうちならね

622 ：デフォルトの名無しさん：2010/03/17(水) 01:27:06

ふーん

623 ：デフォルトの名無しさん：2010/03/17(水) 01:29:34

日本語で出来るから簡単or分かりやすい、なんてのは幻想だから
本当に中学生なら「なでしこ以外」でおやり。
小学生でBASIC&マシン語を始めた俺の経験だと、英単語への抵抗も薄れるし。

624 ：デフォルトの名無しさん：2010/03/17(水) 01:44:18

日本語に見えるが別物の何かで書くのは「なんでそうなるの？」ばっかりで辛いと思うぞ
全部アルファベットの方がプログラムに独特の書き方も「そんなもんか」で済む。
つーか、表示が日本語のソフト作る気なら、周りがアルファベットの方が読みやすい。

漠然とゲーム作るというだけならC#あたりがいいんじゃないかね。
とりあえずググって情報収集しやすい言語を選ぶべきだと思う。

625 ：デフォルトの名無しさん：2010/03/17(水) 01:51:34

逆に英語圏の人はプルグラミングしにくそうだね

626 ：デフォルトの名無しさん：2010/03/17(水) 02:04:51

日本語識別子だとソースの横幅がビッチリ揃えられて気持ちよさそう

627 ：デフォルトの名無しさん：2010/03/17(水) 02:31:07

えげつない略し方で英語圏の人はハゲそう
stdみたいなやつってチョベリバ的な略し方なんじゃないの？

628 ：デフォルトの名無しさん：2010/03/17(水) 04:50:33

そもそも子音ヌキ頭３文字は向こうのやり方だろ？

629 ：デフォルトの名無しさん：2010/03/17(水) 04:53:42

子音って日本語じゃね？と思ったけど
スタンダードをstd
メッセージをmsg
ってのはどういう法則なんだろうか？

630 ：デフォルトの名無しさん：2010/03/17(水) 04:57:01

母音をとる
連続してるのは１つに
先頭３文字

631 ：デフォルトの名無しさん：2010/03/17(水) 05:01:22

Standardこれがなんでstd？
stnじゃないの？
向こうはnは母音なの？

632 ：デフォルトの名無しさん：2010/03/17(水) 05:05:17

nに強勢はない

633 ：デフォルトの名無しさん：2010/03/17(水) 05:56:39

マクドナルドがマックやマクドに略される感じなんだろ

634 ：デフォルトの名無しさん：2010/03/17(水) 06:38:47

>>619
個人的にはC言語（DXライブラリ）かHSPがお勧め。

>なでしこはゲーム等には向いてないのでしょうか?
向いていないことはないかもしれないがマイナーな言語なので情報量が少ない。
なでしこで作られたゲームって見たことないし。

635 ：デフォルトの名無しさん：2010/03/17(水) 09:02:46

初心者がＣ＃から始めてできるもんかね
Ｃ＋＋よりはましかもしれんが

636 ：デフォルトの名無しさん：2010/03/17(水) 09:28:59

最初から「そういうもん」で覚えられるからアリじゃない？

637 ：デフォルトの名無しさん：2010/03/17(水) 10:11:24

まず環境揃えるまでがめんどくさくて挫折する人多いと思う

638 ：デフォルトの名無しさん：2010/03/17(水) 10:48:53

XNAならダウンロード→インストールまで画面を眺めているだけでおわるけどな。

639 ：デフォルトの名無しさん：2010/03/17(水) 10:52:54

XNAの話をすんな(　ﾟДﾟ)ｳﾞｫｹ!!

640 ：デフォルトの名無しさん：2010/03/17(水) 10:53:47

>>615
初心者の最大の敵は三日坊主だと思う。
モチベーションを保つ特別な条件（友達とか）があるのでなければ、
その点を考慮すべきだと思う。

C++ や C# は独学が難しい部類に入ると思う。
最初の言語がそれらで挫折しなかった人は、特別優れた人だと思う。
ROM-BASIC でさえ、俺の周りでは、投げ出さないのは五人に一人くらいだった。
俺は消極的に javascript を推しておく。

最後に、効率云々というのは、努力を嫌がっているように見える。
経験こそが君に力を与えるから、目の前のことを頑張れ。

641 ：デフォルトの名無しさん：2010/03/17(水) 14:08:43

ActionScriptマジオススメ
フリーで環境作れるし、スプライト出して動かすくらいなら5秒で出来る。
成果がすぐにみえるってのは初学の段階では重要な点だと思う。
それなりに歴史があるからネットに転がってる情報量も多いしね。

642 ：デフォルトの名無しさん：2010/03/17(水) 14:18:26

もうXNAの宣伝はしない。
すまなかったな。

643 ：デフォルトの名無しさん：2010/03/17(水) 15:49:46

>>639
なんで怒ってるかわかんない

644 ：615：2010/03/17(水) 18:03:00

皆さんアドバイスありがとうございます
まずはHSPから始めてみます
またお世話になるかもしれませんが
宜しくお願いします・・・

645 ：615：2010/03/17(水) 18:08:57

下げてしまいました・・・
すいません

646 ：デフォルトの名無しさん：2010/03/17(水) 18:14:32

×下げ
○上げ
何度も連投すいません
あぁ恥ずかしい

647 ：デフォルトの名無しさん：2010/03/17(水) 18:26:02

>>641
wonderfl使えばブラウザだけで始められるな。
さらに人のソースの改造からスタートできるし学習にもいいと思う。

648 ：デフォルトの名無しさん：2010/03/17(水) 19:52:25

>>644
HSP を始めるなら、次はこのスレではなく HSP スレに行きなさい。
それと、2ch 以外の HSP コミュニティに打ち解けなさい。
最後に、ム板では質問の時に age て良いし、むしろその方が良い。別に怒られないし、回答が早くなる可能性が少しだけある。お礼の時は sage ると夏とか冬とか言われなくていいかも。

649 ：デフォルトの名無しさん：2010/03/17(水) 22:55:34

>>646
おまえ面白いな

650 ：デフォルトの名無しさん：2010/03/18(木) 04:33:09

ゲームはWinで動いてナンボでしょ
HSPはその点だけみても他を圧倒してるな

651 ：デフォルトの名無しさん：2010/03/18(木) 11:01:12

>>650
一行目と二行目の間で何が起こったの？

652 ：デフォルトの名無しさん：2010/03/18(木) 11:52:13

シューティングで自機が、ある敵機と衝突した場合に受ける効果をオブジェクト指向で表現しようとするとどうなる？
上の場合に限らず、キャラクタ同士が衝突した場合に互いが及ぼし合う影響の表現なんだけど。
ベタな書き方だとif文の嵐になるよね。

653 ：デフォルトの名無しさん：2010/03/18(木) 11:55:11

攻撃力とHPでいいじゃん。

654 ：デフォルトの名無しさん：2010/03/18(木) 12:12:26

アイテムだと色々な効果を与えるよね。
攻撃力とHPだけでは駄目じゃない？
アイテム系と敵キャラで明確に分けて処理してればいいかもしれんけど。
それに敵に接触した場合に特別な効果を与えたいときない？

655 ：デフォルトの名無しさん：2010/03/18(木) 12:40:06

すげえじゃん。

656 ：デフォルトの名無しさん：2010/03/18(木) 12:47:41

>>652
環境クラスをひとつ作る。

敵や自機、弾、アイテムなどが時刻 t においてある場所に存在するということは、
それらが環境のその位置に何らかの影響を及ぼしているはず。

なので、敵クラスは環境クラスに対して、自分がいまいる位置と及ぼしている影響を教える。
（たとえば、自機だけに対してダメージを与える、という影響）

自機クラスも環境クラスに対して、自分がいまいる位置と及ぼしている影響を教える。
（たとえば、接触したアイテムを自分のものにする、という影響）

環境クラスは敵クラスや自機クラスなどから及ぼされた影響を合成し、
敵クラスや自機クラスなどに対して、結果として変化した環境の状態を教える。

敵クラス、自機クラスは環境から伝えられた情報に応じて自分のステータスを変更する。

657 ：デフォルトの名無しさん：2010/03/18(木) 12:50:05

>>652
オブジェクト指向とは関係ない気がするが。
http://www.google.co.jp/search?q=%E3%83%80%E3%83%96%E3%83%AB%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81

658 ：デフォルトの名無しさん：2010/03/18(木) 13:08:49

>>656
それだと各キャラクタクラスが他のクラス（影響を与える対象）を知っていることになるよね。
キャラクタを追加するとき大変だよ。
全キャラクタクラスに手を入れなきゃ。

659 ：デフォルトの名無しさん：2010/03/18(木) 13:53:18

>>658
そんなワケない。

class Element {};
class Ship : public Element {};
class MyShip ; public Ship {};
class Enemy : public Ship {};

class World {
std::list<Element*> elements; // myship, enemies, bullets, etc...
MyShip myShip;
std::list<Enemy*> enemies;
public:
void update( float t );
};

みたいにして、World::update() の中で、個々のキャラクタを見て、一括で解決するの。
自機とか個別の敵が細かいルールを把握してたら変だろ？

例えば RPG で武器に色々な属性がある。
ある武器に毒の属性が付いているとして、その毒の処理は武器毎に実装されたルーチンを呼ぶわけではなく、武器のフラグを見て戦闘解決ルーチンが処理する。
それと一緒。

660 ：デフォルトの名無しさん：2010/03/18(木) 15:12:18

>>656の文面からでは敵機クラスが自機クラスを知っている（あるいは自機の識別子）と受け取ってしまうのだが俺だけだろうか。

ところでWorld::updateではif文中心になるの？
>>657のダブルディスパッチの応用で上手くまとまりそうな気もするけど。

661 ：デフォルトの名無しさん：2010/03/18(木) 16:14:55

実際の現場のやり方は知らないけど、コマンドパターンでいいと思う
struct command
{
virtual ~command(void) {}; virtual void operator () (Jiki &) {}; virtual void operator () (Tekki &) {};
}
っていうファンクタベースを用意して
struct add_speed : public command // 自機ならスピードアップ、敵機なら何もしない
{
void operator () (Jiki &e) {e.add_speed(m_val);}; private: int m_val;
};
みたいなサブクラスを沢山作る
敵機やアイテムはサブクラスを生成して当たり判定と関連付けてフレームごとにどこかに登録して(ついでに空間分割とか）
そんで弾や機体と衝突判定する代わりにこのコマンドと衝突判定して当たってたらダブルディスパッチで実行
例外的な挙動は自機・敵機クラスのサブクラスでポリもって解決する
これでカプセル化されてて汎用的で拡張しやすい構造になる・・・と思う

662 ：デフォルトの名無しさん：2010/03/18(木) 16:25:12

>652じゃなけど

＠は短剣を投げた、
A. オークは3のダメージ
B. スライムは3のダメージ

＠はポーションを投げた、
A. オークは3のダメージ
B. スライムに当たって跳ね返った

この「跳ね返った」の処理はポーションクラスが敵の種類を見て
if文で特別な処理を実装すればいいのですか？
それとももっとスマートな実装がありますか？

663 ：デフォルトの名無しさん：2010/03/18(木) 17:04:47

>>661
敵と弾のあたり判定とか、相互関係にある部分は？
そして誰がそのクラスを生成するの？

それ用のサブクラスを作りまくって具体的な実装をするなら、あまりにも密接な関係になるし
何より関数群作るのと効果がかわらん気がするのだが

664 ：デフォルトの名無しさん：2010/03/18(木) 17:33:09

ちょっと論点を絞ってみた。

キャラクタにはA,B,Cの三種類がある。
これらが他者と衝突した場合には、それぞれ異なる処理を行う。
例えば、AとBが衝突した場合、AにはBに設定された値分の点数を与え、Bには削除フラグを立てるなど。

665 ：デフォルトの名無しさん：2010/03/18(木) 17:38:43

>>663
当たり判定はそれ用の管理者クラスで
生成は任意のゲーム内要素が
ファンクタはインターフェースしか知らないから密接な関係にはならない
パラメータと処理をカプセル化して時間をおいた後でも使えるのが関数より便利（function、bind使うと良さがわかるとおもう）

666 ：デフォルトの名無しさん：2010/03/18(木) 17:48:36

>>664
そこがずれてるんではなくて、誰がどうやって管理しあうのかで意見が分かれてるだけ

統括的に管理する方法
・巨大なクラスになる
・拡張性が低い(何度も書き直すことになる)

ボリモー、ダブルディスパッチの方法
・上の方法よりは拡張性が高い
・全てのパターンをクラス化しなくてはならない
・このクラスを管理するクラスも作ることになるが、管理はまあ楽

普通に考えればどっちも合わせて使うかね

667 ：デフォルトの名無しさん：2010/03/18(木) 17:53:00

>>664
キャラクタを種類ごとにA,B,Cの3つに分ける。実装上はそれぞれの抽象クラスを作る。
各種類ごとに具体的な敵のクラスa,b,cを作る。それぞれA,B,Cから派生させておく。
A,B,Cについては衝突時の処理を全パターン書いておく。

新しいキャラクタdを追加しようとした際に、dの扱いがaと同じであればAを継承すれば済む。
今あるA,B,Cのどれにも当てはまらない挙動が必要ならば、新しくDを作って、
衝突の処理を書き足す。

STGなら自機、敵機、自弾、敵弾くらいの種類を作ればいいんじゃないかね。
ステージ上の障害物も必要かもしれんが、これは別の扱いをするのも手。

668 ：デフォルトの名無しさん：2010/03/18(木) 18:25:01

>>665
なるほどね

ただ、俺だったらスピード操作とかpublicな関数にしたくないから継承使うけど

669 ：デフォルトの名無しさん：2010/03/18(木) 18:46:32

More Effective C++ではmapとtype_info::name()で仮想関数をエミュレートして
多重ディスパッチする方法を紹介してるね

670 ：デフォルトの名無しさん：2010/03/18(木) 18:47:46

template使えば簡潔になるよ

671 ：デフォルトの名無しさん：2010/03/18(木) 18:49:32

>>669
テンプレートテクニックにも仮想関数テーブルの作成方法がのってたな

672 ：デフォルトの名無しさん：2010/03/18(木) 19:21:39

型消去つかったポリモーはオーバーヘッドのコストが仮想関数の３倍くらい多かった
コンパイル時に頑張ってるのに実行時で遅くなるとかアホかと

673 ：デフォルトの名無しさん：2010/03/18(木) 20:21:16

アホがアホといった

674 ：デフォルトの名無しさん：2010/03/18(木) 20:23:41

>>667
その衝突時の処理は何処に書くかだよね。
各クラス内だとキャラクタの種類を増やしたときに全キャラクタクラスに追加するキャラクタに
対する処理を追加しないといけない。
出来るだけ既存のクラスには手を入れたくないよね。

675 ：デフォルトの名無しさん：2010/03/18(木) 20:41:19

衝突判定だけを別にしたクラスを作りそれをいろいろ派生させ、
敵クラスはその衝突判定クラスを持つというやり方もある

676 ：デフォルトの名無しさん：2010/03/18(木) 21:58:49

あるね。

677 ：デフォルトの名無しさん：2010/03/18(木) 23:34:45

ベタに書きゃいいのに。
なぜバグを仕込みたがるかね。

678 ：デフォルトの名無しさん：2010/03/18(木) 23:37:00

ベタに書くとあとでバグの元になるからじゃないの？

679 ：デフォルトの名無しさん：2010/03/18(木) 23:42:51

そのベタな書き方ってのを知らないだけじゃ？

680 ：デフォルトの名無しさん：2010/03/19(金) 00:18:39

１種類の判定方法ならベタでも全然行けるが
種類によって判定方法がいくつかあるのをどうするかって話じゃないの？

681 ：デフォルトの名無しさん：2010/03/19(金) 00:28:21

ベターって書くんでしょ

682 ：デフォルトの名無しさん：2010/03/19(金) 00:29:22

class Base {
virtual void OnCollide(自分, 相手) = 0;
};
class A : public Base {
void OnCollide(自分, 相手){実装する.}
};
class B : public Base {
void OnCollide(自分, 相手)実装する{}
};

if(AとＢが衝突){

683 ：デフォルトの名無しさん：2010/03/19(金) 00:29:26

ポリモーフィズムがなぜ有効なのか語れる人間は実はあまりいない

684 ：デフォルトの名無しさん：2010/03/19(金) 00:30:21

if(AとＢが衝突){
A->OnCollide(A, B);
B->OnCollide(B,A);
}
みたいんじゃだめ？

685 ：デフォルトの名無しさん：2010/03/19(金) 00:32:25

そのifがどこのクラスにあってA/Bがどこにあるか聞いてるんじゃないの？

686 ：デフォルトの名無しさん：2010/03/19(金) 00:39:05

コリジョン管理クラスみたいのがあってそいつがやる
Collision.Add(A);
Collision.Add(B);

Collison.Update() この中でif文→コールバックされる

687 ：デフォルトの名無しさん：2010/03/19(金) 00:48:23

それは>>669で挙げた本でもやってるよ。
暇なときにでも立ち読みするといい。

688 ：デフォルトの名無しさん：2010/03/19(金) 00:57:03

>>687
なるほど、Moreじゃない方しか持ってないんだよなあｗ

689 ：デフォルトの名無しさん：2010/03/19(金) 01:12:25

>>684
なんで引数に自分のアドレスわたしてるの？

690 ：デフォルトの名無しさん：2010/03/19(金) 01:15:40

ああ、いらないなあ。深く考えずに書いてしまった。

691 ：デフォルトの名無しさん：2010/03/19(金) 01:32:44

>>684
引数に相手が必要ってことは
関連しあうオブジェクトのクラスが動作に必要ってことだろ？
コンパイルするだけでもそいつ必要になんじゃん
切り出して単体テストできねーよ
あんまりうまくない設計だな

基本的にＡとＢの関連しあうものが存在するときは
それを包括するＣが必ず必要になる
それはゲームによってシーンだったりステージだったり・・・
ＡにＢを持たせるのもＢにＡを持たせるのもよくない
２つの関連するものがあるときは必ず別のクラスを用意すると綺麗にいく
覚えておくと便利だぞ

692 ：デフォルトの名無しさん：2010/03/19(金) 01:37:56

じゃあif(check_coll(A, B)) on_coll(A, B);のほうがいいのか

693 ：デフォルトの名無しさん：2010/03/19(金) 01:50:49

class Base {
virtual void SetDamage(int) = 0;
virtual int GetAttack() = 0;
};
class A : public Base {
void OnCollide(相手){ SetDamage(相手->GetAttack());.}
};
みたいにすれば相手のこと知らなくてもいいんじゃない？
（Ｂａｓｅを継承した何かとだけ知っている）

694 ：デフォルトの名無しさん：2010/03/19(金) 01:58:48

今してるのは何と何が衝突したかは分かるようにする前提の話だと思うけど
何かに当たってダメージがいくつ入るかだけ分かればいいなら、それでいいと思う
シューティングとかね

695 ：デフォルトの名無しさん：2010/03/19(金) 01:59:51

一方ゲームプログラマーはCでさっさと実装した

696 ：デフォルトの名無しさん：2010/03/19(金) 02:10:58

iいろいろできると思うけどなあ
class Base {
virtual bool IsEnemy() = 0;
};
class EnemyBase : public Base { bool IsEnemy() { return true; } }
class EnemyA : public EnemyBase{}
class EnemyB : public EnemyBase{}
class A : public Base {
void OnCollide(相手){
if(相手->IsEnemy()){
EnemyBase *e = static_cast<EnemyBase *>(相手);
e->...
}
};
とかすればEnemyBaseは必要になってしまうけど、EnemyAなのかEnemyBなのかまでは知らなくて済む。

697 ：デフォルトの名無しさん：2010/03/19(金) 03:22:05

それぞれのクラスに、衝突用の型ID持たせて、
衝突判定用関数ポインタ入れた２次元マップから、
２つのオブジェクトの型IDで関数ポインタ取得してそれに突っ込むってのはだめ？

衝突用以外の用途にもそれ用の型ID持たせておけばいいような。

オブジェクト指向的には、用途ごとの基底抽象クラスを用意して、
複数継承するのかな？

excelとかで管理しといて、コード生成とかさせておけば
継承構造とかなくても見通しはいいと思うなぁ。

698 ：デフォルトの名無しさん：2010/03/19(金) 03:33:46

ストラテジでええんちゃうのん

699 ：デフォルトの名無しさん：2010/03/19(金) 04:41:13

何難しく考えてんのお前ら

こまけぇこたぁいいんだよ

700 ：デフォルトの名無しさん：2010/03/19(金) 04:51:29

>>696
EnemyCだけ特殊な処理したいときはIsEnemyCを用意するの？

701 ：デフォルトの名無しさん：2010/03/19(金) 06:41:45

>>693
そうやって無駄に回避することになんの意味があるの？
結局、その関数内でそいつの情報が必要なら
強制的にインターフェースを固定したところでそれはvoid*と変わらないじゃない
ようはそういう言語レベルの小手先の回避を言いたいんじゃなくて
動作に相手が必要になっちゃうその設計の糞さについて考えてほしいわけよ
ぶっちゃけカプセル化できてないじゃない
ちゃんと閉じた世界を構築しなきゃダメよ

702 ：デフォルトの名無しさん：2010/03/19(金) 08:45:41

>>701
同意
実はこの問題ってなんだかんだで上手い実装方法ないんだよな
だから面白いんだけど

ベースクラスはいるとしても、特殊な動作やインターフェースクラスを用意してやるのもいいかもしれない

struct EmemyInterface : public Enemy
{
// 毒操作
// collision用データを返すとか
};

c++ならテンプレート使ったらもっと汎用的にできる

703 ：デフォルトの名無しさん：2010/03/19(金) 08:47:40

ああ、継承はpublicじゃなくてprotected

704 ：デフォルトの名無しさん：2010/03/19(金) 08:58:52

全部グローバル変数の配列で、ifで比較しまくりでいいじゃん
くらだんところで悩むとゲーム完成しないぞ

705 ：デフォルトの名無しさん：2010/03/19(金) 09:01:04

ある本じゃオブジェクト指向のカプセル化とは、可能な限り閉じたクラス化
privateなメンバ変数やfriendを使用しないクラス化を行うこととある
極力修正しなくていいように設計する

そうすることで単体でテストも可能だし
その作成したクラスをミドルなライブラリとして使い回しできる
もし修正が必要になったら、直接修正するのではなく
継承先で処理を追加するようにしていく

これだけでもかなり効率があがるし
凡ミスもかなり減る
だからコピペ実装はしない

706 ：デフォルトの名無しさん：2010/03/19(金) 10:49:29

>>696
それじゃあ新しいキャラクタを追加するときに全キャラクタクラスを修正しなきゃいけないから駄目では？

707 ：デフォルトの名無しさん：2010/03/19(金) 18:31:25

インターフェースくらい使えよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

708 ：デフォルトの名無しさん：2010/03/19(金) 20:13:07

>>707
だから小手先の技術についての話はしてないってば
あっちいってろばーか

709 ：デフォルトの名無しさん：2010/03/19(金) 23:53:39

インターフェイスは小手先の技術じゃなくて
重要な設計要素だろ。UMLにもあるぞ。

710 ：デフォルトの名無しさん：2010/03/20(土) 01:23:10

まさかインターフェースを挟まずに裸のまま使ってるのか？
面倒なことするなあ(笑)

711 ：デフォルトの名無しさん：2010/03/20(土) 01:23:52

簡単なゲームなら設計とかしない面倒

712 ：デフォルトの名無しさん：2010/03/20(土) 01:26:08

>>711
十二分に開発した経験があるならな
ないならスパゲティの出来上がり

713 ：デフォルトの名無しさん：2010/03/20(土) 01:26:40

根拠が「本に書いてあった」
お前が誤解してるだけじゃ

714 ：デフォルトの名無しさん：2010/03/20(土) 01:33:54

>>709
なんないよ
結局はそのクラスで抱え込むかどうか
インターフェースなんぞあろうがなかろうが設計の本質には微塵も影響しない

715 ：デフォルトの名無しさん：2010/03/20(土) 01:37:38

全部一人で作るなら結局同じことな気もする

716 ：デフォルトの名無しさん：2010/03/20(土) 01:37:51

つか、別にどんなに小規模でもUMLで懸命に設計する必要があるとかじゃないけどな。
JAVAで言うインターフェースが重要なんじゃなくて、仕様変更で入出力の設計を大幅に
変えなきゃいけないようなのはダメだし、頭の中だけでも拡張性を考えておくのは当然だな。

717 ：デフォルトの名無しさん：2010/03/20(土) 01:40:13

>>716
拡張性や汎用性なんか考えて組むのは素人
必要なものを必要なだけ組むのが真のプロ

718 ：デフォルトの名無しさん：2010/03/20(土) 01:47:15

>>717
それは工場のラインを支えてるような熟練工だな。
分野が違うんだろうけど、ゲームにおいてはそんなＰＧは長くやれない。

719 ：デフォルトの名無しさん：2010/03/20(土) 01:54:15

>>718
馬鹿じゃねぇの
もう１０年近くＰＧやってんすけど？
納期残り１ヶ月、あ、このマップ２Ｄ→３Ｄにします
の変更を人生で３回ぐらい経験します他ｗ

はっきりいうけど自分が想定してる範囲の仕様変更なんざ仕様変更に入らない
最小限で作る→仕様変更→関係部分の組んだコードは思い切ってすべて捨てる→新しく組む
のが絶対速い

720 ：デフォルトの名無しさん：2010/03/20(土) 01:57:15

ゲームってころころ仕様が変わるから拡張・変更に強い設計を心がけろ、みたいなことどっかで読んだ記憶があるんだが

721 ：デフォルトの名無しさん：2010/03/20(土) 01:57:22

俺１５年選手だけどｗ同意。
XPって流行ったよね。あれなかったことにされてる気がする。

722 ：デフォルトの名無しさん：2010/03/20(土) 01:59:47

>>719
そりゃその方が速いさ。自分一人ならな。
どのような仕様変更がある可能性があって、それが他の人でも対応できるかどうかを
考えたら、そんな「俺様最強」なことは言えないよ。君は優秀なんだろうけど、あと10年
くらいやればわかると思うよ…

723 ：デフォルトの名無しさん：2010/03/20(土) 02:00:26

>>720
・変化を抱擁せよ
・You Aren't Going to Need It（今必要なことだけ行う）。
という開発手法が存在する。

724 ：デフォルトの名無しさん：2010/03/20(土) 02:05:20

なんかインタフェースという単語が2つのレベルで使われてる気がするんだが。

一つは複数のオブジェクトの共通の性質という設計上の概念。
もう一つはC++やJavaなどで使う基底クラスとかの意味での（実装レベルの）インタフェース。

>>714の言うように、実装レベルでどのようなインタフェースクラスを使うかは設計とは関係ない。
一方で、設計上オブジェクトがどのような共通の性質を持っているべきかを定義しておくことで
オブジェクトの責任範囲を明確化することができる。これは>>709の言うように重要な設計要素。

725 ：デフォルトの名無しさん：2010/03/20(土) 02:08:45

>>722
黙れ
上の例でもそうだけど
こんな１つのキャラを動作させるのに別のキャラのソースが必要みたいな
汚く粘ついたクラスなんて言語道断なんだよ
こういうのはいざ捨てるときに綺麗に捨てられない
カプセル化をやるなら極限までやれ

自機のクラスのメソッドの引数に敵のクラスなんてついてるようなのは設計うまくない変更に弱い
いざその敵捨てたときに全然関係ない自機までいじってるとか存在自体が邪魔なＰＧ

726 ：デフォルトの名無しさん：2010/03/20(土) 02:10:00

>>719
俺もそう思う。
かっこいい仕様のインターフェース作るのは、
それを売りにしたライブラリ作ってる人ぐらいでいいと思う。

で、思い切って捨てるっていっても、本当にゴミ箱行きじゃなくて、
どっかに保存はしておいて、いずれ必要になったら参考にするっていう
再利用の仕方でもいいと思う。

727 ：デフォルトの名無しさん：2010/03/20(土) 02:12:03

設計も基礎研究も給料泥棒なのか効率化に貢献してるのかわからない

728 ：デフォルトの名無しさん：2010/03/20(土) 02:17:01

>>725
いや、その個別のケースについてどうこう言ってるわけではないんで気にしないでくれｗ
敵であるか自機であるか、ってのは本来ゲームプログラミングにおいて別のクラスにする
必要も無いわけだからｗ

まあ別にしてもいいけど、共通化されたオブジェクトを継承する形とかにしないと自機をCPUに
切り替えて眺めるなんてオプションも簡単に出来ないわけで…

729 ：デフォルトの名無しさん：2010/03/20(土) 02:18:06

熱いスレだな

730 ：デフォルトの名無しさん：2010/03/20(土) 02:20:37

結局「適切なレベルで抽象化された問題に固有のコードを書くのが一番」なんて
危なげない結論に落ち着きそうだな。
「適切なレベル」って言葉に全ての問題を押し込めただけなんだがｗ

731 ：デフォルトの名無しさん：2010/03/20(土) 02:21:40

自機や敵べったりにしないためにインターフェースかますんじゃないの？

732 ：デフォルトの名無しさん：2010/03/20(土) 02:25:18

どうきれいに作ろうが、面白くなければ糞ゲー
存在する価値なし

733 ：デフォルトの名無しさん：2010/03/20(土) 02:27:24

それを言っちゃあおしまいよ

734 ：デフォルトの名無しさん：2010/03/20(土) 02:28:40

ごもっともだがここはム板だ

735 ：デフォルトの名無しさん：2010/03/20(土) 02:29:31

>>731
君はJAVAプログラマーかも知れないが、じゃあそれをCでどう書くのってのも考えて置いた方が幅が出るよ。

>>730
その危なげない結論に至る過程で、みんな考えるんじゃないの？
同じ環境・スタッフでやってるわけじゃないから。

>>732
その通り。結果がすべて。だが、それを続けるためには、それだけではない。
俺の屍を越えて行け、ってやつ？ｗ

736 ：デフォルトの名無しさん：2010/03/20(土) 02:54:32

>>735
> 君はJAVAプログラマーかも知れないが、じゃあそれをCでどう書くのってのも考えて置いた方が幅が出るよ。
今はC++使えばいいわけで、あんまり意味無い気がする。

737 ：デフォルトの名無しさん：2010/03/20(土) 03:17:59

>>736
Cと言ってる。古臭くてどうにかしろよ！とか言っても、パチスロ系やらキッズ向けとかの端末では、
C++じゃダメってのも、かなりあるみたいだよ。俺はその分野はやったこと無いけど。

まあ少なくとも、単一プラットフォーム(日本ではゲームコンソールが極端に発達したからね)で商売になるから
いいや、って時代は終わった。想定しうるすべてのプラットフォームを考えると、基礎的なライブラリをCで書いて
置くのが、一番融通が利くってのは皮肉な話だね…

738 ：デフォルトの名無しさん：2010/03/20(土) 03:42:55

どの言語の話か限定されていないからみんなの意見が平行線なんだな

739 ：デフォルトの名無しさん：2010/03/20(土) 03:57:32

世の中は進んでいるようでいていまだに携帯端末や組み込みなんかのＣ＋＋の言語仕様にびっくりする
テンプレートなんてそもそも動かないしなｗ
標準～とか書いてあるもん大抵ダメだしｗ

740 ：デフォルトの名無しさん：2010/03/20(土) 04:19:22

>>737
> C++じゃダメってのも、かなりあるみたいだよ。俺はその分野はやったこと無いけど。
ねーよ。だって最悪 gcc で済むんだぜ？

糞コンパイラベンダを生き長らえさせるためにC縛りを強要されるってんなら
ご愁傷様としか言えないが、それが世間一般だと思われては困る。

741 ：デフォルトの名無しさん：2010/03/20(土) 04:37:00

>>740
俺は関係無いが、gccで何でも済むと思ってるのが間違いだし、それでIO周りが書けるなら、
世話ないだろｗ　悪いがキャリアのあるゲームPGとは間違っても思えないな。

糞コンパイラベンダでも何でもいいが、そんなのは君のオナニーであって、君の理想が何の
言語だか知らんが、その理想の言語でGPUプログラミングしたらいいんじゃねえの？ｗ

742 ：デフォルトの名無しさん：2010/03/20(土) 04:45:34

test ♥

743 ：デフォルトの名無しさん：2010/03/20(土) 05:05:03

>>741
gccで何でも済むと思ってるのも間違いだし、Cしか使えないのが当然だと思ってるのも間違い。

744 ：デフォルトの名無しさん：2010/03/20(土) 05:57:24

グローバル使わんといろいろと面倒臭いんだよな
名前空間じゃ駄目？

745 ：デフォルトの名無しさん：2010/03/20(土) 06:48:44

>>744
駄目！

746 ：デフォルトの名無しさん：2010/03/20(土) 14:01:39

台形とか星型とか閉じた図形の中にランダムでN個の点を発生させたいんですがどうやったらいいですか？

747 ：デフォルトの名無しさん：2010/03/20(土) 14:09:44

図形を含んだ正方形の点をランダムに発生させて
その点が閉じた図形の中になかったら再発生させる。
これをＮ回繰り返す。

748 ：デフォルトの名無しさん：2010/03/20(土) 14:24:51

四角の中に点をN個ランダムに打って
図形にあわせて角を変形させる。
位置がいまいち？シラネ。

749 ：デフォルトの名無しさん：2010/03/20(土) 14:28:31

図形がシンプルなら逆関数法の方がいい

750 ：デフォルトの名無しさん：2010/03/20(土) 14:32:10

"三角形内のランダム点"ができれば、他のもできそうね。

751 ：デフォルトの名無しさん：2010/03/20(土) 14:37:15

>>747
>>748
>>749
>>750
みなさん素早いレスありがとうございます。
もう少し具体的に言うと、閉じた図形は辺で構成されていて、各頂点の座標は既知です。
最初は747さんのような方法をやろうと思ったのですが、一発でやる効率的な方法はないかと思いまして。

752 ：デフォルトの名無しさん：2010/03/20(土) 14:55:45

点をおきたい範囲の座標に対応した乱数テーブル作って、乱数で割り当てるじゃ駄目なの？

753 ：デフォルトの名無しさん：2010/03/20(土) 14:56:24

裏で同じ図形のビットマップを描画、たとえば白背景に黒い図形など
調べたい座標の色を取得
黒なら図形内

デメリット：裏の図形のメモリおよび描画のコストが掛かる

754 ：デフォルトの名無しさん：2010/03/20(土) 15:01:33

画像化なんかしないで、boolかビットフラグをwidth*heightが収まる分だけ用意すりゃいいじゃん

755 ：デフォルトの名無しさん：2010/03/20(土) 15:41:00

その用意した奴の中に図形の情報埋めるには
自前でPolyline＋Fill、またはPolygonする処理を書く必要があるんじゃねーの？

756 ：デフォルトの名無しさん：2010/03/20(土) 16:00:40 BE:732980328-2BP(1346)

このスレ
胸が暑くなるな

757 ：デフォルトの名無しさん：2010/03/20(土) 16:10:56

取りあえず考えてみた
まず図形を三角形の集まりに分解する
ランダムに図形内の点を選ぶ場合はまずそれらの三角形のどれかをランダムに選ぶ
選び方としてはそれぞれ等しい確率で選ぶか、あるいはその三角形の大きさに比例した割合で選ぶのもいいかもしれない
次にその三角形内のランダムな点を選ぶわけだが
仮にその三角形をＯＡＢ、ベクトルＯＡ＝a、ＯＢ＝b、
三角形内の点をＰとすると
ＯＰ＝s(1-t)a + stb　ただし 0 ≦ s ≦ 1、0 ≦ t ≦ 1、
ゆえにランダムな点Ｐを求めるというのは
s, t を 0 ≦ s ≦ 1、0 ≦ t ≦ 1 の範囲でランダムに決めるということに帰着できる

758 ：デフォルトの名無しさん：2010/03/20(土) 16:26:17

じゃあ次は曲線図形の場合を考えてください

759 ：デフォルトの名無しさん：2010/03/20(土) 16:30:38

>>719
インターフェースしっかりしとけば全部書き直す必要もない
君は実に馬鹿だなあ

760 ：デフォルトの名無しさん：2010/03/20(土) 16:32:57

曲線を小さな直線の集まりと近似すれば直線図形のやり方に帰着できる
それが嫌なら大分複雑になる

761 ：デフォルトの名無しさん：2010/03/20(土) 16:36:08

まあ円とかなら曲線でも複雑にはならないけど
一部が円とかね

762 ：デフォルトの名無しさん：2010/03/20(土) 16:42:06

>>719
単純に背景描画を3Dにするだけなら楽じゃね？
インタラクションがあるなら手間かかると思うけどね。

763 ：デフォルトの名無しさん：2010/03/20(土) 16:45:29

矩形に適度な密度で点描→マスクつけてBlt
ぴったりN個じゃなくてもいいならこれでいいんじゃね？
コードが簡単にかけて、写像計算も棄却チェックも要らないからその分速いだろうし

764 ：デフォルトの名無しさん：2010/03/20(土) 18:16:07

>>757
素晴らしいですね！！ありがとうございます！！

765 ：デフォルトの名無しさん：2010/03/20(土) 18:17:07

>>763
ぴったりN個必要だったのでそれができなかったんです

766 ：デフォルトの名無しさん：2010/03/20(土) 18:25:42

>>757は三角形内の密度に偏りがでるね

767 ：デフォルトの名無しさん：2010/03/20(土) 19:54:55

凸包という縛りがないと三角形に分ける部分がやっかいにならない？

768 ：デフォルトの名無しさん：2010/03/20(土) 19:58:43

そもそも点だけ与えられて、凹の場合、形は一意に決まらないよ

769 ：デフォルトの名無しさん：2010/03/20(土) 20:02:17

順番があれば決まる

770 ：デフォルトの名無しさん：2010/03/20(土) 20:03:31

閉じた図形としか書いてないな、点と結ぶ順番が与えられているなら凹もありえるんじゃ？

771 ：デフォルトの名無しさん：2010/03/20(土) 20:34:26

凹も考慮するのは当然でしょ

772 ：デフォルトの名無しさん：2010/03/20(土) 20:53:58

2Dゲームって基本的にビルボードにスプライトなの？

773 ：デフォルトの名無しさん：2010/03/20(土) 21:01:06

>>772
そんなことない
なんでもできるじゃん
背景無駄に３Ｄで操作性だけ２Ｄとかあるじゃない

774 ：デフォルトの名無しさん：2010/03/20(土) 21:54:29

ソース書いてると
全体の構造がつかめなくなってきて
２重構造、３重構造なんてあたりまえで
４重構造とかになっていくんだけど
どうやって、仕様把握してる？

775 ：デフォルトの名無しさん：2010/03/20(土) 22:03:33

どういうこと？
仕様を把握してるからソースを書いてるんじゃないの？

776 ：デフォルトの名無しさん：2010/03/20(土) 22:16:47

問題を分割するのは設計の基本

777 ：デフォルトの名無しさん：2010/03/20(土) 22:17:17

>>774
ゲームの仕様って、プログラム的な構造まで決める物じゃないでしょ？

プログラムの仕様ってなら、そんなの知らんｗ
お前さんの腕が無いんじゃね？

778 ：デフォルトの名無しさん：2010/03/20(土) 22:41:19

>>777
うざい

779 ：デフォルトの名無しさん：2010/03/20(土) 22:58:50

フリゲで月夜に響くノクターンみたいなＲＰＧを作りたい。
でも知識ゼロ。
どこから覚えて言ったらいいだろう……？
パソコン知識も豊富とは言えないんだ。

780 ：デフォルトの名無しさん：2010/03/20(土) 23:03:36

まずそのゲームが何で作られてるか調べたら？

781 ：デフォルトの名無しさん：2010/03/20(土) 23:11:49

RPGツクールで作られてるみたいだね。

782 ：デフォルトの名無しさん：2010/03/21(日) 00:07:19

別に凸でも凹にも関係なくできるのだが
直線の図形であればどんな形であれ三角形に分割できるだろ
あと三角形内の密度に偏りが出るというけど
Ｏを３つのなかからランダムで選ぶことである程度は解決できないだろうか

783 ：デフォルトの名無しさん：2010/03/21(日) 00:14:13

確かに数学的には三角形に分割できるけど、どんな形状でもきっちり重ならない三角形に分割するアルゴリズムが難しいんじゃねーの？

784 ：デフォルトの名無しさん：2010/03/21(日) 00:14:45

ああ、多分三角形の分割も計算で出そうということなのか
それなら確かに凸の方が計算しやすいだろう
でも俺が言いたいのは何でもかんでもプログラムで出す必要はないというわけ
別に三角形の分割位なんて自分で与えるのもそう難しいことじゃないから自分で与えればいいというわけ
大体どうとでも分割できるでしょ
そこは自分で適当に与えましょうよ

785 ：デフォルトの名無しさん：2010/03/21(日) 00:24:31

そのスタンスはＰＧとしてどうなんだ

786 ：デフォルトの名無しさん：2010/03/21(日) 00:24:48

多角形の形が実行前にわかってるとは限らないだろ

787 ：デフォルトの名無しさん：2010/03/21(日) 00:28:54

逆に何でもプログラミングすればいいと思ってないか
自分で簡単にできることでもわざわざ手間暇かけてプログラミングするＰＧの方がどうかと思うよｗ
＞多角形の形が実行前にわかってるとは限らないだろ
＞各頂点の座標は既知

788 ：デフォルトの名無しさん：2010/03/21(日) 00:31:50

問題が１０００問出されたらどうする？
楽するために苦労しようぜ

789 ：デフォルトの名無しさん：2010/03/21(日) 00:36:14

大体多角形も自分で与えるんだろ
それをいくつか分割した三角形与えるのと似たようなもんだろｗ

790 ：デフォルトの名無しさん：2010/03/21(日) 00:36:19

描画する可能性の有る座標をデータにしておけば
実行時には乱数生成とデータ読み込みのコストしかかからない
俺は天才かもしれない

791 ：デフォルトの名無しさん：2010/03/21(日) 00:39:04

三角形への分割なんて凸も凹も関係ないと思うが。

792 ：デフォルトの名無しさん：2010/03/21(日) 00:43:54

>>784
適当なレスだなぁｗ

793 ：デフォルトの名無しさん：2010/03/21(日) 00:48:35

>>791
どうやんの？
データは点の座標と順番だけでできるもんなのかな

794 ：デフォルトの名無しさん：2010/03/21(日) 00:58:39

>>789
例えば、
1000. // 問題数
10, // 問題0の頂点数
0, 0 // 頂点0
....
みたいなフォーマットで与えられたらアウトじゃね？

795 ：デフォルトの名無しさん：2010/03/21(日) 01:10:09

それはそれだけ自分で多角形を与えることが大変なのであって、プログラムとは無関係なのではｗ

796 ：デフォルトの名無しさん：2010/03/21(日) 01:17:52

いやここから手で三角形分割を１０００問分やるんでしょ？
人間がやるんじゃ一旦絵にしてみないといけないだろうし

797 ：デフォルトの名無しさん：2010/03/21(日) 01:32:06

多角形作るにしても一旦絵にしてみないと分からないでしょ
そっから適当に頂点繋げるだけでしょ
あるいは適当な内点と頂点繋いだり
多角形１０００個作るのと大差ないよ

798 ：デフォルトの名無しさん：2010/03/21(日) 01:34:50

ＤＣＣツールなどで作ったデータかもしれない。
自分の作ったものでも単なる数値の羅列になる可能性はある。

799 ：デフォルトの名無しさん：2010/03/21(日) 01:38:23

多角形を自動で生成するかもしれない

800 ：デフォルトの名無しさん：2010/03/21(日) 01:46:55

相変わらずレベル低い

801 ：デフォルトの名無しさん：2010/03/21(日) 01:47:49

すげーいいこと思いついた。
手で三角形分割するんなら、Ｎ個の点も手で打てばいいんだよｗ

802 ：デフォルトの名無しさん：2010/03/21(日) 01:47:51

ではレベルの高い解答お願いします

803 ：デフォルトの名無しさん：2010/03/21(日) 01:57:46

ここから先は有料になります

804 ：デフォルトの名無しさん：2010/03/21(日) 01:58:15

図形は手で与えるものだから
Ｎ個の点はランダムで与えるものだから全く話が違うでしょｗ

805 ：デフォルトの名無しさん：2010/03/21(日) 02:00:21

ばかだなぁ
パターンを網羅してランダムに一つ選ぶんだよ

806 ：デフォルトの名無しさん：2010/03/21(日) 02:07:13

多角形の中でも外でも気にせずにドット打ちゃいいんだよ
ｎ個とか気にしちゃいけないんだよ
文句言ってきたら殴れ

807 ：デフォルトの名無しさん：2010/03/21(日) 02:12:57

ＰＧらしい回答ありがとうございます

808 ：デフォルトの名無しさん：2010/03/21(日) 02:17:17

馬鹿はあんただろｗ
てめえが質問者じゃねえだろ
俺は質問者の意図を汲み取ってそれに対する答え出しただけで
てめえの意図する質問に答えてんじゃねえんだよｗｗｗ

809 ：デフォルトの名無しさん：2010/03/21(日) 02:20:13

馬
て
俺
て

810 ：デフォルトの名無しさん：2010/03/21(日) 02:24:30

　鹿
　め
　は
　め

811 ：デフォルトの名無しさん：2010/03/21(日) 02:27:53

結論
手で分割して、最後は殴る。

812 ：デフォルトの名無しさん：2010/03/21(日) 02:32:48

効率的なら素直に最初の方法でやったほうがいいなあ
ピクセルでラスタライズ(だっけ)したときに、ピクセルシェーダでランダム点作成すればできないこともない

813 ：デフォルトの名無しさん：2010/03/21(日) 02:34:14

厳密な頂点データを作成できないから駄目だけどね

814 ：デフォルトの名無しさん：2010/03/21(日) 02:37:15

>>812
描画するだけならいいかもな

815 ：デフォルトの名無しさん：2010/03/21(日) 02:38:05

ピクセルシェーダで今自分が何個目の点かって分かる？

816 ：デフォルトの名無しさん：2010/03/21(日) 02:39:29

>>774
いってる意味がわからない
相互的に作用してるから何重構造とかいってんの？

817 ：デフォルトの名無しさん：2010/03/21(日) 02:40:37

>>815
ピクセルシェーダ自体で数えさせて取得すればいいじゃん
で、も一つのシェーダで描画

818 ：デフォルトの名無しさん：2010/03/21(日) 02:42:07

>>817
並列に動作しているから排他制御とかしてやらないとカウントできなくないかな？

819 ：デフォルトの名無しさん：2010/03/21(日) 02:46:43

ああ、Ｎ回描画してやればいいのか。

820 ：デフォルトの名無しさん：2010/03/21(日) 02:51:11

>>818
そんなに詳しくないからわからんが
一つのメッシュで一つのカウント格納先にすればいいんじゃないの？

同じようなカウントアップ処理作ったことあるけど
普通に個別にカウントしてたが、もしや処理系依存？

数えるピクセルシェーダやって
次にピクセル1000個なら最初の点は確率1/1000
つぎは1/999...とやってけばまあ理屈上は完全ランダムだ
さっきもいったが、厳密な座標データは作成できんがね

821 ：デフォルトの名無しさん：2010/03/21(日) 02:52:59

みなさんはゲームの仕様で上限が決まってるものはnewじゃなくて普通の配列使ってますか？

822 ：デフォルトの名無しさん：2010/03/21(日) 02:53:54

全てを囲むバウンディングボックスを作成して
中でランダム点、内包すれば次へってのは偏りがでるからな

823 ：デフォルトの名無しさん：2010/03/21(日) 02:56:56

>>820
ピクセルシェーダは並列に動いているから、全員で１つの格納先を排他制御しながらカウントアップするのができないんじゃないか
と思って。

824 ：デフォルトの名無しさん：2010/03/21(日) 02:58:06

>>821
静的確保と動的確保の違いがわかっていってんの？

825 ：デフォルトの名無しさん：2010/03/21(日) 03:12:29

>>823
？？
ポリゴンがいくつあろうと、格納先は一つでよくね？
シェーダではカウントアップするだけだし
格納先はプログラム側のデータなわけだし

もし２つメッシュを同時に描画するなら、カウントアップの格納先は２つにすればよくね？

何を疑問にしてるのか具体的にいってもらえないか？

826 ：デフォルトの名無しさん：2010/03/21(日) 03:17:19

ゲームの仕様で上限決めなくていいものってどんなものがあるの？

827 ：デフォルトの名無しさん：2010/03/21(日) 03:19:59

>>826
ない

828 ：デフォルトの名無しさん：2010/03/21(日) 03:24:33

>>825
ピクセルシェーダの格納先ってテクスチャしか無理じゃないかと思ったが、
ＧＰＧＰＵならできるか。

829 ：デフォルトの名無しさん：2010/03/21(日) 03:33:34

PCやネットゲーなら上限可変の仕様はあるな。
想定上限は決める必要があるが。

830 ：デフォルトの名無しさん：2010/03/21(日) 03:43:03

>>828
いや、シェーダ自体にもたせるんじゃなくて
ハンドル通してC++側なりで保持しろっていってんだが

831 ：デフォルトの名無しさん：2010/03/21(日) 03:55:05

>>830
シェーダ知らないんだろ

832 ：デフォルトの名無しさん：2010/03/21(日) 05:39:24

探って旅を続けよう
月が昇れば口笛吹いて
次の冒険夢見よう

833 ：デフォルトの名無しさん：2010/03/21(日) 06:21:44

>>831
少なくともお前よりは詳しいよ

834 ：デフォルトの名無しさん：2010/03/21(日) 06:37:20

こんだけ説明されてるのに理解できないもんな

ttp://pc12.2ch.net/test/read.cgi/tech/1233076902/
こいつだろ

835 ：デフォルトの名無しさん：2010/03/21(日) 12:04:38

全部のシェーダが同じカウンタに読み書きするときに同期しないといけないから
シェーダで並列処理する旨みがなくなるな。
シェーダごとにカウンタを用意して最後にカウンタを合計するのがいい。
だが、そもそも三角分割が求められてないと重複しないように塗りつぶすことができない。
三角分割はできるが実装が面倒。
二次元の多角形の内外判定は簡単にできるから>>747の方法が一番簡単だろうな

836 ：835：2010/03/21(日) 12:06:39

なんか1行目が滅茶苦茶になってしまった。
「全部のシェーダが同じカウンタに読み書きすると、読み書きする度に同期しないといけないから」
ということで。

837 ：デフォルトの名無しさん：2010/03/21(日) 12:16:53

一々内外判定する位なら>>757の方が手っ取り早くね

838 ：デフォルトの名無しさん：2010/03/21(日) 12:32:31

図形を三角形の集まりに分解するというのが面倒でな。
Triangulationは計算機幾何学とかいう分野で研究されてて
アルゴリズムも確立されてるんだが実装がとても面倒くさい。
最初から三角分割済みのデータがあるならいいんだが。
（>>757の方法だと三角の中での確率密度が偏ってるが）

839 ：デフォルトの名無しさん：2010/03/21(日) 12:47:28

>>757後半は OA,OB に比率を掛けるから偏るんであって、
直交する底辺,垂線に比率を掛ければ偏らないのよ。

840 ：デフォルトの名無しさん：2010/03/21(日) 12:54:33

よしできた！
図形の総ドット数を数え一次元と考えて配列を作り
その個数を上限とした重ならない値のランダムな位置を作りフラグを立て
それに従い点を貼る
これなら問題無いかな？

841 ：デフォルトの名無しさん：2010/03/21(日) 13:01:37

内外判定って簡単に言うけど
・図形を三角形に分割して各三角形に対し内外判定
・図形のビットマップマスクを使って判定
くらいしか思いつかないからそれに準じた処理しかないと思う。

842 ：デフォルトの名無しさん：2010/03/21(日) 13:01:40

そもそも内外判定どうやってやるの？

843 ：デフォルトの名無しさん：2010/03/21(日) 13:04:47

俺も757のほうが簡単だと思うな
内外判定
typedef complex<double> C;
double cross(const C&a,const C&b){return a.real()*b.imag()-a.imag()*b.real();}
vector<C> v;//入力
bool inside(vector<C>&v,C p){
int dir=cross(v[1]-p,v[0]-p)>=0?1:-1;
for(int i=1;i<v.size();++i){if((cross(v[i]-p,v[i-1]-p))>=0?-1:1)!=dir)return false;}
if((cross(v[0]-p,v[v.size()-1]-p)>=0?1:-1)!=dir)return false;return true;
}

844 ：デフォルトの名無しさん：2010/03/21(日) 13:07:55

調べたい点を通る直線を引いて、直線と図形との交点を求めて、交点をソートして、何番目と何番目の間に点があるか調べて、その何番目ってのが偶数か奇数かで判断する

845 ：デフォルトの名無しさん：2010/03/21(日) 13:10:44

え？それって内外積使った判定より速いの？

846 ：デフォルトの名無しさん：2010/03/21(日) 13:16:20

速くないけどいろんな図形に使える

847 ：デフォルトの名無しさん：2010/03/21(日) 13:20:13

いや、三角形分割でもいろいろな図形に使えるし形不変なら分割は事前処理ですむ。
でも直線は任意に取れるから軸平行に取れば意外と計算・判定少ないか？

848 ：デフォルトの名無しさん：2010/03/21(日) 13:27:32

>>847
さあ・・・

849 ：デフォルトの名無しさん：2010/03/21(日) 14:01:52

全頂点がわかってるなら、それらのベクトルの係数合計が1になるような線形和じゃだめだろうか

850 ：デフォルトの名無しさん：2010/03/21(日) 14:43:31

見積もれないプログラマー

851 ：デフォルトの名無しさん：2010/03/21(日) 18:14:40

>>850
見積もれないと見積もっております

852 ：デフォルトの名無しさん：2010/03/21(日) 21:03:36

【春祭り】また割れ厨のスクショと個人情報が晒されてるぞ避難所8
http://jbbs.livedoor.jp/bbs/read.cgi/news/4988/1269162939/

ICO - 国際著作権機構
ttp://warezer.net/search/user/3512

割れてる人は気をつけて
現在ロリコン校長祭り中

853 ：デフォルトの名無しさん：2010/03/21(日) 21:38:54

なかなかメシウマなんだがこのサイトのやってることって違法じゃねーのか

854 ：デフォルトの名無しさん：2010/03/21(日) 23:30:19

見積もれないってことはその仕事はやれないってことだよね

855 ：デフォルトの名無しさん：2010/03/22(月) 08:34:47

また株式会社ロマンシングか？

856 ：デフォルトの名無しさん：2010/03/22(月) 09:40:13

素敵なサムシングにゅ

857 ：デフォルトの名無しさん：2010/03/22(月) 21:03:48

三角形分割とか基本的なことで躓くのってどうよ？
せっかく計算機科学の第二版がでたから線分とか面とかに関わっちゃうゲームプログラマは読みこなしておくのがいいんじゃないの？

858 ：デフォルトの名無しさん：2010/03/22(月) 22:06:10

でもまあ計算機科学に精通してる奴ができるゲームプログラマーってわけじゃないんだよね

859 ：デフォルトの名無しさん：2010/03/22(月) 22:12:24

計算幾何学？

860 ：デフォルトの名無しさん：2010/03/22(月) 22:13:33

>>857
参考までにISBN番号教えてよ

861 ：デフォルトの名無しさん：2010/03/22(月) 22:46:16

>>857
つーか、三角形分割の章はネットで公開されてるだろ。

862 ：デフォルトの名無しさん：2010/03/22(月) 23:11:46

カプコンやるじゃん
ttp://warezer.net/search/user/3871

863 ：デフォルトの名無しさん：2010/03/23(火) 20:43:41

基本情報技術者資格とかって持ってたほうがいいの？

864 ：デフォルトの名無しさん：2010/03/23(火) 20:51:04

ゲーム開発には別にいりませんが
余裕で取れる程度のスキルは持ってください

865 ：デフォルトの名無しさん：2010/03/23(火) 21:08:13

やっぱ業界では当たり前のレベルなのか・・・
じゃあとりあえず資格をとってからアルバイト探すか

866 ：デフォルトの名無しさん：2010/03/23(火) 21:17:19

いやだから別に持ってなくてもいいよ

867 ：デフォルトの名無しさん：2010/03/23(火) 21:18:28

資格手当払いたくないんですね
分かります

868 ：デフォルトの名無しさん：2010/03/23(火) 21:25:04

資格手当てが出るような資格じゃないだろ

869 ：デフォルトの名無しさん：2010/03/23(火) 21:31:50

ゲームプログラミングセンス　１級
ゲームプログラミングテクニックライセンス　準１級
ゲームクリエイターズスキル　１級

870 ：デフォルトの名無しさん：2010/03/23(火) 22:55:13

A16B16G16R16Fなど不動小数点数のカラーバッファから
輝度を抽出するのにはどうしたらいいでしょうか？
[+0.2125f, +0.7154f, +0.0721f]との内積では崩れるんです。

871 ：デフォルトの名無しさん：2010/03/23(火) 23:07:27

色はABGRの4チャンネルなのに輝度の方向ベクトルは3次元なの？

872 ：デフォルトの名無しさん：2010/03/23(火) 23:14:06

Aは透明度なので計算からは除きます。

873 ：デフォルトの名無しさん：2010/03/23(火) 23:18:12

崩れるの意味もよく分からんが、
とりあえずバッファから読もうとしてる値が読めてるか確認してみればいいんじゃね？

874 ：デフォルトの名無しさん：2010/03/23(火) 23:24:15

教えないくっくっくっ

875 ：デフォルトの名無しさん：2010/03/23(火) 23:30:41

>>873
[+0.2125f, +0.7154f, +0.0721f]との内積で輝度を求める方法は
やってみたらそれっぽくなった的な、結構適当なもので
多分RGBがそれぞれ1.0以内で有効なのだと思います。
浮動小数点カラーは1.0以上になりうるので、うまくいかないんだと
考えています。(10.0とかにすると黄色っぽくなるような？)
代わる良い方法はないかと探しています。

876 ：デフォルトの名無しさん：2010/03/23(火) 23:56:37

浮動小数カラーって0から1で表現するんじゃなかったっけ？
たいてい輝度の変換には
Y = 0.299 * R + 0.587 * G + 0.114 * B
の式を使う。
RGBチャンネルと輝度のとりうる値の範囲が同じなら
8bitカラーだろうと16bitカラーだろうと浮動小数だろうと同じ式でいい。

877 ：デフォルトの名無しさん：2010/03/24(水) 00:21:28

トーンマップとHDRでググれ

878 ：デフォルトの名無しさん：2010/03/24(水) 01:08:22

>>877
ググった結果をここで教えて下さい。

879 ：デフォルトの名無しさん：2010/03/24(水) 01:55:56

>>878
ttp://www.google.co.jp/search?hl=ja&safe=off&q=%E3%83%88%E3%83%BC%E3%83%B3%E3%83%9E%E3%83%83%E3%83%97+HDR&btnG=%E6%A4%9C%E7%B4%A2&lr=&aq=f&aqi=&aql=&oq=&gs_rfai=

880 ：デフォルトの名無しさん：2010/03/24(水) 13:36:47

フレームレートに合わせて行うのは描画と更新、どっち？

881 ：デフォルトの名無しさん：2010/03/24(水) 13:37:59

更新

882 ：デフォルトの名無しさん：2010/03/24(水) 13:43:40

描画じゃね？
これは俺もわからん

883 ：デフォルトの名無しさん：2010/03/24(水) 16:30:57

flipっしょ

884 ：デフォルトの名無しさん：2010/03/24(水) 16:35:00

ふりっぷ？

885 ：デフォルトの名無しさん：2010/03/24(水) 17:04:47

ふぃりっぷ？

886 ：デフォルトの名無しさん：2010/03/24(水) 17:18:51

ふぃりっぷす？

887 ：デフォルトの名無しさん：2010/03/24(水) 18:25:52

ふぃりっぷもりす？

888 ：デフォルトの名無しさん：2010/03/24(水) 19:28:31

>>880
フレームレートとは画面書き換え頻度のこと。
レースゲームのフォルツァのように、フレームレート以上の頻度で更新しても構わない。
逆に更新時間が予定フレームレートに間に合わない時は、描画しても前回と同じ絵を描くことになるのでフレーム落ち確定。
更新時間は大丈夫だけど描画時間が予定フレームレートに間に合わない時は、処理落ちさせるかどうかということになる。
させない場合、ティアリングをさせるかどうかという話になる。

更新時間と描画時間は、それぞれ平行に実行できる場合の話。
コンシューマ機では普通だけど、DirectX では描画スレッドを別に立てた時の話になる。

889 ：デフォルトの名無しさん：2010/03/24(水) 19:29:06

ゲーム上必要な自機クラスや敵クラスの生成なんかを統括的に管理するクラスは必ず必要ですよね

そう言った生成や管理を担当するクラスはシングルトンとかにしちゃうと
どこからでもアクセス出来るグローバル変数を作りまくってることになりますよね

これってあまりよくないかと思うのですが
他に解決する方法はありますか？

890 ：デフォルトの名無しさん：2010/03/24(水) 19:33:55

>>889
>ゲーム上必要な自機クラスや敵クラスの生成なんかを統括的に管理するクラスは必ず必要ですよね
別に

891 ：デフォルトの名無しさん：2010/03/24(水) 19:40:13

>>890
分けたとしても、どこかで生成クラスを実行するクラスが必要になりませんか？

892 ：デフォルトの名無しさん：2010/03/24(水) 19:50:29

シングルトンでどこからでもget関数呼べるのは便利なんですが
衝突判定とかで他のクラスの情報がほしい場合
その統括して管理しているクラスから
敵クラスなりの情報を取得しないといけないし
だからと言ってこのままで良い物なのかも疑問なんですよね
解決策も思いつきませんし

893 ：デフォルトの名無しさん：2010/03/24(水) 19:54:43

>>891
シーンクラスに全部おいとけばいいじゃん

894 ：デフォルトの名無しさん：2010/03/24(水) 19:57:38

>>893
統括的に管理するクラスのことですよね
巨大クラスになるじゃないですか
だからと言ってシングルトンで分けるのもどうかと思ってるんです

895 ：デフォルトの名無しさん：2010/03/24(水) 19:58:10

ちょっとまてや
生成を統括するクラスを作る必要はないだろ
シーンクラスに直接おけばいいんじゃないの？

896 ：デフォルトの名無しさん：2010/03/24(水) 20:02:36

>>894
なるよ
実際なるんだからしょうがない
ここは認めないとダメだ
でもシングルトンなんて使う必要ないじゃん
直接シーンクラスにおけばいいじゃん
自機：１、敵：３０種ｘＮ体、弾：３０種ｘＮ個・・・
全部普通に書けばいいじゃん
統括なんてしないよ

JIKI jiki;
TEKI_A tekia[MAXTEKI_A];
TEKI_B tekib[MAXTEKI_B];
TEKI_C
　・
　・
　・
TAMA_A tamaa[MAXTAMA_A];
　以下略

って普通にかけばいいじゃん

897 ：デフォルトの名無しさん：2010/03/24(水) 20:04:02

>>895
すみません
もう少し詳しく教えていただけませんか？

シーンクラスで敵や背景の生成なんかをnewしながらシーンを繋げるということですか？
そうなると、そのシーンクラスを取得し、敵クラスと情報を取得できないと
衝突判定を独立させられませんよね

898 ：デフォルトの名無しさん：2010/03/24(水) 20:10:19

>>896
そこに疑問を感じてるんです
そこで生成するクラスを上手くまとめても
直に管理してるのって何か嫌だと思ってるんです

仕方ないんですかね

899 ：デフォルトの名無しさん：2010/03/24(水) 20:20:52

以下の３パターンってメモリとかパフォーマンスとかどう違う？
どれのほうがゲーム向き？

●１
String[] namelist={"ゴブリン","ドラキュラ",....,"サタン"};

●２
String namelist(int index) {
switch (index) {
case 0: return "ゴブリン";
case 1: return "ドラキュラ";
....
case 30: return "サタン";
default: return null;
}}

●３
String namelist(int index) {
String[] list={"ゴブリン","ドラキュラ",....,"サタン"};
return list[index];
}

900 ：デフォルトの名無しさん：2010/03/24(水) 20:31:10

>>899
どれも微妙くないか
追加するとき手加えないといかんよ

901 ：デフォルトの名無しさん：2010/03/24(水) 20:31:17

>>898
まとめる必要が無い。
まとめたクラスを使う側がいるだろ？
そいつは何を生成するか分かってて呼ぶんだろ？
なら直接呼べばよい。
その生成ルーチンを必要としているのはひと握りなので、そいつらにだけ便利に作ればよい。可能なら他から見えないともっと良い。

>>899
3が良い。
例えばユーザー定義モンスターの追加とかの時に、呼び出し側を変える必要が無い。

902 ：デフォルトの名無しさん：2010/03/24(水) 20:42:28

>>901
なるほど
ここらへんは仕方ないみたいですね
詳しい説明ありがとうございました

903 ：デフォルトの名無しさん：2010/03/24(水) 20:46:39

class Stage
{
public:
void update(void) { user->update(); for_each(mobs, Update()); }
private:
User *user;
list<Mob *> mobs;
};

//---

manager
{
public:
void update(void) { user->update(); for_each(mobs, Update()); }
private:
User *user;
list<Mob *> mobs;
}

Stage
{
public:
void update(void) { manager.update(); }
private:
Manager manager;
};

どっちでもいいんじゃない
後でいろいろ付け足していくんなら下がいいと思う

904 ：デフォルトの名無しさん：2010/03/24(水) 21:07:17

~Managerというクラスを設計した場合、設計を疑えという話しがあるけど

作っちゃうよね

905 ：デフォルトの名無しさん：2010/03/24(水) 21:07:54

>>903
形は少し違いますが、現在下みたいな管理方法を取ってます

他にディスパッチできる所を作って見ます
ありがとうございました

906 ：デフォルトの名無しさん：2010/03/24(水) 21:08:59

>>904
マネージャクラスたくさんあるんですが…
いけないんですか？？

907 ：デフォルトの名無しさん：2010/03/24(水) 21:14:07

クラスの役割分担を考えるのを放棄した証拠

908 ：899：2010/03/24(水) 21:14:58

>>900
なんか他に良い方法ありますか？

>>901
なるほど。参考になります

909 ：デフォルトの名無しさん：2010/03/24(水) 21:17:00

>>906
あくまで同一クラスのインスタンスを管理するサブルーチン的なもんならいいけど
そこに数種類のクラスをぶち込んで～っていうのはいやなにおいがするね

910 ：デフォルトの名無しさん：2010/03/24(水) 21:21:01

極端な話、GameManagerっていうクラスを作って
その中にゲームの全てのコードを詰め込んだって「ゲーム管理」には違いないわな

911 ：デフォルトの名無しさん：2010/03/24(水) 21:45:28

EntityManagerとか使っちゃうがダメなのか
読み込んだステージデータをもとに
mana.registerEnemy(Enemy *p);
とかでゲームに登録して、さらにpにmanaへのポインタか参照を持たせる
pがゲームの状況（たとえばプレイヤーの情報）を知りたければ
pmana->getPlayerInfo(void);
として返されたプロクシを使って作業する（直接playerの参照を返すことは避ける）
弾丸を打ちたければ
Enemy::shot(param pa){ pmana->registerEnemyBullet(bullet::create(pa)); }
みたいな感じで
循環参照にさえ気をつければ、今のところ別に変な問題も起こってないけど・・・なにがだめなのかなぁ

912 ：デフォルトの名無しさん：2010/03/24(水) 21:47:10

>>911
それって使う側はたまったもんじゃないからやめてほしいんだよね

913 ：デフォルトの名無しさん：2010/03/24(水) 21:48:18

仮に敵Ａ～Ｚまでいる状態で敵Ｇだけほしいときって考えたときに
アクセス方法が悪夢にしか見えない

914 ：デフォルトの名無しさん：2010/03/24(水) 21:56:15

ゲームが面白ければどうでもいい

915 ：デフォルトの名無しさん：2010/03/24(水) 21:56:55

まぁたぶん使う側も本人だろうからいいんじゃね

916 ：デフォルトの名無しさん：2010/03/24(水) 22:33:15

>>914
お前のゲームは面白くないけどな

917 ：デフォルトの名無しさん：2010/03/24(水) 22:44:41

なんだと

918 ：デフォルトの名無しさん：2010/03/24(水) 23:17:20

>>913
G型のオブジェクトを検索してイテレータを返すメソッドをマネージャーに持たせればいいだけでは？
G型だけじゃなくてもテンプレート使えば簡単に実装できるよね
マネージャーがなくてもG型を検索するサブルーチンなりなんなりは
どうせ書くはめになるんだからマネージャーに一任させてしまった方が安全でわかりやすくていいと思うけど

919 ：デフォルトの名無しさん：2010/03/24(水) 23:24:38

右手座標系、左手座標系の利点ってなに？

920 ：デフォルトの名無しさん：2010/03/24(水) 23:27:15

上手や下手は基準にならないから

921 ：デフォルトの名無しさん：2010/03/24(水) 23:40:18

相変わらずレベルが低くて安心した

922 ：デフォルトの名無しさん：2010/03/24(水) 23:49:32

>>921
ではレベルの高いレスをお願いします

923 ：デフォルトの名無しさん：2010/03/25(木) 00:47:10

>>918
>マネージャーがなくてもG型を検索するサブルーチンなりなんなりは
なんねーよ
俺は>>896方式だもん
だいたいその検索すりゃいいやってそこしか見えてないからそういうんだろ
更新順番が違うとかここだけは引数から渡さないと問題多すぎて対処しきれないんだよ
生成したばかりのオブジェクトは引っかからないとか更新状態が一つ遅いとか
そういう目に見えにくい不具合を全部こっちに押し付けるから
マネージャ作る奴って嫌いなんだよ俺は
同じフレームで生成した敵オブジェクトは帰ってこないとか頻繁にあるだろ？

924 ：デフォルトの名無しさん：2010/03/25(木) 00:49:57

一番大事なのは協調性。
お前らにチーム開発は無理。

925 ：デフォルトの名無しさん：2010/03/25(木) 00:50:16

まともなソースを出してから、えらそうなことを言え。

926 ：デフォルトの名無しさん：2010/03/25(木) 00:56:46

やーだー

927 ：デフォルトの名無しさん：2010/03/25(木) 00:59:37

このスレにまともなソース出せる奴なんか一人もいないだろうに

928 ：デフォルトの名無しさん：2010/03/25(木) 01:04:25

ttp://www.otafuku.co.jp/product/search_home/item001.html

929 ：デフォルトの名無しさん：2010/03/25(木) 01:07:44

>>928
このユーモアのなさがたまりません

930 ：デフォルトの名無しさん：2010/03/25(木) 02:24:04

http://www.google.co.jp/search?q=SomethingManager

931 ：デフォルトの名無しさん：2010/03/25(木) 02:47:07

>>910
まあそれは極端だが、その方がバグ取りが早かったりするのは皮肉だｗ

932 ：デフォルトの名無しさん：2010/03/25(木) 03:13:12

食卓用ソースのリンク貼るﾈﾀって、10年前くらいからあったよな…

933 ：デフォルトの名無しさん：2010/03/25(木) 03:18:39

理系学生

934 ：デフォルトの名無しさん：2010/03/25(木) 03:52:24

>>931
ねーよw

935 ：デフォルトの名無しさん：2010/03/25(木) 06:33:54

>>919
ひとつは慣れ。一つはアーティストが使うツールとの整合性。
PS1 やサターンの頃は、スクリーン座標を[-1..1]ではなくフレームバッファサイズになるようにしていた。
その時、中学で習ったのとは反対に、スクリーン座標の下が + になるのが都合が良かった。
その名残りだったりもする。

936 ：デフォルトの名無しさん：2010/03/25(木) 07:00:31

アーティストじゃなくてデザイナってゆうなぁ

937 ：デフォルトの名無しさん：2010/03/25(木) 10:54:29

>>919
単に習慣として決まっているだけなので、特に深い理由はない。
右手系を使うのと、左手系で使うのがどっちがいいかというと、正直どっちでもいいと思う。
変換も単にz座標に-1を掛けるとか、その程度の話なので使いやすい方を使えばいい。
ただ、混在させるのは良くないので、通常はどっちを使うかははっきり決めないとダメ。

938 ：デフォルトの名無しさん：2010/03/25(木) 14:08:49

ブロック崩しムズイんだけど・・・どこが初心者向きなんだよｗ

ボールの速度が速いとブロックやバーを飛び越えちゃうし
衝突後の跳ね返りも違和感ありまくりで不気味な動きに見えちゃうし

ナニコレｗｗｗｗ

テトリスのほうがまだ簡単じゃねえかよｗｗｗ

orz

939 ：デフォルトの名無しさん：2010/03/25(木) 14:12:29

だから飛び越える処理は、
pos.y -= idouryou;
じゃなくて、
for(int i=0; i<idouryou; i++)
{
　　pos.y--;
　　if(atari()) break;
}
しろといってるだろ

940 ：デフォルトの名無しさん：2010/03/25(木) 14:17:13

なん・・・だと・・・！？

941 ：デフォルトの名無しさん：2010/03/25(木) 14:20:15

何その力押し

942 ：デフォルトの名無しさん：2010/03/25(木) 14:20:30

if(speed.y < 0){
　　idouryou = - speed.y;
　　step = -1;
}else{
　　idouryou = speed.y;
　　step = 1;
}

for(int i = 0; i < idouryou; y++){
　　pos.y += step;
　　if(atari()){
　　　　atatta = true;
　　　　break;
　　}
}
if(atatta){
　　speed.y *= -1;
　　atatta_toki_no_shori();
}

とかいう感じでも。

943 ：デフォルトの名無しさん：2010/03/25(木) 14:23:40

流石・・・プロのテクニックだぜ・・・俺には想像もつかなかったようなハイレベル・・・

944 ：デフォルトの名無しさん：2010/03/25(木) 14:25:09

え？

945 ：デフォルトの名無しさん：2010/03/25(木) 14:25:25

それでいいと思うし
ここでわざわざする質問でもないな
ググればブロック崩しのソースコードくらい出てくるだろ
>>938 ggrks

946 ：デフォルトの名無しさん：2010/03/25(木) 14:29:01

他人のソースのコピーだけじゃ、見つからなかった場合にどうしようもなくなる。

947 ：デフォルトの名無しさん：2010/03/25(木) 14:30:05

プログラミング初心者向けのゲームなんだから
ググれば作り方くらい紹介してるサイトとかたくさんあんだろ

948 ：デフォルトの名無しさん：2010/03/25(木) 14:31:49

オブジェクト指向的に言えば
Class Ball
Class Block
Class Bar
こうなる