Win32API質問箱 Build125

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/02/27(水) 15:09:08.64ID:6ExXwgQU
Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
http://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
http://mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】
http://mevius.5ch.net/test/read.cgi/tech/1521786252/
504デフォルトの名無しさん
垢版 |
2019/10/23(水) 15:31:41.90ID:J1BMEu9t
いや判るだろ

1809 update 入れた後に可笑しくなったんだろω
505455
垢版 |
2019/10/23(水) 21:03:31.35ID:i0lmBL5A
1809以降の挙動ならプログラムじゃなくてWindows側の問題みたいですね
BitBltだけじゃなくプレビューにも問題出てるからバグっぽいですし
そのうちアップデートで治ることを期待しつつプログラムでの対応は諦めます
いろいろ答えてくれた皆様ありがとうございました
2019/10/23(水) 22:21:30.01ID:bxABcYeD
やっぱりKnownFolderから取得できた。
https://github.com/katahiromz/SHVistaPathMap/blob/master/dump.cpp
自由に使え。
2019/10/23(水) 23:01:48.53ID:bxABcYeD
揚げ物
2019/10/24(木) 00:20:06.38ID:ywNA7G1O
ありがとう。だがしかし別のアプローチで
俺が解決したい（本当の）問題は解決できていたのだよ

まあ誰かの役に立つだろうから放っておいたけどな
すまんなｗww
2019/10/24(木) 00:41:12.27ID:Fw8n9fLr
アップデートで直るかっちゅーても挙動自体は描画の最適化とも言えるので仕様としてこのままいきそうだけどなあ

自作ので試してみたけどやはり一部でも画面外に出てると無効領域をクライアント全体と指定しても
強制的にクリップされたHDCが返ってくるね
BeginPaintだけじゃなくてWM_PAINT外でのGetDCでも同様
DXGI swap chainが出力先ならクリップされない

普段窓を画面外に追い出したままにするってことがないから気付かなかったなコレ
510デフォルトの名無しさん
垢版 |
2019/11/04(月) 15:23:29.75ID:/C5zJSxn
SetForegroundWindowでフォーカスを奪えない、
入力中にフォーカスが奪われるとウザいからWindowsが
奪えないようにしてるって話はよく聞くと思うけど

逆にエクスプローラが起動すると（バックグラウンドなのに）
フォーカスを奪ってくれて困ってるんだけど対応策ない？
ウザいんだがｗ
2019/11/04(月) 15:58:26.30ID:fwURXfb5
>>447
さらに追試を重ねていました
悪いときは 10G, うまくいっても 5000G 程度（日によってばらばらです）で
FILE_END ができなくなる現象は、
FILE_END が悪いのではなく、システムで圧縮するように指定するとそういうことがおきることがわかってきました。

Windows もいろいろとあてにならない、もう linux に軸足を移そうか、と思案しています
2019/11/04(月) 16:19:56.83ID:1IiqNDSP
>>510
SetFocus()を使うと好きなコントロールにフォーカスを与えることが出来る。
SetForegroundWindow()は余り効果が無い。
2019/11/04(月) 16:52:05.66ID:KwYoxUXo
longポインタ引数にintポインタ渡して>>445みたいなトンチンカンな返答する人が何か言ってる
2019/11/04(月) 18:29:13.81ID:fwURXfb5
>>513
>>445 を日本語に翻訳してみました。
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointer
では api 関数の第二引数は　「LONG」で定義されています。
ここで注意しないといけないのは「long」ではなくて「LONG」。
すなわち LONG は win32api.h で定義されている型です。これが実際の環境ではどう typedef されているかは環境依存です。
それを調べるために >>445 で実際に sizeof(LONG) の値を出力させると sizeof(LONG) = 4
私は >>443 で第二引数に int (そして渡す値は 0) を使っていますが sizeof(int) = 4
値は 0 だから signed/unsigned については問題ない
そして sizeof(int) = sizeof(LONG) だからなおさら問題ないのです。
昔は DWORD (Double WORD) と定義されていましたが、1 word = 2 bytes, 2 words = 4 bytes
32bit 環境での普通の int のサイズは 4 なので昔から int を当てて問題なかったのですよ

結論：>>513 >>444 はニワカ、win32api スレに投稿する前に 10 年 ROM ってください
2019/11/04(月) 18:55:51.87ID:KwYoxUXo
>>514
445のどこがWindows環境？
2019/11/04(月) 19:29:40.39ID:ex697rOI
DOS窓でprintf出力しながらWin32APIだって使えるからWin環境
2019/11/04(月) 20:03:10.14ID:xxqq9QlV
LONGは、WPARAMやLPARAMと型変換する危険コードが多い気が。もちろん古いコードだけど。
2019/11/04(月) 20:32:15.68ID:fwURXfb5
>>515
だから、あなたは 10 年 ROM ってなさい、ってさっき言ったでしょう？
2019/11/04(月) 23:46:10.01ID:hiiCgg8I
ここはWin32スレなんだからWin64や総称であるWindows APIはスレ違い
32ビットの話だけしてろ
2019/11/05(火) 00:15:09.88ID:SbnLKNM3
>>519
残念ながらその意見に賛同する人は少数派だと思いますよ
2019/11/05(火) 01:54:03.16ID:RTdVMJgD
Win64APIなんてどっから出てきたの？
522デフォルトの名無しさん
垢版 |
2019/11/05(火) 11:28:00.41ID:f5fZl2jz
> 昔は DWORD (Double WORD) と定義されていましたが
LPARAMは 16bit,32bit共に LONG (符号付整数)
2019/11/05(火) 11:48:37.07ID:McETm4vA
>>519
64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ
Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度
つまりスレチでも何でもない
2019/11/05(火) 19:37:14.92ID:wVD+ILW8
double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが
2019/11/05(火) 20:20:06.81ID:Rmlz0hln
>>524
16bit CPUや32bit CPUという言葉と
ポインタ = アドレス幅が違うことは普通にあるってわかってる？

8086は16bit CPUでレジスタ幅は16bitだがアドレス幅は20bit（最大1MB）
80286も16bit CPUだがアドレス幅は24bit（最大16MB）

80386は32bit CPUでレジスタ幅、アドレス幅ともに32bitで
分かりやすい時代がPentiumの第一世代（1995年ぐらい）ぐらいまで続いたが
Pentium Proからは物理アドレス拡張が搭載され32bit CPUだが
アドレスバスは36bit（最大64GB）になったんだが
2019/11/05(火) 20:52:13.30ID:mHpC8FDb
>>525
釈迦に説法ご苦労
2019/11/05(火) 21:08:53.99ID:Rmlz0hln
釈迦は俺やしｗ
2019/11/05(火) 21:43:32.83ID:mHpC8FDb
俺メインフレームでdiagnose命令とかいじくってて
別な案件でhdlでcpu書いたりしてるけど
2019/11/06(水) 01:32:27.55ID:k1IDaN6Q
メインフレームw
何歳になってもイキリ小僧してるんだな
サルのパパとママはご存命かい？
2019/11/06(水) 02:20:55.89ID:71FJFoA8
>>529
何イキっとんねん
2019/11/06(水) 04:07:48.25ID:Z1mcKm+J
イキなりえなり
2019/11/06(水) 07:21:07.12ID:cnDla3Ge
>>525
ソフト的なAPIの話に物理アドレス空間で語るバカ乙w
533デフォルトの名無しさん
垢版 |
2019/11/06(水) 12:01:28.81ID:o3tEvZiY
釈迦がどうかはともかく
>>525 が全くトンチンカンなレスであることは事実
いつものあいつだろ
2019/11/06(水) 15:05:39.69ID:Z1mcKm+J
>>532
APIの話だというのなら、OSが16bitだろうが32bitだろうが
APIの仕様が代わるわけないんやで
異常事態でもなんでもなく、それが高い互換性の理由だ
2019/11/06(水) 15:13:44.92ID:Z1hQUtYe
64ビット対応で
Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、
DialogProcの戻り値をINT_PTRにしろ。
とかの若干の変更点があるようだ。
536デフォルトの名無しさん
垢版 |
2019/11/06(水) 15:19:20.45ID:o3tEvZiY
HANDLEもこっそりtypedefに_PTR変えたんだっけ
2019/11/07(木) 01:18:36.16ID:7K0XtVuo
ダイアログプロシージャの戻り値がめんどうなことになる
x86じゃBOOLだけどx64だとINT_PTR
でもVC6だとBOOLはintだという
2019/11/07(木) 01:32:58.79ID:sEmiRyTj
歴史的理由で仕方のない面もあるが、
単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから
型の実態は結局なんなんだ？って悩むことになってる。

もうそろそろネイティブ型だけを使えるようになってほしいが
そのために言語を変えるほうが楽だろうな
2019/11/07(木) 01:44:34.42ID:ubAK6fog
intとlongのサイズ違うこともあるしな
c#みたいにint32みたいなの最初から用意しとけよ
2019/11/07(木) 01:48:09.03ID:cfOynPV2
stdint.h使おう
2019/11/07(木) 02:23:16.77ID:+N3PsKU8
前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。
2019/11/07(木) 02:26:43.25ID:4jX7Qkw7
いいかげんな知識で語りたがるやつ多すぎ
2019/11/07(木) 02:27:07.09ID:+N3PsKU8
32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に
悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか
どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。
恐らく、exeファイルのサイズも増加するだろう。
2019/11/07(木) 02:42:22.07ID:sEmiRyTj
コンピュータが遅かった時代はCPUに最適なデータ型を
使うことが重要だったが、今は数値型しかなくて
データサイズは自動的に決まりますとかばかりだもんな
2019/11/07(木) 02:44:07.15ID:+N3PsKU8
64BITポインタptrと配列添え字idxに対して、
ptr[idx]
と書いた場合、idxが32BITと64BITだと実は、32BITの方が
1クロック増えてしまう可能性が高い。なぜなら、マシン語レベルでは、
上記の演算で、ptrは64BIT整数として扱われ、ptr[idx]は、
*(ptr+idx)として処理される。ところが、64BIT+64BITの整数演算は
あるが、64BIT+32BITの整数演算は無い事が多い。なので、
idxが32BITだと、いったん、64BITにBIT幅を拡張する命令を1つ
挿入する必要がある。

だから、64BITポインタのアーキテクチャだと、idxも64BITにした方が
速度が上がる可能性が高い。
2019/11/07(木) 02:45:21.76ID:+N3PsKU8
>>544
>今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな
C++だと今でもデータサイズは明示します。
547デフォルトの名無しさん
垢版 |
2019/11/07(木) 02:54:21.19ID:PsJP4fV8
size_t型が無難にして最強
2019/11/07(木) 03:00:35.26ID:sEmiRyTj
>>546
他の言語の話や。今は速度よりも利便性のほうが重要や
2019/11/07(木) 03:18:33.19ID:+N3PsKU8
>>548
例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている
わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、
整数は32BIT整数型までだと double型に精度を落とすことなく完全に
収まるので、何も考えずに正しく扱えるだけです。
JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
2019/11/07(木) 03:23:20.54ID:+N3PsKU8
>>549
また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、
console.log(54 / 10);
とすると、5.4と表示されます。これは、54や10が整数ではなく、
54.0 や 10.0 という double 型浮動小数点として扱われているためです。
これは、Sun/Oracle の Java とは全く結果が異なります。後者では、
54/10は、「整数除算」なので、結果は整数の「5」となります。
2019/11/07(木) 03:38:26.22ID:sEmiRyTj
> JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
64bitも使うのかって話なんだけどな？ 52bitで十分だろう？

https://sbfl.net/blog/2018/06/18/javascript-bigint/

> JavaScriptのNumber（数値型）は倍精度浮動小数点数となります。
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
2019/11/07(木) 03:39:52.10ID:sEmiRyTj
なんだ。JavaScriptにBigIntあるじゃん

Numberで表せる最大の整数値は十分な値にも思えますが、
分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。

BigIntは、任意精度の整数を表す新しいプリミティブ型です。
任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。
2019/11/07(木) 03:43:05.27ID:sEmiRyTj
やっぱりどんなときでもプログラマがデータ型を
選んでくださいっていうのは時代遅れだと思わ
2019/11/07(木) 03:53:54.05ID:+N3PsKU8
>>553
自動化することは可能ですが、現在の技術でそういうところまで自動化した
言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる
かも知れません。これはコンパイル意を作成した経験に基づく話です。
もの凄く厳しい世界が実はまだ沢山残っています。
2019/11/07(木) 03:55:32.96ID:+N3PsKU8
>>554
誤：かも知れません。これはコンパイル意を作成した経験に基づく話です。
正：かも知れません。これはコンパイラを作成した経験に基づく話です。
2019/11/07(木) 03:58:19.11ID:sEmiRyTj
100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ
2019/11/07(木) 03:58:57.97ID:sEmiRyTj
今より100倍遅かった時代もあるのに
何を言ってるんだろうか？
それこそ時代遅れの感覚
2019/11/07(木) 03:59:39.43ID:sEmiRyTj
あと、「かも知れません。」とかいう推測はどうでもいいから

コンパイラを作り上げた俺が言うのだから
説得力は高いだろうし
2019/11/07(木) 04:00:34.74ID:+N3PsKU8
>>555
GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような
例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を
floatや整数型などにバラして処理するので数10倍かかります。
なので、慎重になる必要があります。
CPUの場合でもintとdoubleで速度がかなり違うことが多いです。
2019/11/07(木) 04:02:01.90ID:sEmiRyTj
あと極まれにスピードが重要な部分があるから
全部スピード重要視しろとかいうアホな感覚なｗ
あれはやめてほしい。

極稀に重要なら、極稀に使うものを作ればいいだけ
よく使うものを短くする。（仕事の）圧縮の鉄則
2019/11/07(木) 04:02:17.73ID:+N3PsKU8
>>558
あなたより私の方が良いコンパイラを作っている可能性も有りますよね。
2019/11/07(木) 04:05:54.80ID:+N3PsKU8
>>560
自動化の道は検討の価値はあるでしょう。
しかし、int32型とint10000000型を自動的に取捨選択できるほど、
コンパイラが賢くなるのは恐らく遠い未来です。
どこかで機能制限や精度を人間が指示する必要があると考えられます。
2019/11/07(木) 04:07:52.13ID:sEmiRyTj
>>561
そういう俺のほうが優れてるとか言う主張をしたいなら、
個人を特定できるような情報をだせ
2019/11/07(木) 04:08:39.82ID:sEmiRyTj
>>562
コンパイラが無理なら実行時にメモリ拡張すればいいだけ
そういうことも思いつかないから、その程度止まりなんだよｗ
2019/11/07(木) 04:08:50.01ID:+N3PsKU8
>>563
それはお互い様です。
2019/11/07(木) 04:11:41.18ID:+N3PsKU8
>>564
それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、
OSなどの作成には向いていない言語になるでしょう。
2019/11/07(木) 04:12:20.64ID:sEmiRyTj
大胆に変数はすべて128bitしかないという言語だって考えられる
最大 340282366920938463463374607431768211456 までしか扱えないが
2019/11/07(木) 04:13:03.08ID:sEmiRyTj
>>566
そんな言語が今はたくさんあり実用化されています。
2019/11/07(木) 04:17:30.53ID:+N3PsKU8
>>567
64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。
あなたが普段使っているコンパイラも、非常に細かい高速化を施して
あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの
動的言語では達成できません。

例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ
から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。
あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。
2019/11/07(木) 04:18:51.44ID:+N3PsKU8
>>568
有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの
メジャー言語ではそのような方針はとっていません。
2019/11/07(木) 04:23:37.69ID:+N3PsKU8
>>564
「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。
全く発表してませんから。
2019/11/07(木) 05:42:32.39ID:xrNXmkmc
スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ
2019/11/07(木) 06:22:21.36ID:D8b5RtWG
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。

ひどい説明だな
どのくらいひどいかというと
WM_SYSTEMMENU並み
2019/11/07(木) 11:03:05.72ID:JQdG/Jj/
公共の場で変数型のピロートークですか
575デフォルトの名無しさん
垢版 |
2019/11/07(木) 11:05:56.88ID:dB1QBGXo
>>545
size_t 使え
2019/11/07(木) 11:27:25.53ID:nSoHFrko
>>575
NULLは0だから〜
site_tはどうせintだから〜

こういう馬鹿なハケンが一人いると崩壊するよね
2019/11/07(木) 12:11:51.38ID:sEmiRyTj
とか言うやつほどnullptrのことを知らなそうｗ
2019/11/07(木) 12:17:00.95ID:9pMbL+ZJ
（´∀｀）＜ぬるぽ
2019/11/07(木) 17:55:20.14ID:7K0XtVuo
#ifdef _WIN64
#define BOOLX64 INT_PTR
#else
#define BOOLX64 BOOL
#endif

BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp)

こうやって回避してるわ
2019/11/07(木) 18:14:03.25ID:2gAeIIzZ
Windowsのデータ型だけのヘッダファイルって無いかしら？

データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、
APIのヘッダファイルはincludeしたくない。

APIを直接使うのは面倒だから、全部ラップしてるんだよね。
だから他からは使えないようにしたい。
2019/11/07(木) 19:03:13.60ID:+mjs9icr
データ型もラップしとけよ
2019/11/07(木) 19:07:36.74ID:2gAeIIzZ
>>581
どうやってラップすればいいですかね？
2019/11/07(木) 19:16:08.80ID:2gAeIIzZ
なんとなくわかったからいいやｗ
2019/11/07(木) 21:31:30.10ID:6aSe0RTj
横にそれるが
データ型もAPIの一部だと思ってるがあってるよな？
2019/11/07(木) 21:47:07.60ID:nSoHFrko
アプリケーション独自の型なんか知りませんがな
2019/11/07(木) 23:33:07.15ID:rEYaLqlI
個人的には構造化したほうがやりいいかな
2019/11/08(金) 03:59:17.05ID:ksOnEph7
お前らMFCでも使ってろ
2019/11/08(金) 04:54:11.01ID:2aYByRbi
普通のアプリならMFCが一番だと思うんだがなあ
変に角を丸くするとか透明にするとかされても使いにくいだけだろうに
2019/11/08(金) 05:57:08.22ID:bt2cbsd4
むしろMFC = 角を丸くするとか透明だろ
MFC以外でそんなの見たことないわｗ
2019/11/08(金) 07:30:44.18ID:D1bzmSlR
あんまりMFC関係なくね？
WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで
MFCはラッパーとしての薄さがありがたいだけやん
2019/11/08(金) 07:52:07.38ID:tDaXxZK7
MFCはかゆいところに手が届かないからな
廃れたWTLがいい
592デフォルトの名無しさん
垢版 |
2019/11/08(金) 09:32:12.24ID:MipGbP9q
>>591
WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。
https://git.code.sf.net/p/wtl/git
2019/11/08(金) 11:37:03.54ID:bt2cbsd4
廃れたかどうかは、使ってる人がいるかどうかであって
作っている人がいるかどうかではない
2019/11/08(金) 12:13:14.99ID:xtk88Sle
俺が使ってるから廃れてないぞ
2019/11/08(金) 12:17:45.01ID:2aYByRbi
>>594
ちょと見せてみて？
2019/11/08(金) 13:27:31.55ID:D1bzmSlR
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ
2019/11/08(金) 13:56:39.50ID:1R79qYgq
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ
2019/11/08(金) 21:00:43.55ID:lpVjWTGo
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
https://social.msdn.microsoft.com/Forums/ja-JP/17563f89-9838-4beb-925f-32f47d90c994/topmost
2019/11/08(金) 21:14:49.46ID:sQQR9KNr
TOPMOST同士があるからな
2019/11/09(土) 13:55:21.92ID:hHKZwsDl
タスクマネージャもよく後ろに移動する時あるけど何なのあれ
601デフォルトの名無しさん
垢版 |
2019/11/09(土) 14:13:06.87ID:BZG37V3w
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる
2019/11/09(土) 15:42:27.57ID:01iIJK4d
タスクバーより手前にくる時もある

別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある
2019/11/09(土) 17:34:31.94ID:GyhiHYRD
もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが
2019/11/09(土) 17:44:43.05ID:HanEs9+F
アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。