Pygame embedded in wxPython - 1.5

I have use your example script, and modify it to make the picture spin accordind to the slider speed value. Somehow inside the redraw section , the blit often hang the window everytime I adjust the slider. Any tip on how to make it work :)

Thank you for your helpful script :) I have been trying to combine wxpython and pygame recently, and your sample do help to kick start my project. A big thumb up for you :)

Excelente script! It saves my day!

I did some r&d on this today. Cool stuff. I actually got my Opioid2D scene to run in the wx window. Fancy! Unfortunately, when I resize the window all my textures get corrupted. I'm sure it's something to do with GL and deeper engine stuff that I can't justify getting into right now. Some day.
Thanks again for writing this awesome little tidbit. Let me know if you'd ever want to help with an awesome open-source game editor project ;)

What I've done is run Opioid2D in a separate process. So I have a wx editor window editing a game that is running in a separate pygame/sdl window. And yes, that causes some strange problems from time to time. It would be great to get those running in the same loop and the same window. Some day I'm hoping that someone that's good at that sort of programming will be so excited about my open source game editor that they'll take it upon themselves to just do it.

Anyway, maybe we shouldn't take up the area on your pygame page about this. If you'd like to continue discussion, feel free to post to http://groups.google.com/group/pug_discuss

Aah right, I can see why that would cause problems. Pygame by itself would be fine, but when you try and run a second loop alongside the wx one things tend to go a bit awry.

I'd be interested to hear how that goes. If you could make Opioid2D relinquish control to wx so that only one of them had a constant loop running then all should be well, but if they were both insistent on running at once you'd probably find it wouldn't work very well. Depends on what sort of loop Opioid2D uses though.

I remember now that because I use the old Opioid2D engine, it was that engine loop that was conflicting with the wx loop.

I will have to look into whether I can get Opioid to draw to your wx context. It would make my game editor SO much more slick if it all existed in one window.

Got the slider redrawing working again! I just added an event.yield() to the bottom of the PygameDisplay's OnPaint() method so that paint events get passed on to other objects. For some reason only the PygameDisplay was getting sent paint events this time, so its redraw function was the only thing to be called when the window was supposed to be redrawn.

Incidentally, I've thought of another advantage to using generic Pygame surfaces for drawing - one could theoretically have multiple Pygame displays running at once, even in separate frames. I'll give this a try later, and if it works I'll include it in the next update.

Ah, well that shouldn't be a problem as I've decided (for my project) to let wx handle the events anyway to make code less complicated. This approach admittedly wouldn't be ideal if someone was making a game which involved a lot of event-handling and only needed wx to show a small menu at the side though. I think when I next update I'll also post an alternative version which uses if/else statements to set the video mode to one appropriate to the OS, and see if it'll let Pygame receive events too.

Initializing the display would work fine, but I just figured that setting the video mode would be unnecessary this way. One downside of this approach is that pygame's event module is closely tied to the display module, making it unusable without having a video mode set for capturing events; the best way to clear this hurdle I think would be to bind the input events into wx directly.

@sunspider: Actually, Pygame doesn't have a mainloop in the same way as wx does; that has to be created by the user - that's why Pygame scripts are always built around a "while True" loop of some sort which checks for events and redraws. The two libraries aren't really running in parallel as such; wx is the only one which needs to run independently, so it can be given complete control and can call Pygame to redraw when necessary. In the demo this is done using a wx Timer event which calls an update/redraw function for the Pygame part of the program periodically. The slider redraws without any problems in the version posted here (as seen in the screenshot), so I think it's something to do with the device context - perhaps it has to be freed after being used so the rest of the window can redraw or something like that. I'm not really sure; It's been ages since I last fiddled with that sort of thing :P

What were the problems you ran into, out of interest? If you had the same redraw issue, you might have done what I originally did and bound the wx.EVT_PAINT event to a drawing function which only draws the Pygame display, which would override the code drawing other parts of the window. The only other issue I've run into is getting Pygame and wx to close - closing wx first left Pygame with no display (never good), and closing Pygame first caused problems when wx seemed to want to redraw before it closed. In the end I had to close Pygame first, but make it unbind all the redraw events beforehand to ensure that Pygame wasn't called on wx's exit. Apart from that, I haven't really found any major problems using the two together, but then I haven't tried anything complicated just yet.

I ran into this problem when I tried to run pygame in wx. What I found is that I couldn't get the wx mainloop to run properly in parallel with pygame. I suspect that is why your slider is not redrawing.
But I'm no expert, so I don't want to discourage you from trying.

@randomeyes: Aah, I see. Thanks for the code, I think I see what you're doing there :) I found a strange bug though. For some reason it doesn't redraw the slider at the top now, and I haven't a clue why - it's possibly something to do with the use of the device context; perhaps it's overridden the rest of the frame's repainting method in some way. I'll take a look into it anyway.

Incidentally, what's wrong with initialising the display? Does it have to be done differently on other platforms? I'm not particularly familiar with cross-platform differences (I only ever use Windows :P ) so I didn't know it caused problems.

Actually, having looked at the code again, I presume it's the bit that sets the video driver? That would make sense. Well, thanks for the workaround :) I'll try and get it redrawing properly and then shall post an updated version here.

@sunspider: Thanks :) Well, turns out it isn't at the moment (see randomeyes' comment), but it soon will be with randomeyes' modification, once I sort out the redrawing bug.

This is a good start, but you can get around the cross-platform differences by drawing straight to a generic pygame Surface, instead of initializing the display.

Hopefully this paste will help explain:
http://www.pasteall.org/14391/python

This is fantastic! Is it cross platform?
Check out my pug project on http://code.google.com/p/pug .