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

usao

while(1){ ... } って書いたら，「...」のところが複数回実行され得る，という点については大丈夫かな？示されたコードでは入力処理がこの部分に描かれているけど，「nやmを何度も何度も入力しろ」という話には見えないから，まずここの時点で変なことになっていると思うけど． …という感じで，あなたがどういう処理手順を実装したつもりなのか？　というのがそもそも他者には謎なので，ifの条件をどうしたいのか？　とかも正直謎．（間違っているコードだけ示して，そこからあなたの考えを読み取れというのは無理がある） --- あと，とりあえず「nからmまで」とかいう言い方から察するに， n<=m み...

usao

ウィンドウのサイズを変えるような処理は，その結果として，スクロールバーの表示有無だけでなくメニューの表示幅が変わったりとかいうことも生じ得るため，サイズ変更前の状態における「画像表示する領域のサイズ」に基づいて新しいウィンドウサイズを求めても，そのサイズにすれば表示域のサイズが画像ぴったりになるとは限らないです．私がこれ系の実装をしたときは，上記のような「現領域サイズを基準にして新しいウィンドウサイズを求めてウィンドウリサイズする」という処理を２回以上（ウィンドウサイズを変えずに済む状態になるまで）実施するようにして対処しました．（経験上では２回で終わる様子．３回以上やることになる場合が...

usao

OnPaint() の中でウィンドウサイズを変えてるってのは妥当か…？　というのも若干気になりますが，それはそれとして…

ウィンドウのサイズを変える処理を行っている個所のサイズ計算過程を調査して「どうしてそうなるのか」を突き止めれば良いのではないでしょうか．

当てずっぽうですが，

(1) スクロールバーがある状態でサイズ計算すれば，スクロールバー込みでのウィンドウサイズに変更することになる
(2) (1)の後でスクロールバーが要らないという判定になり，スクロールバーが消される．その結果としてスクロールバーがあった箇所が余白になる．

みたいなことになっているのでは？

usao

オフトピック

Hello.

I want to recommend to write in English instead of in Chinese.
This is because most Japanese have no experience using Chinese, but have some experience learning English at school.

usao

変数値の切替の部分： > ( CurrentImageIndex<(3-1) ? CurrentImageIndex+1 : 0 ); の書き方が「何なの？」っていう場合，これをもっと素直(?)に書くなら //とりあえず１個次に進める ++CurrentImageIndex; //でも，有効な値は {0,1,2} だけなので，↑のインクリメントで3になっちゃった場合には 0 に戻す if( CurrentImageIndex==3 ){ CurrentImageIndex=0; } とかだ．こんなのは意味さえわかればどう書いてもよいので，たまたま示した記述例にこだわらなくて良い．こういう場...

usao

> キーを押したら次の画像に移り、最後まで行ったらまた最初の画像に戻るというプログラムを作りたいのですがどうしたら良いのでしょうか？「キーを押す」度に表示する画像を切り替える　という話なのであれば，表示を行う処理の部分はある瞬間にそのキーが押されているかどうか？なんてことには関与する必要は無く，とにかく「今現在表示すべき画像っていうのはコレ」という情報（の現在値）に基づいた表示を行っていればよいだけなのでは．そのライブラリを知らんから，具体的な型とか処理コードは示せないけども，例えばこんな話かと． int main() { //ここではなんか画像データが３個あるのだとして… 画像デー...

usao

オフトピック

teratail に関しては，複数アカウント作ることがルール上禁止されてはいますが，実際上は完全に放置されていてやりたい放題されているという有様みたいですから，
仮に現行のアカウントが使えないとしても，別のアカウントをさくっと作ってそっちでは「ごく普通のひとを装ってれば」いいんじゃないですかね？
（SOに関しては，そこらへんどんな感じなのか私は知りませんが）

usao

> テラテイルでは、アカウント停止寸前、stack overflowでは、アカウントが停止されました。

何をやらかしてそんな状態になっているのかわかりませんが…

とりあえず前者側は「寸前」ということであればまだ使えるのでしょうから
今からでも　普通に（：停止されないように）　使えば良いのではないでしょうか．

オフトピック

私もこことか teratail とかでわりとクソみたいな態度をとっていますが
それでもとりあえずアカウントをどうこうされるような事態にはなっていないので，
問題視されている何か（言葉遣い？　振る舞い？　よくわからんけど）をある程度抑えて臨めば大丈夫なんじゃないかな？

usao

そもそもノードの型を main関数側が知らなきゃならない話（を扱っている状況）なのか？
というあたりから疑問というか謎．

main関数側から見たら

【具体実装がどうなってるかは知らんけども】とにかく「単語のリスト」というデータが（１つだけ）存在していて，それに対する限定的な操作（新しい単語を加える，ソートさせる）手段が提供されている

ではダメなのか？
（やりたいこと以上の自由度を設ける必要は無いように思うけど）

usao

それはそれとして，main関数で直接的に list の値を弄るのは正しいことですか？

おそらく，本来ならば変数 list は main関数からは見えない存在であるという前提のうえで，各種関数を使っていく想定なのだと想像しますが…

で，そしたら「各関数がきっちり己の役割を果たしているのか？」っていう話も当然ありますね．確認できていますか？
例えば，私から見ると，create_node関数は役割を十分に果たしているとは思えないのですが，実際のところどうなんでしょう？（実際の仕様はあなたにしかわからない）

usao

> とりあえず実際にどう動いているのか細かく見ていけばどうか．の部分が言いたいことであり，以降は例である，という点をまずはご理解いただきたい．【あなたは，このプログラムにある入力が与えられた際のあるべき動作を隅から隅まで知っているハズ】なのだから，そしたら１行ずつでもなんでも【あるべき動作をしているか？】をチェックしていけば良いのではありませんか？そしたらある時点で，「なんでそう動くん？」っていう動作をすることを発見できるのではありませんか？仮に，このコードがどこかからやってきたような代物であって，上記の【隅から隅まで知っている】をあなたが満たさない状況にあるのであれば，その状態で...

usao

オフトピック

> C言語何でも質問掲示板では、C/C++を初めプログラムに関する様々な質問を受け付けています。

とのことなので，まぁ，言語が制限されている場だというわけではないのだろうけども……

それでも，わざわざ「C言語」って名前が付いている場所でやるよりは，そのジャンルを明示的に扱っている場所を利用した方が良いのでは感．
（余計なおせっかいかな？）

usao

とりあえず実際にどう動いているのか細かく見ていけばどうか．
例えば，

node = search_node(buf);

を初めて実施する時点で

node_t *list = NULL;

が NULL のままだったりしたらヤバそうだよね．
そして実際そう動きそうにも見える（だれも list を更新しないであろうから）．

usao

> 何というキーワードを検索すればいいのか

っていう点に関しては，例えば…

・"ab" の型については「C++ 文字列リテラル　型」
・配列の index の型については「C++ 配列 index 型」
・bool から int へのキャストについては「C++ bool int キャスト」

…とか，愚直にトライしてみればいけるのではないかな，と．
「仕様」みたいな単語を入れてみても良いかもしれない．

usao

//このpに対して… const char *p = "ab"; //こうしたら，'a' と 'b' が表示されるよね std::cout << p[0] << std::endl; std::cout << p[1] << std::endl; //--- //っていうのと，まぁ，同じような話で，これでも 'a' と 'b' が表示されるよね． // "ab" の型は多分，const char[3] だろうから，普通に配列の [0] と [1] を出力しているだけだ． std::cout << "ab"[0] << std::endl; std::cout << "ab"[1] << st...

usao

関数に切り出さないとしても，せめてこのくらいに整頓すればどうであろうか．（現代の C言語って，このくらいの書き方できるんだよね？）・定数たるべきものは定数にする．・各変数のスコープと寿命範囲を必要以上に大きくしない． int main(void) { //こいつらは定数 const double rhofilm = 950000; const double tfilm = 0.00000022; const double rhohe = 178.6; const double rhoair = 1293; const double g = 9.86; const double mdro...

usao

ループで値を持ち越すべき変数と，ループ内部での計算だけに使う変数（次回に持ち越さない）とがあるのなら，きっちりとそれらを分ければ間違いも減るでしょうし，コードもすっきりするんじゃないかな，と．例えば，wfilm, lfilm だけがループで値を持ち越すべき存在なのだとしたら， for( i=0; i<=2; i++ ) { //wfilm, lfilm の値をちょっと増やして計算する wfilm += 0.1; lfilm += 0.1; SomeFunction( wfilm, lfilm ); //指定した wfilm, lfilm の値を用いて何か計算する関数 } みたいな形でルー...

usao

デバッグしてください．コード書きました　→　コンパイルしました　→　思った通りに動きません　→　はいお手上げ（今ココ） …ではなくて，実際にどう動いているのかを確認する作業に入りましょう，という話です． > つまり、wfilmとlfilmの値をfor文で更新しているにも関わらず,while文の中身に反映されていないということです。これは実際の変数値や処理の遷移を確認した上で述べているのでしょうか？　それとも推測でしょうか？実際に確認していないならば，各所に printf でも入れてみて動作の様子を観測してください．（もちろん，デバッガを使えるのであれば，その方が早いですが）例えば ...

usao

オフトピック

> …みたいな作業を行う関数

「んなもん，stringのメソッドを使えばよくね？」みたいな無粋な突っ込みが入りそうな気がしないでもないので，先手を打って述べておくぜ！

usao

で，それはそれとして… > 暗号化するプレーンテキストは、T,H,I,Sなど一時ずつ ','で区切らないといけない本当ですか？　そうとも見えませんが．むしろカンマを入力させること自体の意味が不明と見えます．（本来は「カンマの入力を必要とするもの」を作っているハズなのであれば，現状のコードはその点に関して間違っているのかもしれません） > 復号の際は最後の数字の後に','をつけないと正しく復号してくれません。何かを「カンマである」という条件だけで判断しているからでしょう．そのような個所を例えば「カンマあるいは入力の末尾のいずれか」みたいな話にすれば良いのではないでしょうか．この点に関...

usao

あなたが「欠点」と述べている現仕様を定めた理由は何ですか？ …と問うのは，現状そのようになっていることには何かしらの理由があるハズだと思うから．（だって，そうじゃなければ，わざわざそんな不自由な形にしないだろうし，「そういう形にしてやろう」とか思いついたりもしないよね？）要は，何が必要事項なのかが他者には不明なのでこのままでは回答不能かと見えます．（仮に何のこだわりもないのであれば，「じゃあその仕様をやめればいいよね」っていう話にしかならない） --- ひらがなに関しては， > 0から26までの数字に暗号化という仕様のままで何とかしたいという方向の話なのか，相応に値の範囲を拡張するよう...

usao

自分が答えるわけじゃないけど

> switch文の中で

っていう話が何だか意味不明に思えるよ．
（あえてそのように書いてるということは，何かそこが成否を分ける重要な要素なのだろうけども）

usao

> その図の(3)の赤い点群から出発して(6)の処理がやれないのだろうか？

の側を考えた方が話としては楽なのかもしれないなぁ．
例えば，とりあえず適当にドロネーか何かで三角形分割した後，要らない三角形を捨ててしまえば良いのでは的な方向とかで．
（話としては楽だったとしても，現実的には処理速度とかの面でNGになり得る？）

usao

オフトピック

一方が完全に他方の内側に入っている場合とか
四角形が三角形の頂点をいくつか含む場合とか
四角形が三角形を複数個の図形に分断するような場合とか

…も扱わないとならないだろうし，
「ちょうど接する」みたいな状態でバグらないように気を付けないといけないかもしれないし…
有り得る様々な状態にちゃんと対応できるような実装を用意するのは大変そうだなぁ．

usao

オフトピック

あと，「文字を消す」という文言がちょっと気になるなぁ．

> while (ScreenFlip() == 0 && ProcessMessage() == 0 && ClearDrawScreen() == 0 && UpdateKey() == 0){

とかいうループを書いている時点で，「描画したものは毎回消えている」のではあるまいか．

そしたら，やりたいことは「表示した物を消したい」じゃなくて「所望のものだけを描画したい」という形に表現されるべき場面ではないかと思える．

usao

Text(1); //txtファイルの1行目を表示する Text(2); //txtファイルの2行目を表示するって２つ書いたら　→　両方が表示されるというのは極めて自然で当たり前すぎる話だと思える．（むしろ，「頑張って２つ書いたのに何故か１個しか表示されない」とかなったら困るじゃん？）そしたら，１個にしたいなら１個だけ書けばいいんじゃない？　っていうのも極めて明瞭な事柄であろう． Text( LineNo ); //LineNo行目を表示するとか１個だけ書いとけばよくない？あとは LineNo の値を適切に変えていくだけだ．例えば既に回答されている仕組みをそのまま用いればよいので...

usao

まぁ具体的アルゴリズムとかまでは示せないけども，例えば，その図で三角形の左側の辺　と　四角形の上側の辺　との交点を求めたとき… その交点というのは，三角形の左側の辺の両端の頂点のうちのどっちと繋がるのか？　というのは判断できるハズ．（例えば，図形の各辺に「図形の外側」を向くような法線でも与えておけば良いんじゃないかな．この例だと四角形の上辺の法線が向く方向にある側の頂点：「四角形の内側に切り取られない側」にある頂点　を選ぶ感じか．）同様に，この頂点が四角形の上側の辺の両端の頂点のうちのどっちと繋がるのか？　もわかる． …んじゃないかな？　という話．（つまり，この交点は，三角形の上側の...

usao

言い換えれば，「その図の(3)の赤い点群から出発して(6)の処理がやれないのだろうか？　という疑問」…になるのかな？ --- それはそれとして（点群を「つないで」外周みたいなデータを作る必要があるのだとして），「交点」を求めているときに，それは「どの辺とどの辺との交点なのか」というのが分かっているハズだから，そこから，「その求めた交点と隣接する点というのはこいつとこいつだよね」っていう話が既知だと言えるのではないかな．例えば，三角形が A→B→C(→A) っていうグラフで四角形が a→b→c→d(→a) っていうグラフであるとわかっているところから出発したのだとして，あるとき（そ...

usao

すぐに（三角形に）分割するのなら，そこで一旦つなぐ意味って何になりますか？

（【ばらばらの点群　→　何故かつなぐ　→　すぐにまたばらばらにする】という話だとしたら中間のステップって要るんですか？　という素朴な疑問．）

usao

> 「ある文字」を「新しい文字」に変えることは出来ましたということは「ある文字」は「消せた」のでしょうから，全く同じ手段を用いて「新しい文字」も消せるのでは…？リンク先では if (GetNowCount() - startTime < 2000) { // まだ2秒経っていない DrawString(50, 50, "ある文字", color); } else { // 2秒経った DrawString(50, 80, "新しい文字", color); } ってなってて，「新しい文字」は２秒経過して以降ずっと表示しているのでしょうから，「新しい文字」の側にも何かしらの条件を付ければ良...

usao

オフトピック

直近にそれっぽい話題があるみたいだけど．
viewtopic.php?f=3&t=21492

usao

オフトピック

> int_aesを用いてtest2.cを分割

っていうのも日本語として意味不明と思える．

「そのくらい察しろ」とか「わかるだろ」とか思ってると，読み手の推測が外れた場合に誤解に基づいたやりとりが繰り広げられることにもなりかねない．
「相手の読解力に過度に期待した結果，無意味なやりとりで時間と労力を費やすことに…」とかいう事態を防止するために，最初から話を明瞭に書いた方が良いと思うよ．

usao

とりあえず行数だけしか見てないけど
元のソースファイルと，それを単に分割したハズの(?)ファイル群の行の総数が激しく違うのは一体何が起こっているのかさっぱり．謎．
「分割すればコード量が激減！」なんてことが起こるとも思えないし，何か話の根本が見えない感じ．

usao

リファレンスで見比べたらいいんじゃない？
https://dxlib.xsrv.jp/dxfunc.html

usao

> 1.デバック時のエラーはVisualstudioのアップデートでも解決することがあるのか

アップデートの内容（それっぽい何かが修正されたのか否か）について調査してみてはどうでしょう．
https://docs.microsoft.com/ja-jp/visual ... ease-notes
あたりで？

usao

> 上手く働かなくなってしまいました

という言い方から察するに，「以前は上手く働いていた」のだと思われるので，
その時の状況と見比べてみてはどうですか？

とりあえず提示された main() 関数を見た感じ，
値が不定な変数の値に関するチェックが書かれているので「まぁダメだろうな」という感じですが…

関数群の雰囲気から，変数のスコープとかそういう根本的な話が分かってないようにも見える．
例えば
char digitChar;
なるローカル変数がいくつかの関数に存在するけども「そいつらは互いに全く無関係な別々の存在である」ということは大丈夫なのかな？

usao

オフトピック

挙動部分を自前で実装する場合，それ系の実装経験が無い場合には，最初はとりあえず２Dでやってみるステップを経た方が良いのかも？
（例えば真横から見た感じで　サイコロは正方形，茶碗は折れ線で定義　みたいな）

usao

そのライブラリの３D関係のリファレンスをざっと見た感じ，表示することに関してはまぁやればできるんじゃない？　っていう雰囲気．（どの関数を使えばいいのかまでは知らんですけど）サイコロを「それっぽく」動かすことに関しては，列挙された関数群の範囲ではサポートは無さそうに見える．どこまでの物が必要なのか次第だろうけど，物理シミュレーション的な方向に行くなら，何か使えそうなライブラリを探すなり，自前で実装するなりする方向になるのでは．「そのライブラリを使って」という前提　＋　「３D」　っていう話だと，それそのものを触れたことがある人の話を聞けた方が有用であろうと思うので，そのライブラリを配布...

usao

気になって検索してみた感じ，バージョン毎の言語の準拠が書いてあるところで，"VS 2022 17.0" という記述が見られるので，何かしら違うのかな？
（個々の項目の中身が何なのかまではわからん/見ていないですが）

usao

オフトピック

「結局何かしらのライブラリを使うっていうなら，最初からそれで始めればいいだろ」という意見も十分あり得ると思う．
そっち方向の話は他の誰かに期待！

usao

> 一度は Win32API+GDI な枠組みでやってみるのが勉強になるんじゃないかという雰囲気でGDIを挙げているので，「GDIでガチる」んじゃなくて，勉強目的で触れてみるのだ，というスタンスで軽い気持ちで(?)やってみるのが良いと思う．例えば，STGなら操作する機体とか敵とかを「画像ファイルを読み込んでそれを表示するぜ！」とかしているとそれだけで割と辛いハズなので，「とりあえず四角とか丸で表せばOK」くらいでやるといい．そういう表示部分はゲームの内容の実装とは本質的には無関係だし，表示に凝りたくなったらそれこそ別のライブラリを使う方がよい． --- っていうことをとりあえずやってみる...

usao

違和感が無かったゲームの動きを実際に見て（プレイ環境が無いなら，動画を探すとか？），ご自身のプログラム　と何が違うのか？　というのを探してみると良いのかもしれません．

マリオやロックマンといったゲームでも

> プレイヤーが常に画面中央

だっただろうか…？　とか．私も正確には覚えていません．
ひょっとしたら「遊び幅」（：画面中央のある幅の中ならばスクロール無しでキャラクタが左右に動くみたいな）があったのかもしれません．

usao

オフトピック

あと，ちょうど直近でこんな質問があったけど，
ちょっとした算数/数学が（プログラミング以前の前提知識として）必要だと思う．

usao

> 有名なfor構文やwhileループなどは知っていますが、それ以上の発展的な文法は知らない状態です。 C言語自体について言えば，ループが書ける段階から先に何かあるか？っていうともうほとんど無いような…？ C言語の文法的要素って・型，変数（スコープ，生存期間，宣言と定義とか）・配列・関数・if, swich とかの分岐・for, while とかのループ　←　いまこのあたり・ポインタ・構造体・共用体　←　個人的に，コレは本当に必要になるまでは知らなくてもＯＫじゃないか？とか思う．みたいな．（順序に多少に前後はあるかもだけど，大抵，それ系の本の目次とかもこんな感じじゃない？）...

usao

効率の良さについては何とも言えないけども，結局のところ【必要なこと「だけ」を１つずつやっていく】ということになるかと．「C言語」自体の文法はかなり小さいので，「C言語を学ぶ」というよりは，あなたがゲームを作るために使う枠組（：ライブラリ．下記）に振り回されたりとか，そういうあたりに苦労があるのではないかな，と想像します． --- 「C言語」だけだとウィンドウを出したり絵を表示したりという機能が無いので，そういったことをするための手段として何を使うか？　を何はともあれ模索する/決める必要があるかと． Windows上なら，一度は Win32API+GDI な枠組みでやってみるのが勉強になる...

usao

それはそれとして，（「一般的」とか「セオリー」とかいわれると私は知らんのですが）ごくふつーに(?)考えれば

> 「リフトの移動量」+「プレイヤーの移動量」

で良いと思います．

あなたのいう「カメラのスクロール」というのが何なのか/違和感に関してどのような影響を与えているのか/etc は不明ですが，
プレイヤー vs 背景（：リフトと関係ないもの）の観点で見てやれば妥当に見えるのではないでしょうか．

usao

この例で言えば

初期位置 P(0)
「前方」なるベクトル F
「右方向」なるベクトル R （※別に「左」でやってもいいけど）
「前方」に進む速度 Vf
sinカーブの位相の進み具合を決めるための係数 k

くらいを用いた，時刻 t における位置 P(t) に関する式を書けるであろう．
これはプログラミングとは関係なく純粋に数学の話．
まずは落ち着いて，こういう所からやるのがよいかと．

コレみたく解析解が得られる話だとわかれば，差分法でやる必要性も（おそらくそうする利点も）ないだろう，ということも見えるので実装方針も立つかと．

usao

「東方なんたら～」とか言われてもそれを知らない人には通じないので，きちんと自分の言葉で所望の挙動を説明されたい．これは他者に話が伝わるか否かだけでなく，自分自身の中で具体的/詳細に物事を捉えるのにも必要なステップであると思う．（自分の中で　漠然としたもの　は実装できないよ．細かくかみ砕いて細部まで具体化しないと．）例えば弾がX軸に平行に右向きに撃ちだされたとしたら，時間と共に右の方向に動いていくんだけども，それだけではなくて，上下方向にある振幅でsin関数な動きもしてほしい …みたいな話なのだろうか？（文章後半を読んだ雰囲気から想像）仮にそうだとしたら，コレを弾自身から見た話とし...

usao

ちょうどこちらでもそういう感じのを書いて確認作業みたいなことをしていたので大丈夫です．
メンバ初期化子ならそのまま && が伝播する感じで(?)いけたりするのかな？　とか実験してみましたが，やはり move 必要っぽいですね．

質問内容とは無関係な事柄ですが，質問内でのやりとりがきっかけとなってこういうあやふやなところが明確になる機会が得られているので，ありがたいことです．

usao

コード:

//こんな関数があったとして…
void F(){  printf( "F" );  }

int main()
{
  void F();  //関数F()を呼ぶための記述はこうじゃねぇよな，っていう．
  F();  //こうだよね．
  return 0;
}

usao

main関数内に書いてある

> void TIKAWA_Initialize(); // ロードする

という記述では関数呼び出しになっていない．（関数の宣言になってる）
他の関数についても同様．

つまり，分割コンパイルの問題ではなくて，単純に関数呼び出しの文法に関する問題．

usao

※言うまでもないけど，私のコードは完全に固定配置なボタン群のみを想定している．
ボタンが途中で増えたり減ったりとか，場所が動いて配置関係（：フォーカス的な意味での）が変わったりし得るのであれば，私の書いたやつじゃ全然ダメ．

usao

> Builder を利用しているのはなぜなのでしょうか？完全に気分です． (1)「ButtonContainer 自身にAddしていく形」だと，「中途半端な（データが全部揃ってない）状態の ButtonContainer が存在するタイミング」があるのがなんか嫌な気がした．（まじめにやるなら，各Add後の状態が常に大丈夫な形になるように実装せねばならない←面倒） (2)「全てを揃えてから BottonContainer のコンストラクタに入れる」という形だと，コンストラクタが要求する形のでかいデータを作る必要が出てきて，これもなんか嫌だなぁ，と．（→Add みたくやりたい）・IDが自動...

usao

ButtonContainerの保持データの注釈

コード:

//ボタンと，各ボタンからの４方向のフォーカス移動先．（移動先の値は m_Data のindex）

に不足があったので念のため補足：

（Builder側の実装を見ればわかるけど）
「４方向のフォーカス移動先」データの値は，その方向の移動先が存在しないことを負の値で表す．

usao

この辺↓の move 関係の文法は怪しいかも…
「それはこう書くんだよ！」とかある場合には突っ込んで（というか教えて）いただきたく^^

コード:

ButtonContainer( std::vector<   std::pair< std::shared_ptr<Button>,  std::array<int,4> >   > &&Data, int iCurrFocus )
		: m_Data( std::move(Data) ), m_iCurrFocusButton(iCurrFocus)
	{}

usao

雰囲気書いてみたっす．（↓のmain() の記述でしか動作確認してないけど）ボタンの隣接関係の登録時には「ID」という値で指定． ↓ コンテナ自体は単に自身が持つ vector の index 値で全ての情報を保持． //ボタン．※ここでは単にTextを持つだけ． class Button { private: std::string m_Text; public: Button( const std::string &Text ) : m_Text{Text} {} const std::string &Text() const { return m_Text; } }; //「コンテナ...

usao

オフトピック

移動体の上に載ってるときには移動体の移動速度がキャラクタに作用するのに
そこでジャンプした瞬間にその作用がゼロになるゲームも多い気がするので
そこらへんのルールは「ゲーム内容に合うもの」で良いのでは．

物理的な正しさ(?)方向にこだわると，「落下中のリフトから飛び移る」とかすっごい難しくなる気がしますし．

usao

…なので(?)，本件に関して言えば，私ならまずは方法２側を考える．
ボタンの集合を配下に持つ「フォーカスという話を解決する者」（コンテナ）を用意するという意味で．

フォーカスの移動先に関する具体実装は

> 上下左右のボタンをポインタ

という形でも何でもいいけど，それはボタンに持たせるのではなくて，コンテナ側が勝手に持つデータ構造．
（その構造をどうやって作り上げるのか？　という話はそれこそ具体実装そのものでしかないので，最も実際の用途に見合う形でやる）

usao

Sorry．私は　GUIライブラリの具体実装　を知る者ではないです．（単に「自分ならこうするかもな」的な話を好き勝手に書いているだけの素人です．GUIについては専ら何かを「使う」だけの側．） #14 は，自分だったら「ボタンはコンテナの存在とかフォーカスがどうのいうようなことを可能な限り知らなくて済むようにしたいかなぁ（そんな形になんとか持ち込めないかなぁ）」と考えるかな，っていう話で，おそらく > 「ボタンのフォーカスの移動のためだけのコンテナ」と「ボタン」との間に密接な結合が生まれるのも嫌だという感情と同じ/似ている感覚であろうと思います．例えば，単一のボタンだけがあれば済む場...

usao

作り方次第だけど，ボタン自体は「フォーカスを別のやつに変える」という話を知らなくても良いんじゃないかな．入力情報が上から降りてきたとき，「コンテナ」はその入力がフォーカス移動操作になるのか否かだけを判定して，そうだったらフォーカス変更の処理をする，そうじゃないなら現在フォーカスを持っているボタンに入力情報を渡してボタン固有の処理をさせる，みたいな． …そんな感じで，フォーカスがあるボタンだけに処理機会が回ってくるのであれば，ボタン自身はフォーカスという概念自体を知る必要も無さそうな気がします．（例えばフォーカス有無で描画具合を変えるのだとしても，枠を付けるくらいならコンテナ側でそういう追加...

usao

Block::sprite の初期化をなぜそんな形に書くのか？という意図/理由/効能(?) みたいなのがわかりませんが…
その初期化が成されるタイミングの面に問題はないのでしょうか？
（そのライブラリには全体的な初期化みたいなのが必要だったかと．それより前のタイミングになってたりしませんか？）

usao

オフトピック

「お前の話はズレすぎている．そういう話をしているのではない」とか
「正直話のレベルが低すぎて応答するだけでも面倒だから無理して入ってくるな」だとか
そういう場合には遠慮なく言ってください．
そういう反応を割りと良くもらう人なので大丈夫です．

usao

方法２に関する > （GUI コンテナとして実装する場合、invisible なオブジェクトであるのに GUI 関連として実装するのはどうなのか...逆に関係のないものとして実装するとそれはそれで実装が分散して嫌な感じ...）という話の内容がよくわからない．（そもそも私が不勉強なのか「GUIコンテナ」なる単語の意味がいまいち不明．標準的に通じる言葉なの？）「ボタンの集合もまたGUIなのだ」というCompositeパターン気味な(?)話では何が｛実際に問題になる/しっくりこない/嫌/etc｝なのか？ GUIって入れ子な階層構造になってるのが「一般的」な気がしますが．いわゆる Window...

usao

> 私が聞きたいのは実装の具体的な内容ではなくということだが，行われているのはかなり具体的な実装な話に見える… という観点（実装の違い）で見れば，方法１と２の違いとは「グラフのノード自身が連結（枝）に関する情報を保持するか否か」と見える．見当違いであろうか？連結リストの実装で例えるならば struct Node { Data data; //リスト構造で保持したいデータ Node *prev; //前のノードを指す Node *next; //次のノードを指す }; みたいなのが方法１の話で， std::list<Data> とするのが方法２の話，という感じ．

usao

オフトピック

> なぜ、最新版である VisualStudio2022 でないのか ?
> PC のスペックが低くて、VisualStudio2022 が動かない、というのであれば、その PC は、プログラミング初心者がゲームを作るのには向かない。

個人的には全然そんなふうには思わないが……
何かしら最新版じゃなきゃやれないことをやるのなら違うだろうけど．

usao

話の前提がよくわかんねぇけど，要は，平面上に点群があるときに，ある点から見て最も「右隣りな」点っていうのはどれだろう？　っていうだけの話に見える．であれば，点間の相対的な座標関係から「右隣っぽさ」をてきとーに評価し，閾値以上の評価値を持つ最もそれっぽいやつを右隣だということにすれば良いのでは．で，その演算を毎度やるのが重いのであれば，どこかのタイミングで求めた結果を覚えておく感じで．例えば， > 上下左右のボタンをポインタとかいうのに結果を記録しとけばよい． --- どうでもいいけど， > 一般的な実装方法なのでしょうか？みたいな問い方は，非常に敷居が高いものになるんじゃない？「コレ...

usao

> VisualStudio2019で

だけでは情報不足．
どんな言語でどんなプロジェクトの種類でどんなライブラリを使ってるとか，そういうの次第かと．

逆に言えば，そういった言葉と一緒に「マウスカーソル　座標　取得」みたいな検索ワードでググれば何かしら見つかるんじゃない？

usao

オフトピック

何やら別の質問も「テキストファイルで寄付がどうの」とか言ってやがるな．
大流行なのか？

usao

まぁそれはそれとして，取っ掛かりとしては，【ある固定の「寄付コード」についてのみ「donation.txtファイルから特定の寄付の既存の数量を照会する」ことができるプログラム】あたりを作ってみることから始めてはどうですか？今書いている scanf だの strcmp を用いたif だのいうのはまずは忘れて，例えば【紹介すべき「寄付コード」とは "CT" である！！！】っていうのを作る，っていう．（それができたら　固定　にしていた部分を　入力されたもの　を使う形にするだけで終わる） --- 前記「取っ掛かり」を作る時点で躓くのであれば，その躓く内容についてのみをどこぞで質問することもでき...

usao

あなたの文面だけを情報源としている我々には > 寄付コードを使ってdonation.txtファイルから特定の寄付の既存の数量を照会するオプションとかいう何かが具体的にどういうものなのか？を知る由もありません．もちろん，あなたが書いてみたというコードに関しても，求められている物にたいしてどれだけ近いのかも不明です．せいぜい，fclose が怒涛の勢いで書かれているのをぱっと見した時点で「コーディングに関してはほぼほぼ何もわかってなさそうだな」くらいのことを想像できるだけです．【学校で尋ねた方が早いでしょう】というのが，現状では最も真摯なアドバイスだと思います．というのは，このような「他...

usao

> 貴重なアドバイス

っていうのはどの部分のことなん？
コレ↓だとしたら「計画が年単位になってしまいます」という点が何も変わらんし…？？

> おとなしく高校に 3 年間通えばいいだろ。理系のコース選べよ。

usao

オフトピック

そういや，大昔にこんなのやってましたね．
（そのとき貼ったソースは「zip がどうの」とかで失われているようだが）

usao

> Windows APIで、ウィンドウを作成し、…（中略）… 可能な気がしてきました。

そういうことを一度はやってみると良いだろう，と思います（何ならワイヤーフレームでも）．
実際の（本番の?）3DなAPPを作る際には何かしらのライブラリを使うとしても．

（理由は既述した通り，ライブラリを使うにしてもそのこと自体，行われる演算とかの内容を何も知らない状態でやれる話ではないと個人的に思うから）

usao

オフトピック

画像を表示する手段を用意することが厄介な場合，
表示手段自体はprintfとかでもなんとかなるかもしれません．
あるいはてきとーな形式の画像ファイルに出力する（そしてそれを画像を見れるソフトで確認する）といった形に割り切ってしまうならば，表示系も不要．

usao

というわけで，目的は「各ピクセルを何色にするか」っていうのを2Dな絵の全ピクセルについて決定する（計算する）ことですから，それを実際にどうやって計算するのか？　という話（アルゴリズム）を実装すればよいです．

「レイトレーシング法」　とか　「Zバッファ法」　とかそういう話をググれば，3Dグラフィクスに関するそのあたりの処理の雰囲気が掴めるのではないでしょうか．
光源を意識した色の決定方法（シェーディング）については「スムーズシェーディング」とかでググれば，フォンとかグーローとかそういうのが見つかるでしょう．
視点の位置だとか遠近感（透視投影）だとかいう話は純粋に算数/数学の世界です．

usao

難易度については，何を実装するか次第でしょうけど

描画できるものは三角形のポリゴンのみ
使える光源は１個のみ
処理速度はまぁ気にしない方向で

とかそういう制限された物であれば難易度はかなり低いでしょう．

OpenGL みたいなのを使うにしても，3Dな各種事柄を何も知らずに使えるような物ではなくて，そういった素朴な3D描画のコードであれば自前で書けるくらいの知識は必要な気がします．
（ライブラリを使うにしても，シェーダのコードを書くタイプなら，そういった演算そのものをプログラマが書く必要があるのだし）

usao

（全部CPU上でやると処理が厳しいとかそういう話を度外視するならば）可能でしょう．

少なくとも何かしら「絵を表示する手段」が必要ですよね．
で，とりあえず2Dな絵を表示するための何かしら存在するのであれば…
プログラムが扱っているデータの概念が3Dであろうが，最終的な絵というのは2Dなのですから，2Dな絵を（いろんな必要な計算をした結果として）作り出すコードを書けば良いです．
そしたらその作った絵を2Dな絵を表示する手段で表示する．完遂！

…っていう話になるかと．

usao

オフトピック

> 経験者のアドバイス

を得るには，何はともあれ「経験者」の目にとまる必要があると思うので，
とりあえず「過疎ってない箇所」でやることを考えた方がよろしいのでは．

（そういう都合の良い場所があるのかどうかは知らないけども…
ここって，誰かが書き込んだ質問に対して何かしらのリアクションを書いているのはもはや数人しかいなさそうだし．）

usao

オフトピック

結果/結論，というか，
「実際にこういう形で取り組んでみたところ，こういうところはやりやすかったけど，この点は苦労した」とか
何かそういう実経験談みたいなのが得られた暁には，それを書いていただきたい．

特に，「これこれこういうことがあるから，おまえが適当に書いてたような話だとかえって面倒なんだよ」みたいな話があったらうれしい．

usao

> ゲームプログラマではないから， > 経験者のアドバイスにはならないだろうけども，漠然とリストアップするよりも，必要なものを必要な分だけ学べばよいのではなかろうか，とか思う．ペーパーテストで点を取るのが目的ではなく，使うために学ぶのであろうから，漠然と「数学」を勉強するのではなくて例えば何かしらの（ゲームな分野の）処理を想定して，そこに必要な数学的要素を学ぶ，っていう感じで．例えば，３次元のグラフィクスを扱うことを想定するとしたら｛三角関数，ベクトル｝あたりはどう考えても必須であろうが，そこに「極限」とか「数列」とかいう話は多分出てこないだろう．そしたら，「極限」とかを漠然と勉...

usao

で，ご自身で取り組む気がある場合……

そこまでクソ細かく（あなたが考える余地がほとんどないほどに）物事が指定されているのですから，上から順にやっていけば良いだけの話かと見えます．
全部一気にやるんじゃなくて，１機能ずつ追加しては確認するという形でやっていけばよいでしょう．

usao

「宿題は自分でやってください」というテンプレな返しが欲しいのでないならば，
実際にあなたが取り組んでいて遭遇した解決すべき事柄に関する「質問」をしてください．

「何一つ自分自身ではやりたくないから，俺の代わりにこの問題に取り組んでコピペで提出できる物をよこせ」
という話なのであれば，何はともあれその旨を明記するべきでしょう．
（やってくれる人がいるかどうか？ってのはまた別問題ですが，話を明確にすることは必要でしょう．）

usao

あるシーンが「自分の上に別のシーンを積みたい」みたいな場合，それはそのシーンの内側で勝手にやれば良い事柄なんじゃないかなぁ．そういう場合，積む物というのは自身の担う作業領域の一部を切り出したような物になるのだろうし． //概念的な疑似コード class SomeScene { private: class ChildScene { ... }; ChildScene *m_pChildScene = nullptr; public: void Update() { if( m_pChildScene ) //「自身の上に積んでるもの」があれば { if( m_pChildScene->Fin...

usao

「解決済み」みたいなのは，ここには存在しない様子です． --- 個人的に，スタックの話は，「タイトル」とか「ゲーム」みたいな大きなシーンの流れに使うのではなく，もっと細かい箇所（例えば，複数段の選択を行うメニューみたいなのとか）の実装で活きる話かな，とか．あと，スタックに突っ込まれる側が「俺らはスタックで管理されているから～」とか知らなければならない実装形態なのであれば，苦しいように想像するなぁ．各シーンは，自身がどこかにあるスタックに積まれる経緯と別のシーンに遷移するために行うべきスタック操作を把握している必要があるんだよね？　コレ．外側の具体実装の都合でしかないハズの話がシーン内側...

usao

スタックで管理するのだとして，「別のシーンXXXに行く」というのが，

XXXをpushする
XXXが出てくるまでpopする

のどっちでなければならないのか？　っていうのを誰が判断するのだろうか…？
とか，そういう話がもっと先に書いてあるのだろうか？（私はわざわざ確認しないけど，とりあえず先の方を見てみたらどうでしょう？　ひょっとしたら，あなたの疑問点に関する説明もあるのかもですし？）

usao

…なので，

> 2.「あなたの GameScene 実装部からどこかにあるスタックにpopさせるにはどうすればよいのか」がわからない？

みたいな状況なのであれば，スタック（あるいはそれを管理している何か）にあなたがアクセスしやすい形で実装すれば良いのだし，

> 3. 「単にpopするだけだと TitleScene に戻らない」といったような問題がある？

みたいな状態なのであれば，単純に，その話ではあなたのやりたいことを素直には実装できない，というだけのことかもしれない．

usao

そういう話を参考にするときは，話の主たる内容（この話で言えば，「こいうのって，スタックで管理するという手もあるよね」っていう話）だけを参考にすればよいのであって，そこに示されている特定の実装例までをもあなたのコードに無理に取り込む必要はないと思うよ．あなたがやりやすい形で，必要と思う事柄だけを取り入れればよい．そしたらそんなに「？」は出ないんじゃないかな．例えば，そのリンク先の実装について，私は遷移先シーンの指定がemunとか言ってる時点でなんか嫌な感じがする… こんなのだと「異なるシーンに対しては当然異なるparameterが必要になり得るのだが？」という点をどうするのかが疑問...

usao

本当にpopすれば済む話ならばpopすればよいではないか，って話になるよ．
一体何が問題なのか？　というのを具体的に述べないと．

「popとは何か」がわからない？
「あなたの GameScene 実装部からどこかにあるスタックにpopさせるにはどうすればよいのか」がわからない？
「単にpopするだけだと TitleScene に戻らない」といったような問題がある？
その他？

usao

異なる意見/考え方　が書かれていた方が何かの参考になるかもしれないので，書いてみる． > ・引数付きコンストラクタ… 「書くのが面倒」とかそういう話ではなくて，「どうしてそうするのか？」という理由/必要性の観点から考える事柄かと．（個人的には，本件の「敵」みたいなのは，メソッドの引数として都度受ければ済むだけの話と見えるので，この形にする必要はないと思う．） > ・インスタンスの数×ポインター分のメモリがもったいないよほど切羽詰った環境でやってるのでもなければ，その程度のメモリ節約を理由とした設計を考える必要はないんじゃないかなぁ．グローバルな何かに依存する方向に持っていくというのは，...

usao

なにはともあれ「必要なものだけを書く」から無意味に逸脱しないこと　を心掛けると良いんじゃないかなぁ．「こういう形にしとけば　→　こういうこともできるよね」とかいう話があったとしても，その「こういうこと」をそもそもやる予定が無いのであれば，その形にすることを選ぶ理由にはなり得ない．特に，その形にすることに相応のデメリットが存在するようであれば，そのデメリットしか享受しないことになるのだから，その場合は選ばないのが正解であろう．「自分が今作っている物の範囲を超えた何かをもサポートできる（かもしれない）枠組み！」みたいなのを目指す意味は無い（そのこと自体が目的でないなら）．「べったり」でO...

usao

実装する前に，「どうすれば良いのか？」というのを日本語で具体的に説明してください（説明できる状態まで考えてください）．これは算数の話なので，プログラミングとは無関係です．で，それができたら，その話をその通りに実装してください．おわり． …っていうだけの話になるかと．例えば，話を少しだけ単純にして，「N以下の正の整数の総和を求む関数 F(N) があるとき，２つの正の整数a,b（ただし a<b）に関して，a以上b未満の正の整数の総和を求む関数 G(a,b) を F() を用いて書け」とかいう話だったらどうですか？ F(b) は b以下の総和． F(a) は a以下の総和．そしたら例...

usao

おまけ：これは完全に邪推(っていうのか?)だけども，もしも

コード:

class AbstEnemy : public Task { ... };
class AbsBullet : public Task{ ... };

みたいなことになっていて，「Update() は引数無し」という話がこういうところから生じていたりするのであれば，まずそこから考え直すと自由になるんじゃないかな．
すなわち，「こいつらって Task から派生する必要が本当にあるん？」っていう．
（さらには，「そもそもこの Task ってやつ，必要なの？」とか）

usao

> として、敵クラスでは特にインスタンス化せず引数として持ってくるのがいいのでしょうか。しかしこの場合updateはオーバーライドしてるので引数変えるなら大幅に変更が必要になりそうなのですが。（敵クラスが「インスタンス化」するという話は，何かを間違っている感を感じますが）実装形態に関しては好きな形でやれば良いでしょう．何かしら外部とのやり取りをせねば仕事をできないであろう update() が，あえて(?)「引数無し」にされている理由は私（というか，あなた以外）には不明ですから，どんな形が望ましいのかはあなたにしか判断できません．あなたにとって最もやりやすい形にするのが良いでしょう． ...

usao

> これだと結局インターフェースを継承しているクラス（ここでは弾管理クラス）が敵クラスで必要になっているのでは…と思いました。必要になってないですね．そういうのはコンソールアプリのプロジェクトでも作ってそこで小さい検証コードを作ってやってみればよいです．例えば，このような基底クラスを設けたとする． //Base.h class Base { public: virtual ~Base(){} //（テスト用なのでこの動作自体に特別意味は無いが，とにかく処理内容を以下のように規定する） //引数をコンソールに出力する． //戻り値として 77 を返す． virtual int Output...

usao

関数を提示するならするで
「この関数というのは何をするもので，引数はこういうもので，戻り値はこうなる」っていうような説明をまともにすればいいのに．
そういった正しい動作に関する説明が関数 moji() に対して存在していたら，こんな無意味に話がこじれたりしないよね，きっと．

（まぁ，それが把握できているならこんな関数名を付けてはいないであろう，とも思えるが）

usao

そこは言語文法の範疇なので，ここで素人説明するよりはまともな説明を見て学んでもらうべき事柄と思う．とりあえずものすごくざっくりと書いておくと， //なんか基底クラスがあって class Base {...}; //それをpublic継承したクラスがあるとき… class Deriv : public Base {...}; //これが可能 Deriv D; Base *pBase = &D; っていうことになってる．「継承」「仮想関数」「ポリモフィズム」「is-a」「静的な型/動的な型」とかいったような言葉を「C++」と絡めて検索するとかしても相応に必要な情報にたどり着くんじゃないかと思う...

usao

逆に言えば，「敵」がアクセスするのが実際のところ未来永劫 BullterManager である（つまり，そこには実装変更の自由度は要らない）ということが確定事項なのであれば，あえてそんなことをしなくても良いとも言える．

usao

「敵」から見れば，自身がアクセスする IXXX がとにかくその役割を約束通りに果たしてくれさえすればよいので，その相手は別に BulletManager じゃなくてもいい（ ← ここが変わる）．

例えば，「この BulletManager ってやってること少なくね？　別のやつにこいつの機能も持たせちゃえば要らなくね？」とかいう変更をして BulletManager なる存在が消滅したとしても敵の実装には全く影響が及ばない．

usao

> 結局どこかで弾管理クラスをインクルードしてこなきゃいけない

少なくとも，IXXX のメソッドを呼ぶ側（敵）は IXXX のクラス定義を必要とするから，
「class IXXX の定義が書かれたヘッダ」をインクルードする必要はある．
それは間違いない．

しかし，
「敵」から見れば IXXXのポインタが指す物が何なのか（：動的な型）は分からないし，知る必要も無いのだから
「IXXX を継承した BulletManager」の定義が書かれている BulletManager.h をインクルードする必要はない．
ここが違いとなる．

usao

で，それはそれとして，「敵」がやりたいことは「どこかが弾を管理しているから，そこに新しい弾を登録する（：管理下に置いてもらう）」なのであろうから，「どこか」が実際には何者なのかを知る必要も無く，例えば， class IXXX //名前は知らんが {//話と関係ない所は全て省略 public: //弾を管理下に登録する void RegisterBullet( std::shared_ptr<AbstBullet> ); }; みたいなのがあれば良い， ……っていうのが「インタフェースがどうの」いう話だよね．単純には，「敵」の Update() を //必要なら rXXX のメソッドを使っ...

		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

検索結果 1881 件