【どうして？】777town.net ｴﾝﾄﾞﾚｽﾌﾞﾗｯｸ【閉じる】

ん〜GetWindowDC使ったことないから試したけど
GetDCでDC取得
ループ {
　BitBltでリール部分をを自アプリのコントロールの裏DCにコピー
　InvalidateRect()
　Sleep()
}

GetWindowDCでDC取得
ループ {
　　BitBltでリール部分をを自アプリのコントロールの裏DCにコピー
　　InvalidateRect()
　　Sleep()
}

どっちもリール部分が回転してますけど・・・

C使いですか。
リールじゃなくて、液晶の部分の話だと思うが。。。

ＣでUWSCでも使ってるのは同じWin32APIですよね
液晶部分もリール部分も１枚のDCなので
液晶部分で試そうが、リール部分で試そうが結果は同じです。

777townアプリが毎秒数十枚の描画していても
その間に処理ロジックは何千回何万回ってできちゃうので
>>27のナビ取得処理は運良く通っちゃってるけど
運悪ければ反転に当たる って結論でいいですよね？

>>462
＞GetWindowDCが1回だけだから負荷は少ない
＞GetWindowDCが一番高負荷だからね。
こちら未だにＵＷＳＣでやってるので、ここの部分を認識していませんでした。
なんで、ＣＰＵパワーの話はこちらの誤りです。すいません。

しかし、ナビ無しを含めて４種類、反転を含めても７種類しか絵柄がないのに、
なぜに４点も判別に必要？

＞それもナビを取得するのはリールが全部回転している時の1回だけ
であれば点滅するのは右リールのみだし、
左リール：２カ所（ボヌス３種＋ナビ無しを弁別、ナビ無し時は処理抜け）
中リール：１カ所（ライオンとダチョを弁別）
右リール：２カ所（ライオンとダチョそれぞれの反転を弁別）
で済むんじゃない？

簡単に済ませるなら
1.左中のナビ取得
2.中停止
3.右のナビ取得
4.左 or 右 好きなほうから停止

逆押しにこだわるなら
　途中反転があっても判別できる２箇所探す
　or
　メモリDCにコピってゆっくり探す
ということで
Ｃ屋の助言ですたm(_ _)m

>>465
私も試してみた・・・
（;ﾟДﾟ）変化してる
今まで変化しないものと思って作ってたのは間違いだったんだな
ナビ取得ミスした事ないから気づかないままだったよ。
465さんありがとう。
動作しているが念のためコピってからチェックするように変更するよ。