DXライブラリ総合スレッドその3

**名前は開発中のものです。** · 2009/03/31(火) 01:14:36

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。

DXライブラリの詳細ついては
http://homepage2.nifty.com/natupaji/DxLib/
を参照して頂きたい。

DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

過去スレ：DXライブラリ総合スレッド
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/
　　　　　DXライブラリ総合スレッド 2008
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1224923873/

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

フラッシュマン

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

>>748
リアルタイム処理で使うのは駄目に決まってるな
フェードアウト後の待ち時間とかに使うのが正しい
でも個人的にはウェイト系の関数やら処理体系作って、それを使えばいいと思う
while(……){
　//ここにwaitから切り放したい処理を書く
　//例えば、ゲームは止まっても風景は動かしたい
　//処理ごとにwaitを分ければさらに色々なことができる
　if(waitFlag==FALSE){
　　//ここにwait前にやりたい処理を書く
　　//waitTime、waitFlagは本来条件式で設定するのが望ましい
　　waitTime=1500;//1500ミリ秒=1.5秒
　　waitFlag=TRUE;
　}else{
　　if(1ミリ秒経過したら){
　　　waitTime--;
　　}
　　if(waitTime==0){//1.5秒経った
　　　waitFlag==FALSE;
　　}else{
　　　//waitTime=0未満;を描いたな？と怒る
　　　//エラーフラグを大量に埋めるのは開発の最適化とアンチートに役立つ
　　}
　}
}

こんな

**名前は開発中のものです。** · 2009/07/20(月) 01:09:47

最後のとこはelse if(waitTime<0)だた

**名前は開発中のものです。** · 2009/07/20(月) 18:56:48

ジャンプするたびに画像をロードしまくってどうする

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

>>750
これならどの環境でもキッチリ結果が出るね
カウンタ回すしかやったことないから参考になるわ
だけどアクションとかだと遅延おきてカクカクにならないかな

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

同じフォルダ内にあるＴＴＦフォントを使って文字列描画したいんですけどそれはＤＸライブラリでできますか？
フォントのファイル名を指定して読み込みするような関数が見つからなくてどうすればいいか困ってるんですが

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

なんかソレっぽいサンプルどっかで見かけたような気が……

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

ごめん適当なこと言った
ＤＸライブラリでは出来ないような気がする
でもフォントファイルを一時的に開くプログラムがあれば通常のフォントと同じように
名前の指定だけで使えるはず……

**754** · 2009/07/23(木) 02:35:05

ありがとう！！探してみて解決したよ！！

結果はWin32APIのAddFontResourceEx関数を使えば一時的にTTFファイルからフォントリストに登録できるみたい
第二引数に0x10(FR_PRIVATE)を渡せばそのプロセスだけで使えるようになるぽ
使い終えたらRemoveFontResourceExで開放する必要もあるみたい。登録時とまったく同じ引数で呼び出す必要あり

AddFontResourceEx("hoge.ttf", 0x10, 0); // これでhogeフォントを登録。DxLibのEnumFontNameでも表示されるはず。
RemoveFontResourceEx("hoge.ttf", 0x10, 0); // 削除。引数を↑と同じにしないといけないらしい

いくらDxLib関係でググっても見つからなかったので少々冗長気味に解説してみたよ
正直この機能はDxLibにラップされてても違和感無いと思うんだけど

**名前は開発中のものです。** · 2009/07/23(木) 03:39:18

確かに自動対応してもいいレベルではある

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

暗転ってどうやってやってる？

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

普通に画像を表示して、その上にかぶせるように真っ黒な画像を少しずつ濃くしながら表示。
完全に濃くなったら、表示する画像を切り替える。
真っ黒な画像を少しずつ薄くしながら表示する。完全に薄くなったら、以後、真っ黒な画像は表示しない。

これでいいと思う。

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

SetDrawBlendModeとDrawBoxでやってるな。

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

これ一旦止めた音楽止めた場所から再開させることできないのか

**名前は開発中のものです。** · 2009/07/24(金) 03:42:20

できるけど
Dxlib.h内を、サウンドハンドルの再生位置で検索

**名前は開発中のものです。** · 2009/07/24(金) 04:08:03

ありがとうございます
やってみました
PlaySoundMem でやってるときは GetSoundCurrentPosition で取得すればいいのかな
でやってみましたが GetSoundCurrentPosition がいくら再生してるときでも０しか返ってこないのですが
ちゃんと引数に正しい SoundHandle 入れてますよ

**名前は開発中のものです。** · 2009/07/24(金) 04:20:10

ごめん、検証してなかった
PlaySoundMemのTopPositionFlagを0にすれば
取りあえずは途中から再生できるはず

**名前は開発中のものです。** · 2009/07/24(金) 06:13:08

ありがとうございました、できました

**名前は開発中のものです。** · 2009/07/24(金) 08:59:47

DXライブラリ卒でD3D9使ってるけど、久々にDXライブラリ時代のソース引っ張り出して
ちょっと懐かしかった。pchも使ってなかったんだなぁとか。
つーかpch使ってない奴も多そうだから勝手に手順説明するぜ。

1. プロジェクト→新しい項目の追加→ヘッダーファイルでstdafx.hをプロジェクトに追加
2. プロジェクト→新しい項目の追加→C++ファイルでstdafx.cppをプロジェクトに追加
3. DxLib.hや標準ライブラリなど、自作でない巨大ヘッダのinclude文を*.cppから全部削除して、
代わりにstdafx.hの中に全部突っ込む（自作ヘッダは普通に*.cppで各自includeする方がいい）
/* stdafx.hの例 */
#pragma once
#include <DxLib.h>
#include <string>
using std::string;
/* ここまで */
4. 全ての*.cppの最初に#include "stdafx.h"を書く（コメントは前に入れてもおｋ）
ちなみにstdafx.cppは、#include "stdafx.h"の一行だけでおｋ
5. ソリューションエクスプローラでプロジェクト名を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを使用する
(/Yu)」に変更する
6. ソリューションエクスプローラで「stdafx.cpp」を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを作成する
(/Yc)」に変更する

これで、stdafx.hを変更する時以外は、ビルド速度がかなり劇的に上がるはず。
大した作業にはならないはずだから一度試すといい。

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

ああ、気付きにくいかもしれないことを補足。
自作ヘッダから<string>とか<math.h>とか使いたい場合も、「必ず全ての*.cppの最初で
stdafx.hがインクルードされる」という規則だから、結局は自作ヘッダがインクルードされる
時点ではstdafx.hが既に読み込み済みになってる。
なので、自作ヘッダに#include <string>とか書く必要も無し。自作ヘッダで使いたい標準の
ライブラリなんかのincludeも、全部stdafx.hに逃がせばおｋ。

**名前は開発中のものです。** · 2009/07/24(金) 17:40:08

これは便利そうですね
デメリットとかはありますか？

**名前は開発中のものです。** · 2009/07/24(金) 18:12:52

今の俺には何のことだかさっぱりだがメモっておく

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

デメリットは思い当たらないなぁ。
「使いたい外部ライブラリのヘッダを全部何も考えずにstdafx.hに入れまくれ」
「全てのcppファイルの頭でstdafx.hをインクルードしろ」
ってルールが縛りといえば縛りだけど、むしろ楽になるだけだと思う。コンパイルも
別次元に速くなるし。

原理的には、stdafx.hの中身をコンパイルし終わったとこでいったん止めちゃって、
中間情報として拡張子pchのファイルに保存しておき、*.cppをコンパイルする時に
その情報を使い回して、#include "stdafx.h"まで読み飛ばして、それ以降のソース
だけコンパイルするイメージ。実際に内部がどう動いてるかは知らないけど。
なので、cppの頭で#include "stdafx.h"を入れ忘れると、
「プリコンパイル済みヘッダーの検索中に予期せぬ EOF を検出しました」
とか言われる。
stdafx.hの中には、C++のソースなら何書いても多分平気だから、大抵の使い方には
対応できると思われ。あまり頻繁に書き換えると、そのたびにpch作り直しで効果が
薄まるけど、自作ヘッダでも「更新少ない」「かなり色々なソースから参照される」
みたいな奴はstdafx.hに入れちゃってもいいと思う。

**名前は開発中のものです。** · 2009/07/25(土) 15:25:58

当たり判定はこうすればいい。
プレイヤーキャラクターを移動させたければこうすればいい。

といった部品部品は作れるけど、いざゲーム自体を作ろうとなったら全然作れないんだ。
いったいどうしたらいいのかな・・・？

**名前は開発中のものです。** · 2009/07/25(土) 15:36:28

その部品を組み立てればゲームになるはずなんだが
一体何が問題なんだ？

それを言わずして質問されてもわかるはずがない。

**名前は開発中のものです。** · 2009/07/25(土) 15:37:45

>>772
とりあえず目標を決めてはどうか。

ただし、あまり大作でも作れなきゃ意味がないので、
初期の携帯電話用ゲームや、初期のファミコン、インベーダゲーム、倉庫番あたりを目指す。
矢印キーだけ、せいぜいそこにボタン１個くらいで遊べるゲームが楽でいい。

目標が決まったら、それを「部品」に分解する。
うまく部品単位になればお前さんの勝利。

**名前は開発中のものです。** · 2009/07/25(土) 17:05:50

綺麗な部品作りの楽しさとゲーム作りの楽しさは、何というかちょうど90度くらい
ずれた方向性がある。両方うまい人はすごくいい。
最初の一歩はとにかく単純に、ゲーム内容どうでもいいから一本のゲームとして
成り立ってる物を作る、つーこと。極端な話、全部WinMain()に入ってても一向に
構わない。（綺麗な部品作りに慣れてるならそうはならないだろうが）
部品は必要性を実感してから作る方が最適になりやすい。いわゆるシーズじゃなく
ニーズで作る。先に需要を予測して部品を作る、ってのはほどほどにすべき。
で、「クソゲー作ってもなぁ」と思うなら、いっそ最初から真面目に本気ゲーを
作り始めてしまっても全然問題ない。

**名前は開発中のものです。** · 2009/07/26(日) 08:48:42

個々の部品の作り方が分かっていても、それらを全部組み合わせて、うまく動くようにするのは結構大変。
特にシーンやリソースの管理が入ってくるとかなり面倒になる。
そういう点ではやっぱり最初は１面のみの単純なゲームから始めた方がいいね。
プログラムが大きくなればなるほどバグ取りも大変になるから、最初は小規模から始めた方がいい。
自分はいつも最初からあれこれ入れようとして墓穴を掘ってる。

**名前は開発中のものです。** · 2009/07/26(日) 11:40:31

プログラムを書く能力とゲームを組み立てる能力は、全くの別物
紙にステータスを書いて遊ぶとか、人形をいじって遊ぶとか
そういうアナログな手法でイメージを立てて設計する
何も考えずにプログラムを先に書くのは意味がない。

ゲームを考える（妄想する）、ゲームを作る、ゲームを遊ぶ
この３つのどれが欠けてもうまくいかない
まず面白いシステムや世界観を考える
次にプログラム、シナリオ、絵、音楽などで形にする
最後に完成品を遊び倒して面白いゲームに近付ける
ゲームは工業製品だから、作り手の職人気質がもろに出るよ

**名前は開発中のものです。** · 2009/07/26(日) 11:57:44

>>772は単に大枠の設計が分からないとかそういうことなんじゃね？
>>776のいうシーン管理とかそういう骨組みの構造とか

**名前は開発中のものです。** · 2009/07/26(日) 23:48:51

stdafx.hにいれた上で、そのソースに必要なヘッダはあえて書くソースに書くようにしてる

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

俺は何も考えずにいきなりプログラム作るぞ。
特に最初のうちは、あんまり考えないほうがいいと思うんだけどな。
緻密に設計していくのは、ミニゲームを何本か完成させた後のほうがいいと思う。

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

俺は「これできるかな？　……できた。んじゃこれはできるかな……？　よしできた」とかやってるうちに
肥大化してゲームになってる。

**名前は開発中のものです。** · 2009/07/27(月) 00:16:38

俺は「これできるかな？　……できた。んじゃこれはできるかな……？　よしできた」とかやってるうちに
肥大化してまとまらなくなってやめる。

**名前は開発中のものです。** · 2009/07/27(月) 00:30:42

俺は「これできるかな？　……できない。んじゃこれはできるかな……？　できない……」とかやってるうちに
肥大化することなく寝る。

**名前は開発中のものです。** · 2009/07/27(月) 01:20:08

>>781-783
ﾌｲﾀｗｗｗｗｗ

**名前は開発中のものです。** · 2009/07/27(月) 01:49:38

>>781-783がそれぞれ昔の俺、少し昔の俺、今の俺な件

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

昔はコードが汚いだとか構造が嫌だとかの細かいことが気にならなかった
今はゲームが完成しない

**名前は開発中のものです。** · 2009/07/27(月) 04:44:35

習作はできるが完成はできん

**名前は開発中のものです。** · 2009/07/27(月) 08:01:02

> 「○ ○の作り方」という本を読んで「この本に××が足りない」と考え、
> そこで今度は××に冠する解説をよみ「これには△△が抜けている」という印象をもち、
> そしてなかなか自分のゲームが完成しない、というパターンに陥った人は少なくないでしょう。
> さまざまな技術書や解説書、入門書を読みつくし、最先端技術に精通しているはずなのに
> 自作アプリケーションがほとんど作れないというのは、決して珍しくありません。

**名前は開発中のものです。** · 2009/07/27(月) 08:53:03

そういうのを「頭でっかち」というんだな。

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

どこの引用なんだ

**名前は開発中のものです。** · 2009/07/27(月) 17:02:26

本を読めば作れると考えるのが間違い

**名前は開発中のものです。** · 2009/07/27(月) 21:15:32

昔どっかのゲームクリエイターが「やってみるのが一番勉強になる」的なこと言ってたから
俺はそれを胸に頑張ったよ…。

**名前は開発中のものです。** · 2009/07/27(月) 23:14:17

男は度胸
何でも試してみるもんさ

**名前は開発中のものです。** · 2009/07/27(月) 23:41:51

女は豊胸？

**名前は開発中のものです。** · 2009/07/28(火) 02:18:15

股だな

**名前は開発中のものです。** · 2009/07/28(火) 05:12:13

ＤＸライブラリPortable、次のバージョン来ないかな
３Ｄポリゴン描画したいです……

**名前は開発中のものです。** · 2009/07/28(火) 12:23:42

そういやＤＸ３Ｄってどれくらいできたのかな？

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

>>797
逃げたんじゃないか？
大学中退するやつだし

**名前は開発中のものです。** · 2009/07/28(火) 19:50:25

DX3DってD3DXと紛らわしいな。
3D描画をDXライブラリみたいに単純化するのは無理。3D描画のフレームワークは
D3DXで十分。それ以上やるとライブラリの独自色が付く。
2DもD3DXSpriteで構わないし、ちょっと調べればテクスチャにαの付いた板ポリを
D3DXで描画する方法はいくらでも出てくるけど。
DirectX6はDreamcast向け、DirectX8はXbox向けに作り直されてる訳で、そのまま
でも十分行けるライブラリ。DXライブラリの最大の意義は、WinMainのすっきり感
だと思う。

**名前は開発中のものです。** · 2009/07/28(火) 20:50:59

本家の名前の紛らわしさに比べたら…

DXライブラリでも使えよ！って言われて固有名詞だとは夢にも思わず
なかなか存在に気付けなかった俺

**名前は開発中のものです。** · 2009/07/28(火) 20:52:30

3Dなんかいくら敷居を下げたところでDXライブラリしか使えないような子には扱えないよ
ゲームフレームワークみたいな方向に簡単にするなら別だけども

**名前は開発中のものです。** · 2009/07/28(火) 21:36:50

あの・・・
流れを断ち切った横レスなんですが、
C言語＋dxlibで作ったプログラムをC++のクラスってのを使って
まとめようと思い、メインループを書いてみたんですが、
書き方があっているのかすごく不安なのでお聞きしたいと思いました。

もし、スレチならいいスレ教えて・・・
よし！見せてみろ！ならソース張る。

**名前は開発中のものです。** · 2009/07/28(火) 21:37:39

DXライブラリに親でも殺されたのか

**名前は開発中のものです。** · 2009/07/28(火) 21:43:58

>>802
ヨシみせてみろ

**802** · 2009/07/28(火) 21:52:18

ワーイ　ID　GCCってｗ

#include "GV.h"

int WINAPI WinMain(
HINSTANCE hI,HINSTANCE hP,
LPSTR lpC,int nC
)
{
ChangeWindowMode(TRUE);
if(DxLib_Init() == -1) return -1;
//↓このあたりがめっちゃ不安なのですが。
Flame* T = new Flame;
//
SetDrawScreen(DX_SCREEN_BACK);

//MainLoop()内で処理を書いてます
while(!(ProcessMessage()) && !(CheckHitKey(KEY_INPUT_ESCAPE))
&& (T -> MainLoop()) && !(ScreenFlip()) && !(ClsDrawScreen()));
//
DxLib_End();
return 0;
}

ヘッダファイルも見てもらえるのなら・・・・☆彡ってレスしてくらさい

**名前は開発中のものです。** · 2009/07/28(火) 22:00:28

それだけならそんなにおかしいところはないと思う
細かいどうでもいいことを突っ込ませてもらうと，

FlameじゃなくてFrame
あと大文字一字の変数名はやめてくれ紛らわしい

**801** · 2009/07/28(火) 22:09:21

フレイム・・・フレーム・・・
一文字違いが大違いでした・・・
参考にした本（セガ本？）にそういう記述があったのでつい　（Tの件は）

T*　＜＝この変数を使う場合

T->A
T->B
とか、
for(int i=0;i<1000;i++){
T->　X[i]
}
みたいに変数の中身をwhileの中で更新しまくっても問題ないですか？

**名前は開発中のものです。** · 2009/07/28(火) 22:10:29

ゲームプログラマーになる前に～ってタイトルの本か

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

そうです。
ちなみに2章を読み始めてから進まないまま二ヶ月目

**名前は開発中のものです。** · 2009/07/28(火) 22:16:24

>>807
ダメダメ
それならCの構造体と変わらない
クラスの外からメンバ変数にアクセスするのは避ける
クラスっていうのは，外からはボタンを押すだけで中で勝手に処理してくれる
便利な機械みたいな感じ(そういう風に作るのが理想)

**名前は開発中のものです。** · 2009/07/28(火) 22:19:08

先にEffectiveC++とデザインパターンの本読むべき

**名前は開発中のものです。** · 2009/07/28(火) 22:26:10

クラスを利用したこともないのにいきなり作れるわけがない
ためしに他の人が作ったC++のクラスライブラリを触ってみればいいんじゃない
ゲームエンジンならSeleneとか
英語大丈夫ならIrrlichtなんかも簡潔でおすすめ
どういう風にクラスを使えばいいのかわかるよ

**802** · 2009/07/28(火) 22:29:42

なるほど。。

本高い・・・。
すでに
１４才から・・・、
OS自作・・・
やさしいC・・・
よくわかるC・・・
IP!
Cプログラミング講座、
アルゴリズムマニアックス、
はじめてのアルゴリズム入門、
とかの本を買っては進めないところがあって止まるを繰り返してもう資金が・・・

来月余裕があったら買ってみます。

**名前は開発中のものです。** · 2009/07/28(火) 22:31:58

買う前に一冊読みきれｗｗｗ
それか図書館だな

**801** · 2009/07/28(火) 22:35:44

これだけ本読んだらもしかしたらオレゲーム作れるんじゃね？
と勘違いして作り始めたのさ！

もう・・・タイムリミットがちかずいている・・・・・・
やつが・・・・来る！

**名前は開発中のものです。** · 2009/07/28(火) 22:36:54

マクドに注文する側がバイトのシフトとかパンズの在庫を気にしちゃ駄目だぜ

**802** · 2009/07/28(火) 22:41:24

>>815
そういうことなのか！

なんかよくわかった気がしました。
クラスの中で処理を完結すればいい感じになれるってことですね♪　

アレ？ッてことは今書いるプログラムは・・・・

**名前は開発中のものです。** · 2009/07/28(火) 22:50:21

スタックフレームとヒープとスタティック領域が分かってないとC/C++は辛い。
どっかに親切な解説ねーかな。ここじゃ正直めんどい。

とりあえず今から風呂→ネトゲでギルド潜りするんで、一分でそれっぽいとこ探して
おいた。
ttp://gihyo.jp/dev/serial/01/antique_assembler
初心者に分かるかはシラネ。でもこれが分かればCのメモリでつまづくことはたぶん
無くなりそうな記事に見えた。15秒くらいしか読んでないけど。

**名前は開発中のものです。** · 2009/07/28(火) 22:55:24

すまん、面白そうなんで↑の記事をちょっと読んでみたが、初心者でWindows環境だと
素直に読めるもんじゃないかも。
ある程度「ふんふんそんなもんか」って飛ばし読みするには悪くないとは思うけど、
真面目にサンプルコードを走らせたりするタイプだと微妙にきつそう。

**名前は開発中のものです。** · 2009/07/28(火) 22:57:31

あんまり低レベルなことは気にしなくていいと思うよ
オブジェクト指向をちゃんとやりたかったらJavaのような
思いっきり抽象的な世界でリフレッシュした方がいいかもしれない
ゲーム作るのだって簡単

**名前は開発中のものです。** · 2009/07/28(火) 22:58:28

えっと・・・
関数を呼び出したときには元の場所に帰ってくるための情報が
どこかよくわからないない場所に
スタックの構造をした形でつまれているんだよ、ってこと？

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

しかしゲームを作るのにそれほど必要ない知識なのであった

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

java・・・・
とりあえずおいらゲームを作って見るよ！
クラスの中でクラスを宣言したりnewする方法がまったく理解出来ないけど。
時間切れなので・・・ノシ

ご指導ありがとうございました！

**名前は開発中のものです。** · 2009/07/28(火) 23:29:31

さて、そろそろD言語に手を出そうか…

**名前は開発中のものです。** · 2009/07/28(火) 23:32:38

そして一向にゲームが完成しない罠
勉強もいいけど取り敢えずサクッと作った方がよいかも

**名前は開発中のものです。** · 2009/07/28(火) 23:40:38

上から降ってくる「モノ」を、ただひたすら画面下部で避けるだけのゲームとか、そういうの？

**名前は開発中のものです。** · 2009/07/28(火) 23:45:05

あら？？
ニコニコ動画にうpしたのならあるけど・・・・
それよりヘッダファイル見る？

**名前は開発中のものです。** · 2009/07/28(火) 23:53:41

見てあげないこともない

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

ttp://www.nicovideo.jp/watch/sm7736340

とりあえず張ってみる。
これ以上スレすると荒らしになってしまいそうな気ガスる

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

つーか、やろうとしてることから考えると、ちゃんとメモリの意味が分かってないと
トンチンカンになる。
余計なことやろうとせず、意味の分かってる仕様だけ使っていればいい。いわゆる
better CとしてのC++。newとか罠満載なものにやたらと触らない。

**名前は開発中のものです。** · 2009/07/29(水) 00:37:52

俺は昔アセンブラかじったことあったからメモリの意味はある程度わかってるつもりだったが、
最近までポインタが理解できずに使えなかった……。

どっかのサイトで「int *p」は「int* p」だって書いてあるのを読んでやっと少しだけわかった気がした。

「なんで *p で宣言してるのに使うのは p なんだ？？？」とずっと疑問だった。

Cって俺にはわかりづら過ぎる……。わかる奴凄い。

**名前は開発中のものです。** · 2009/07/29(水) 00:46:49

>>831
68系のアセンブラを知っていればポインタを知っているとおもう。

ここを読んでみなさい。C++について詳しく解説してある。
http://www.asahi-net.or.jp/~yf8k-kbys/

**名前は開発中のものです。** · 2009/07/29(水) 02:17:12

ポインタなんて最初あまり分からずに大分年月経ったらやっと分かり始めた
いろいろ試行錯誤とか苦労しないと分からないのでは
話変わるがちょっと上のレスに関連することだが俺結構メンバ公開にして外からアクセスしてた
何かアクセサ使うとその分遅くなるような気がしてしまうんだよなあ

**名前は開発中のものです。** · 2009/07/29(水) 04:42:03

ぶっちゃけアセンブラが分かってれば、ソフトウェアレベルの出来事なら一番下の構造
から透けて見えるから、ポインタなんかは概念も挙動も一発で飲み込める。
下の構造が見えないと、どんな処理が速いとか遅いとか効率いいとか悪いとかは経験の
繰り返しで飲み込むしか無いけど、下から見えていれば論理的に自然に飲み込める。
だが、アセンブラを理解する段階での苦労が大きいし、今のご時世でどんだけ報われる
かは自信ないからお勧めもしない。
とは言っても、昔は「まずアセンブラで」とか「BASICかアセンブラしか開発環境は
ありません」とかが普通だったから、そこまで難しいもんでも何でもないけどな。

**名前は開発中のものです。** · 2009/07/29(水) 05:06:48

アセンブリ言語自体はそらもう単純なもんだからな
ただ今のプログラミング環境に慣れ親しんでると、ちょっとした事すら書くのが面倒ってだけで

**名前は開発中のものです。** · 2009/07/29(水) 06:22:35

newとかdeleteとか
必要性がよくわからなくて結局殆ど使っていない。

使った方がカッコいいんだろうけど

**名前は開発中のものです。** · 2009/07/29(水) 07:15:08

動的に確保するときだけ使ってる

**名前は開発中のものです。** · 2009/07/29(水) 09:17:36

俺も必要性よく分らなかった時は使わずにやってた
使い方覚えたら結構便利だ
すぐでなくともそのうち覚えればいいんじゃないか

**名前は開発中のものです。** · 2009/07/29(水) 10:34:12

使わないでなんとかできてると
覚えようとしないんだよなぁ……。

プログラム言語の解説サイトとかで命令の説明とかはいくらでも読めるけど、
「ゲームを作る際にこうやって使ったら便利！」とかまで書いてある事ないじゃん？
だから「ふーん」で終わっちゃうんだよね……。

いや俺が不勉強なのはわかってるんだが。

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

必要になったときに学ばないと覚えないんだよなぁ……
ポインタもメモリの確保もよく分からなかったけど、
一度必要になってから調べなおしたら結構使いこなせるようになった

**名前は開発中のものです。** · 2009/07/29(水) 11:05:54

俺もテンプレート使う気なかったけどある時どうしても使う必要に駆られて使ってみたらすんなりいって便利だったなあ
まあ使わないでいけるんならいいんじゃまいか

**名前は開発中のものです。** · 2009/07/29(水) 11:45:25

C++は文法習得～良いコーディングの間が長すぎる
いろいろ覚えるとC++のほうがゲーム作りやすく感じるんだけどな

**名前は開発中のものです。** · 2009/07/29(水) 13:08:33

Javaだと手軽にクラス使えるから結構細かいこともクラス使って実装したりするけど
C++はクラスが使いにくくて返って面倒になったりするからつい細かいことはC風に書いてしまう

**名前は開発中のものです。** · 2009/07/29(水) 13:15:13

STLはすげー便利

**843** · 2009/07/29(水) 13:17:37

いや出来合いのクラスを使うのはいいんだけど
作るのがめんどくさいんだよね

**名前は開発中のものです。** · 2009/07/29(水) 13:47:45

そもそもＪａｖａはクラス使わずに書けないのでは

**名前は開発中のものです。** · 2009/07/29(水) 13:54:50

そりゃもちろんそうだけど，「すべての変数や関数がクラス内に収められている必要がある」
というだけのことであって，クラスを単なる名前空間と考えるならCと変わらん
クラス使ったからってオブジェクト指向になるわけじゃない

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

まあ、intだってクラスだし、C++は設計的に変数は全部クラスっちゃクラス

さまざまな動きするものをまとめて管理するにはクラス使う方がラクだと思う
シューティングの弾とかRPGのNPCとか。
というか俺はクラス使った半オブジェクト指向でしかゲーム作れなかったりする

DXライブラリ 総合スレッド その3

DXライブラリ総合スレッドその3