The previous Python code just had the source code but none of the GUI components that were needed (pictures, fonts). So now this is the working, but still very alpha, source code. Run “GuiMain” in the gui directory. All you can do is move 3 card images around. You cannot move the card outside of its current zone. The three colored region on the screen represent your hand, your play area and the computer’s play area.When you move the card it “bleeds” (look at the picture to see what I mean). This behavior is on purpose although it may seem like a bug. First a little background. For one, I don’t know anything about graphics programming other than the basic xy coordinate plane. (I actually did teach a few months of geometry, go math!!) Two, I thought I could just draw the whole screen 15 times a second but my computer isn’t that fast. So my compromise is that I only redraw the card that is moving and I don’t redraw everything.
In order to correct the bleeding effect, I should redraw the background where the card was previously at. That is easier said than done because I don’t know anything about graphics programming. Basically I feel like I am building my first dog house. I know the tools, hammer, nails, wood but I’m not sure how to best use them. I know the end result that I want, but I don’t know the exact steps.
This code requires Python and Pyglet
Download Source Code
Posts
7 comments:
I had to change the screen resolution or I got some very weird long recursion error. I change this and it looked like it worked:
###################################
class GuiMain:
def __init__(self):
self.win = window.Window(resizable=True, width=800, height=600)
###################################
Is there a reason you didn't use sprites? I found the class for them but I don't know if that would be any faster or not. Perhaps a spritegroup with a card image and a white rounded rectangle PNG image? Sorry about the formatting here, but:
###################################
import pyglet
main_window = pyglet.window.Window(width=800, height=600)
main_window.clear()
card1_image = pyglet.resource.image('card.jpg')
card1 = pyglet.sprite.Sprite(card1_image, x=0, y=0)
@main_window.event
def on_draw():
card1.draw()
@main_window.event
def on_mouse_press(x, y, button, modifiers):
card1.x = x
card1.y = y
card1.scale = 0.5
card1.rotation += 90.0
card1.draw()
pyglet.app.run()
###################################
There was some code moving sprites around at
http://pyglet.org/linuxconf/
although it looks like they clear the screen and redraw everything each time...
Hey Forge,
I fixed your code so that you don't get the blitting problem, and it also runs at 30 frames per second:
http://www.mediafire.com/?cttdlmqx2lm
The main problem with the code was that you were loading the images and creating the text images every time through the run loop.
One tip for GUI programming - creating data for images or text is slow, but drawing it to screen is fast. So you only want to create the images when absolutely necessary (ie when it changes). Unfortunately this makes your gui code 'inside out', but that's the price of interactivity.
I have found very interesting thing which can help you in development
http://code.google.com/p/los-cocos/
Cocos is a framework for building games, demos, and other graphical/interactive applications. It is built over pyglet. It provides some conventions and classes to help you structure a "scene based application".
A cocos application consists of several scenes, and a workflow connecting the different scenes. It provides you with a "director" (a singleton) which handles that workflow between scenes. Each scene is composed of an arbitrary number of layers; layers take care of drawing to the screen (using the pyglet and OpenGL APIs), handling events and in general contain all of the game/application logic.
Cocos simplifies the game development in these areas:
* Defining a workflow for your game
* Composing scenes and scene components
* Creating special effects & transitions
* Managing sprites
* Basic menus
Yeah, my program assumes 1000 by 700 or something like that. Instead I should just maxmize the window.
There was no reason why I wasn't using the sprite class.
Thanks Incantus. I'm not used to events being "inside out" but I'm learning :)
I like the idea of Cocos and I may or may not use it. It seems like it would make some things easier (like changing screens) but the learning curve is killing me.
clacker,
if you need any help using cocos, join us at the mailing list. We are really looking forward to get some users and polish whatever we can, so you can be sure we will try our best to be helpful.
This is great info to know.
Post a Comment