プログラマ専用SNS ミクプラ

ISLe

プレイヤーの座標を元に、どこから弾が出るかを弾クラスが処理するのは、設計としてマズいのでは。

弾はプレイヤーに従属するものですから、へにっくすさんのおっしゃるように、プレイヤーが、弾(あるいは弾を発射する位置の基準となる座標)を返すメソッドを持つべきと思います。

ISLe

>ところで、この方法は、水門さんが最初に、目的に合わないと否定された方法でもあるのですが、問題ないのでしょうか。なんの話ですか？最初の質問文で、水問さんは以下のように書いています。小一時間googleを使って調べてみたのですが、合いませんでした・blackBoardを使う（xmlのみで記述するやつ） →多機種に対応したいため画面サイズに依存する方法は無理（巨大な画像を使えばいいじゃないというのは変）・表示している画像それぞれにalpha値を適用する（android.view.animation.Animationとその仲間） http://cleanings.jp/develop/...

ISLe

webページから無断でコピペしてくるのが無断転載で、 webページ上にその手の記述があってコピペしてくるのが引用でしょうか？明記してあるサイトは少なさそうで、骨が折れますね・・・引用には引用と認められるための要件があります。要件を満たせば許可は必要ありません。『引用』で検索すれば著作権とともに解説されたページがたくさん見付かるはずです。現状の下記のコードでは、透明になったりこそするものの、２秒間ﾌﾞﾜﾌﾞﾜ画面を往復しているように点滅します android:fromAlpha要素とandroid:toAlpha要素に設定する値はfloatです。水門さんが製作時に参考にしたという...

ISLe

なるほど、では回答者の方々に回答をしていただくには質問者としてどのような扶助を行えばよいでしょうか？他の方々の質問トピックに私の知識で回答した後、質問をしてくださいということでしょうか？私がこの場で扶助できる事は何でしょうか？先の投稿において同じ文体で繰り返し書いたのですが伝わりませんでしたでしょうか。水問さんが試しに書いたプログラム一式を提示してください、ということです。試したあとに質問したのであれば手元にあるコードをコピペするだけで済むことではないでしょうか。確かサンプルコードにも著作権があると聞いたことがあります。今後他所サイト様からの引用は控えたいと思います。引用は著...

ISLe

MakeScreenで作成したアルファチャンネル付きグラフィックに対して、SetDrawBlendMode関数のDX_BLENDMODE_ALPHAを使って半透明で描画すると、アルファ値だけでなく、RGB各要素も指定した割合で合成されます。そのため、半透明を含むMakeScreenで作成したアルファチャンネル付きグラフィックを他の画面に描画する際には、乗算済みアルファとして扱う必要があります。あとから透明にしたい部分にSetDrawBlendMode関数のDX_BLENDMODE_ALPHAを使って100%透明で描いてもアルファ値は変化しません。 RGBも変化しないので何も変わりません。 ...

ISLe

聞くついでで申し訳ないんですが、ImageButtonなども自動的に比率が変わるのでしょうか？解像度に依存しない単位でコンポーネントのサイズ指定を行えば自動的にサイズが変わるはずです。 Android SDKで画面サイズの異なる仮想デバイスを作成して試してみれば分かることではないでしょうか。当初は画面サイズにあったcanvasを生成して、黒一色にしようかと思ったのですが、googleで調べていた所負荷が重いというワードがやけにあったので避けていました例えばViewの一部だけを処理したい場合、その部分を半透明で塗りつぶすだけで済むはずです。その程度で負荷が問題になるのかどうかは試して...

ISLe

SetTransColorは、それ以降に作成されるグラフィックハンドルに対して有効です。
そもそも、アルファチャンネルを持つ画像は透過色を無視します。

MakeScreenで作成したアルファチャンネル付きグラフィックに対して、アルファチャンネルのみを対象とした操作はできないようですが、透明にしたい部分に対してSetDrawBlendMode関数のDX_BLENDMODE_SUBを指定しておいて描画することでアルファ値を削ることができます。

ISLe

・blackBoardを使う（xmlのみで記述するやつ） →多機種に対応したいため画面サイズに依存する方法は無理（巨大な画像を使えばいいじゃないというのは変）画面サイズに依存するプログラムは作成できるのですね。変更点を指摘して差し上げますのでそれを提示してください。ちなみに、背景に指定できるのは画像ファイルに限りません。画像を使う場合でも、実際の画面のサイズに合わせて自動的に比率が変わります。・表示している画像それぞれにalpha値を適用する（android.view.animation.Animationとその仲間） http://cleanings.jp/develop/280...

ISLe

また、Handlerを使いたいというのはPageView内のスレッドでページめくり処理が終わった時にリスナーを介してActivityからTextViewの表示を変更するためです。なのでHandlerを使わないもっと良い方法があるなら教えて頂きたいです。既にわたしは、以下のとおり書いております。そもそも、ページめくりをできるようにしたいViewにRunnableインターフェースを実装すれば良いと思うのですが Handlerを使わなくてもリスナーを介してActivityにアクセスすることは可能です。とりあえずスレッドの学習として、タッチと関係なく、自動でスクロールして次のページに移って...

ISLe

複数のインスタンスで共有されるしインスタンスの寿命も越えて共有される、ということを理解し想定しているのかどうかが問題だということですね。

ISLe

『ACK NAK』をキーワードに検索すると良いかもしれません。

ISLe

既存の規格で作られた通信機器と送受信するのが最終目的なのでしょうか。

そうでなければ受信側は適当に決めた応答コードを返すだけで良いのでは。
安易なコールバックというのが既にそういうものかもしれませんが。

送信側は受信可能サイズでまとめて送れば良いのでは。
サイズ固定だと困るならネゴシエーションすれば良いですし。

ISLe

non さんが書きました:もちろん、ArduinoはTXとRXだけで、フロー制御もできません。

ソフトウェアフロー制御も実装できないということですか？

ISLe

onTouchメソッドで、MotionEvent.ACTION_UPでもまだスクロールさせる必要があるときにHandlerを使ってスレッドを起動しよう、ということですかね。

Handlerを使うサンプルはRunnableインターフェースを匿名で実装するクラスばかりですけど、PageViewクラスの入れ子ならPageView.thisでPageViewのインスタンスを参照できます。
個人的にオススメはしませんけど。

スクロールが完了する前に再びタッチされたらどうするのかとか、起動済みのスレッドとの連携で面倒なことになりそうなので、自動スクロールのスレッドは一本化しておいたほうが良い気がします。

ISLe

Threadクラスは、Runnableインターフェースを実装した任意のクラスに対して使えます。
並行して実行されるrunメソッドであっても、メンバ等にアクセスする方法は通常のメソッドと同じです。

他のViewを参照したければ、そのViewを参照できるようにしなければいけません。

そもそも、ページめくりをできるようにしたいViewにRunnableインターフェースを実装すれば良いと思うのですが、どうして他のViewを操作する必要があるのでしょうか。

ISLe

皆さんはどのようにして自分でプログラムを考えることができるようになりましたか？わたしは、自分のやりたいことを分解して知っていることに置き換えているだけです。そういう点からすれば、いまでも自分で考えているとは、まったく思えません。自分では何も考え出せないので、常に勉強です。掲示板を巡って自分では機会を得ない問題や解法に触れるのも勉強だと思っています。わたしもプログラミングを始めたのは小学生の頃で、やりたいことがそこそこできるようになるのに数年掛かりました。そこそこできたといってもいまみたらそうとうにショボイものです。できるようになったというより、やりたいことと知っていることのバラ...

ISLe

motion_e変数が参照するMotionEventオブジェクトは、遅延指定した処理が実行されるころには、既に新しいタッチイベントで上書きされています。

遅延実行する処理に必要な情報は、コンストラクタを明示して引数で渡せば良いと思います。

onTouchEventの引数が参照しているMotionEventオブジェクトが使い回される可能性はゼロではない気がするので、複製したほうが良いかもしれません。
ただ整数型でx,y座標を渡すだけで良いですけども。

ISLe

Zソートが必要な描画オブジェクトを抽象化、Zソート対象リストを用意する。
マップを描画する際に、建物だったらその場で描画せずにZソート対象リストに登録。
プレイヤーもZソート対象リストに登録。
Zソート対象リストに登録された描画オブジェクトをソートして順に描画。

というふうに、わたしなら、します。

ISLe

ひよつこさんが書きました:とりあえずThreadをstartしてみたのですが
他のViewの処理をしようとしたところエラーで落ちました。

なぜ落ちたのでしょうか。

申し訳ありませんが、わたしはなぜとだけ問われて答えられるような能力を持ち合わせておりません。

ひよつこさんが書きました:また、Threadを途中でとめておくにはどうしたらいいでしょうか。

スレッドはwaitメソッドで停止します。
再開するにはnotifyメソッドやnotifyAllメソッドを使います。

ISLe

100ms周期程度ならWin32 APIのほうが良いのではないでしょうか。描画命令も豊富にあって線種に凝ったりもできますし、同じコードを使って印刷も可能です。おおむかしにWin32 APIでゲーム作った経験から秒間60コマでも十分対応できるはず。 DXライブラリだと、VSYNCより速くても遅くても不都合が出ると思います。センサのサンプリングを並行して処理するならなおさら。ちなみにアニメは劇場用で滑らかに動いているときでも秒間24コマ、日本のテレビアニメだと秒間8コマも多くあります。ゲームでフレームレートが高い必要があるのは、ユーザーの操作に対する反応速度の問題です。アニメーションが...

ISLe

すみません。演算子の優先順位の問題で^演算を括弧で囲わないと正しく動きませんでした。参考にしたというトピックのコードが間違ってました。 #あとで修正しておきます。 #…トピックが閉鎖されてて修正できなかった。検証したコードはこちら。 #include "DxLib.h" static int prevMouse; enum buttonState { OFF_ON, ON_OFF, OTHER }; static buttonState status = OTHER; static void Keys_nextFrame() { int mouse = GetMouseInput(); ...

ISLe

やっぱり2回以上呼び出されているとしか思えないですけどね。

kgtekito さんが書きました:nextFrame()の呼び出しはupdateKey()でしか確認できませんでした・・後者についても１回の呼び出しのみでした。

こちらの意図していることを理解していただけているでしょうか。
ほんとうに1箇所ではなくて1回ですか？

そもそも、コンポーネント指向にしたほうがもっと使い回しやすく、こんなめんどうな話にもならないのではないかという気がします。

ISLe

Javaのマルチスレッドは他の言語処理系と比較して容易で、多方面で利用されており、情報も豊富です。
この機会に習得されることをお勧めします。

ひよつこさんが書きました:そうすると画面から指を離す度にThreadを開始し
処理が終わる度にThreadを停止しなくてはなりません。

そんなことはありません。
ビューの生成と同時にスレッドを起動して、必要のないときは待機状態にしておくのが良いと思います。

ひよつこさんが書きました:しかしイマイチThreadを開始したり終了させたりする方法がわかりません。

Threadクラスをごくふつうに使えば、勝手に起動して勝手に終了します。

ISLe

まさかとは思いますが、nextFrame関数をupdateKey関数以外でも呼び出しているということはないですよね。

updateKey関数を１フレームに2回以上呼び出している可能性もありますけど、それだとキーでも不具合が出ますし。

ISLe

VC++で作ったDLLのヒープがC#のガベージコレクションの対象になるかどうかということなら「なりません」という答えになりますかね。ですが、アプリケーション全体でガベージコレクションの影響が少なくなるかどうかは分からないのではないかと。例えばいまはJavaで作られるゲームソフトが多くありますが、ガベージコレクションを発生させないように工夫されているものは多いと思います。そもそも制御系のソフトはもともとメモリの確保・解放を繰り返さないように作られることが多いのではないでしょうか。むしろデバッガ等でメモリの使用状況を把握しやすくなって開発効率が上がる可能性だってあります。「経験的に～」と...

ISLe

ログに
177:フルスクリーンモード用のウインドウを作成します
と出ているのでそもそも実行ファイルが更新されていないのでは？

ISLe

2012用をそのまま2013でも使えるのではないかと思いますけど。

ビルドし直すには、アーカイブを展開した先のsrcフォルダ以下にあるslnファイルを開いてビルド(リビルド)するだけかと。

開けない場合は、slnファイルを選択してコンテキストメニューから、『プログラムから開く(H)』→『Microsoft Visual Studio Express 2013 for Windows Desktop』を選択してください。

既にソースコードを書き換えて対応しているので、今後の開発環境のバージョンアップにビルドし直すだけで対応できるかどうかは疑問ですが。

ISLe

真っ黒な影は重ねても真っ黒なので単純に描画できます。

半透明の影を単純に重ねると濃くなってしまうので、シーン全体の影になる部分を一様に求めておいて合成します。

ここで細かい手法を説明するのは難しいので、とりあえず“シャドウマッピング”をキーワードに検索してみてください。

ISLe

ウィンドウメッセージを調べてみると『デスクトップを表示』のときは、ウィンドウが遥か彼方の座標に移動してますね。

POPUPスタイルのウィンドウだと最大化したときにタスクバーも隠れるようです。

ISLe

定期的にチェックしなくても、最小化されるのはWM_SIZEで分かりますけどね。

最大化についてはどういうふうに最大化しているのか分からないことには何とも。

ISLe

DXライブラリを使っているのでしたね。
『デスクトップを表示』で消えるのはしかたないと、あきらめるしかないのでは。

SetUserWindowという関数で、自前のウィンドウとウィンドウプロシージャを使うことができるようですが、ウィンドウズの内部動作とDXライブラリの内部動作がどのように影響し合うか予測できませんね。
DXライブラリの想定外の用途でしょうし。

ISLe

>渡すパラメータは正しいか関数に渡す定数のことですよね。いいえ、違います。デバイスを操作する関数に渡すパラメータです。 DXライブラリを使用しているならデバイスを直接操作する場面は少ないでしょうがまったくないわけではありません。あまりに多く、中々発見しにくいのですが、 VC++にこの検出を自動で行わせることはできないのでしょうか。ヒープのバッファオーバーランを動的に検出するツールは、企業向け製品としていくつか存在します。低価格なものでも数十万円からですが。フリーの検出ツールもありますが、本件のような症状に対しては役に立たないと思います。症状が出ないようにコードの書き方をアドバ...

ISLe

ちなみに、WM_SYSCOMMAND→SC_MINIMIZEを阻止すると、ウィンドウメニューの『最小化(N)』を選択したり最小化ボタンを押したりしても最小化しないというユーザーから見たら不思議な状態になります。

だんごさんさんが書きました:誰かのブログ？になるのですがリンク貼ります。こちらです。
他の方法も調べてみましたが、結果上記の方法しか載っていないことがほとんどでしたので質問させていただきました。

やはり『デスクトップを表示』で消えないとはどこにも書かれていないようですが。

再背面に配置することと最小化を阻止することは別の問題だと思うので、へにっくすさんの案はアプローチとしては間違っていないと思います。

ISLe

テカリを出すために必要なレンダリングステートの操作があるようです。
スペキュラライティング (Direct3D 9)
テカリ具合はスペキュラのパラメータを調整することになります。

ISLe

ブルースクリーンを発生させるとなると、ビデオドライバ関連を疑いますね。
プログラムではデバイス操作の周辺で曖昧な点がないかチェックしてみてください。

渡すパラメータは正しいか
エラーも含めて戻り値は調べているか
デバイスの状態変化を考慮しているか
といったところでしょうか。

ISLe

分かりやすいかどうか分かりませんが、提案した3つの方法を図にしてみました。 sample.png 左上のが完成図です。各行、右にいくほど優先順位が高くなります。 1行目は、背景の上にZソートしたキャラクタを順番に描画する方法です。もっとも応用が効きますが手間もかかります。 2行目は、高さで分けたタイルマップを重ねる方法です。通路が立体的に交差するマップでよく使われます。例えば、この上に人物を描画して、柱の上に立っているように見せることもできます。 3行目は、キャラクタに重なる部分だけを隠すことでその都度前後関係を作り出す方法です。容量等ハードウェアの制約が厳しい、プログラムを大きく変...

ISLe

そもそもプログラムマネージャの子ウィンドウにすると『デスクトップを表示』で最小化されないのでしょうか。
再背面にすることと最小化されないこととは関係がないのでは。

ISLe

WM_SYSCOMMANDは、ユーザー操作やシステムからの事前通知的なメッセージです。
へにっくすさんのリンクされた先にもちゃんとそのように書いてありますね。

ウィンドウメッセージを監視すれば分かりますが、『デスクトップを表示』では通知されません。

ウィンドウ操作系のメッセージを片っ端から無視すれば可能かもしれません(確認はしてません)が、『デスクトップを表示』によって発生したものかどうかを区別する術がないので操作不能になりますね。

ISLe

やりたいことというのは、ページめくりではなくて、指を離したあとも自動でスクロールするようにしたいということですかね。
だとしたらフリックでページめくりの処理というのは余計じゃないですかね。

タッチイベント外でスクロールさせたいのであれば、スレッドやタイマーを使って少しずつ座標をずらしてViewを更新してやれば良いでしょう。
メモリリークに注意してください。

ISLe

おっしゃっていることがよく分かりませんが、Viewの表示座標を変更する方法は取れないということですか？

ISLe

kon さんが書きました:地面と、草むらや建物を分けて描画するということでしょうか？

分けて描画できるならそれが良いかと思います。

分ける場合と分けない場合とそれ以外、の3つの方法を提案したつもりですが。
それぞれ組み合わせて使うこともできます。

ISLe

三角関数を使う題材としては…
線を使って描いた戦車を、左右のキーで回転、上下のキーで前進後退、で動くものが良いと思います。
キャラクターは画像を回転させたものでもかまいません。
重要なのは回転とともに進行方向が変化するという点です。

おおむかしにアステロイドというシューティングゲームがありましたが、あれを真似て作ってみるというのも良いかもしれません。

ISLe

常に残りの距離を30フレームかけて移動するというふうに見えるのですが。
それだと理論的には永久に到達しないということなのでは。

「指定されたポイントに特定のフレーム数で移動する」のに三角関数は必要ないので、題材として不適切なのではないかと。

ISLe

一般的にはZソートと呼ばれる処理を行い、奥から手前に向かって描画します。 Zとは奥行きのことで、キャラクタに何らかの基準点を設け、奥行きを求め比較して並び替え(ソート)します。本件のような場合、基準はキャラクタの足元の座標を用います。キャラクタが宙に浮いている場合は、そこから垂直に下ろして地面と接する点になります。建物のようにある程度大きくて固定されたものの場合は、タイルマップのレイヤー(層)を分けて描画します。処理としてはタイルマップ全体をひとつのキャラクタとみなしたものです。レイヤーを持たないタイルマップにおいて特殊な方法もあります。キャラクタの足元と重なる部分のタイルと同デザ...

ISLe

amehirune さんが書きました:ところで、その↑のやつをOFFにする方法とは?
いったいどうすればいいのでしょうか?

DXライブラリの公式サイトに書かれているDXライブラリの使い方に記述があります。
こちらは2012を対象として書かれていますが2013でも同じです。
http://homepage2.nifty.com/natupaji/DxL ... press.html
『4.ＤＸライブラリを使用するためのプロジェクトの設定を行う』
の11番目に書かれています。

公式サイトには開発環境ごとにDXライブラリを使うために必要な手順を具体的に説明したページが用意されています。

ISLe

Log.txtの内容を見る限りではElecom Wireless Gamepadのドライバに問題があるのでは。

エレコムのサイトでワイヤレスゲームパッドのページを見ると、ドライバの更新情報に

Ver.1.1
特定の環境でDirectXアプリケーションが起動しない現象を改善しました。

という記述がありますが。

ISLe

いまどきのVisual C++はプロパティファイルを追加するだけでDXライブラリの設定ができるというメリットがありますけどね。 DXライブラリ専用のプロパティファイルを作っておけばDXライブラリを使う/使わないで簡単に設定を切り替えできます。 #ちなみにわたしが自分で使っているものをブログに公開しています。 2013は登録キーもありませんし。ちなみにSAFESEHというのは、コンピュータウィルスに感染するのを防ぐための仕組みです。とうぜん新しいほうがより安全です。端的に言って、無効にするとコンピュータウィルスに感染しやすくなるということなので、必要以上に無効にするべきではないと思います。...

ISLe

例えば、MS-Word。例えば、基幹システム。このようなプログラムについても同じことが言えるのではないでしょうか。特定の状況を再現させるために苦労することも同じです。例えばMS-Wordは1ページ目に入力した内容によって、同じ操作で2ページ目に入力した内容が変化するでしょうか。基幹システムでキーボードから入力するタイミングやマウスをクリックするタイミングで金額が増えたり減ったりするでしょうか。ゲームは同じ操作の繰り返しでもどんどん状況が変わります。そのような部分にテスト項目を用意することは事実上不可能です。他の方が既に書かれていることの繰り返しになりますが、特定の入力に対して特...

ISLe

ゲームプログラムはシンプルな機能の複雑な組み合わせが延々と繰り返され状況が変化することで動くものです。例えばイベント入れ忘れても、いきなりラスボス倒せるキャラを作れても、自動テストで誤りと判定することはできません。特定のマップで壁にハマらないかどうかなどを検出するためには天文学的な数のマップが必要で、自動生成するにしても自分が生きているうちにテストが終わるかどうか分かりません。というわけで、完成品(に近いもの)で実際にプレイしながらデバッグするというのがもっとも効率が良いということになるわけです。シンプルな機能の組み合わせで作れないひとを、そうなるよう仕向けるためにTDDを活用するとい...

ISLe

パーティションが複数ある場合でも、起動パーティションはそのうちのひとつだけです。起動パーティションにインストールされているブートマネージャが起動します。 OSをインストールした際にブートマネージャが認識しなくてもOSのインストールが失敗しているわけではありません。 OSをひとつインストールするごとにmenu.lstをバックアップし、最後に起動パーティションのmanu.lstに手作業でそれぞれの内容を統合するのが手順としてはシンプルかと思います。ただし、OSのカーネルアップグレードなどに伴いGRUBが更新され、再び他のOSが起動できなくなることがあると予想されます。それを防ぐために編み出さ...

ISLe

ViewFlipperは、View(あるいは派生したView)を入れ子に配置して使います。
ViewFlipperの中にSurfaceViewを配置すれば良いのではないでしょうか。

ピンチ操作でズーム処理するのにSurfaceViewの高速な描画が必要だというのは何か根拠があるのでしょうか。
例えばTweenアニメーションではSurfaceViewに限らず滑らかに動くわけですが。

ISLe

トンデモ記述が目について気になったので、ついコンテストページをあちこち見て回っていて見付けました。

『競技部品』はJava用のアーカイブですが、サーバープログラムも含まれていて、そのサーバープログラムはコマンドラインオプションでマップファイルを指定できるということを。

使い方もコンテストページにある資料の中に書いてあります。

こちらのサーバープログラムを使えばバッチファイルだけで希望の処理が可能かと。

ただしファイル名に2010とあるので、なでしこ版2012と何か違いがあるのか分かりません。

マップファイルの複数選択からをGUIで行う『アプリを作ること』が目的であるなら見当違いですが。

ISLe

nanashi さんが書きました:みけCATさんの下半身と上半身を分けて描画する案もいいと思いましたが
やはり座標で描画順に並び替えるのがよろしいですか。

ソートしないで下半身と上半身を分けて描画するだけでは胴体切断が発生しますよ。

Zバッファを使う場合でもZソートが必要な場面は多いので覚えておくべきかと思います。

ISLe

提供されてるテスト用(？)サーバープログラムが、有無を言わさずファイル選択ダイアログを開いてマップファイルを指定させる謎仕様なのがそもそもの問題でしょうね。
さらに通信内容はサーバープログラムとクライアントプログラムの起動タイミングを変えるだけでまともに動かなくなる謎仕様。

動作確認にUWSCを使いたい気持ちは十分理解できます。

ただ、前のトピックでは作成したクライアントプログラムの動作確認をしたいらしかったのが、このトピックではクライアントプログラムのビルドも含めて自動化したいというように変わっているように感じます。

ISLe

Androidの機能を使わない縛りでしょうか。
そうでなければViewFlipperとかTweenアニメーションをキーワードに調べてみてください。

ISLe

実物を見ないことにはどこに問題があるか分からないですね。

単純にモデルを限定し配置して描画するだけのシンプルなコードで再現できないのでしょうか。

ISLe

質問文には海も半透明テクスチャだと書いてありますね。
海全体がひとつのメッシュだとしたら優先順位が問題になりそうですが。

HUDに正方形の枠を表示するなら常に正方形であるほうが良いのではないでしょうか。
敵の位置が自機と同じ奥行きのときは直線になってしまう(あるいは表示されない)のでは。

ISLe

Zソートのコードが1パターンということは、Zバッファが有効な状態で半透明のものとそうでないものをまとめてソートしているということでしょうか。

Zバッファが有効な場合、半透明でないものを手前から奥に向かって描画すると効率が良いわけですが、半透明のものは奥から手前に向かって描画しないと奥が描画されないので透けません。
また、半透明でないものをすべて描画してから、半透明のものを描画する必要があります。

描画するもの全体が半透明のときはZバッファの書き込みだけ止めるという手もあります。

HUDの情報をワールド空間に配置しているというのはおかしな感じがしますが、そういうものなんでしょうかね。

ISLe

この問題が発生するのはIE10だけで、IE11では正しく表示されます。

ISLe

デジャヴ…

Matrixだけを保持すれば良い気がしてならないです。

ISLe

ptolemy さんが書きました:interSectRect関数は、以下のテキストを全て理解した方がいいですか？

ひとつも理解する必要ありません。
DXライブラリを使っているなら何の準備をせずともIntersectRect関数を利用できます。

ISLe

DXライブラリ前提なら、Windows APIのIntersectRect関数を使ってはいかがですか。
矩形同士の重なりを判定していると、ひと目で分かるようにコードを書くことは重要だと思います。

ISLe

jsファイルはcgi通してダウロードできませんでしたっけ。
cgiで何らかのチェックをすればある程度の対抗策になるかもしれません。

最初から晒すつもりでアタックしてくる輩には効果ないと思いますし、むしろ晒される原因を作る可能性のほうが高い気がしますけど。

ISLe

わたしは、インベーダーは(特に現代において)極めて高度な物だと思います。

ひとつの見方としてインベーダーだけに絞って分類するとしたら
#以下タイトーのスペースインベーダーを本物と表記

初級者：
サンプルプログラムをコピーして動かして満足する。
本物も同じプログラムで動いていると考える。

中級者:
本物はサンプルプログラムと違うと気付き、サンプルプログラムを改造する。
自分で考えてプログラミングできるようになる。

上級者:
本物を調査、理解し、資料を元にしてそっくりに動くプログラムを作ることができる。
要求される仕様に応じてプログラミングできるようになる。

という感じですかね。

ISLe

一時変数を使っていれば、コードは見やすくなるし、softyaさんの勘違いにもすぐ気が付いたと思うんですけどね。
コードが見やすければそもそもsoftyaさんが勘違いすることもなかったはず。

ISLe

ただ、＞私は，最初に示されたコードの状態で既に，画像と判定枠との関係が＞あなたが示した画像（の左側の絵）のようになっているのではないかと思っていました．この勘違いが今回の元凶ではないでしょうか。あなたは最初から画像の状態が出来ていると思った。だからあとから私が画像の状態ができた式を出したところで「だから？」となった。だったら私も今はあなたのその反応が理解出来ます。でも、勘違いされたのはusaoさんですよ。私はこのソースのおかしい部分を指摘してほしいと提示したのでこの部分の式はすでに正しいなどと確認無しで信用されても正直困ります。バカなんで。 usaoさんは勘違いなどして...

ISLe

ISLe さんが書きました:訂正したという式もサイズによっては誤差があるくらいで何も変わってませんしね。

わたしもこう書きましたがスルーされたようです。

ISLe

Shift_JISとUTF-8のバイト列を直接処理するものなら、わたしのブログでサンプルコードを公開しています。

ノベルゲーム風に一文字ずつ表示する:ISLeのビデオゲーム工房 ※Shift_JIS/DXライブラリ版/禁則および改行機能付き
ノベルゲーム風に一文字ずつ表示する【UTF-8/DXライブラリ版】:ISLeのビデオゲーム工房 ※禁則および改行機能付き
参照する際には、前後の記事も合わせて読んでください。

入力データとしてShift_JISを使うことはいまでも少なくはないと思いますけど。

ISLe

土門さんが書きました:これで、ISLeさんのご指摘通り、各クラスで当たり判定の矩形座標を出して
それ用の変数にでも入れといてコリジョン関数で利用すれば、
完全に問題無い状態ですよね？？

問題はあります。
先に書いたとおり根本的に間違ってます。

コードが読みにくいせいで、それが分かるまでにこれだけの時間を要してしまいました。

ISLe

usaoさんの指摘は、真横じゃなくて縦にズレてたらどうなの？ってことです。上端しか判定してなかったら、下半分に引っ掛かるブロックはすり抜けてしまいますよね。訂正したという式もサイズによっては誤差があるくらいで何も変わってませんしね。この式だと当たり判定を画像の中心にしか配置できないと書いたように、少なくともわたしは最初からgetbounds_*の意味は分かってましたよ。ブロックごとにピクセル単位で比較するのは、ブロック単位でループを回す場合の当たり判定処理(を行うサンプルコードによく見られるパターン)です。プレイヤーの位置からマップ座標を求める場合は、矩形が重なる範囲を求めて、その範...

ISLe

いちおう断っておくとわたしは中心座標で管理したほうが良いとは言っていません。どこでも良いです。どこでも良いのに関係のない要素に依存しているのが問題だというのがわたしの言い分です。つまり、自分のクラスで当たり判定のサイズなり、当たり判定の左上なり、出しておけってことでしょうか？要するにそういうことです。当たり判定するときは、当たり判定の矩形というかたちで表現すればコードは読みやすくなります。関係のない情報は隠されるので(土門さんにとって)余計なことに口出しされることもなくなるでしょう。わたしの投稿でスルーされた部分ですが、反対側のオフセットが求まることが分かりました。式を変形して...

ISLe

if (hoge -1) { /* hogeから1を引いて、それが0でなければ実行される (hogeが1のとき以外は実行される) */ }
if (hoge == -1) { /* hogeが-1に等しいとき実行される */ }
です。
どちらもビルドは通ります。

ISLe

getposX/getposY関数は、関数名からはそのように見えないが、画像の左上を指していなければならない。
画像の基準となる左上座標は存在するが、当たり判定の左上基準座標は存在せず画像の中心を基準にした配置である。

言ってることとやっていることに矛盾する部分があるし、各数値がそれぞれに依存しているので、一箇所いじればあちこちに影響するでしょう。
いちばんの問題は本人がそれに気付いていなかったり気付いても改める気がない(ように見える)ことだと思います。

ISLe

boxさんの書かれた判定方法は、何人でじゃんけんするか関係ありません。
じゃんけんの勝敗を判定する関数はひとつにまとめられます。

じゃんけんの勝敗ではなくて誰が勝ち残ったかを処理する部分の問題なのでは？

ISLe

cppの58行目の条件式は書き写し間違いですか？

ISLe

一般的な弾と弾、敵とプレイヤーだの、プレイヤーと障害物の矩形衝突判定は簡単です（どんな状況だろうととにかく当たったら、「当たった」と判断すればいいだけだから）ですが、当たった方向を考慮して、判定後の処理を書く場合は面倒なことになりますよね？しかも、ただの障害物として「進めない」処理をしたいだけなのです。シューティングゲームにおいて、これが面倒でした。面倒なことにはなりません。天の声が「ここまで下がれ」と指示するだけで、実際に下がるのはプレイヤーの仕事にすれば良いのです。プレイヤーの見た目と当たり判定の相違は、プレイヤーのオブジェクトだけが知っていれば良いしそれ以外が知っている必...

ISLe

こういうのはどうでしょう。

コード:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    div_t res;
    int sum, sec;
    for (sum = 0; scanf("%d", &sec) == 1; sum += sec);
    res = div(sum, 60);
    printf("%d\n%d", res.quot, res.rem);
    return 0;
}

ISLe

標準入力は、読み出した分だけが消費され、残った分は次の読み出し操作に繰り越されます。

ISLe

DXライブラリ関数のFileRead_*はアーカイブ機能に対応しているのだと思います。

ISLe

とりあえずSetUseZBufferFlagでTRUEを指定しないことにはZバッファが有効になりませんが大丈夫でしょうか。 SetDrawZは、それ以降に描画されるピクセルに対してZバッファに書き込まれる値を指定します。ですからSetDrawZ関数を呼び出す順番が異なれば結果も異なります。サンプルコードをよく見てください。 0.2fのとき描画したものは0.3fで描画するものより優先されます(DX_ZCMP_DEFAULTの場合)。だから既に(透明で)描いたところには描画されないというわけです。 Zバッファをいったんクリアしてしまうので3D描画と平行して行うことはできません。 2D描画...

ISLe

DXライブラリの描画関数をふつうに使えるのでZバッファを利用するほうが楽だと思いますが。 #include "DxLib.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { ChangeWindowMode(TRUE); if (DxLib_Init() != 0) return 0; SetDrawScreen(DX_SCREEN_BACK); int maskX = 0; // Zバッファを使う準備 SetUseZBufferFlag(TRU...

ISLe

楽器店で子ども向けのピアノ譜とか買ってひたすら打ち込むと良いかもです。

調べたら無料で楽譜をダウンロードできるサイトがあるらしいです。

ISLe

libbox2d.aに日本語とか使ったファイル名のファイルが含まれていませんか？
多言語対応のarコマンドを使う必要があるのではないかと。

ISLe

arコマンドにディレクトリパスを扱う機能はないはずですが。
というかなぜarコマンドの対象がsoファイル？

ISLe

一般的にはDXライブラリの分割ロードのほうが特殊で、画像の一部を描画する命令を利用します。
#DXライブラリも実際は画像を分割しているように見せているだけです。

参考:
Graphics.DrawImage メソッド (Image, Rectangle, Rectangle, GraphicsUnit)

ISLe

Linuxのリンカを呼び出すのはldコマンドですが、実体はディストリビューションに依存します。

ISLe

マスク画像を作るよりZバッファを利用するほうがメモリ消費量や速度において有利かもしれません。

参考:ゲーム中の半透明ウィンドウ表示について

ISLe

LOCALNET変数にローカルループバックアドレスを指定しているのが間違っているのでは。

ISLe

インテリセンスが強化されたVisual Studio 2013ならlltestさんのご希望に沿うと思います。

ISLe

みけCAT さんが書きました:本当は仕様書で確認するのがいいですが、1.4万円くらいするようなので、

JIS規格の閲覧だけなら無料ですよ。
JISC 日本工業標準調査会

ISLe

3Dモデルはモデルごとにローカル座標系を持っています。それをワールド座標系の空間に配置するのがモデル変換です。 2Dでは、セットした座標をそのまま描画命令に使いますしそのまま使い回します。そのため3Dで描画のたびに行うモデル変換に違和感を持つことがあるかもしれません。ワールド座標系に配置されたモデルをカメラのパラメータによって、いっせいに処理するのがカメラ変換です。 #パラメータが共通というだけで、実際の処理はいっせいにという表現では語弊がありますが。モデル変換で作ったステージをどこから見たふうにするかというものです。カメラ変換が対象にするのもワールド座標系です。モデル変換とカメラ...

ISLe

そもそもdicさんはカメラを動かす方法なんて質問してませんよね。
プレイヤー目線にすることもカメラを動かすことも手段としては知っていることが質問文に書いてありますし。

問題の本質はカメラとはまったく関係ないと思います。
ただしカメラの存在が誤解の元になっているので区別する必要があります。

ISLe

委譲というのは簡単に言うと他のオブジェクトに処理を丸投げすることです。
インターフェースというのは言語機能等のことではなく言葉どおりの働きのことです。

ISLe

翻訳単位での分割はそのとおりです。

Enemyクラスがインターフェースとして働くことになるのでそれに関する部分は自ずと共通化されることになります。

各キャラクタの固有部分が分離されて、オブジェクト別に状況に応じた柔軟な設計が可能になります。
全体的にはシンプルでないかもしれませんが再利用性の高いシンプルな実装の組み合わせで作れるメリットは大きいと思います。

ISLe

敵キャラの管理では、継承よりも委譲のほうが適していると思います。
1.です。

外部スクリプトでなくとも翻訳単位で分離できますし、大量に発生する敵キャラのオブジェクトプールを作る場合も共通化が図れてシンプルになると思います。

ISLe

<uses-permission android:name="android.permisson.VIBRATE"/>
は
<uses-permission android:name="android.permisson.VIBRATE" />
#/>の前に空白を入れる
でなければいけないと思います。

ISLe

dicさんの1つめの質問は、2つの問題に分けられると思います。第1の問題は、視線に対して右や左を向くというのがどういうことなのか分からないということ。第2の問題は、カメラの概念を理解していないということ。ゲームエンジンで簡単にカメラを配置できたとしても、プレイヤーを追いかけるなどの移動するキャラを追加しようとすれば変換行列に触れることになるため、すぐ同じ問題に行き当たります。 dicさんが最初に提示したコードは周りの景色を回転させていましたから、dicさんは画面に映る像を基準に考えていると想像します。 2Dでは特に扱われないモデル変換の概念が行き場を失っている状態で、単にカメラだけの問題...

ISLe

showメソッドでブロックしないので、seveメソッドはダイアログのボタンを押す前に書き出しに進んでしまいますね。

onClickの中からseveメソッドを呼び出す形にするのが良いのではないでしょうか。

ISLe

showメソッドを呼び出したあとに、editView変数からアクセスできるのでは？

ISLe

ジルコニアさんが書きました:まあ自分ならカメラの動き等は気にせずさっさと完成させますけど。

プログラムでカメラを動かさないとあさっての方向しか画面に映らなくてデバッグもまともにできないということにはならないのですね。
だったらゲームエンジンを使えばプログラムでカメラを動かさずともプレイヤー視点のゲームが作れるということですよね。

わたしがいちいち細かく説明する必要なんてありませんでしたね。
計算なんて知らなくても良いわけですからね。
失礼しました。

		4月 2024
日	月	火	水	木	金	土
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

検索結果 2636 件