APIを使ってファミコンレベルのRPGを作成しようと思っています。ワールドマップ上を主人公が歩くプログラムを組んでみたのですが、ワールドマップをスクロールする時に若干引っかかるような違和感を感じます。ゲームプログラミングのサイトなどでは「ちらつき対策」としてダブルバッファリングが紹介されていましたが私の感じている「引っ掛かり」のような感覚について記載のあるサイトは見つけられませんでした。ワールドマップ用の非表示画面(デバイスコンテキスト?)が大きすぎるのか、bmpファイルが良くないのかまたは単にPCスペックの問題なのか皆目見当がつきません。スレッドの動作を再開し、終了させる。4年前ここで使われているGDIというAPIは、滑らかなアニメーションが苦手なのでゲームプログラミングにはあまり使われません。ほとんどのWindows用ゲームは、DirectXというAPIを使っています。DirectXはGDIと書き方が異なるのでこのプログラムをそのまま活かすのは難しいかもしれません。4年前DXライブラリなどを利用して頂くとWin32APIよりも楽に少ないコードで滑らかスクロールが実現可能かと思います。滑らかスクロールのサンプルです(1マスづつスクロール・サンプルの下にあります)。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。APIを使ってファミコンレベルのRPGを作成しようと思っています。グローバル文字列を初期化しています。4年前usaoさんがサンプルコードを投稿されてますが、肝はメッセージループで処理する部分ですね。ウィンドウプロシージャにごちゃごちゃとゲーム本編に関するコードを書くべきではないです。質問者さんはメイン処理をマルチスレッド化してますが、ごちゃごちゃする根本的な要因はここにあると思います。してもマルチスレッドにしなければいけないのでしょうか。GDI関連は同一のスレッドコンテキストで処理する必要があるので、どうしてもマルチスレッドを使いたいなら、画像リソース関連から描画まで含めたモジュール化を再優先で行うべきです。それができればウィンドウプロシージャのごちゃごちゃは解消します。その辺根本から変えていかないと、DirectX使っても同じだと思いますけど。DirectXが登場するよりずっと前から滑らかにスクロールするゲームはありました。Windows3.1でWin32s使ったゲームとか。GDIがゲームに向いてないから使われないというのはダウトです。DirectXが登場するよりずっと前から滑らかにスクロールするゲームはありました。Windows3.1でWin32s使ったゲームとか。GDIがゲームに向いてないから使われないというのはダウトです。GDIがゲームに向いてないというのは当然ながらDirectXと比較しての話です。現在の環境でGDIがゲームに向いてないから使われないのは事実です。GDIでゲームが作れないなどとは言っていませんし、比較での話なのでDirectX以前の話を引き合いに出しても意味がないと思います。APIでどうしても実現できない場合に、次のステップとして勉強しようかと思っています。includeするものが多くなってきたりすると私自身すぐ混乱してしまう事があるのでなるべく自分にとってブラックボックスというか呪文に近い部分を作らずに作成していきたいので。APIでは私には目的のプログラムが作れないと思った時は皆さんの仰るDirectXを使った書き方を取り入れようと思います。コメントありがとうございます。APIにこだわって作成したいと思っています。DirectXを使った書き方の中にヒントがあるかもしれないのでリンク先については拝見させて頂きます。APIの形に持っていけたら嬉しいので記載して頂いたコードは非常に参考になります。一読しただけでは意味合いを理解できないので内容については中身を熟読した上でコメントさせて頂きます。WM_CREATE:」内の処理がポイントになっていると思いますのでその辺りを重点的に読み込んで(出来ればこのコードに沿ったプログラムを動かして)自分のプログラムに活かさせて頂きたいと思っています。具体的なプログラムコードを示して頂いてありがとうございます。usaoさんがサンプルコードを投稿されてますが、肝はメッセージループで処理する部分ですね。ウィンドウプロシージャにごちゃごちゃとゲーム本編に関するコードを書くべきではないです。質問者さんはメイン処理をマルチスレッド化してますが、ごちゃごちゃする根本的な要因はここにあると思います。してもマルチスレッドにしなければいけないのでしょうか。すいません、基本が分からないもので教えてください。シーンによって(今ワールドマップを歩いている状況なのか、メニュー画面を開いているのか)処理は変わってきますので、その辺りの記述はプロシージャ内で処理するものと思っているのですがそれは間違っているのでしょうか?また、もしusao様が記載してくださったコードに関する事でしたら取り急ぎ返答してくれたコードですのでそのような細かな点の指摘よりも私のプログラムに転用できる部分が少しでもあれば質問者の私にとってはありがたい情報ですしそんな事は後でどうとでも修正できる内容かと思います。メイン処理をスレッド内で行っている事に関してはごちゃごちゃしているとは感じておりませんのでご安心ください。「引っ掛かり」が発生する要因になっているとも考えておりません。設計思想によるかもしれません。DXライブラリを使った時のようにメインループでキー入力をポーリングするプログラムを書きたいなら、プロシージャ(のキー入力に関するメッセージの処理を行う部分)には入力状態データの更新を行う処理のみを書くべきでしょう。イベントドリブンな処理を行いたいなら、プロシージャ、もしくはそこから呼び出される関数にキー入力の結果行われる動作を直接書くのは自然だと思います。今回のようにプロシージャ内にウェイトを含むループを書くのはおかしいと思います。代わりにするべき動作は、例えば「common->Character[0][0]と動く方向を設定した後、移動を行わせるタイマーをセットする」でしょう。オフトピック一般論として、思い込みは危険です。メイン処理をスレッド内で行っている事に関してはごちゃごちゃしているとは感じておりませんのでご安心ください。「引っ掛かり」が発生する要因になっているとも考えておりません。Win32APIで作れないわけではないです。面倒で作るのが難しいのが問題なのです。簡単な方法を提示したまでです。>includeするものが多くなってきたりすると私自身すぐ混乱してしまう事があるので>なるべく自分にとってブラックボックスというか呪文に近い部分を作らずに作成していきたいので。ブラックボックスを減らすと手間が増え、ややこしいものとなりがちです。DXライブラリは、Win32APIやDirectXのややこしい所をブラックボックス化することでシンプルに扱えるようにしています。ゲームを作ることに集中できるわけです。Win32APIの勉強をしたいのか、ゲームを作りたいのかで変わりますが、目的と手段は混同しない様にしてください。どちらが目的で、どちらが手段ですか?「補足」Win32API自体が既に20年の歴史を超えるレガシーなインターフェイスです。マイクロソフトは.NETなど何度もWin32APIを無くそうとしてきましたし、今後もチャンスが有れば表面から徹底的に隠すことは厭わないでしょう。Windows8がうまく軌道に乗っていたらWin32→WinRTとメインAPIが切り替わる予定でした。私はWin32APIに固執される理由は余り無い、どちらかと言うとしないほうが良いと思っています。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。4年前オフトピック>そうですね。Win32APIで作れないわけではないです。>ただ面倒で作るのが難しいのが問題なのです。4年前こちらでも論議されていますが、様々なことを理解しないとWin32APIではゲームを作る場合に支障が出ると思います。http://dixq.net/forum/blog.php?u=950&b=5617それらをほとんど解消できるならDXライブラリを利用するメリットは大きいと思います。Win32APIを使いこなしたいという理由が主たる目的であるならWin32APIを使うことは正しいと思います。ないなら、新たな学習コストを掛けたほうがバグ等の発生率や生産性で私は勝ると思っています。私のは視点はできるだけ容易にC言語でゲームを完成させることで、Win32APIを使いこなすことではありません。Win32APIのスムーズ・スクロールの追求は眼中にないと言えます。ゲームを作ることが面倒でもWin32APIの学習が主目的なら、私の意見は無視して頂いて結構です。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。APIプログラミングに集中したい、ということでしたら、わたしの意見は無視してください。わたしの投稿は、ゲーム本編を構成するコードと、ウィンドウズと対話するためのコードを、物理的に距離を置くことで、ゲーム本編のプログラミングと、ウィンドウズと対話する部分のプログラミングそれぞれに集中できる状況を作るべきだという提案です。キーリピート間隔で発生します。キーが押されたかどうかのフラグ変数を用意し、ウィンドウプロシージャのWM_KEYDOWNでフラグを立て、WM_KEYUPでフラグを寝かせるというのが常套手段だとわたしは認識しています。ウィンドウプロシージャの中に静的変数でフラグを用意したりなどはプログラミングスタイルとしてももってのほかそもそもウィンドウプロシージャはゲームと一対一に対応するとは限らないので将来に禍根を残すような先入観は排除すべきです。GDIを使うな、というのも固執しているように見えるのは気のせいでしょうか。GDIはDirectXやDXライブラリを使うより難しいのでしょうか。そもそもDirectXやDXライブラリを使えば解決する問題なのでしょうか。DXライブラリでCheckHitKeyとか使えば解決するでしょうけど、それでは回答になっていないのでは。こちらでも論議されていますが、様々なことを理解しないとWin32APIではゲームを作る場合に支障が出ると思います。http://dixq.net/forum/blog.php?u=950&b=5617それらをほとんど解消できるならDXライブラリを利用するメリットは大きいと思います。Win32APIを使いこなしたいという理由が主たる目的であるならWin32APIを使うことは正しいと思います。ないなら、新たな学習コストを掛けたほうがバグ等の発生率や生産性で私は勝ると思っています。私のは視点はできるだけ容易にC言語でゲームを完成させることで、Win32APIを使いこなすことではありません。Win32APIのスムーズ・スクロールの追求は眼中にないと言えます。リンク先で書いているとおり、GDIだから発生するという問題では無いので、DirectXやDXライブラリを使っても解消できない(できるとは限らない)というのがわたしの意見です。GDIを使っていて発生した問題なのだから、GDIを使ったまま解決すべき。なければ何が原因かを曖昧にしてしまうだけではないでしょうか。4年前オフトピックウィンドウプロシージャに原因があるとはっきりした途端にGDI否定派の方々はだんまりなのでしょうか。何も言わずに去るのは禁止などと質問者には厳しいのに、常連回答者の方々はあいかわらずですね。>質問者さんusaoさんのサンプルコードは、キーを押されているかどうかに関係なくスクロールするわけですがここに、ウィンドウプロシージャでキーが押されたかどうかを判定して、オン・オフの情報(だけ)をメッセージループ側に届けるよう仕組みを作ることになります。わたしが提案しているのは(最初から)そういう部分のことです。わたしの意見は要らないようなので、具体的な方法はあなたの信用する方に教えて貰ってください。他のひとが言うからと同じ内容の意見を容易に受け入れたりはしないでくださいね。そのような態度はあなたの人間性を貶めることになりますよ。4年前win32APIで2DスクロールRPGを作ったことがあります。0;}のようにしていました。引っかかりはありませんでしたよ。タイマー割り込みの中なので注意は必要です。このRPGはクリア時間20時間以上でしたが、特に問題はありませんでした。問題は解決と思います。4年前なぜマルチスレッドにする必要があるのでしょうか?ハンドルを作成したスレッドで制御や破棄をするべきで、他のスレッドがそのハンドルを触るべきではありません。コードを見る限り、この原則に反してますのでマルチスレッドにするのはやめた方がよいと思いますが。※この場合のハンドルとは、No.1のコードで言うHWND、HDC、HBITMAP、HANDLEなどすべてです。common->hOriginalDCはWinMain関数で作成してますが、このcommon->hOriginalDCを別スレッドMain関数で使用しているのは問題です。私なら絶対こういったコードは組みません。どんな不具合が出るか分かったもんじゃないしね。メイン処理をスレッド内で行っている事に関してはごちゃごちゃしているとは感じておりませんのでご安心ください。「納得してください」ならまだわかりますが、「ご安心ください」というのはなんか違う気がしましたが...気のせいだろうか?私の質問に対してISLe()様に「納得して」もらう必要はどこにも無いと思います。いうより、ISLe()様は「”私(質問者)自身が”、”コードを整理できていない(ごちゃごちゃしている)”からこれが解決できたら質問内容に対する問題ももっとはっきりわかるようになりますよ。」という意味合いでごちゃごちゃの根本原因について言及してくださったのだと理解しました。このコメントは私の質問に対する答えだからです。いう意味で”私は”ごちゃごちゃしているとは「感じておりません」と返答しております。「引っ掛かり」が発生する要因になっているとも考えておりません。(確かに今回の場合はMain関数にはほぼ初期化と片付けのコードしかないので、あまり関係なさそうだとは思いますが...)みけCAT様が既に仰っているとおり、Main関数では入力に対するコードは記載しておりませんしMainスレッド起動およびその起動確認以降はメッセージループの処理しか行っておりません。「根拠をもって」というのはこれ以上の根拠が必要ですか?必要だと思っているのはただの勘ですか?私の考えも「ただの勘、もしくは思考停止ですか?」と言われれば強く否定できません。自分なりの根拠を持って判断した事を以って「ただの勘」と言われるのであればコミュニケーションの大部分は「ただの勘」になるでしょう。(これも私のただの勘ですが)また、考えが間違っていて、その間違いが質問の解決を妨げているのであればそこを追求して頂けるのは質問者として非常に助かりますが現状みけCAT様の発言の意図を掴みかねている状況です。どちら(あるいは両方?)なのでしょうか.確かに私の書き方ではこの部分の詳細が不明でした。今回の質問は前者の方です。それにしても、現状「WM_KEYDOW」の発生タイミングについてはあえて無視(というか今回の件とは直接関係が無いと思って確認を後回しにしていました)していたので、もしかしたらこの辺りが悪因になっているような気もしてきました。優先順位は高くはないと思っていますが、発生タイミングについては確認しようと思います。Win32APIの勉強をしたいのか、ゲームを作りたいのかで変わりますが、目的と手段は混同しない様にしてください。ファミコンレベルのrpgを作る」両方目的です。優先順位としては1の方が高いです。自分には難易度が高すぎると判断した場合は1を取り下げて「別方式のコードの勉強」を目的に切り替える事もありえると思っています。「目的と手段は混同しない様にしてください。」と仰いますが今行っているプログラムは趣味ですので、私がやりたいと思ったことがすなわち目的です。APIで作りたい」と思った時点でこれも目的に含まれます。Win32API自体が既に20年の歴史を超えるレガシーなインターフェイスです。マイクロソフトは.NETなど何度もWin32APIを無くそうとしてきましたし、今後もチャンスが有れば表面から徹底的に隠すことは厭わないでしょう。Windows8がうまく軌道に乗っていたらWin32→WinRTとメインAPIが切り替わる予定でした。私はWin32APIに固執される理由は余り無い、どちらかと言うとしないほうが良いと思っています。それは知りませんでした。書きにくくなる)というのは少しショックです。今のところ他の方法に切り替えるつもりは御座いません。そもそもウィンドウプロシージャはゲームと一対一に対応するとは限らないので将来に禍根を残すような先入観は排除すべきです。勉強不足ですいません。ウィンドウプロシージャの中に静的変数でフラグを用意する事を避けるべき理由は何なのでしょうか?また、ウィンドプロシージャがゲームと一対一に対応しない場合というのはどのようなパターンがあるのでしょうか?上記は私にとっては初耳なので、コードの記述方式を変更すべきと判断する可能性が浮上してきました。説明が面倒であれば、その辺りに触れているサイトなど教えて頂けると助かります。GDIを使っていて発生した問題なのだから、GDIを使ったまま解決すべき。なければ何が原因かを曖昧にしてしまうだけではないでしょうか。私も基本的には、現状発生した原因を特定して、これを回避した記述方法を模索したいというのが希望ですが「そうは言っても別の手段を採った方が良いよ」というのも私にとっては大切な意見ですしなにより当初の希望では私には無理と判断した場合の選択肢を広げることにもなりますので私の前提を超えるコメントをして下さった方には非常に感謝しておりますしこの掲示板としては特に問題ではないと思います。ISLe()様のコメントも私の知らない情報が多数あり凄く感謝しています。ウィンドウプロシージャに原因があるとはっきりした途端にGDI否定派の方々はだんまりなのでしょうか。何も言わずに去るのは禁止などと質問者には厳しいのに、常連回答者の方々はあいかわらずですね。ここに、ウィンドウプロシージャでキーが押されたかどうかを判定して、オン・オフの情報(だけ)をメッセージループ側に届けるよう仕組みを作ることになります。わたしが提案しているのは(最初から)そういう部分のことです。わたしの意見は要らないようなので、具体的な方法はあなたの信用する方に教えて貰ってください。他のひとが言うからと同じ内容の意見を容易に受け入れたりはしないでくださいね。そのような態度はあなたの人間性を貶めることになりますよ。ISLe()様の意見が要らないという風に伝わってしまったのであれば本当にすいません。私は誰からのコメントも拒絶するつもりはありません。基本的には今のところMain関数からMainスレッドを起動し、ゲーム構成の大部分はここで記述し、メインループでは入力に対する応答を記載しようという大枠を変えるつもりはありません。(Sleepを使う場合など、コールバック関数内でも必要に応じてスレッドを起動すべきかもしれないとは思っています)”今のところ”というのは、このやり方が致命的に問題の解決を妨げているとは”今のところ”考えていないからです。今後の議論や試行錯誤の中でこの考え方は変わるかもしれませんし、それがISLe()様が初めから仰っている事と同じ事になる可能性は否定できませんがそれは現時点では私が理解できていない事に起因するためです。言い換えれば”同じ内容の意見を受け容れる”可能性はありますが”容易に”に対しては”私が理解・納得できれば”という前提が入ります。変数を宣言しなくても済みそうですね。個人的には入力に対応したタイミングで描画させたいと思っていたのですがコメントを読んでいると入力に関わらず所定の時間間隔で描画するのが一般的なようですね。どちらにしても、教えて頂いた関数は凄く使いやすそうなので参考にさせて頂きます。ありがとうございます。様ご指摘ありがとうございます。スレッドをほぼ同じレベルで扱っているのはよろしくないのかもしれませんね。マルチスレッドにする必要性があるかどうかは良くわかっていません。思想としては、メインループはただただ入力を待つだけにしたかったというところです。行為なのでしょうか?勉強不足で申し訳ありませんが教えてもらえると助かります。ゲームプログラミング」をキーワードにネットを検索してみてはいかがでしょう。回答者個人の意見に傾ける耳はなくとも、検索して見付けたサイトがみんな同じ書き方をしているなら、それに倣おうという気も湧くのではないでしょうか。ところで、へにっくす様が仰る原則を守る場合、スレッドを起動する前に作成されたウィンドウへの描画にはスレッド内では行えない事になってしまうように思うのですが、この考えは正しいですか?はい、その通りです。別スレッドで起動しているMain関数で使わないでください。1つのハンドルに対し複数のスレッドが使うタイミングを全然考慮していないですよね。たとえるなら1つのキャンパスに複数の人がいろいろ絵を描画しようとしてるのと同じですよ。制御する方法を知らないのなら使わないことです。マルチスレッドにする理由が「メインループはただただ入力を待つだけにしたかった」というのでは私としてはNGです。入力に関わらず所定の時間間隔で描画すると、RPGだとすると、海辺の波とか、川面とか滝、そう主人公の足踏みとか、動かせるよ。ところで、へにっくす様が仰る原則を守る場合、スレッドを起動する前に作成されたウィンドウへの描画にはスレッド内では行えない事になってしまうように思うのですが、この考えは正しいですか?はい、その通りです。別スレッドで起動しているMain関数で使わないでください。1つのハンドルに対し複数のスレッドが使うタイミングを全然考慮していないですよね。たとえるなら1つのキャンパスに複数の人がいろいろ絵を描画しようとしてるのと同じですよ。制御する方法を知らないのなら使わないことです。同一のスレッドコンテキストで処理する必要があるという話はわたしがNo.6で既にしてるんですよね。ハンドルの扱いとかあちこちに散らばってごちゃごちゃしている(これからもっとひどくなる)からまず根本的に対処すべきと。それに対して、質問者さんはNo.8で、ごちゃごちゃしてないし不具合の原因にもなってない、という返答をしていらっしゃいます。ウィンドウメッセージはそのウィンドウを作成したスレッドに対して投げられるのでウィンドウを作ったスレッドごとにメッセージループを回さないとウィンドウプロシージャが回らない。#ウィンドウはウィンドウを作成したスレッドのコンテキストと結ばれる。ウィンドウから取得するデバイスコンテキストはとうぜんスレッドに依存する。デスクトップは普遍ではないので、デスクトップにコンパチなハンドルはデスクトップが変化したら作り直さなければいけない。同様の理由でデバイスコンテキストは必要なときに作って(要求して)使い終わったらすぐに削除(解放)する。ビットマップはDIBであればデスクトップ(というかデバイス)に依存しない。Win32で作るならダイアログや子ウィンドウを使うのも自然だろう。子ウィンドウのメッセージが親ウィンドウのウィンドウプロシージャに流れる場合もある。上記したスレッドウィンドウのコンテキストの関係も影響する。ウィンドウプロシージャとウィンドウは一対一でないし、ゲームコンテンツはウィンドウとすら一対一でない。ふつうに長年Win32でウィンドウアプリ作っているひとでも知らないことが多いと思います。ゲームプログラムというのはいろんな制約に引っ掛かりやすい。いえ、ゲーム本編部分の独立性を高めることを意識してコードを書いてさえいれば、制約の影響をほとんど受けないし、GDIだのそうでないだのなんてことも些細な問題です。イベントドリブンやマルチスレッドはいまでもふつうに使われるので、そういうものの扱い方をいまのうちに覚えておくのは悪くない。Win32についてさらに詳しいことを知りたいのなら、インサイドウィンドウズなどの技術書を読み込んでください。そこまでウィンドウズの中身を知らなくても、ゲーム作る上での作法としてのレベルで知ってれば十分だとわたしは思いますけどね。質問者さんは、わたしなどとても及ばない頭脳をお持ちのようなので心配なんてしませんよ。質問者さんがわたしを信用するかどうかは質問者さんの自由なのと同じくわたしが質問者さんを信用するかどうかはわたしの自由です。それが対等ということですよね。この掲示板に対しても以前から主張していることですが、わたしの興味対象はトピックの中身です。わたしはトピックの主旨に沿った情報を含む投稿を心掛けています。それ以外の部分にばかり目を向ける方が跡を絶ちませんがね。hMapDCのサイズが大きすぎた事が原因だったようです。スクロールするたびにhMapDCからhOriginalDCにコピーしていましたがhOriginalDCより周囲1マス分大きいデバイスコンテキストを用意してスクロールはここからhOriginalDCにコピーするようにしました。ご相談に乗って頂いた皆様ありがとうございました。様ISLe()様の仰っている事は私にはレベルが高すぎるようです。コミュニケーションが取れる程度のレベルがあれば良かったのですがそれも適わないようで残念です。先ほど解決したと書きましたが、もう一度起動して動かしてみるとやはり引っ掛かりとチカチカするような感じがありどうやらマップサイズが原因ではなかったようです。皆様から頂いたコメントにまだ試していない方法がいくつもありますので、理解できる部分から1つずつ実効して確認していきたいと思っています。下記1、2のようなプログラムを作りたいという思いがあり、この条件を満たすような解決方法に辿り着けるか不明ですがもし解決したら原因を報告させて頂きます。(既に解決済みにしてしまっていますので質問を重ねる事は控えます)1キー入力があった場合のみ処理を行う(入力が無い場合は常に待機する)2キー入力があった場合に即座に処理を開始できる状態にする先ほどの書込みと重複しますがご相談に乗って頂いた皆様ありがとうございました。ISLe()様の仰っている事は私にはレベルが高すぎるようです。コミュニケーションが取れる程度のレベルがあれば良かったのですがそれも適わないようで残念です。いえいえ、わたしにはこんな複雑なコードは書けませんし一日とて向き合っていられません。シンプルなコードで実装します。No.24に、デバイスコンテキストは必要なときに用意して使い終わったらすぐに破棄する、と書きましたけど、箇条書きは読み取るのが難しいですか?デバイスコンテキストを必要なときだけ使うようにすれば、処理的に単なるビットマップ同士の画像転送になるのですが。#GDIの特殊性は薄れ汎用性は高く且つ見た目はシンプルになる。少なくともNo.8のお返事からはコミュニケーションを取ろうという意志は微塵も感じませんでした。わたしの意見に対する疑問と否定しかなく論破してみろと言わんばかりですからね。こちらもこちらの判断でコミュニケーションできる相手かどうかは見ています。4年前こんばんわ!滑らかなスクロール以前に、1と2があるなら、それができるようにやってみるといいです。それが出来たら滑らかなスクロールをやってみる。自分は一つ一つやっていったほうが分かりやすかったです。やると、何が何だか分からなくなりますしね。僕なんかベーシックで同じコードを何度もコピーしまくって作ったゲームが雑誌に載ってこの道です!今でも勉強しまくりです。お互いがんばりましょう。4年前かなり期間が開いてしまいましたが、最終報告をさせて頂きます。結果から言いますと、真の原因を突き止めることは出来ませんでした。1つの推測はできました。私の感じていた違和感は「ティアリング」という現象だと思います。APIでは解決が不可能なようです。これを解決するには垂直同期(vsync同期)を採る必要があるらしく、この時点で私のコンセプトから外れてしまいますので解決自体は放棄しました。その代わり、リフレッシュレートに合わせて描画タイミングを調整する事と、再描画の処理をStretchBltからBitBltに変更する事で体感的にはかなり違和感を抑制できたと思います。ご相談に乗って頂いた皆様ありがとうございました。一人で思い悩んでるだけでは恐らくここまで辿り着けなかったと思います。ミクプラは自由にリンクできます。