※ 引述《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