I have a question.
Choosing between pygame and pyglet, I want to choose pyglet more. But I am frightened of the dicorations.
Tell me please, is it possible to design pyglet as well as in pygame? Use while true and so on?
Thanks in advance!
2 (edited by magurp244 2017-04-17 09:26:17)
It is possible to use a while loop for updating in Pyglet, its not much different than previous examples. You would still need to either subclass the window or use "@window.event" tags for drawing and input functions, and also manually dispatch events or it will lock up.
3 (edited by magurp244 2017-04-17 09:31:51)
Actually, digging abit into Pyglets documentation I think i've come up with a better example thats alot closer to the pygame version. Instead of having to use event tags or window subclassing you can also push keyboard handling into the windows event stack and handle it similarly to pygame.
import pyglet from pyglet.window import key def Example(): #create window window = pyglet.window.Window(640,480,caption='Example') #load sound sound = pyglet.media.load('example.wav',streaming=False) #load image picture = pyglet.image.load('example.png') #load keyboard handler keyboard = key.KeyStateHandler() #add keyboard handler to window window.push_handlers(keyboard) #main update loop while True: if keyboard.items(): #play sound if keyboard.get(key.SPACE): sound.play() #quit program if keyboard.get(key.ESCAPE): window.close() #clear keyboard buffer keyboard.clear() #clear screen window.clear() #draw picture to window picture.blit(0,0) #update screen window.flip() #dispatch events window.dispatch_events() Example()
Can I use pygame and pyglet at the same time?
That example should work... But (unless I missed something), you need to tick the clock.
Also what real advantage is there to be gained by manually doing this over using app.run() (asking the original poster). Decorators aren't difficult to use, and there are plenty of examples in pyglet's documentation.
Just because pyglet's way is different from other libraries doesn't mean it's "bad" or needs to be changed to act like other libraries, especially if it requires code that essentially duplicates something the library can already do (and probably a lot faster).
I just do not understand how to make a game with pyglet.
I do not understand the dicorations, I'm used to the simple game tsy while while true.
I can't tell you how to make a game, I'm not doing anything like that yet. But to answer your previous question, yes you can use pygame and pyglet in the same script without any problems. I'm not sure how you code using both of them, but yes it can be done. I would suggest reading the documentation, that's always a good starting point.
Playing music and coding, are kinds of real world magic.
Hm, you may be right about the clock. Reading the pyglet programming guide though it seems to suggest its more to make certain scheduled events are called including sounds and video played through pyglet, not that its explicitly required to do so. The example seems to work fine, though I wouldn't necessarily call it ideal.
This might not seem like the most straight foward way of going about using pyglet, but doing it this way could still prove to be educational. Most people start off with the standard approach and migrate to topics like this for edge cases, in this instance he may start off here and migrate to the standard approach. Its sort of like starting off learning Assembler instead of C I suppose, heh.
I'm sure you could use Pyglet and Pygame at the same time, but I don't see much reason to do so. Both have similar functions such as audio output, keyboard input, and window display functions, so mixing them together as opposed to sticking with one individually doesn't come with many benefits and could cause potential conflicts.
What do you like about pyglet over pygame?
It seems to me that dicorations are easier than classes and objects. But I know that with the dicorations the speed of the program is lower, and the classes and objects I do not know very well.
@magurp: True, though I get the feeling he'll try this way, and either (a) conclude that it's too hard and will switch to something easier (bgt comes to mind as the go-to easy language), or (b) he'll stick with this way, because it works and the correct way is "weird".
I think your right about the clock ticking bit not (technically) being essential, but (in my admittedly limited experience), all but the simplest games will need a "frame rate" to schedule even the most basic of physics (gravity comes to mind), as well as automatic enemy movement and any number of other things that depend on a consistent ticking.
To the original poster: Just try examples. I don't care if you think decorators are weird - if you've read the documentation you should know you don't even need to use them, (assuming you know how to use class inheritance or can follow examples). There is plenty of material (tutorials, how-tos, explinations on how using them works) for decorators online, but as I mentioned, you don't really need to use them at all.
As for why I like pyglet? I like the event framework. I like that I can create events in my classes for in-game objects that allows code to "subscribe" to their events. It makes it really easy to have lots of things happen without specifically calling methods to do those things.
As a basic example, take a stationary item called a switch. When a player "uses" that switch, the use method only needs to dispatch, say, an on_use event. Any code that wants to run when that switch is used only needs to tell the event handler so, either by a decorator, or by calling a register method specifying which instance and event, or by pushing a class with lots of events relating to that switch on top of the event stack.
If i want to update that switch so that more things happen when it's used, all I need to do is register the the desired code as a handler for whatever instance and event I want.
It also has really convenient keyboard, mouse, and joystick functions, though I haven't really messed with pygame so I can't compare them.
Well yes and no, you don't necessarily need the clock to handle the framerate, physics, movement, etc. as the main loop iterates through cycles acting like a clock tick. Though doing it this way can be prone to wild fluctuations in the flow of the game based on resource load. If your not building real time applications like card or turn based games its not as much of an issue, but yeah in almost all cases its much more convient and reliable to use the clock. There are actually a number of classic games that were coded like this that haven't held up very well over the years, largely because they are unplayably fast on current gen processors without using emulating software like dosbox to throttle the processor speed.
If it helps, why not break each class or part you want to play around with into smaller examples to help familiarize yourself with them? That way you only need to focus on one or two as you go. It will take some time and patience, but breaking things and learning about them is part of the process and an occupational hazard of being a programmer, heh.
Nods, I'm assuming here that you want a stable game, not one that arbitrarily speeds up and sows down.