勝手ながら、サッカーに一段落つけたところで次はどこに進もうかと。
作りたいものは溢れてるんだが。
挫折したわけでもないけどテトリス再開しようかと思ってた。
ここ(テトリス)に至るまでに、もう少し簡単な(に見える)プログラムあるんじゃないかと。
俺的に、簡単なプログラムの条件
・アクション性が無い
ターン制のSRPGとか「不思議のダンジョン」系とか、「上海」とか「鮫亀」とか「倉庫番」とか。
対CPUの無い、対人対戦前提なら将棋とかチェスも難しくはない。
・敵がいない、敵に高度な思考を要求しない
1ドロップで役を揃えるだけのカジノポーカーなんかはかなり楽。
ブラックジャックなんかでも、CPUとプレイヤーの駆け引きが関わってきたら難易度一気に上がる。
そんなこんな考えてたら、倉庫番系の固定画面パズルか今回の3目並べか。
今時点で考えても対CPUの3目並べより倉庫番のほうが簡単だと思う。
なんでこっち選んだのかな。
ダウンロード
http://hiyayakko.sarashi.com/MaruBatu/MB001.zip (2009.08.25)
なんて決意を決めつつ、今日はあんまり進展ない。
fpsまわりの処理を2日ほどかけていじってみたけど、結局元どおり。どうにも納得いかない。
今の方法では、1フレームおきに描画処理してるんだけど、それ以上のフレームスキップが
入ると、やっぱり遅くなってしまう。
原因はわかってるんだけど、どうにもキレイにまとまらないんだこれが。
今日の夜時間は、ファイルのアップロードについていろいろ悩んでた。
ソリューションファイル(.sln)を含めるのにはいろいろと抵抗あるんだけど、やっぱ、これを
入れておけば、ダウンロードファイルからクリックでプロジェクト開くし、使い勝手がいいと思う。
ここに含まれてる俺の個人情報なんて好き放題抜いてくれても実害なかろうっていう覚悟。
main.cppは、前のSimpleSoccerの初代とほとんど変わってないと思う。
メインのメインを見れば処理の流れが見えるように意識しつつ。
若干の変更はあるけど、雛形としていつもコピペで持ってきてる形。
今回、StdAfx.h ファイル(pch:プリコンパイルヘッダ)を作ってみた。
この名前にはVisualStudio6.0 時代の苦い思い出があって切なくなるんだけど。
767 名前:名前は開発中のものです。[sage] 投稿日:2009/07/24(金) 08:59:47 ID:5C3gkZxn
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"を書く(コメントは前に入れてもおk)
ちなみにstdafx.cppは、#include "stdafx.h"の一行だけでおk
5. ソリューションエクスプローラでプロジェクト名を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを
使用する(/Yu)」に変更する
6. ソリューションエクスプローラで「stdafx.cpp」を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを
作成する(/Yc)」に変更する
これで、stdafx.hを変更する時以外は、ビルド速度がかなり劇的に上がるはず。
大した作業にはならないはずだから一度試すといい。
768 名前:名前は開発中のものです。[sage] 投稿日:2009/07/24(金) 09:09:49 ID:5C3gkZxn
ああ、気付きにくいかもしれないことを補足。
自作ヘッダから<string>とか<math.h>とか使いたい場合も、「必ず全ての*.cppの最初で
stdafx.hがインクルードされる」という規則だから、結局は自作ヘッダがインクルードされる
時点ではstdafx.hが既に読み込み済みになってる。
なので、自作ヘッダに#include <string>とか書く必要も無し。自作ヘッダで使いたい標準の
ライブラリなんかのincludeも、全部stdafx.hに逃がせばおk。
771 名前:名前は開発中のものです。[sage] 投稿日:2009/07/24(金) 19:26:36 ID:5C3gkZxn
デメリットは思い当たらないなぁ。
「使いたい外部ライブラリのヘッダを全部何も考えずにstdafx.hに入れまくれ」
「全てのcppファイルの頭でstdafx.hをインクルードしろ」
ってルールが縛りといえば縛りだけど、むしろ楽になるだけだと思う。コンパイルも
別次元に速くなるし。
原理的には、stdafx.hの中身をコンパイルし終わったとこでいったん止めちゃって、
中間情報として拡張子pchのファイルに保存しておき、*.cppをコンパイルする時に
その情報を使い回して、#include "stdafx.h"まで読み飛ばして、それ以降のソース
だけコンパイルするイメージ。実際に内部がどう動いてるかは知らないけど。
なので、cppの頭で#include "stdafx.h"を入れ忘れると、
「プリコンパイル済みヘッダーの検索中に予期せぬ EOF を検出しました」
とか言われる。
stdafx.hの中には、C++のソースなら何書いても多分平気だから、大抵の使い方には
対応できると思われ。あまり頻繁に書き換えると、そのたびにpch作り直しで効果が
薄まるけど、自作ヘッダでも「更新少ない」「かなり色々なソースから参照される」
みたいな奴はstdafx.hに入れちゃってもいいと思う。
引用終わり。
なんかコンパイル通らなくて悩んだ場合は、一度ビルドからソリューションのクリーンをやって
みるといいかもしれない。
初学者向けっぽい内容じゃないなあ。
次のエントリから一気にレベル下がると思うので、今日のところはうまくいったら拍手って
ところで、内容は理解してなくてもいい。
実質はソースをダウンロードして、marubatu.sln をクリックしたらVisualStudioに全てお膳立て
できてるはずなので、これがコンパイル実行できたらいいだけの話。
○×ゲームを作るとか言いながら、雛形だけで黒い画面にfps計測結果を出してるだけだし。
PR