※ 引述《linjack (嗯)》之銘言： : 想法1: 只有 gamewindow 去 inherit library 中的 widget class(QWidget) : 其他的 bricks / pad / ball 都是自己從頭設計的 class : 呼叫 pad 和 ball 的移動 method, 還有所有的 : collision detection 都寫在 gamewindow 中去 handle : 重繪事件通通交給 gamewindow 做, pad / ball / brick : 是經由 gamewindow 的重繪才得以顯現在視窗畫面上. : 想法2: 所有物件都去 inherit library 中的 widget class(QWidget) : 使用者所輸入的移動指令會直接去 call pad 繼承自 widget class : 而來的 move method, 同樣 ball 的移動都是自己處理的 : 而 collision detection 只寫在 ball 裡面 : 我理想中的狀況是, 這樣寫似乎 gamewindow 就不用處理重繪了 : 因為東西不是被畫上去的, 而是每一個物件都是一個 widget : 看起來想法二似乎比較好 ? : 可否請板上大大指點一二呢 ? 感激不盡. 小程式的話其實怎麼做都可以啦 不過一般遊戲的做法，都是自己處理重繪的部份 而且很重要的一點，計算（遊戲的邏輯、資料處理、物理運動…等）和顯示 （不管你是怎麼畫）的處理，最好是分開的 在顯示上，有部份的設計和 QWidget 現有的功能是重疊的，因此自己重做 可能會覺得有點浪費；換句話說，如果你對 QWidget 夠熟，的確是可以最 大限度利用它現成的架構…… 但是這樣的缺點就是你會被綁在 QWidget 上。舉個例子，假設有一天你需要 做大量的混色，或者你發現需要 60 fps 以上，才能保持流暢度，QWidget 不夠快怎麼辦？如果當初是用第一種想法（自己處理重繪），也許還有辦法 簡單移植（修改底層的成像核心）；如果當初是用第二種，你大概會發現重寫 還比較快！ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.120.214.120