09/03/08 19:09:05 CrTNgcou
この際、本家DXライブラリにDXライブラリ3Dを機能統合してしまっても良いんじゃないか？
今どき2Dだけじゃなぁ
776:名前は開発中のものです。
09/03/08 19:25:34 tHlNETTL
>>775
いや、意味が分らん。
碌にDirectXすら使えない人間が３Dに手をだしてどうしたいんだ？
むしろ、本家は本家であの程度でまとまってるからこそ良いライブラリだろ。
もっと色々とやりたかったら海外の３Dライブラリをあさればいい。高機能の多いぞ。
（まぁ、普通に日本語対応がメンドイけど。）
777:名前は開発中のものです。
09/03/08 19:52:53 CrTNgcou
っていうか、DXライブラリ3Dの開発を継続してほしいJEXさん
778:名前は開発中のものです。
09/03/08 23:53:47 Os5GQobq
>>772,773
弾幕毎に名前付けてるから、気を付けないとまんまになっちゃうんだよね
もう開き直っちゃおうかな……
779:名前は開発中のものです。
09/03/09 00:24:37 y+3gsDNg
どうせやるなら「白い弾幕くん」くらい自由度上げてみたらどうだ
780:名前は開発中のものです。
09/03/09 05:38:20 xYWyf4vJ
縦弾幕だったらどうやったって東方っぽいって言われるのがオチだから、
変なこと気にせず好きにやっちゃえYO！
781:名前は開発中のものです。
09/03/09 13:06:42 Ge4atQjd
東方のオマージュである、と明記しちゃえば変な因縁はつけられなくなると思う
782:名前は開発中のものです。
09/03/09 13:28:18 1MIteGpr
自分で考えて実装した者に対して
なんという屈辱を。
783:名前は開発中のものです。
09/03/09 14:58:21 Yq7DJGmB
パクってないんなら堂々としてればいいじゃない
ここで愚痴る前にちゃっちゃと完成させて
もう東方に先を越されないようにすればいいじゃない
784:名前は開発中のものです。
09/03/09 15:06:44 mr6tRDyA
先を越されたから愚痴ってるんだと思うがのｗ
785:名前は開発中のものです。
09/03/09 15:12:00 anLE8kz6
新しいの出るごとに被るというと
低速移動時に敵を貫通するとかボム使うとパワーが減るとかその辺りか？
786:名前は開発中のものです。
09/03/09 15:54:45 z4EGzSSU
別に愚痴のつもりじゃありませんでした
こうやって悩むのもゲーム制作の楽しさの一つなので……
気分を害されたのならすいません
>>785
点レートアイテムとか、特殊アイテムを取るとボーナス敵が出る点が……
787:名前は開発中のものです。
09/03/09 17:01:47 GzA1DnX1
どんなシューティングでもお前。。。
788:名前は開発中のものです。
09/03/09 18:04:17 dWRPooR0
Q.○○のパクリですか？
A1.はい、参考にしました。
→盗作ｲｸﾅｲ！ 俺の好きな○○を汚すな！ ○○の公式サイトのBBSに通報(?)書き込み
A2.いいえ、オリジナルです。似ているのは偶然でしょう。
→嘘を言うな、正直に言えよ
A3.いいえ、○○ではなく△△のパクりです。
→そんなん知らねーよ！ △△も○○のパクりだな！
実際にあるから困る。
789:名前は開発中のものです。
09/03/09 18:28:11 aHHsyNV0
結論：気にせず作れ
作ることにも価値がある
790:名前は開発中のものです。
09/03/09 18:40:02 6kYj4gTE
>>788 どっちかと言うと、この手の奴で、実際にパックたりしてなかったら、
何も答えないのがベスト。ただただ、事務的返しで流すべし。
あと、>>786みたいのは 東方以前からあるのばっかじゃねぇかよwww
それこそ、ファミコン全盛の時代（のアーケード）から・・・・
「今更それを先を越されたとかwww」
と言われるのが落ちじゃね？
791:名前は開発中のものです。
09/03/09 18:51:35 z4EGzSSU
んー、今更だけど自分で気にしすぎだった気がしてきた
前作が東方をリスペクトしたものだったので、今回も素直に断り書きを入れてみます
792:名前は開発中のものです。
09/03/09 19:02:29 dWRPooR0
パロディにまで昇華させてしまうという手もあるな。
793:名前は開発中のものです。
09/03/09 21:33:00 Zw6a9bk0
URLﾘﾝｸ(siv.creation.googlepages.com)
知ってるとは思うがこれにはずっと期待してる
794:名前は開発中のものです。
09/03/09 22:34:04 GzA1DnX1
押しっぱをできなくするようにしたいけど
char a[256]
GetHitKeyStateAll(char *a)
つかうとうまくできねぇ。。
ポインタをctrcmpやるのはおかしいの？
それとも配列に入ってるのがおかしいの？
俺の頭がおかしいの？
795:名前は開発中のものです。
09/03/09 23:19:34 2qC8QqlY
>>774
遅レスだがコンストラクタについて幾つか書きます。
さすがに長文書いてコメントが無いのは可哀想だったから。
昔の言語仕様ではコンストラクタではインスタンスの生成途中であるから複雑な処理を書かないようにしていた。これは慣習・慣例の部類の話。
コンパイラの亜種が多くて、C++の仕様外の範疇での動作はどのようになっているのか分からない時代だったからという背景もある。
自分はコンストラクタに初期化処理を噛ませる横着な書き方をしていたときに先輩に指摘された事は、1,2,3以外にも、、、
・クラス設計者とクラス利用者は同じでない
⇒利用者がstaticで外部変数なインスタンスを生成するかもしれないから、
mainよりも先に呼ばれる処理に複雑な記述を置くべきでない。
つまり、利用者の立場になって明示的に初期化処理を宣言するべき。(手を抜くな)
・戻り値を持たない件に関して、例外処理を使うのは怠惰な手段である。
⇒try-catchを用いるのは、デバッグの最終手段である。(例外処理はネストできない為)
例外処理は一般的にコンパイラの最適化の阻害となり遅くなる要因となる。(ジャンプテーブルを生成する為)
つまり、保持値チェックにはassert使えというお話。
⇒メモリ確保に失敗する危険性をもっと認識するべき
特定のハードウェアを対象にする場合、大概は独自のメモリアロケーター(dlmalloc等)を実装していることが多く、
new失敗の可能性(インスタンス生成失敗)は大いにある。
とのことでした。
>問題点は、
>「このような状態で他のクラスのインスタンスのメンバ関数を読んだりすると巡り巡ってまだ生成途中の自分自身のメンバ関数が呼ばれるかもしれないから」
>との事です。
これには同意です。
だから「コンストラクタに記述するのはせいぜいメンバ変数に対して初期値の代入ぐらい」に留めている人が大半で自分もそうしています。
いや～、バグの無いプログラムって難しいですね。
796:名前は開発中のものです。
09/03/09 23:31:07 2qC8QqlY
>>794
上手くできないってどういう意味？
char m_cKey[2][256]; //キーバッファ
とでもして
毎フレーム
void GetAllState(){
memcpy(m_cKey[1],m_cKey[0],256);
::GetHitKeyStateAll(m_cKey[0]);
}
を呼んで、
int GetKeyPress(int KeyCode){return m_cKey[0][KeyCode];}//キーが押されているかどうか
int GetKeyDown(int KeyCode){return (m_cKey[0][KeyCode] && !m_cKey[1][KeyCode]);}//キーが押された瞬間
int GetKeyUp(int KeyCode){return (!m_cKey[0][KeyCode] && m_cKey[1][KeyCode]);}//キーが離された瞬間
とでもすればおｋ
前フレームとの差分で押された瞬間と話された瞬間を検出するべさ
797:名前は開発中のものです。
09/03/09 23:31:59 6kYj4gTE
>>794 エスパーじゃないんで、
何をやって何ができないのかすら分らん。
とりあえず、×ctrcmp =>○strcmpだと過程しても検討範囲外。
ポインタの使い方とか、関数の使い方は大丈夫だと仮定してもだ・・・・。
そもそも、そのchar a[]が何を入れるか理解してるかい？
そいつらに入るのは、あるキーが押されてるかどうかのon offフラグであって、
押されてるキーがchar型として'o'みたいに入るわけじゃないぞ。
押しっぱなしは、基本的には、
char NowKey[256];
char OldKey[256];
// ....somewhere to initilaize Nowkey[] and OldKey[], to 0.
GetHitKeyStateAll( NowKey );//Now get putting on key
if( NowKey[ KEY_INPUT_Z ] == 1 )
{ if( OldKey[KEY_INPUT_Z] != 1 )
{ PutOnFUNCTION(); // only not on putting Z_KEY.
OldKey[KEY_INPUT_Z]=1;
}
//There is No doing on putting Z_KEY.
}
else
{
OldKey[KEY_INPUT_Z]= 0 ; //No to put Z_KEY, initialize OldKey[] to 0.
}
な感じに書く。
798:名前は開発中のものです。
09/03/09 23:42:23 YtHLVg0L
推しっぱをできないようにするなんて
int pushOK = 0;
とか用意しといて
if (a[チェックしたいキー] && pushOK) {押したときの処理}
if (!a[チェックしたいキー]) pushOK = 1;
とかやればいいじゃない
（※厳密な文法に突っ込むのなしね、あと変数名が良くないことにもね）
799:名前は開発中のものです。
09/03/09 23:49:28 GzA1DnX1
あぁ。詳しくなくてすまん。ありがとう。
でも、なんとか、動作はしたぜ。
800:名前は開発中のものです。
09/03/10 00:11:41 Y5ijcxK4
LoadSoftImage()でPNG-8のパレットが取得も設定もできん…。
パレットはBMPしか有効じゃないんか。
透過色設定とパレット変更を同時にしようと思うと、PNG-8がベストな選択だったんだけど、
さてどうするべか……。
801:名前は開発中のものです。
09/03/10 00:43:20 liOB0hIm
どっかの時点でBMPに変換されるんだろうけど
その時点じゃまだなんだろうかね。
てかそんな命令あったのか……。
802:名前は開発中のものです。
09/03/10 01:39:41 Y5ijcxK4
PNGについてはlibpng使ってるっぽいからなぁ。
パレット変えられないのは困ったぜ。
803:名前は開発中のものです。
09/03/10 02:42:45 f5O5uX62
libpngって最近脆弱性が発見されたよね
804:名前は開発中のものです。
09/03/10 05:14:32 Y5ijcxK4
パレットアニメーション諦めて、アルファブレンディングで代用できるんかな……。
例えば、パレットアニメーションで
void PatteGradation(int red,int green,int blue,float ratio)
{
int new_red,new_green,new_blue;
int* p = m_pPalette; //元のパレット配列[3*256]
for (int i=0;i<256;++i)
{
new_red = *p + (int)((red - *p)*ratio);
p++;
new_green = *p + (int)((green - *p)*ratio);
p++;
new_blue = *p + (int)((blue - *p)*ratio);
SetPaletteSoftImage(m_nSoftHandle,i,new_red,new_green,new_blue,0);
}
}
という感じで指定の色(red,green,blue)にratioの比(0～1.0)で近づくエフェクトを考えているんですが、
これと同じ機能をブレンドモードを変更することで代用可です？
上手い演算具合が見つからない。
805:名前は開発中のものです。
09/03/10 05:17:44 Y5ijcxK4
あ、一個p++抜けてた。
でも、伝えたいことは伝わったはず。
806:名前は開発中のものです。
09/03/10 05:52:02 6T+yw6I/
フェードイン?
807:名前は開発中のものです。
09/03/10 06:29:38 Y5ijcxK4
そうですね、指定色へのフェードイン・フェードアウトという感じです。
SetDrawBright()では黒フェードが出来ますが、それの多色化＆抜き色対応版です。
808:名前は開発中のものです。
09/03/10 09:58:02 1/mzBUbU
2パターンだけ作って重ねてアルファを変えていくのが効率いいんじゃないかな
809:名前は開発中のものです。
09/03/10 11:39:59 xhsEfov4
>>793
ゲームパッドがX-BOX専用コントローラーしか使えないとか論外すぎる。
810:名前は開発中のものです。
09/03/10 15:29:37 AMym+srg
>>809
つ URLﾘﾝｸ(www.4gamer.net)
811:名前は開発中のものです。
09/03/10 16:10:09 qoncgAvF
使う側ならともかく、作って配布する側ならそれは解決にならんでしょ。
まあ自分で対応のパッド追加できると思うけどな。
812:名前は開発中のものです。
09/03/10 16:12:21 xhsEfov4
>>810
いや、そういう問題では・・
813:名前は開発中のものです。
09/03/10 21:25:09 LXtgug0h
>>809
やっぱり白黒2値のパターンが別途居るようですよね……。
PNG使ってるのに、わざわざマスク画像が必要なのがめんどくさいと敬遠しているんですよ。
814:名前は開発中のものです。
09/03/11 00:49:09 SDHRypL0
あれGraphLockって関数がいつのまにか消えたのか、と思って検索したら出た
URLﾘﾝｸ(hpcgi2.nifty.com)
>GraphLock は現在のＰＣ環境に適していないので非公開関数にすることにしました
これってどういう意味なの？非対応な環境が多いの？詳しい人教えて
一応コピペ
宣言 int GraphLock( int GrHandle , int *PitchBuf , void **DataPointBuf ) ;
概略 グラフィックメモリ領域のロック
引数 GrHandle : ロックするグラフィックのハンドル(または画面の識別子)
PitchBuf : ロックするグラフィックの１ライン辺りのバイト数を保存する変数へのポインタ
DataPointBuf :グラフィックデータのあるメモリへのアドレスを保存するポインタへのポインタ
戻り値 ０：成功 －１：エラー発生
宣言 int GraphUnLock( int GrHandle ) ;
概略 グラフィックメモリ領域のロック解除
引数 GrHandle : ロックしたグラフィックのハンドル（または画面の識別子）
戻り値 ０：成功 －１：エラー発生
815:名前は開発中のものです。
09/03/11 12:48:22 4qWzS982
>>814
対応してないとかじゃなくて、単に古くて多用されない技術だからじゃないかと無責任に予想
816:名前は開発中のものです。
09/03/11 23:25:34 tpGaQ5tp
使えたら部分的なぼかしとか波紋とか屈折描画とかできて表現の幅ひろがりまくりんぐなのに・・・
817:名前は開発中のものです。
09/03/11 23:28:32 jT1zwAC2
シェーダサポートフラグですね。わかります。
818:名前は開発中のものです。
09/03/12 00:06:32 5lgaab4l
>>816
いいなぁそういうの使ってみたい。
819:名前は開発中のものです。
09/03/12 14:35:44 hH9qj7K7
歪みはテクスチャに背景を描画→２Ｄポリゴンで挑戦中
820:名前は開発中のものです。
09/03/12 23:20:03 TV/Jr7F7
>>814からの流れに関連してるかわからないけど、
ちょっと前に気になった事があるので質問させてください
LoadGraph系統以外で作成したグラフィックハンドルから
グラフィックデータのメモリを参照し、編集する事ってできないんしょうか？
SoftImage系の関数で同じような事はできるみたいだけど、
これは画像ファイルから取得したもののみですよね。。
821:名前は開発中のものです。
09/03/13 00:27:53 CMJVUsQ6
>>820
MakeXXXColorSoftImageじゃあかんの？
822:名前は開発中のものです。
09/03/13 00:43:55 GbqqCgmR
Easy3D正式版きてるな
823:名前は開発中のものです。
09/03/13 01:09:59 H+Qfngp2
>>820
ありがとう、今気付いたんだけど先に用途を書くべきでした。
例えば>>816の波紋を実現しようと考えた時、
「このエフェクトをかける前までに描画された画面から
エフェクトをかけたい矩形のグラフィックを取得して、
これを元にピクセルを書き換える」
という処理を考えてみたんですが、GetPixelは重いようなので、
なら直接メモリを参照できないかと思った次第です。
MakeXXXColorSoftImageで作成するのはソフトグラフィックハンドルなので、
ここを描画先にしたりはできませんよね。。？
824:名前は開発中のものです。
09/03/13 01:19:10 H+Qfngp2
>>823
訂正：ソフトグラフィックハンドル->ソフトイメージハンドル
あと「描画先」と書いたのは、「DrawGraph等で描画できる描画先」という意味です。
直接グラフィックハンドルをソフトイメージハンドルに変換できる方法があればよいのですが。
そもそもこの考え方自体がアホなんでしょうか。。。
825:名前は開発中のものです。
09/03/13 03:43:56 CMJVUsQ6
>>824
画面全体にエフェクトを掛けたりするのに有ると便利だが、ちょっと調べてみたが出来ないっぽいね。
そもそもLoadGraphやMakeGraphはVRAMに転送した時点でPC環境に依った画像フォーマットに変換されちゃうから、
そこからソフトイメージハンドルを生成するとなると、コンバーター(デコーダ相当）が必要になる。
DXライブラリの作者としては手間が掛かるから、要望が無い限り実装を見送っていると予想している。
優しい作者さんなんで、要望送ってみてはどうかな？
現状で対応するとなると、どうしても遅くなるが、
画面サイズと同じ大きさにMakeGraphした裏画面領域をSetDrawScreenして、
一連の画像を転送し、GetPixcelとDrawPixcelするのがベストな選択かねぇ。
SaveDrawScreenを使ってbmp保存して、そこからSoftImageを作るという最終手段もある。(とても遅い)
826:名前は開発中のものです。
09/03/13 03:50:25 CMJVUsQ6
>>823
ああ。書いてておもったが、SaveDrawScreenがあるから、デコーダ処理は既に内部には出来てるのか。
作者に要望だすと、すぐに実装してくれると思うよ。
827:名前は開発中のものです。
09/03/13 04:00:17 HX55tf54
解説 グラフィックデータのあるメモリ領域には『ロック』をしなくては アクセスする事が出来ません。
細かい事は抜きにしてとにかくWindows 環境ではメモリの管理が厳重なので malloc関数 などで確保したメモリ 領域のように簡単にはアクセスは出来ないようになっています。だから 『ロック』という作業を行い直接アクセスできるようにします。
グフィック領域に直接アクセスする利点はDrawPixel や GetPixel 関数を使用するよりも処理が速い、等があります。
ロックの説明をはじめる前に注意なのですが、ロックを行った場合は 直接アクセスが終り次第直ちにロックを解除してください。
ロックを している最中にデバッグモードなどのブレークポイントを使ってプロ グラムを止めるとハングアップするので注意してください。
ロックを すると 『GraphUnLock』関数を使用してロックを解除しない限り DrawLineをはじめすべての描画関数が使用不可能になるので注意してください。
では話を元に戻します。
ロックをするにはまずロックをしたいグラフィックハンドル、または DX_SCREEN_FRONT , DX_SCREEN_BACK 識別子を使って画面をロックする 事も出来ます。
ロックが完了すると関数は PitchBuf に指定したポインタにロック したグラフィック領域の１ライン辺りのバイト数と、DataPointBuf で 指定したポインタにロックしたグラフィックへのアドレスが代入されます。
こうしてロックしたグラフィック領域にはめでたく直接アクセスが 出来るようになります。まず希望の座標（点）にアクセスするには 以下の式を用います
(グラフィック領域の先頭アドレス) ＋
(Ｘ座標値 × (グラフィックのカラービット数 ÷ ８)) ＋
(Ｙ座標値 × １ライン辺りのバイト数)
＝ 希望の座標のポインタ
828:名前は開発中のものです。
09/03/13 04:02:17 HX55tf54
この中の『グラフィック領域の先頭アドレス』と言うのは DataPointBuf から取得できる値、『１ライン辺りのバイト数』は PitchBuf から取得できる値
『グラフィックのカラービット数は』SetGraphMode関数 の 引数 ColorBitNum の値（デフォルトでは１６です）となります。
次に１ドット辺りのビット数はカラービット数と比例します、以下に カラービット数と一般のデータ型との比例関係を示します。
８bitカラー char 型と同サイズ
１６bitカラー short 型と同サイズ
３２bitカラー int 型と同サイズ
もし１６ビットカラーのグラフィックに１ドット分データのアクセスを するつもりで int 型変数で値を代入した場合は２ドット分描画してしまう ので注意してください。（アドレスの算出のときも同じです）
注 … グラフィックをロックする場合は SetUse3DFlag 関数で３Ｄ機能を使わない設定にしてからLoadGraph,MakeGraph等で作られたグラフィックでないとロックは失敗します。
例 １２８×１２８のグラフィックデータを作成し、座標( 24 , 11 )
の点に色コード０を代入します。（１６ビットカラー）
char *GraphData ;
short *DrawPoint ;
int Pitch , GHandle ;
// グラフィックの作成
GHandle = MakeGraph( 128 , 128 ) ;
// グラフィックのロック
GraphLock( GHandle , &Pitch , &GraphData ) ;
// 座標( 24 , 11 )のデータのアドレスを算出
DrawPoint = ( short * )( GraphData +
24 * ( 16 / 8 ) +
11 * Pitch ) ;
// 色コード０を代入します
*DrawPoint = 0 ;
// ロックを解除します
GraphUnLock( GHandle ) ;
829:名前は開発中のものです。
09/03/13 04:05:06 HX55tf54
サンプル 表画面をロックして直接アクセスで画面にグラデーションを描きます
#include "DxLib.h"
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ){
int i , j , k ;
int Pitch ;
short *DrawPoint , Cr ;
char *GraphData ;
if( DxLib_Init() == -1 ){return -1;}
// 表画面をロックします
GraphLock( DX_SCREEN_FRONT , &Pitch , ( void ** )&GraphData ) ;
// 画面にグラデーションを描きます
for( i = 0 ; i < 480 ; i ++ )
{
for( j = 0 ; j < 640 ; j ++ )
{
// 色の値を取得
k = 255 * i / 480 ;
Cr = ( short )GetColor( k , k , k ) ;
// 描画する座標のポインタを計算
DrawPoint = ( short * )( GraphData + j * ( 16 / 8 ) + i * Pitch ) ;
// グラフィックデータへの直接アクセスで点を描画
*DrawPoint = Cr ;
}
}
// 表画面のロックを解除(『GraphUnLock』使用)
GraphUnLock( DX_SCREEN_FRONT ) ;
// キーの入力待ち
WaitKey() ;
DxLib_End() ; // ＤＸライブラリ使用の終了処理
return 0 ; // ソフトの終了
}
830:名前は開発中のものです。
09/03/13 04:17:46 CMJVUsQ6
>>827
ありがとう。
GraphLock/Unlockなかなか便利だねぇ
ちょっと使ってみます
作者から非公開関数になった理由が知りたいとこだね
831:名前は開発中のものです。
09/03/13 10:15:03 H+Qfngp2
>>825-829
なるほど、そのためのGraphLock/UnLockだったのか。
あと非公開関数になっただけで使う事はできるんですね。
てっきり使用すらできなくなったものだとばかり思ってました。。。
とりあえずはこれで出来そうなので、デコード処理の要望の方は見送ろうかと思います。
お二方とも、ありがとうございました。