指定した座標の色の取得

[dame]

DXライブラリを使ってRPGのゲームを作成したいと考えています。

背景画像とキャラクタの絵を用意し、背景画像の上をキャラクタがドット単位で移動できるようにしたいのですが、そのとき、移動可能なエリアと進入不可能なエリアを作りたいと思います（例えば背景画像が海のところは移動できない）
進入不可能なエリアであるかどうかの判定をしなければならないのですが、最初は、背景画像に合わせて０と１で移動できるか、できないかのデータを２次元配列などに格納しておくことを考えたのですが、ドット単位でやろうと考えると、量が多すぎて自力でデータを作るのは難しい気がします。

そこで、背景画像が特定の色のところには進入できない、というような方法を考えたのですが、指定した座標の色を取得することは可能なのでしょうか？あるいは、この問題を解決するのに、もっと適切な方法があるようでしたら、教えていただけないでしょうか。お願いします。

[bodomcross]

DXライブラリのGetPixelSoftImageで取得できます。

くわしくは本家のリファレンスを参考にしてください。

http://homepage2.nifty.com/natupaji/DxL ... tml#R20N13



※新しい機能だったような気がしますので、DXライブラリの再インストールがオススメです。

[Dixq (管理人)]

先日のDXライブラリバージョンアップでそういう系統のことが高速で出来るようになりました。
リファレンスの「ドット単位で画像にアクセスしたい関係」をご覧下さい。

なお、１ピクセルとってくるだけ位だったら
http://homepage2.nifty.com/natupaji/DxL ... .html#R2N6
これが便利です。※多用は無理

しかし色でいけるかどうかわけるにしても、画面から色を取ってくるのはちょっと非効率ではないでしょうか。
もしその方法でやるのなら、地形データのビットマップ画像を用意し、ビットマップ画像を配列に読み込んではどうでしょう？
以下のようにゲームで実際に使う画像と、地形データ画像を２種類用意するということです。


（赤が行けない所）
ビットマップ画像って無圧縮の画像データです。
なので
RPGがそれぞれ0～255の値で入っており、これらの色素子３つで１画素を構成しています。
ビットマップファイルは54バイトのヘッダ部分と、その後の画像本体のデータで構成されています。
「ビットマップ　フォーマット」「ビットマップ　ヘッダ」
などで検索すると、その意味が解ると思います。
この方法でやるなら、まずビットマップファイルを開いて画像データを配列に入れることが出来るようになるといいでしょう。
自力で実装出来たほうが今後の為になると思いますが、一応サンプル提示します。
一応自力で最初作ってみて下さい。
http://www.play21.jp/board/formz.cgi?ac ... 6061#26033

やったことないんで、この方法がいいのかどうかわかりませんが・・。

[dame]

bodomcrossさん、Dixqさん、ありがとうございます。
とても助かりました。
Dixqさんの言われたように、画像を二枚使う方法で試してみたいと思います。

また困ったことがあったら相談させてください。よろしくお願いします。

[lbfuvab]

移動禁止かどうかの判別なら白黒ビットマップで充分だと思いますがどうでしょうか？

[Dixq (管理人)]

それもそうですね＾＾；

[Justy]

　実際のところ移動の可・不可だけならどっちでもいいんですけど、本格的に作り始めると
そのうちマップに附随する付加情報……例えば床の素材から来る足音の変化とか、
フラグによって移動可能範囲を変えたいとかあるかと思うので、
容量的に厳しいとか特に制限がなければカラーのままでもいいかと思います。

　まぁ、それ毎にマップを用意する、という手も有りますが……。

[Dixq (管理人)]

確かに足音変わるやつありますね。
こういうときプロはこうやって実装してるっていう何か主流な方法とかあるんですかね？

ただ、１画面ずつ固定で画面の切り替わるタイプのRPGならいいですけど、
FFやドラクエみたいに画面スクロールで切り替わっていく奴だと処理がめんどくさそうですね。
1万x1万位のビットマップ用意したらそれだけで数百メガ行きますし、
必要な部分をリアルタイムで読み込むとしても・・・。

そう考えるとある程度いくつか地形パターンのあるチップを並べた方がよさそうな気もします。

[Justy]

＞確かに足音変わるやつありますね。

　コリジョンデータの中にアトリビュート（属性）の１つとして埋め込むことが
多いですね。
　
　コリジョンをとると同時に属性を取得できると何かと楽ですし。



＞画面スクロールで切り替わっていく奴だと処理がめんどくさそうですね
＞1万x1万位のビットマップ用意したらそれだけで数百メガ行きますし、
＞必要な部分をリアルタイムで読み込むとしても・・・。

　そうですね。

　そこは質問者さんがどういうゲームにしたいのかによるのですが、
自分のいる画面とその周辺の画面分はメモリに保持、移動したら裏で
ストリーミングで読み込むっていうのはよくある話です。

　3Dだとカメラの向きに依っては遠くが見通せてしまったりして、
それなりにいろいろと工夫が必要になることもあるのですが
2Dならそんなこともないので、普通に実装できるかと。



＞ある程度いくつか地形パターンのあるチップを並べた方がよさそうな気もします

　ごもっともｗ

[Dixq (管理人)]

なるほど。
３Dゲームのデータをリアルタイムで読み込むのは大変そうですね・・。

そして、今までの議論を無意味にする提案ですが、
地形データすらなくても、移動は1ピクセル単位で移動可能であっても、
実際にいけるところ、いけないところは昔のRPGのように32x32の区間単位で実装してもいいような気がします。
斜めとかは確かにギザギザになると思いますが、アクションゲームの地面じゃないので、そこまで厳密に実現する意味はあまり無いのでは無いかと思います。
昔作ったスーパーボムマンも1ピクセル単位で移動出来るが、いけるところ、いけないところは32x32の区間単位で制御してます。
あれはまた違うかもしれませんが・・。