https://ameblo.jp/punpuku708/ 不定期更新ブログだからちょくちょく。暇な時しか更新しないから暇な時に見てね。ゲームのレビューとか、プログラムのこととか。 ja
このタイプの記事は二度目。
ずいぶんと調子に乗ったこと書いていたのをまた発見したので。

この記事。
ゲーム業界が


また偉そうにゲーム業界のことをお客様の視点で書いてんだけど・・・
もうどうしようもないよね。何も考えずに叩くユーザだよ。ゲハ板にいそうな。

消してしまおうかなとか思ったけど、己への戒めとして残しておくよ。


特にひどいのが最後よ。
任天堂がスクエニより嫌いになっちまっただってよ。
初めて批判を覚えた中学生かよッて感じだわ。当時18歳。


少しはゲーム業界に詳しくなったから今の意見を簡単に書いておこう。

任天堂はやべえ。ほぼゲームだけで世界企業になってる時点でやべえ。
スクエニもやべえ。グラフィック技術が特にね。世界的に見てもトップクラス。
後SCEもやべえ。特に今はPS4も出て更にこれからって感じ。


とにかく、一般人でも知ってるような企業は、全部やべえんだよ。当たり前だけど。
常にユーザの事一番に考え、悩んで悩んで商品を世に出してる。
正直、頭のおかしい連中しかいないんだろうなと思う。
自分もその一部になりてえな。その一歩は踏み出せそうだけどさ。


批判はさ、理由を付けて、相手に納得させないと何も価値がないってことを専門学校で知ったよ。そういう議論は楽しいとも知ったよ。

そんなわけで、過去の自分へのメッセージでした。
この記事も、後で読み返したらｳﾜｱｱｱｱｱｱｱｱｱｱってなるんだろうね。


次はいつになるかな。 ]]> https://ameblo.jp/punpuku708/entry-11820365293.html Sat, 12 Apr 2014 08:56:12 +0900
これは数学的な処理をまとめたもので、例えばベクトルや行列を構造体として定義していたり、
内積や外積を求めたり、逆行列を求めたりする関数が宣言されている。


DirectXなので、当然ゲームに使えそうなものしかないが、これはかなり重宝するものだ。
D3DX系にもこういったものがあった。
が、前回書いたように、D3DXは使えない。(使おうと思えば使える)

で、DirectXMathについて調べていたら、これを扱うには注意点があるようだ。


何も考えずに使うと、特定のCPU上では、これが動かない可能性があるというのだ。
何も考えずといったのは、本来動かない環境でも、動かす方法はあるということだ。

具体的には、
SSE/SSE2に対応していないCPU
また、ARMアーキテクチャのCPUでは、ARM-NEONに対応していないCPU
の2つである。

？？？？？
である。


今まで自分のCPUが速いのか遅いのかでしか考えなかった俺には、全くわからない。
が、それではプログラマ失格。逃げてはいけない。そのうち取り上げるかも。

とにかく、自分のCPUではどうなのか調べてみた。

DirectXMath自体に調べる関数があった。
XMVerifyCPUSupport()である。戻り値はBOOL。

で、自分は対応していたので安心。このライブラリを使える。
が、もしも対応していなかった時は、_XM_NO_INTRINSICS_を#defineで宣言してやればいい。


すぐ気づくだろうが、これがめんどくさい。#defineはプリプロセッサである。
つまりコンパイル時に解決されるため、例えば、アプリ起動時にCPUを調べ、
それに合わせて処理を切り替える・・・ということが簡単にできないのだ。
これに対応するくらいなら、アプリ終了させたほうが楽。

やるとしても、別の数学系ライブラリをリンクさせて、使い分けるくらいかな・・・？
おすすめは出来ないな。


といっても、先述した条件に当てはまってしまうCPUは、今の時代では殆ど無いと思う。
(完全に個人的な意見)
理由としては、SSEが初めて登場したのが1999年だから。SSE2も2000年である。

ので、それ以前の古いCPUの載ったPCは使ってる人なんてかなり少ないと思う。
まあ、だからって今のCPU全部がSSEに対応してるかって言われると・・・わからん。


とりあえず、アプリ実行時に調べることくらいはしてあげたほうが、ユーザには優しいかも。 ]]> https://ameblo.jp/punpuku708/entry-11820332095.html Sat, 12 Apr 2014 07:53:22 +0900
Windows8にはD3DX系が無い。
代用として、DirectXTexやDirectXMath、DirectXTKがある。
要ダウンロード。


それを使う際、プリプロセッサに以下の文字列を追加すること。
それによりターゲットにするOSが変わる。


_WIN32_WINNT=0x0600

デフォルト値は0x0602で、これはWindows8を表す。
7にしたいなら0x0601、Vistaなら0x0600を設定。

おそらく、下位のOSで設定しても、上位のOSでは動くと思う。
(まだテストしてない。そのうちしないと)
プリプロセッサだから、あくまでコンパイル時だけの話なのかな？


参考：
http://www44.atwiki.jp/bokuyo/pages/190.html
http://d.hatena.ne.jp/poyonon/20121106/1352152645 ]]> https://ameblo.jp/punpuku708/entry-11817561729.html Wed, 09 Apr 2014 02:23:47 +0900
結局、MotionJoyというツールに頼ってしまった。それはいいとして。
わざわざ記事にしたのだから、もう少し突っ込んでお話を。



PS3のコントローラは、13ボタン、十字キー、スティック2本で構成されている。
入力系統はDirectInputを使って処理するのだが、このボタン達が、DirectInputではどのように処理されるのかについてだ。

ここに関しては軽くキレそうになったので、今回記事にした。


言わずもがな、PS3のコントローラはXboxのものとは違い、PCでの使用はそんなに考慮していない。
しかし結構DirectInputさんで問題なく処理できるので、使おうと思えば普通に使える。

DirectInputでジョイスティックを使えるようにする流れは別のサイトさんを参考にしてほしい。
ここで書くのはだるいので。

PS3のボタン配置はこうなっている。

△ボタン・・・ボタン１
○ボタン・・・ボタン２
ｘボタン　・・・ボタン３
□ボタン・・・ボタン４
L2ボタン・・・ボタン５
R2ボタン・・・ボタン６
L1ボタン ・・・ボタン７
R1ボタン・・・ボタン８
SELECT・・・ボタン９
START・・・ボタン１０
L3　　 　・・・ボタン１１
R3　　　・・・ボタン１２
PSボタン・・・ボタン１３

だ。すぐに調べられることだけど、参考になるかもだからどうぞ。

で、ゲームパッドにも当然種類がある。やっかいなのは、それによって十字キーやアナログスティックの処理の仕方が異なってくることである。これだけでキレそう。せめてゲームパッドくらい合わせてくれよ各メーカーさんと思うところである。

ましてやボタンさえ違う。配置は同じなのに、中身が違う。マジおこですよ。
何？キーコンフィグくらいゲームで実装しやがれクソ野郎みたいな？ぶっ飛ばすぞ？おお？って感じ。



ちなみに。PS3のコントローラはツールなしではPCでは使えないようです。(俺が知るかぎりでは)
なぜかというと、アナログスティックの処理をDirectInputがやってくれない。情報がどこに入っているのか俺にはわからなかった。

が、MotionJoyってのを使ったら情報を取得できたってこと。
ボタンと十字キーの取得はMotionJoyなしでもできたんだけど・・・なんでなんだろうか・・・。

きっと方法があるんだろうけど、俺にはわからない。誰か知ってたら教えて下さいな。


構成がかなり適当な記事になってしまった。
終わり。

]]> https://ameblo.jp/punpuku708/entry-11580089669.html Thu, 25 Jul 2013 22:36:36 +0900 HRESULTには、色々な定数がある。

E_FAILとS_OKをよく使う。これはbooleanとおんなじ様なもの。

FAILED(),SUCCESSED()をif文の条件に使って分岐させると、プログラマっぽい。

で、注意しないといけないのが、S_FAILED。一見FAILED()でtrueが返ってきそうな定数だけど、
残念falseが返ってくるので注意。

この定数の意味は、「関数の処理自体は成功した、が、君のしたいことはできなかった」って感じの意味。つまりエラーではない。

要は、HRESULTに詳しくない人(俺とか)はS_FAILEDなんて使わないほうがいいよってことだよ。


ハイ終わり。

HRESULTを知らない人にとっては何言ってんだこいつと思う。
知ってる人でも、少し考えないと理解できないんじゃないかと思う。

それぐらいいい加減でめちゃくちゃな記事になりました。
自分がわかれば良い。


]]> https://ameblo.jp/punpuku708/entry-11556226914.html Thu, 20 Jun 2013 00:27:51 +0900 もうすぐ発売するゲームだよ。楽しみだね。


これです。体験版だけど。



結果だけ言うと・・・決してモンハンとは違う。
確かに、別のゲーム性を追求していた。
と言っても、大概の人はモンハンじゃん。というだろう。


まあ、とりあえず、いつもどおりに。


良かった点
・普通に攻撃するだけでは、ボスにダメージを与えられない。考えて攻撃する必要あり。
・その考える時に、結構色んな選択を迫られる。その選択が縛られることも少なかった。
・間違いなく、協力プレイが面白くなる。しかし、人がいないだろう。

悪かった点
・根幹はやはりモンハンである。パクリと言われてもしょうがない。
・演出のクオリティが全体的に低かった(特に音関係)。もっと作り込めたはず。
・最初に期待していたのが、太刀の納刀による攻撃なのだが、期待を裏切られるカッコ悪さ。やればわかる。


このゲームで大事になるのは、「部位破壊」である。
モンハンにとっては、部位破壊は尻尾を除き、戦闘には大きな影響を与えなかった。
が、このゲームは部位破壊を考えなくては効率がガクリと落ちる。

詳しくは説明がめんどくさいので、体験版をやってみてほしい。



一つだけ言いたいのは、なぜロックオン機能をつけたのかということである。
確かに、このゲームはモンハン以上に敵が動くので、ロックオン必須である。
しかしだ。

他の仲間が設置系の回復エリアとかを用意することが出来るのに、これはいかがなものか。
だって、敵にロックオンしてたら、それ見えないじゃん。
わざわざロックオン外せって？そんなことをユーザにやらせるのかと。


「わざわざ」はストレスにしかならない。それが頻繁に発生するこのゲームは・・・。
という感じがある。


まだもっと良いゲームになったのではないだろうか。
と、思ってしまう。

でも、やる価値はあると思う。体験版はやる価値ある。

なんだか、Vitaの人気ソフトは狩りゲーばっかりだね。


これぐらいで終わっておこう。
次はいつになるかな。

]]> https://ameblo.jp/punpuku708/entry-11552804244.html Sat, 15 Jun 2013 13:54:55 +0900
この射影変換をすれば、普段の3Dの画面が2Dになる。そして奥行き、つまり遠近感がなくなる。



その事に関して長い間引っかかったことがあったので・・・メモる。

DirectXでは、D3DXMatrixOrthoLH()という関数を使えば、簡単に正射影変換ができる。

で、その関数の引数に、幅、高さ、ニアプレーン、ファープレーンを設定するわけなんだが・・・。

それで普通にゲームを作っていたら、何かがおかしい。
具体的に言うと、当たり判定がバグった。

画面の右下に行けば行くほど、当たり判定がずれていくのだ。

「なんじゃこりゃ？」と、悩むこと1週間。
原因はこの正射影だった。

幅と高さに、ウィンドウの幅、高さを渡していたのだ。それが間違い。

ウィンドウには、外枠が存在する。ウィンドウの名前とか、終了ボタンとかがある場所がそれだ。
ウィンドウの幅、高さというのは、その外枠を含めてのサイズになる。


つまり、実際の画面のサイズ(クライアント領域という)とウィンドウのサイズは微妙に違うのだ。


それ故に、当たり判定がずれた。
正確には、自分の思っていた位置とは少しずれた位置に描画されていたのだ。


正射影をするときには、クライアント領域の幅、高さを渡してやらないといけない。
同じ現象にもしも悩まされている人は、ぜひとも試していてほしい。 ]]> https://ameblo.jp/punpuku708/entry-11551627172.html Thu, 13 Jun 2013 22:37:09 +0900 メモっておく。前記事で言ったマルチスレッド関連はいつになるかわからない。

D3DDEVTYPEには2つある。D3DDEVTYPE_HAL,D3DDEVTYPE_REFだ。
HALだって！？なんて一瞬思ったが、全くの無関係である。


これはIDirect3D9::CreateDevice()の第2引数に渡す定数なんだけど、
この2つを切り替えるだけで、バカ見たく処理速度が変わる。

結論、速いのがHALで糞遅いのがREF。
どうやら、描画関係の処理全て(頂点処理除く)をGPU(ハードウェア)でやるかD3D(ソフトウェア)でやるかを切り替えるものみたい。

当然GPUの方が速い。ならば迷うことなくHALを使うべきである。
しかし、REFを使わなければならないタイミングは存在する。じゃなきゃこんな設定は存在しない。

それが大事かなと思ってメモしている。しばらくHALのままで行きそうだから。

REFは、いわゆるデバッグに使うことができる。
HALだといろんな情報をGPUに渡して計算してもらうので、GPUの中でどのように値が変化していっているか、見ることはできない。これは絶対にできない。
(できたらGPU作ってる会社のノウハウがダダ漏れになるってことだからかな？)

REFにしとけば、D3Dの方ですべての計算を行うので、どのように値が変化していっているかを追う事ができる。
つまり、デバッグができるということなのだ。

その分処理は遅くなってゲームどころではなくなるが、これは大事な機能だ。


覚えておくと、便利かもね。
終わり。


]]> https://ameblo.jp/punpuku708/entry-11542892419.html Sun, 02 Jun 2013 03:30:24 +0900
初のゲームプログラム関連の記事がこんなものになろうとは・・・


現在、DirectXというSDKを使ってゲーム開発をしている。バージョンは9.0。

で、最近マルチスレッドを学んだ。
なんと便利！そう思っていた。

しかしマルチスレッドというのは如何せん理解しづらく、「並列で処理が走る」が故の
同期処理を習得するのに時間を要した。

同期処理を一つミスれば、プログラムが止まってしまう可能性があるからだ。

なんという厳しい世界。とかなんとか思っていた。
そして少しはできるようになったんだ。


そして、DirectX9を使ったプログラムに、マルチスレッドを使ったのだ。
するとあら不思議。一定の確率でゲームがメモリエラーを起こして止まっちゃう。

原因がマルチスレッドにあることは明白だった。しかしどう考えても同期はとれている。
いや、きっと凡ミスをしているに違いない・・・そういって約一週間。悩まされた。

ところが、知り合いのスーパープログラマーに聞けば衝撃の解答が。

「DirectX9はマルチスレッド推奨してないで。」



そうなのだ。調べるとすぐに出てきた。DirectXを作っているMicrosoft自体が

「推奨していません。」といっているではないか。

俺には
「推奨していませんｗｗｗｗｗプギャーｗｗｗｗｗ
　ねえ今どんな気持ち？ｗｗｗｗねえ今どんな気持ち？？？？ｗｗｗｗｗｗ」
と見えたが・・・。

しかし、どうやらDirectX10以降は対応しているようだ。しかしまだそこに踏み入るには・・・
という段階。

もう白目だね。白目。泡吹いちゃう。
もうマルチスレッドでゲーム作っちゃってんだよ！！！くそったれ！！！！


・・・ふう。


そんなことは良いのだ。過去のことである。

DirectX9でのマルチスレッドの使用はすっぱり諦めることにする。

しかし、マルチスレッドの知識を無駄にしてはいけない。
今後DX10、11とシフトしていくかもしれない。
他の環境でマルチスレッドを使うかもしれない。

だから忘れてはならないのだ。
と思ったのだ。

なので、マルチスレッドに関して自分がすぐに理解できなかった部分をメモする。
記事が長くなったので、次の記事で書くことにしよう。

次は、今週中に。



]]> https://ameblo.jp/punpuku708/entry-11540730286.html Wed, 29 May 2013 23:17:06 +0900 技術多すぎて忘れちゃうことも多いしね。

エフェクトを作りたいなあと思ったので、作り方をメモしておく。
絶対忘れる。


といっても、全くの初心者なのでその辺はご愛嬌。


メモ用なので画像も貼らず淡々と。

①図形ツールの直線で輪郭の線を引く。入り、抜きを適当にそれっぽく
②両端をぼかしツールで少しぼかす。
③新しいレイヤーで、真ん中にかなり細い線。白がいいかも。てかなくてもいい。
④繊維にじみツールで、細い線をガシャガシャぼかす。
⑤新しいレイヤーで、今度は①よりも少し細い線。色は③のと同じ。
⑥①と⑤のレイヤを結合、指先ツールでそれっぽくガシャガシャ。



これでできるのがこれ。



終わり。

何に使えるかわからない。初めてってそんなもの。

]]> https://ameblo.jp/punpuku708/entry-11538806127.html Mon, 27 May 2013 02:13:03 +0900