I have a problem that iam facing which has made me grow weiry. A have a
simple game, very simple as you can hear. It is about the falling Debris.
The debris which i created using the wx.PaintDC, and using
self.dc.DrawCirle(and cordinats here") , and i also binded the key event
down. But here is a problem that when i tried to press the key which i
tested using if code.keycode == wx.WXK_LEFT. It failed to move. the Object
that i wanted to move failed.
My goal was to make sure that when the game starts ,the Debris start
falling from up, when the object down handled them and and knocks them and
destroys them.
And also the Debris move on a very slow pace how can i really combat tham
I have a problem that iam facing which has made me grow weiry. A have a
simple game, very simple as you can hear. It is about the falling Debris.
The debris which i created using the wx.PaintDC, and using
self.dc.DrawCirle(and cordinats here") , and i also binded the key event
down. But here is a problem that when i tried to press the key which i
tested using if code.keycode == wx.WXK_LEFT. It failed to move. the Object
that i wanted to move failed.
Problem #1 is that you are using wx.PaintDC within a timer callback.
wx.PaintDC can ONLY be used in an EVT_PAINT callback.
Problem #2 is that you use "self.keyCode" in OnPressDown. keyCode is a
local variable; remove the "self.".
Problem #3 is that you are never changing line_x_axis. In OnPressDown,
you really want something like this:
if keyCode == wx.WXK_RIGHT and self.line_x_axis <
self.GetSize()[1]:
self.line_x_axis += 10
My goal was to make sure that when the game starts ,the Debris start
falling from up, when the object down handled them and and knocks them and
destroys them.
You might think about making this more "object oriented", by creating a
"ball object" that knows its location, how to draw itself, and how to
detect collisions with the bar. That way, you can just create a
collection of 8 balls and update them all in a loop.
And also the Debris move on a very slow pace how can i really combat tham
The balls fall slowly because your timer is set to 500ms. It only falls
two pixels per second. Set the timer to 50ms and things get more
responsive. Even that is too slow for game play; you will want to move
your balls more than one pixel per iteration.
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I have a problem that iam facing which has made me grow weiry. A have a
simple game, very simple as you can hear. It is about the falling Debris.
The debris which i created using the wx.PaintDC, and using
self.dc.DrawCirle(and cordinats here") , and i also binded the key event
down. But here is a problem that when i tried to press the key which i
tested using if code.keycode == wx.WXK_LEFT. It failed to move. the Object
that i wanted to move failed.
Problem #1 is that you are using wx.PaintDC within a timer callback.
wx.PaintDC can ONLY be used in an EVT_PAINT callback.
(I should have added "Use wx.ClientDC instead.)
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I have a problem that iam facing which has made me grow weiry. A have a
simple game, very simple as you can hear. It is about the falling Debris.
The debris which i created using the wx.PaintDC, and using
self.dc.DrawCirle(and cordinats here") , and i also binded the key event
down. But here is a problem that when i tried to press the key which i
tested using if code.keycode == wx.WXK_LEFT. It failed to move. the Object
that i wanted to move failed.
I don't know if I can help with the key binding issue, but some other issues:
1) Dont create a wxPaintDC outside of a paint event.
- the "modern" way to do it is to do all your drawing in a Paint
event, then call self.Reresh(), self.Update() when you want the Window
re-painted.
2) don't keep dcs around -- creat them, use them, let them go away --
i.e don't do "self.dc = ..."
It's going really slow because yo have the Timer set to 500 ms -- 1/2 second.
Enclosed is a re-worked example that does the drawing right.
On Wed, Aug 29, 2012 at 9:18 AM, want_learn1 <wangolob@gmail.com> wrote:
My goal was to make sure that when the game starts ,the Debris start
falling from up, when the object down handled them and and knocks them and
destroys them.
And also the Debris move on a very slow pace how can i really combat tham
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
better yet what I suggested and demod -- clientDCs interfere with teh
System screen update timing -- it's best not to do that unless you
REALLY need to draw it NOW.
-Chris
···
On Wed, Aug 29, 2012 at 9:41 AM, Tim Roberts <timr@probo.com> wrote:
(I should have added "Use wx.ClientDC instead.)
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
On Wed, Aug 29, 2012 at 9:41 AM, Tim Roberts <timr@probo.com> wrote:
(I should have added "Use wx.ClientDC instead.)
better yet what I suggested and demod -- clientDCs interfere with teh
System screen update timing -- it's best not to do that unless you
REALLY need to draw it NOW.
I'm not quite sure what you're saying here. WM_PAINT messages are not
synchronized to vertical blanking. Your code is philosophically better,
because drawing outside of OnPaint usually ends up with duplicated code,
but that doesn't have any implication on screen update timing.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
On platforms besides Windows it does. Specifically, on OSX using a wx.ClientDC imposes a fair bit of overhead because it has to interrupt the "display pipeline" and dump the pending operations, flush the content of the ClientDC to the screen, restart the pipeline and reload the formerly pending operations which could require paint events being resent to other windows. I believe that on wxGTK when using a compositing window manager or similar then you could have similar issues. Similarly on Windows, if the native double-buffering (or whatever MSW calls its compositing mode) is turned on for a window then most of the time any drawing done with a wx.ClientDC is never seen, only that which is done in a paint event with a wx.PaintDC.
BTW (Chris), at least on OSX using the Update() method to force an immediate paint event can have similar overhead to using a ClientDC. It would be best to just do the Refresh and then make sure that there is nothing time consuming between that and the return to the event loop so the paint event can then be delivered naturally and ASAP.
···
On 8/30/12 9:55 AM, Tim Roberts wrote:
Chris Barker wrote:
On Wed, Aug 29, 2012 at 9:41 AM, Tim Roberts <timr@probo.com> wrote:
(I should have added "Use wx.ClientDC instead.)
better yet what I suggested and demod -- clientDCs interfere with teh
System screen update timing -- it's best not to do that unless you
REALLY need to draw it NOW.
I'm not quite sure what you're saying here. WM_PAINT messages are not
synchronized to vertical blanking. Your code is philosophically better,
because drawing outside of OnPaint usually ends up with duplicated code,
but that doesn't have any implication on screen update timing.
I just remembered that the last time I explained it this way that somebody pointed out that I was misunderstanding some aspect of it, but I don't remember what. I do know however that Stefan, our wxOSX expert, strongly recommends that drawing with wx.ClentDC or using Update() should be avoided if possible because it will be very inefficient and will impact performance.
···
On 8/30/12 10:35 AM, Robin Dunn wrote:
Specifically, on OSX using a
wx.ClientDC imposes a fair bit of overhead because it has to interrupt
the "display pipeline" and dump the pending operations, flush the
content of the ClientDC to the screen, restart the pipeline and reload
the formerly pending operations which could require paint events being
resent to other windows.
I'm not quite sure what you're saying here. WM_PAINT messages are not
synchronized to vertical blanking.
Not the messages themselves, but when you Update, the system puts it
on the draw queue or something like that. At least on OS-X, and maybe
newer Windows.
Anyway, there have been multiple conversations on this list indicating
that it's yes way to do it.
Chris
···
On Aug 30, 2012, at 9:56 AM, Tim Roberts <timr@probo.com> wrote:
Your code is philosophically better,
because drawing outside of OnPaint usually ends up with duplicated code,
but that doesn't have any implication on screen update timing.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
BTW (Chris), at least on OSX using the Update() method to force an immediate paint event can have similar overhead to using a ClientDC. It would be best to just do the Refresh and then make sure that there is nothing time consuming between that and the return to the event loop so the paint event can then be delivered naturally and ASAP.
Hmm--it's probably somewhat application specific, so trying it without
the Update() first makes sense. But I know I've. Needed it to get
reasonable refreshing. In fact, if you wanted to update during a Mose
move-- I still needed a ClientDC. It that was a while ago -- I haven't
tried with a Cocoa build at all.
On Aug 30, 2012, at 9:56 AM, Tim Roberts <timr@probo.com> wrote:
I'm not quite sure what you're saying here. WM_PAINT messages are not
synchronized to vertical blanking.
Not the messages themselves, but when you Update, the system puts it
on the draw queue or something like that. At least on OS-X, and maybe
newer Windows.
Interesting. Windows has never done that -- Update just sends a
WM_PAINT, which goes immediately into the thread's message queue. There
are no delays.
The syncing is even less necessary in newer Windows, because the app
isn't actually drawing into the visible frame buffer -- it's drawing
into a texture that gets rendered by the desktop compositor.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.