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

ISLe

「解像度256×224の枠の中で16×16のキャラクタ」のような具体的な数値を挙げているので、ゲームを作ることと同時にファミコンの環境に対しての関心も高いのではないかと想像します。 LoadDivGraphが便利だとおっしゃっているので、まだ先の話、あるいは無用なことかもしれませんが、ラスタースクロールやパレットアニメーションを実装しようというレベルになれば、DXライブラリでも不便なものです。別に高度な技術を習得したいからでもなく、ゲームプログラマになりたいからでもなく、ただゲーム機が好きでゲーム機に興味があるだけ。楽しんでいつのまにか高度な技術を学べるならそれでいいんじゃないですかね。 ...

ISLe

時間が経つとフリーズする原因として一番に考えられるのはGDIリソースのリークでしょう。
GDIリソースの上限数はデスクトップ全体で固定なので不要になったハンドルの解放や破棄を忘れると枯渇し、ウィンドウズのシステムに影響します。

ISLe

恒久的なBitmapはDIBが良い。 DIBであればデスクトップの画面モードが変更されても作り直す必要がない。 (DDBだとデスクトップの状態が変化すると描画されなくなる可能性がある) CreateDIBSection関数を使ってDIBを作成しビットマップハンドルを得る。 BitBltは、転送先と転送元のDCが逆。 hDcSrc,hDcDstといった変数名を使って転送元と転送先を明確に区別すると間違いに気付きやすくなるはず。 CreateCompatibleDCは、描画の直前に呼び出し、そこで取得したDCはすぐに破棄する。デスクトップはいつ変化するか分からないので、ライフサイクルは短く。 B...

ISLe

コード見ただけですが、0.01f(Near)～1000.0f(Far)の有効桁数6桁がfloatの精度ギリギリなのは関係ないですかね。

ISLe

No.4のリンク先にあるサンプルコードの中の
eRender
を
eCapture
に変更すればマイク入力(既定の録音デバイス)のミュート状態を取得できました。

ISLe

マイクロソフトのサイトから直接ダウンロードしたほうが安全なのでは？

https://www.microsoft.com/en-us/search/ ... -downloads
日本サイト(ja-jp)からは検索しても(エンドユーザーランタイムしか)ヒットしませんが、本家(en-us)だと…。

DirectX 9 SDKを使うのであれば、中でも最新版のJune2010を使うのがよろしいかと思います。
No.1のリンク先のものはタイムスタンプが2002年なのでかなり古いですね。

ISLe

無償版とは言えわざわざ中途半端な機能制限をする合理的な理由が見付からないので調べてみました。

結果、ソリューションエクスプローラーでプロジェクト直下に表示されるファイルは同時にエクスポートされました。
『ソースファイル』等のサブフォルダ(フィルター)の下だとエクスポートされません。

過去にはC/C++のプロジェクトで『テンプレートのエクスポート』機能はサポートされていなかったらしいです。
VB.NETやC#のプロジェクトテンプレートはフィルターを作らない(作れない？)ので、その名残でしょうかね。

ISLe

1. プロジェクトテンプレートのzipファイルに、ソースファイルを追加 2. プロジェクトテンプレートのzipファイルに含まれるMyTemplate.vstemplateに <ProjectItem>ソースファイルの名前</ProjectItem> を追記(1ファイルにつき1つずつ) 上記手順で希望のことができました。 VS2017Communityでも同様にソースファイルが含まれませんでした。プロジェクトごとファイルをコピーするとプロジェクトファイル(.vcxproj)に記録されている識別ID(GUID)が複数のプロジェクトで同一となるため、コマンドラインからコンパイルするという使い方だけ...

ISLe

1920x1080を前提に作っていても、それを任意のサイズで表示することはほとんど手間をかけることなくできるのに、その手間を惜しむというのは選ばれたひとにしかプレイして欲しくないという意思表示になってしまうと思いますけどね。 1920x1080固定だと4Kディスプレイでは小さい画面でプレイするのを強制することになりますよ。ファミコン時代の256x240とかのゲームがPCに移植されるのを豆粒のような画面でプレイしたくはないですよね。 1920x1080を800x600で表示したいのなら、SetGraphMode(1920,1080)のままで、SetWindowSizeExtendRate(0....

ISLe

どちらにしてもデフォルトコントラスタは作らなければならないようですね・・・デフォルトコンストラクタは作らなくてもできます。既存オブジェクトを上書きするのではなく、更地に構築します。 #include <iostream> #include <random> #include <new> using namespace std; class A { private: int a; public: A(int num) : a(num) { } void show_a() { cout << a << endl; } }; int main() { int test_num = 5; cha...

ISLe

CreateToolBarExはビットマップの背景色の処理をやってくれるので利用しましょう。 1番目のパラメータはビットマップ内のボタンイメージのインデックス自前部分は0から振る TBBUTTON tbb[] = { { STD_CUT, ID_CUT, TBSTATE_ENABLED, BTNS_BUTTON, 0, 0 }, { STD_COPY, ID_COPY, TBSTATE_ENABLED, BTNS_BUTTON, 0, 0 }, { STD_PASTE, ID_PASTE, TBSTATE_ENABLED, BTNS_BUTTON, 0, 0 }, { 0, ID_CREAT...

ISLe

2つ目のコードの32行目で代入すべきは、ビットマップハンドルじゃなくて、ビットマップのリソースIDなのでは？

ISLe

解決しちゃってたけどせっかくだから投稿します。 #include <vector> #include <list> #include <algorithm> #include <iostream> // for DEBUG int main() { std::vector<std::list<int>> foo = { {1},{2,3,4,5},{6,7,8},{9,10} }; for (auto &l : foo) { l.erase(remove_if(begin(l), end(l), [](int i)->bool { return i == 4; }), end(l)); } ...

ISLe

アセンブラの話で盛り上がっているのでこちらはオフトピで。質問の後半に「ポインタのところで、違和感を感じています」とあるので、変数名が即値にバインドされるという勘違いから生じている疑問ではないのかなあ。ポインタが分からないという理由によくある話だと思う。 int a = 123; という変数の宣言の中身としては、 1. int型の値を格納できる大きさの記憶域が確保される。この記憶域は生存期間中一定のアドレスを持つ。 2. 1.で確保された記憶域をaという名前で(アドレスを使うでなく)アクセスできる 3. 1.で確保した記憶域は初期段階で123という値を持つというふうだけれど、特に初心者向...

ISLe

オフトピック

C++11で追加された乱数ライブラリを使うと、DXライブラリのGetRandと同様のメルセンヌツイスタによる疑似乱数生成を選択できますし、また、複数のインスタンスを生成できるので、うっかりGetRand使ったらリプレイ全滅、といった事故を防ぐこともできます。

コード:

# include <iostream>
# include <random>

int main()
{
	std::random_device rd;
	std::mt19937 mt(rd());
	for(int i=0; i<10; ++i) {
		std::cout << mt() << std::endl;
	}
}

ISLe

2バイトのやつはリトルエンディアンですよ。（output_d.htmlを読めばわかりますが…。） keito94さんの提示したコードでビッグエンディアンとして処理しているのをそのまま書き換えたのですよ。反省したと言いながらあいかわらずトピを読み返さないので自分の書いたコードに原因があることに気付かないのでしょうかね。あるいは、わたしを貶めようと目論んでいるのでしょうか。必要最低限の書き換えで済ましているのは、このような状況でもある意味keito94さんを信用してのことですが、そのような悪意を突き付けられるとは。自分を棚に上げて他人に間違いを直させる姿勢にさらに磨きがかかってますね。

ISLe

ファイルの先頭から10バイトは順番に読み込むだけだし structモジュールとかいうのを使うと複数バイトデータの変換が楽にできるらしい。こんな感じ？(未検証) from struct import * class Map: # マップを開いてヘッダ情報を読み込む。引数:filename（ファイルのパス。） def __init__(self,filename): self.fn = open(filename, 'rb') # マップの幅を獲得。 self.MAP_W = unpack('>h', self.fn.read(2))...

ISLe

keito94さんは回答者を、問題解決する方法を教えてくれる先生じゃなくて、作りたいものを一緒に作る仲間みたいに見てるいいえ、そう考えてないですよ！！回答者は、解決方法を教えてくれてると思います！！例えばの話ですが、回答者の中にバンダイナムコから公式にリリースされているパックマンの開発に関係したひととかがいて、そういうひとに向かって「あなたの考え方のコードください」とか「あなたがマップチップ自作してください」とか平然と言うのは、とてつもなくあつかましいことだと思うんですよ。回答者を下に見てる意識があってもなくても、あつかましいことには違いはないですけどね。どうやって、32x32のキ...

ISLe

オフトピック

keito94 さんが書きました:回答者さんはちゃんと知識などがある方だと思ってますよ…。
下手の横好きだなんてとんでもない。

そういうことでなくて…
keito94さんは回答者を、問題解決する方法を教えてくれる先生じゃなくて、作りたいものを一緒に作る仲間みたいに見てるんじゃないだろうかってことなんですけどね。

あと、下手の横好きってのは知識や技術のありなしでなくて、本物かどうかってことですよ。

ISLe

クローンの意味分かってます？
パックマンを目指していると言ったり目指していないと言ったりあげくにクローン。
支離滅裂。

クローン作るのを手伝って欲しいならオリジナルがどうなっているか観察して分かることをすべて具体的に発表してください。
いまのところそれはkeito94さんでなくわたしがやっている。
keito94さんが自分からは何もしないから支離滅裂なのですよ。

オフトピック

keito94さんは回答者をどんなふうに見ているのだろうか。
自分と同じ下手の横好き(!)が集まっているとでも思っているのだろうか。

ISLe

keito94 さんが書きました:でも、画像を何個作ればいいのかわからないので、マップチップのサンプルを自作でください。

何でそんなに上から目線なんですか。
あなたの指示で動く義務はないのでお断りします。

ネットで検索すればパックマンのスクリーンショットくらい簡単に見付かるでしょうに。

他所で、パックマン風はパックマンとは異なる、というのを肯定されてますよね。

本家パックマンと異なる本家パックマンみたいなもの、というのは難解で理解が追い付きません。

本家パックマンのことなら分かるんですけどね。

ISLe

keito94 さんが書きました:本家パックマンに近い当たり判定への鍵もあったら教えてください。

これまでの投稿に書いたことでは足りませんか？

ちゃんと読めば、パックマンには、いわゆる壁との当たり判定も、このトピの主題であるワープ判定も、もともと必要ないことが分かると思うんですが。

ISLe

コンテナを使った当たり判定は削除されていますね。
#コンテナ自体は残ってるけど。

どうしてブロックをすり抜けてしまうのか、については基本すぎるので、ちゃんとデバッグしてください、としか言えません。

ISLe

でも、なかなか大変ですね…。それは、最初にどうするか・どうしたいか決めずに、目に付いたコードを適当に切り貼りしているからですよ。きちんと最初に決めたことに必要な部分だけを参考にしたり、最初に決めたことに必要な改変をしたり、中身を理解して軸がブレないようにやればもっと楽にできるはずです。混ぜたらダメなコードを混ぜて使って絶対にうまくいくわけがない。あと、ブロックの当たり判定部分について、keito94さんは過去のトピでソースファイルをzipで添付したことがあるだけでまだいちども説明してない。わたしが「パックマン風にはまったくの不向き」と書いた部分のこと。そこは現在どうなっているのか...

ISLe

ゲームプログラミングの館の移動サンプルプログラムは方向転換がブロック単位です。
ちなみにわたしがNo.8に書いたパックマンの動きとは合致しません。

仕切り直しが発生しているのでしょうか。
現状どういう状況なのでしょう。

「パックマン風」とはパックマンではなく、とにかく目に付いたコードを切り貼りしてそれっぽく動くことを目指すところのものなのでしょうか。
そもそもkeito94さんが何をもって「それっぽい」と判断されるのか分かりません。

なにがなんだか。

ISLe

オフトピック

パックマンの迷路は、8x8のチップ画像で構成されています。
直線と角が数パターンあり、それらの組み合わせです。

パックマンの迷路のチップ画像は、壁がチップの中央を通るように描かれています。
パックマンは(モンスターも)迷路の壁の描かれたチップの半分といつも重なっています。
曲がり角に達するより先に、重なっているチップの種類で曲がり角かどうか容易に判定できるというわけです。

ISLe

privateに存在する変数は、そもそもアクセス権限がないわけですから、扱えない(使う必要が無い)じゃないですか。それなのに、どうしてインテリセンスは表示してくるのでしょうか？どう考えても、無駄な気がします。 TEST::F()やTEST::F2()の定義の中ではアクセス権があるのに表示されないと困るのではないでしょうか？でもそれを実現しようとするとコンパイル時の文法解析と同等の処理が必要。処理コストがかかるので実現していないのではないでしょうか。コンマ数秒でもキーボードから単語入力するたびに待たされたらイライラしてブチ切れる気がします。ちなみにVisual Studio 201...

ISLe

否定的なことはすべて全否定と捉えるのは、コードの中身を理解していない(しようとしない)からでしょうかね。 C++＆DXライブラリのときに、移動先判定は… 『等間隔に並ぶ固定されたブロック、とプレイヤーキャラのみの当たり判定』が前提になってるから、のちのち苦労することになりますよってなことを何回も書いたの覚えてませんか？パックマンて『等間隔に並ぶ固定されたブロック、とプレイヤーキャラのみの当たり判定』(※モンスター等は障害物ではない) なんですよ。先読みが有効な場面なんですよね。そもそも曲がり角をショートカットって先を見ないと不可能だと思いませんか？ところがですね、パックマンは現在座...

ISLe

改善案を教えてくれませんか…。改善案とは？それこそパックマンを真似れば良いのではないでしょうか。パックマンを真似るというのは、どこかにあるそれっぽいコードをコピペすることではないですよ。パックマンの動作を見て、自分でデータ構造やアルゴリズムを考えることが「真似る」ということです。あの方法は全体的に不向きでしたか…。（初心者向けコードの延長線でかないということですか…。初めて知りました…。）あなたが考えるパックマン風の当たり判定の考え方と、将来的にはアクションゲームを作りたいから、あなたが考えているアクションゲームの当たり判定の考え方を教えて下さい。（同じなら同じと言ってくださ...

ISLe

keito94さんの念頭には、 [pygame]画像が分割して表示されない…。に添付されているソースファイルにあるブロック関連のコードと同じ方法でワープ通路を実装したいというのがあるのでしょうかね。マップデータ配列から、位置とチップ画像をセットにしたブロックの情報を個々に生成したものをグループ化、当たり判定はグループで行い、その際、チップ画像のサイズを利用している、というもの。でもリンク先のトピックでもこのトピックでも、そのへん一切話題になってない。過去に一度も触れていないことを前提にされてもなあ、って思います。そもそも、どこかのサイトを参考にしたらしいコードですが、パックマン風の...

ISLe

keito94 さんが書きました:
ISLe さんが書きました: 進行中に逆方向に入力があるとその場で反転しますが、進行方向と垂直の方向の入力があってもそのまま直進し、曲がり角に達すると入力方向に曲がります。
そのアルゴリズムの組み方がよくわからないので、その手がかりとなるものを教えて下さい。

手がかりは書いたとおりのことですよ。
書いてあることをコードに落とし込めばよいだけです。

#keito94さんが何を期待しているのかが分からない。

あと、これはワープ問題とは別の事案なので新規にトピをたてたほうが良いと思います。
#No.8もオフトピであるべきでした。

ISLe

ワープトンネルとは無関係なところを移動させる処理を簡単に説明すると、 ①プレイヤーのキー入力を確認する ②パックマンの移動する方向を入力した方向に変更する ③パックマンが壁に衝突するのなら、そこで停止（今のだと操作感がめちゃくちゃ悪いかも…。なにか改善案出してくれますか？）改善案とは？それこそパックマンを真似れば良いのではないでしょうか。パックマンは… 進行中に逆方向に入力があるとその場で反転しますが、進行方向と垂直の方向の入力があってもそのまま直進し、曲がり角に達すると入力方向に曲がります。さらに、曲がり角に達する前から曲がりたい方向に入力していた場合、正面の壁に突き当たることな...

ISLe

パックマンには、緊急回避のために左右がつながっているワープトンネルがあります。ワープ通路であることを表すチップをマップデータに入れるというのはわかっているのですが、まるでパックマンにワープ通路を表すチップがあるかのような書き方ですね。パックマン『風』とパックマンはきちんと区別して欲しいと思います。パックマンにこだわらないなら、以下は気にしなくてもかまいません。パックマンには、「ワープ通路であることを表すチップ」というものはありません。モンスターの速度が遅くなる部位設定というものはあります。パックマンは、上下・左右がそれぞれ円筒状に繋がったマップです。迷路の見えている部分は22...

ISLe

ゼルダの伝説時のオカリナの映像を見る限りでは、シームレステクスチャ(ループテクスチャ)のようです。

UV座標を0.～1.の範囲で貼り付けると、メッシュの中でテクスチャは一対一です。
UV座標を0.～2.の範囲で貼り付けると、メッシュの中でテクスチャは2回繰り返されます。
繰り返す回数が多いほどピクセルは密になり、間延びしなくなります。

Blenderでは、Image Mappingでリピート回数を指定できるみたいです。

ゲームプログラムでは、地面のような平面ポリゴンは動的に生成することも少なくないと思います。

ISLe

頂点情報は、頂点座標とUV座標がセットなので、UV座標が異なれば頂点情報は別個となります。それを、D3DPT_TRIANGLESTRIPのDrawPrimitive系関数一回の呼び出しで描画したいときは、縮退ポリゴンを利用します。縮退ポリゴンとは、面積がゼロのポリゴンのことです。 No.2のMathさんのコードに対して、26行目から32行目までを以下のコードに置き換えます。 CUSTOMVERTEX v[]= { { Cx - width/2, Cy + height/2, 0.0f, 1.0f, 0.0f, 1.0f}, { Cx - width/2, Cy - height/2, 0....

ISLe

CCollision::CheckMapを改造。戻り値のRECTは、矩形ではなく、各方向に何ピクセルめり込んでいるかを表す。 rcMoverは、CMoverクラスから直接持ってきたいところだが、引数周りを変えると変更点が多くなりすぎるので先送りとする。 RECT CCollision::CheckMap(int x, int y) { RECT rcMover = { x + mPt[0].x, y + mPt[0].y, x + mPt[7].x + 1, y + mPt[7].y + 1, }; RECT rc, rcResult; CopyRect(&rcResult, &rcMove...

ISLe

オフトピック

やたらサンプルコードよこせ言ってたけど、うちのブログは参考にならんかったかな。
まあ、2010年の記事だしJavaだし。
実験要素山盛りなのでそのままコピペはよろしくないから、せめて自力で見付けられるくらい意欲ある人でないとな。

ISLe

keito94 さんが書きました:ブロックに当たったら当たる前の座標に戻すでしたね…。
頭のなかで勘違いしてしまいました…。

いやいや、さらに酷くなってますよ。

A.「当たったら」とは
当たっていない状態から当たっている状態への『変化』
B.「当たっている」とは
その時点で当たっているという『状態』

AとBの違いが分からないですかねえ。

状態×変化のAは、状態だけのBより複雑になるのは明らか。

わたしはずっと「めり込みの補正」と表現してますよ。

Pythonを学んでこのような日本語のニュアンスの違いが分かるようになるといいですね。

ISLe

ISLeさんに言われてRECT構造体に書き換えてみたのですがバグだらけです。なにか、アドバイスはないのでしょうか？バグだらけなのはわたしの責任なんですか？何か書いても、書いた内容を理解する気はないように見えるし、無関係なところも含めてあちこちテキトーにいじくり回して問題を増やすし、さらにはその責任を押し付けられるのでは、何も書きたくないすなあ。 No.1に添付してるRectCollision.cppとか、大元からめちゃくちゃいじくり回してるけど、No.5ではわざわざIntersectRect関数とは別に関数作ってたりするし、ほんとにコードいじくり回すだけで理解してないんだなって思います...

ISLe

keito94 さんが書きました:効率が良くて汎用性のあるブロック当たり判定がどうしても思いつかないんです…。
衝突したブロックの座標を返すサンプルコードをくれませんか…。

いますぐやるべきは、CCollision::CheckMap関数にある、キャラとブロックの当たり判定をRECT構造体を使うように書き換えること。
いまは動作そのものは変えなくていい。むしろ変えてはいけない。
衝突したブロックの座標云々はRECT構造体使って衝突したブロックが分かるようにできてから。

言っちゃあなんですが、効率が良いとか汎用性があるとか、keito94さんに判断できるんですか？

ISLe

keito94 さんが書きました:RECT型で当たり判定を実装していますが、当たり判定の部分は実装できました。

ここは、敵キャラとの当たり判定だけにRECT使っています。
いまやろうとしているのは、ブロックとの当たり判定にRECTを導入しようということではないのでしょうかね。

そのまんま引っ張ってきて、無意味だ無駄だってやりとりを何度も繰り返すばかり。
コード理解しようとしてくださいよ。

オフトピック

そもそもネットに転がってるサンプルコードがなあ。

ISLe

ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。

keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。

ISLe

もしかしてめり込み防止の部分ですか？「もしかして」？あてずっぽうですか？あてずっぽうであたったとして何の意味があるんでしょう。場所はCCollision::CheckMapで合ってると書いたのに。 #そこだけとは言ってないけどひとつは、ブロックとキャラが当たってるかどうか調べるのに、縁を何点かだけ調べているところですよ。これは、ブロックが固定で等間隔に並んでいて、尚且つキャラとブロックが同一サイズというのが前提になる。 #keito94さんサイズ変えたらうまくいかないっていう質問を前にしてましたよね。この前提では、ブロックがあるところは、全面ブロックである。だから、ピクセル座...

ISLe

オフトピック

そういえば、No.47でリンクしたトピで、ブロックに当たったら当たる前の座標に戻す、という方針を採用する方向だったはずだけど、いまのコードには欠片も見当たらない。

当たる前の座標に戻せば、当たっていない状態に戻る、というのが悪魔の証明なので、それ以降スルーしてたのに。
前提条件がなければ、当たっていないとすることを保証できないのだから。

前提条件を積み重ねたコードはトピが解決してもずっと爆弾抱えたまま。

ISLe

分かっている、を選択しておいて、分かっていませんね。

キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。

keito94 さんが書きました:（今のコードでは）左へ上へ行ってしまうバグが起きてしまうことです。

そうなるようにコードを書き換えたのはkeito94さんですよ。

keito94 さんが書きました:その問題というのは、CheckMapや、マップチップを確認する部分にあります。

「どこが」はまあ合ってますけど、たまたまですかね。

“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。

ISLe

keito94さんは、“坂道を実装するには邪魔になりそうな前提条件”が何なのか分かっているのでしょうか。
分かっていないなら、差し当たって、目の前のコードを理解するところから始めましょう。
分かっているなら、どこがどうして問題なのか、説明して見せてください。

どうやって排除するか、を考えるのはそのあとです。

ISLe

keito94 さんが書きました:ですが、地上に着地せずにめり込んで左に移動してしまいます。

添付されているソースファイルは、そうならないようにCPlayer::GroundFlag書き換えている箇所を移動してますね。
どうしてでしょうね。

ISLe

現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。（キャラの座標が中央基準なので…。）ですが、地上に着地せずにめり込んで左に移動してしまいます。ブロックが等間隔に並んでいることが前提条件になりますよね。わざわざブロックが等間隔に並んでいないといけなくするメリットって何でしょう。むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。そもそも、衝突したブロックの左にあるブロックがキャラより左にあって、衝突したブロックの右にあるブロックがキャラより右にある、というのは当たり前。こちらも同時に成立する条件。あいだにelseを入れたので、前...

ISLe

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。 CCollision::GetXPosition関数内 Collision.cpp:267行目～ int bpos = block.x * 16; int brpos = bpos + 32; int blpos = bpos - 32; bool Debug = true; if (brpos < *myx) { *myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f); } if (blpos > *myx) { *myx = (float)...

ISLe

正確には当たり判定のコード自体は完成していたのですが、例えば、CCollision::GetXPosition関数の中にあるコード… (Collision.cpp:267行目～) if (block.x < *myx) { *myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f); } block.xは、左端のブロックを0番目として右へ何個目かという数値が入ってます。 *myxは、キャラの中心のX座標がピクセル単位で入ってます。まったく意味の違う数値を比較しているこのコード、正しいですか？なかなか理想通りの動きになりません…。どう...

ISLe

坂道に沿って上り下りするというのは、キャラを基準に移動するだけでなくプラスアルファが必要。特に坂道を下るのは、補正に頼るとキャラが浮いてしまったりしてうまくない。 #逆にそれが活きるデザインもあるが。なので、坂道の上り下りの際は、キャラを主体ではなく客体とする。どういうことかと言うと… ・坂に入ったら、キャラは見えない動く床に乗った状態になる・ユーザーの操作で動くのは見えない床で、キャラはその床に対して位置を保ちつつ、その場で足踏み・坂道の端を超えて移動するあるいは途中でジャンプするなど坂道を離れたら、見えない動く床は消滅し、キャラは通常運転に戻るという具合。もちろんこれも方法...

ISLe

(※下線加筆) No.67に書きました。 CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。ある意味keito94さんの才能かもしれませんね。これ、いますぐやっちゃダメって読めないですかね。わたしの文章がおかしいのかな。あと、不思議な文言があるのに気づきました。 #前後のインパクトのほうが大きかったもので No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、上下の当たり判定で、めり込んで左の壁まで行ってしま...

ISLe

CPlayer::GroundFlagがオンのときCPlayerは地上にいるように振る舞う。 CPlayerはCPlayer::GroundFlagによってのみ振る舞いを変える。これは前提。現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。当たり判定の範囲と、めり込んでいるとする範囲をずらすという方法がある。選択肢の一つであり何が正解というわけでないが、シンプルだし、現状においては変更点も...

ISLe

後、重力の部分を分割してみました。これ、何か目的があるんですよね。コードに手を加えるというのは、バグを生む可能性を含みます。プログラムを台無しにするのと引き換えにしてもいいくらい意味のあることなんでしょうね。ちょっと分からないので説明していただけませんか。もし、万が一、意味もなくやったのだとしたら… (※下線加筆) ごめんなさい、座標をずらす部分をむやみにいじってしまいました… No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、上下の当たり判定で、めり込んで左の壁まで行ってしまいます。後、重力の部分を分割してみました。正に舌の根の乾かぬうちにって...

ISLe

現時点で気になることを書き残しておきます。 CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。タイルのサイズは16ピクセルであるのに、-8～8という範囲(＝17ピクセル)を使って重要な判定をしている。座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。 CPlayerはCMoverを継承しているのに、どう...

ISLe

壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。これはつまり… CCollision::GetXPosition関数にある(あった) *myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f); *myx = (float)((block.x + 1) * 16 + 8 + OffsetL + 0.1f); とか CCollision::GetYPosition関数にある(あった) *myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f); *myy = (float...

ISLe

なん…だと…。地上にいるというのは振る舞いだけだったのか…。『CPlayerは』『CPlayer::GroundFlagによってのみ』振る舞いを変えることでCPlayerの独立性が高まります。 CPlayer::GroundFlagの変化とは無関係になるので、キャラの挙動と、ブロックのあたり判定それぞれ別々にデバッグが可能になる。という内容のことをNo.47で書いているんですけどね。当時は理解できなかったとしても今は理解できるかもしれない。何回も読み直して理解しようという気はないのでしょうか。あと、バグの原因の特定も容易になる。挙動の変化がおかしいならCPlayer::Groun...

ISLe

現在は移動量に依存していた部分を取り除いたところです。前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。 CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。（混乱を招く回答すいません…。）それはわたしがNo.84で書いた表現をなぞっているだけですね。 No.84では、それに対する問題の指摘も同時にしているのですが、理解できませんでしたか？ No.85を見たら理解しようという気概を感じられませんけどね。画面右端のブロックに触れると右外に消えてしまう問題については、さらに前のNo.81で既に書いて...

ISLe

移動量撤廃の方針を続けるならこのトピで続ければよいのでは。移動量を使うなら、元の木阿弥だという意味ですよ。同じことの繰り返し。新しいトピを立てても同じ内容のトピができるだけだと思うけども。そもそもkeito94さんがこのトピを読み直しているようすが見えない。わたしがkeito94さんのアップロードしたソースコードを過去の分も全部保存して、返信する都度、比較してここが変わったあそこが変わった、また同じことしてるだの、というふうなことをしているわけだけども。別に、わたしが苦労しているのを分かれだとか、何かを押し付けようというつもりはないよ。最低限そのくらいしないと内容を理解できないだ...

ISLe

keito94さんは、CPlayer::GroundFlagが真のとき、地上に立っている状態と説明しました。

CPlayer::GroundFlagが真のとき、キャラは地上に立っているように振る舞います。
そこでは、実際にキャラが地上に居るかどうかは関係ありません。

キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。
次のフレームで、それは地上に立っていることになるのでしょうか。

コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。

ISLe

オフトピック

そろそろXとYで関数を分ける必要もない段階まできてたわけだけども。
そうなると、
めり込みを許容して押し戻すマリオ(ブラザーズ)タイプ
と
めり込みを許容せず一気に移動のロックマンタイプ
を選択する余地も生まれるのだけども。

マリオ(ブラザーズ)タイプ、ロックマンタイプってのはわたしが勝手に分類して言ってるだけだけども。

ISLe

オフトピック

いちおう移動量を使わない方法を書いておきます。

めり込んでいる対象のブロックは分かっているので、ブロックの座標とキャラの座標を比較して、どちらにずらしたほうが良いか決定します。

移動量で決めると、例えばトンネル状のマップを抜けるとき、うっかりジャンプして天井ブロックに触れると、一気に入り口まで戻されるという現象が発生します。

ISLe

No.76のkeito94さんが書いたCPlayer::GroundFlagの説明は正しいのでしょうか。間違った理解でコードをいじるからおかしなことになるのと違いますか。そもそも、コードに「～となるはず」なんてコメントありえません。引き算のつもりで足し算書いたのをPCが忖度して直してくれるはずもない。 - + - + - 引数の移動量が復活してますね。ここにきて、移動量撤廃の方針をひっくり返しますか。移動量を使わないでどうやって判定するのか？といういちばんのキモを質問しないのですね。やっとここまで問題点をピンポイントであぶり出せたのに。いや、別にいいんですよ。どういう方針を選ぶ...

ISLe

ヘッダファイルを混在すると、defineマクロによって予期しない置換が発生することがあります。

この場合、これより前にインクルードされたヘッダファイルのどこかにverifyというマクロが定義されていると思われます。

ISLe

オフトピック

クラスやメンバなどの役割りを決め、その役割り通りに且つ役割りを発揮できるように構成を考え、それらを繰り返し練っていく、というのがプログラミングの本質であると思う。
コーディングは、それのアウトプットに過ぎない。
いきなりコーディングという場合でも、過程においてのコーディングは思考を補助する役割りであると思う。

役割りを考えず、役割りに基づいてコードを書いていないのであれば、それはプログラミングではない。
プログラミング言語を使ったラクガキだ。

ラクガキだから楽しいというのはあるかもしれない。
であればラクガキを楽しめばいい。

ISLe

CCollisionと言うのは当たり判定の処理を行うクラスです。それはCCollisionの説明になっていませんね。 CPlayerも当たり判定の処理をしてますよね。CCollisionのメソッドを呼び出しているから。もっと言えば、このプログラム自体も当たり判定の処理をしてますよね。そんな中でCCollisionの役割りとは何なんですか？それを説明できないから何でもかんでもCCollisionでやろうとしてCCollisionがないと動かないコードになってしまうのでしょう。 CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。 CPlaye...

ISLe

そもそもCCollisionクラスって何なんですか？クラスの役割りを説明できますか？説明できないのにただいじくり回しているだけならキリがないのでやめましょう。 No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。そういう目的に使える情報は既にCPlayerクラスにありますよね。 CPlayer::GroundFlagってありますよね。 CPlayer::GroundFlagって何ですか？これも役割りを説明できますか？ CCollisionのアウトプットとして、...

ISLe

No.1のコードは下記のようにするとC99でも(言及がないという意味で)許容範囲になるのかな。 #include <stdio.h> int main(){ int m[3][3]; int (*p)[3] = m; for(int i=0; i<3; i++){ for(int j=0; j<3; j++){ p[i][j] = -1; } } printf("%d\n",p[0][3]); printf("%d\n",p[1][3]); printf("%d\n",p[1][4]); return 0; } 配列名を...

ISLe

僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。なので、移動量に頼らないめり込み防止のサンプルコードをください。いちいち頭で考えなくても、引数の宣言からaddx,addyをまるまる取り除けば、変更が必要な部分はコンパイラが教えてくれますよ。なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。常に落下してしまうのはどうしてなのか、というところに頭を使いましょうよ。 No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落...

ISLe

C99より前は、構造体の最後にサイズ1の配列を配置して、バイナリのヘッダ構造に続くデータを読み書きする方法を慣例として認める記述がありましたが、規格としては特に規定はありませんでした。

C99では、構造体の最後のメンバに限り、サイズ指定のない配列の宣言が規格として取り入れられました。

それに合わせて、配列に対しては、厳格となりました。

みけCATさんの指摘は、よく見てもらったら分かると思いますが、6.5.6に対する注釈であり、aに対しては未定義動作となるという記述ですが、pに対しては言及されていません。

ISLe

あと、(いまのところ)削らなくていいものまで削ってますね。

ISLe

ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。ずいぶん中途半端に変更したのですね。これをわたしが考えたと言われるのはかなり抵抗あります。 addxとaddyを0にしないとまともに動作しません。（このステージでは関係ないんですが…。）それはそうでしょうね。わたしがNo.63で書いた、移動量を何回も加算してしまわないだろうか、と懸念していたことを新たにやらかしてます。このステージでは関係ない…ほんとうにそうでしょうか。例えば坂道を登りきる前に坂道の判定が消える、ような気がしますが。もしかして中途半端なのは、CCollision::GetMoveにある落下に関する...

ISLe

現在位置 p 移動量 a パターンA 移動関数() { 　aを生成　当たり判定と補正を行う関数(p, a) { 　　if (p + a がめり込んでいる) { 　　　pをめり込んでいない位置に補正　　　aをリセット　　} 　　pにaを加える　} } パターンB 移動関数() { 　aを生成　pにaを加える　当たり判定と補正を行う関数(p) { 　　if (p がめり込んでいる) { 　　　pをめり込んでいない位置に補正　　} 　} } パターンA,Bともに結果は同じです。パターンAは、補正が必要なときに、pをいったん更新するのを避けられます。ただそれだけです。 pを格納する変数...

ISLe

keito94 さんが書きました:出力する引数は、ポインタをつけろというわけですね…。

ここは(いまのところ)結果に影響を与えていないので、単に、引数に与えた値(特に現在座標と移動量)の変化を把握していないのではないかという疑問を補強する意味で指摘しました。
そういう意味では今回の変更においても疑問は一切解消されていません。

keito94 さんが書きました:あと、入れ子化していた部分を修正しました。

階層が1段増えましたね。
これを修正というのでしょうか。
わたしには改悪にしか見えませんが。

ISLe

開発環境に依存する内容なので開発環境が分からないと回答のしようがないです。

Visual Studioであれば、ソースファイルのプロパティで、ソースファイルごとに指定できます。

ファイル名の干渉を気にするなら、ライブラリ単位でプロジェクトを分けてプロジェクトのプロパティを設定するほうがより自然な形だと思います。

ISLe

ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。 CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。直しているとき、他に、移動量渡してない関数があることに気付きませんでした？あと、現在座標と移動量のポインタを引数で渡して、当たり判定の結果によって、書き換えたり書き換えなかったりするわけですが、それが3段くらいの入れ子になっているので、書き換えた内容が上書きされるのではないだろうか、とか、移動量を何回も加算してしまわないだろうか、とかのうっかりミスをやらかしてしまっている可能性を考えるとキリがな...

ISLe

わたしがVector2の修正を指摘した時点では、それを適用すると上下動は無くなり、坂道に対する当たり判定そのものがなくなったように動作していました。最新の状態では、上下動は再び発生しています。原因が異なるであろうため前とは若干挙動が違います。プレイヤーの移動処理をCPlayerクラスからCCollisionクラスに丸投げしているところで一気に読む気を削がれるのですが、何とか耐えて坂道関連の処理をひととおり読んでみました。読んでみましたが理解するのは無理でした。場所によって、移動先の座標で判定してその結果で移動元の座標を更新していたり、移動先の座標を引数で渡してさらに移動量を加えて使っ...

ISLe

ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか？ No.33と違い、No.51は明らかに無断転載でしょう。このトピックをログインせずに見るひとからしたら、まったく意味不明ですよ。そういう脈略のないところがコードにも表れているのと違いますか。 ISLeさん、言い方が悪かったみたいですね…。今書いているコードがスパゲッティコードになってるのは認めます。しかし、どうしても、坂道の当たり判定が、今のしか考えられないので、あなたが考えている方の当たり判定のサンプルコードを提示してください。 No...

ISLe

＞ keito94 さんわたしの書いた文章をちゃんと読みましたか。文字をなぞるだけでなく、意味を理解しましたか。「それをもとにして、Collision.cppをプログラム」する必要があったら、それはもうわたしのやり方ではないのです。「それをもとにして、Collision.cppをプログラム」できるようなサンプルコードをわたしのやり方で書いたら、もはや何も(あるいはほとんど)変更する必要がないのですから、コードを入れ替える一択しかあり得ません。理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありま...

ISLe

そもそも、その場所からどかなければならない理由は、Playerにとっては知らなくて良いことです。 Playerのメソッドの中で、マップとのあたり判定を行っていること自体が不自然です。 Playerは、どの方向にどれだけどけばよいか(あるいはそれを求めるために必要十分な情報)を得て、その情報のみに従って移動先を決めればよいというのがわたしの考え方です。わたしなら、Player::Updateの外で、プレイヤーと壁(やその他の障害物など)の当たり判定を行い、例えばRECT構造体に上下左右のめり込み量を設定。Player::Update内でそれを取得して、挙動を決定するようにします。既に移動でき...

ISLe

そうか、Collision.cppの当たり判定は間違っていたのか…。わたしが違う方法を使うというだけで、間違っているとは言っておりません。キャラが壁にハマってしまうわたしが使う方法は既に最初期にお伝えしてます。壁にめり込んでいるのを補正するなら、ただ壁にめり込んでいるのを補正するだけでいい、というふうなことです。やり方が違うというだけで、やること自体は変わりません。 keito94さんのいまのコードでは、機能ごとに階層が深く複雑化していく構造です。機能ごとの依存度が高く、機能の変更や追加が他へ大きく影響するため、そのバランスを取ることに大量の時間を割くことになります。わたしが使...

ISLe

Vector2.cppを修正してやっとまともにデバッグできる状況になるというだけです。
坂道判定に関しては、ここからスタートですよ。
ご自身で取り組んでください。

keito94 さんが書きました:Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので

わたしはこれを残したままのやり方を知りませんし考えたくもないです。
もっとシンプルに実装する方法を知っていますが、根本的に考え方が異なるのです。
#某所に書いたのはそういうことであってコードが正しいとか正しくないとかいうことではない。

ISLe

とりあえず、他は現状のままでよいので、Vector2.cppの下記の関数を変更してください。これでやっとまともに坂道判定にとっかかれると思います。 Vector2& Vector2::operator *=(const float& a) { #if 0 return Vector2(x * a, y * a); #else x *= a; y *= a; return *this; #endif } Vector2& Vector2::operator /=(const float& a) { #if 0 return Vector2(x / a, y / a); #else x /= a...

ISLe

②あらかじめMakeScreen()で作成したスクリーン(s)を用意しておいて、マップが編集された直後だけ　sに全体マップ500*500個をDrawExtendGraph()し、GetDrawScreenGraph()でハンドル(h)に格納。　あとは毎フレームDrawExtendGraph(h)で描画する。　　→　カーソルがリアルタイムで描画できる。　　→　GetDrawScreenGraph()が重く処理落ちが顕著でマップを連続的に編集できない。 MakeScreen関数の返す値がスクリーン(s)のグラフィックハンドルなので、それを使って描画できます。 GetDrawScreenG...

ISLe

Visual StudioのIDEが文字として認識するのは、ワイド文字(wchar_t)かANSI文字(char)です。 std::stringはANSI文字対応なので、ANSI文字列に変換する必要があります。文字コードの変換に言語レベルでの標準は無く、下記はWin32 APIを使う場合の例です。 #include <string> #include <iostream> #include <windows.h> int main() { char buf_utf8[] = u8"あいうえお"; wchar_t buf_wc[256];// = L"あいうえお"; char buf_ansi...

ISLe

あたり判定に条件を加えるのはよろしくない。押し戻したあともめり込んでいる状態が解消されないと移動できなくなるから。そういう質問だからそういう理由で起きてるのだろうと予測してコードを読んでみる。なるほど、めり込み判定をなんとかしろというわけですか。そういや、そうかもしれませんね…。まずは、めり込んでいる状態を解決してくださいと。ということは、直前の移動フレームを実装すればいいわけですね。どうして今まで気づかなかったのだろうか…。そういうことではないです。シンプルであるべきと書いたのは、考え方や手順についてです。キャラが移動して壁にめり込むのを補正するのではなく、ただ壁にめり込...

ISLe

Cygwin版はインストールドライブ以外のドライブでもちゃんと日本語になるんですけどね。
Cygwin版というくくりじゃなくて、MinGW-w64ではちゃんとしてるということなのかもしれませんけど。

ISLe

Cygwin版のMingw64 gccバイナリを覗くと、"/usr/share/locale"という文字列が見えるので、パス自体はハードコーディングされているみたいです。
そうなるとルートディレクトリがどのように決定されるかという問題になります。

MinGW版はMSYSのmountコマンドでルートディレクトリを変更できるらしいので、もしかしたらMINGW_HOMEじゃなくてMSYS_HOMEが関係するのかもしれません。

ISLe

オフトピック

読みやすいとは言えなくても、内容が分かりにくいとまでは思わないけれど、わたしは。

あたり判定に条件を加えるのはよろしくない。
押し戻したあともめり込んでいる状態が解消されないと移動できなくなるから。
そういう質問だからそういう理由で起きてるのだろうと予測してコードを読んでみる。

壁に当たってるときに押し戻す量が1.0f固定になってる。
これは圧倒的に足りていないのではないだろうか。

そこを直しても、浮動小数点数だから、計算上は足りてても誤差でハマる可能性が残る。

あたり判定はもっとシンプルであるべきと思う。

ISLe

MinGW gccを単体で呼び出す場合の話ですよね。
環境変数MINGW_HOMEを設定すると良いみたいです。
MinGWのデータが「C:\MinGW\bin」にあるなら
MINGW_HOME=C:\MinGW
というふうに。

ISLe

Cygwin版は/usr/share/locale/以下にある言語ファイルを参照しているようです。
不要な言語のものを削除してしまえばかなりの容量を削れるような気がします。

MinGW版の容量が少ないのは言語ファイルがないということなのかもしれません。
#だとしたら切り替えれるという情報は…？

ISLe

ウチはCygwinでパッケージ配布されているMingw64のものを使っているのですが、LANG=ja_JP.UTF-8だけで日本語に切り替わってます。

未確認ですが、Mingwのインストーラーからインストールしたものだと
LANG=ja_JP.SJIS
と
OUTPUT_CHARSET=sjis
で日本語に切り替わるという情報が見付かりました。

ISLe

日本語化に対する要求レベルはいかほどでしょう。

リンク先の記事は、未翻訳のメッセージを(独自に)翻訳したものに置き換えたいというものです。

英語を日本語に切り替えたいというものであれば、環境変数にLANG=ja_JPを設定すれば切り替わると思います。

ISLe

せっかくなのでMicrosoft開発者ブログの記事へのリンクをはっておきます。この記事では再生デバイスをループバックするシンプルなコマンドプログラムを公開しています。・ブログ記事 Sample – WASAPI loopback capture (record what you hear) – Matthew van Eerde's web log ・ソースファイル blog/loopback-capture at master · mvaneerde/blog · GitHub IAudioClientの初期化時にAUDCLNT_STREAMFLAGS_LOOPBACKフラグを指定する...

ISLe

オフトピック

AudacityでWASAPIを使うとき、再生デバイス名の後ろにloopbackとあります。
『WASAPI loopback』で検索するとMSDNの記事(英語)やMicrosoft開発者ブログ記事(英語、サンプルコードあり)などが見付かりました。
WASAPIには再生(レンダ)デバイスに対するループバックモードという機能があるそうです。
再生したそのままを取り込めるなら、ステレオミキサーでは避けられない劣化も回避できるのですが、はたして…

ISLe

オフトピック

1. WM_ERASEBKGNDで何もせず1を返す
2. WM_PAINTで何もせずBeginPaintとEndPaintだけを呼び出す
をテンプレにしておくとよいと思います。

1.は背景消去処理そのものを無効化します。
2.はWM_PAINTメッセージが連投されないように無効領域を解消します。

ISLe

59行目で作成したJLabelは、フレームのContentPaneにセットしていないので、フレームに影響しません。提示されたURLの記事は、このコードをフレームのContentPaneにセットするように変更してもダメ、ということが書かれています。また、JLabelを新たに生成してセットすると、JLabelが増えていくことになる(※)ので、画像を切り替えているとは言えません。 ※同じ場所に同じ大きさで配置するといちばん上に表示されたものだけが見えることになります。無駄にメモリを消費することにもなります。画像を切り替えたいのであれば、59行目を LabelDayo0.setIcon(Img...

ISLe

オフトピック

あんどーなつさんが書きました:主語がないので回答できません。文脈から判断すればいいのでしょうが、あえてしないです。
それをして間違えるともっとあほくさくなるからです。
質問者の人に言うのも筋違いですが、勢いで読み間違えて回答することもありうるので、
その時は許してあげてください。

この回答が既にあほくさいと思いますけどね。
どうしてNo.40に対する質問だというのが分からないんですかね。
どうしてあんどーなつさんが「回答できません」って言い切ってしまうんですかね。

「回答できません」って言い切られてしまったあとに、他の回答者がどんな顔して回答したらいいんですかね。

ISLe

人間の考えている事なんて分からないことだらけだと思いますが、事の顛末とこの掲示板にいつからいたのかということから考えて、ISLeさんのほうが正しそうだとは思います（逆に言うとNo.7->No.13->No.18とかのことはいまださっぱりわからないし、わかるときが来ないと分からないと思ってます）。わたしは正しいか正しくないかという話はしてません。根拠を求めているだけです。だから、わたしはわたしの根拠を説明しました。それよりも私が不可解だと思っていたのは、私のつぶやきのような発言にISLeさんが食って掛かったかのように私の方で感じたことです。おそらく私の方で社会一般の人たちがスロットに関...

ISLe

No.13のコードは、No.7で書いたリールの末尾と先頭をまたがる対策が、スマートに解決できるコードになってた。このコードがすんなり出てくることに、スロットを作ることに対して手慣れていると感じた。そこが出題者の指示であろうことは間違いないと思った。そこから、質問者さんのフィルターを通す前の指示の内容は「配列の部分はもう『これでいい』からあとの部分を考えろ」というものであろうと想像した(No.18)。質問者の立場に立つ、あるいは寄り添うというのは、鵜呑みにすることとは違うと考える。「実行しようとしたらわけのわからないエラーが出て実行できません」という質問にわけのわからんエラー...

		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 件