Pygame 2.0(github.com)
github.com
Pygame 2.0
https://github.com/pygame/pygame/releases/tag/2.0.0
62 comments
I don't know specifically about pygame, but since it uses SDL, and SDL can run in browsers using emscripten, I wouldn't be surprised.
I've written a lot of stuff in pygame on the pi.
The major issue I ran into was no hardware acceleration, so performance came from (software) blits of only the updated part of the screen and similar techniques.
But I found it very fun to program in an environment with integrated graphics and sound and fonts and video and input devices and a event loop with timer ticks.
A lot of linux folks are thinking x vs wayland, but I'll bet if we replaced everything with an integrated environment that had everything necessary to support a game, we would have much better linux user interfaces.
The major issue I ran into was no hardware acceleration, so performance came from (software) blits of only the updated part of the screen and similar techniques.
But I found it very fun to program in an environment with integrated graphics and sound and fonts and video and input devices and a event loop with timer ticks.
A lot of linux folks are thinking x vs wayland, but I'll bet if we replaced everything with an integrated environment that had everything necessary to support a game, we would have much better linux user interfaces.
I put together a halloween display using a Kinect and pygame for my front yard (very quickly hacked together by the way):
https://github.com/erahhal/kinect-halloween-skeleton
Pygame is nice and easy to use, though I think I'd go with something else next time, as it doesn't support multiple monitors or OpenGL very well. I see OpenGL stuff at the top of the Pygame 2.0 change list so maybe worth checking out.
https://github.com/erahhal/kinect-halloween-skeleton
Pygame is nice and easy to use, though I think I'd go with something else next time, as it doesn't support multiple monitors or OpenGL very well. I see OpenGL stuff at the top of the Pygame 2.0 change list so maybe worth checking out.
It supports multiple monitors and has better OpenGL support now.
I've looked in the docs for multi-monitor support without luck - do you have a link?
When I first learned Python (2.5, so old!), pygame was my introduction to programming GUIs, sounds, and games. I learned a lot about Python using pygame. I am surprised to see it's still going fairly strong!
Great news! There were 5+ years during which I warned people away from Pygame. First there was no official release with Python 3 support in sight. Once that happened, I was disappointed that it still used the old SDL, which was utterly obsolete by then.
The last area I'd like to see improved is the documentation. But the list of stuff that did get done over the last couple of years looks fantastic. Thanks to all the contributors; I'm looking forward to kicking 2.0's .whls.
The last area I'd like to see improved is the documentation. But the list of stuff that did get done over the last couple of years looks fantastic. Thanks to all the contributors; I'm looking forward to kicking 2.0's .whls.
Nice! The first real game I ever made was with pygame :) https://github.com/samertm/snake-python
Made this in a few days (it is a tetris which starts shaking, rotating, inverting and solarizing the area as you pass levels)
https://github.com/nurettin/tedriz
I don't know if pygame is really easy or if I got pretty good at coding in python. Probably the former.
https://github.com/nurettin/tedriz
I don't know if pygame is really easy or if I got pretty good at coding in python. Probably the former.
Any good commercial games released?
I have no idea, but to me the opposite of good commercial games is the point here. What is not to love about a title such as mediocre tetris: https://www.pygame.org/project/5421/7844
I have heard that "Unity of Command", the WW2 themed wargame was built in pygame.
This comes to mind: https://store.steampowered.com/app/951360
DaFluffyPotato also shares his Pygame work on Twitter, if you are interested in professional Pygame development his timeline may be worth checking *
* https://twitter.com/dafluffypotato?lang=en
* https://twitter.com/dafluffypotato?lang=en
This is cheating, but renpy is based on pygame. So tons of visual novels are technically made in pygame, the most popular is probably Doki Doki Literature Club.
Fantastic! Feels like it's been a dead project for so long, it's good to see it's properly back and fully modernized.
Pygame is great, I've used it for a one day gamejam and despite not being familiar with it, i was up and running quickly.
As coincidences go, just the day before yesterday I looked into pygame and came across this Quora question: https://www.quora.com/Is-Pygame-fast-enough-for-modern-game-...
The sentiment seems to be that it's not suitable for more than small toy games -- which in itself would still be interesting. I mean, it's clear that professional AAA studios are not the core target group.
But has anyone here on HN additional hands-on experience that would support or reject the above assessment?
The sentiment seems to be that it's not suitable for more than small toy games -- which in itself would still be interesting. I mean, it's clear that professional AAA studios are not the core target group.
But has anyone here on HN additional hands-on experience that would support or reject the above assessment?
It's a friendly wrapper to SDL. The people saying "but it's not a serious engine" are letting the point of it fly over their head. If what you want is some raw control over I/O it's a fine choice, provided you aren't going for a compute-intensive main loop. I know of a few folks who shipped pygame stuff in the 2000's - that was an era when software rendering was still defacto the right choice for high compatibility, and of the options for speeding up development, a dynamic typed language offered some compelling advantages. If your game didn't scroll the screen, or targeted low res and 256 colors, or you mixed it with pyOpenGL, it was hardly the end of the world. The first comment in that Quora thread is from a student, who unsurprisingly has blamed the tool.
Emphasis on "pygame is slow" mostly comes down to "Python* is slow", and that, too, has an asterisk in that you can hybridize to add Cython or a C module. It will never be as fast as a good native code implementation, but when using all available tools to extend performance, you could easily accomplish just about anything from 90's-era gaming.
Emphasis on "pygame is slow" mostly comes down to "Python* is slow", and that, too, has an asterisk in that you can hybridize to add Cython or a C module. It will never be as fast as a good native code implementation, but when using all available tools to extend performance, you could easily accomplish just about anything from 90's-era gaming.
I am working at a company that is tracking vehicles using GNSS antennas. When designing the vehicle dynamics model for the Kalman Filters, I found it useful to have a graphical representation (including error ellipses, velocity vectors etc). Turns out that pygame was a great fit for that type of visualization.
Fast forward to two days ago, when I was idly watching George Hotz design a monocular visual SLAM prototype in 11h. Much to my surprise, one of the first things he fires up is pygame for visualization [1]!
[1] https://youtu.be/7Hlb8YX2-W8?t=701
Fast forward to two days ago, when I was idly watching George Hotz design a monocular visual SLAM prototype in 11h. Much to my surprise, one of the first things he fires up is pygame for visualization [1]!
[1] https://youtu.be/7Hlb8YX2-W8?t=701
I used pygame for a reinforcement learning course assignment: I built a gridworld simulator where you can input a text file with the origin, goal and obstacles, and watch as an agent learns a policy using Q-learning. It's based on a visualization used in a Berkeley RL bootcamp: https://miro.medium.com/max/992/1*FnCKMEFZC9QRnxLWT3lSCA.png
I never got to open-sourcing it though
I never got to open-sourcing it though
I can't speak to PyGame2, but PyGame circa 2010 was definitely super slow compared to, say, Java and SDL. For some kinds of games it was fine, and it was good for prototyping and if you were just getting in to game dev.
That was more or less Python's fault, rather than PyGame, which uses SDL also. I remember getting a huge speedup for one game with import psyco; psyco.full(). It's going to continue being true that Python + whatever is going to be slower than almost any other lang + whatever, even with more GPU support. But still, lots of games (even shippable ones) are possible, and lots of non-game applications. I'm still in love with the pygame/SDL1 way of doing 2D graphics, it was just so straightforward, and working with their interfaces and abstractions (pygame.sprite was nice) rather than SDL directly was always more pleasant too.
From my limited experience with Pygame, I found that it struggles[1][2] with sprite rotations. I am assuming that this was happening due it being using software rendering instead of the GPU which might have changed now with Pygame 2.0.
[1] https://github.com/ducaale/nyan/blob/feature/lines/examples/...
[2] https://youtu.be/OfaZavigYUw
[1] https://github.com/ducaale/nyan/blob/feature/lines/examples/...
[2] https://youtu.be/OfaZavigYUw
I've done a fair amount with Pygame. It's great for learning the fundamentals of 2D graphics and little toy games, it works well for writing simple programs to do things with image data, and I imagine you could use it to pretty easily get an OpenGL window to draw into.
I would not recommend using Pygame to develop a serious game project. All of Pygame's provided functions use software rendering, so you won't be able to take advantage of the graphics card. More seriously, Pygame includes essentially none of the features that come out of the box in a modern game engine, so you have to do things like write the event loop yourself and find your own solutions to physics and animation and figuring out which UI element is currently under the mouse cursor. Great for learning how that stuff works, not great for getting a high-quality game shippable.
I would not recommend using Pygame to develop a serious game project. All of Pygame's provided functions use software rendering, so you won't be able to take advantage of the graphics card. More seriously, Pygame includes essentially none of the features that come out of the box in a modern game engine, so you have to do things like write the event loop yourself and find your own solutions to physics and animation and figuring out which UI element is currently under the mouse cursor. Great for learning how that stuff works, not great for getting a high-quality game shippable.
Are you sure you're not talking about an older version of Pygame regarding the software rendering? I haven't used it but the very first bullet point in the list of changes of this release says:
> Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other modern hardware accelerated video APIs across many platforms.
> Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other modern hardware accelerated video APIs across many platforms.
pygame team member here
There's an important caveat: We provide an API for the SDL2 render system, and some functionality for up-scaling pixel art games on the GPU, but existing pygame 1.x games won't magically become faster by running on PyGame 2.0. They will be a little faster, because we have new, optimised blitting and drawing routines. To make use of GPU-based rendering, you will need to use the new APIs.
There's an important caveat: We provide an API for the SDL2 render system, and some functionality for up-scaling pixel art games on the GPU, but existing pygame 1.x games won't magically become faster by running on PyGame 2.0. They will be a little faster, because we have new, optimised blitting and drawing routines. To make use of GPU-based rendering, you will need to use the new APIs.
Would the pygame team be interested in presenting a talk at the Debian gaming mini-conf?
https://mdco2.mini.debconf.org/ https://wiki.debian.org/DebianEvents/internet/2020/MiniDebCo...
https://mdco2.mini.debconf.org/ https://wiki.debian.org/DebianEvents/internet/2020/MiniDebCo...
Hello. pygame volunteer here.
Here's some awesome libraries and frameworks that work with or are built on top of pygame.
pygame_gui - gui elements for pygame.
pymunk - 2d physics library. Lots of examples, very well maintained.
Thorpy - a GUI library for pygame.
pyscroll - Scrolling maps. Fast scrolling images easy.
pyTMX - Reads Tiled Map Editors TMX maps. Can use a Map editor easily.
spritesheetlib - loading sprite sheets.
animation - Tasks and tweening using pygame groups. No framework needed to smoothly move sprites or execute things over time.
pyknic - collection of useful tools (tweening, animation, context, timing, fonts, spritesystem, skeleton, ...) for games.
pytmxloader - Map loader for tmx files
pygame-text - Greatly simplifies drawing text with the pygame.font module.
Wasabi2d - cutting edge python game framework.
pgzero - game framework built on top of pygame. Intended for education.
moderngl - Modern OpenGL bindings for python. pygame-menu - A menu for pygame, simple, lightweight and easy to use.
Here's some awesome libraries and frameworks that work with or are built on top of pygame.
pygame_gui - gui elements for pygame.
pymunk - 2d physics library. Lots of examples, very well maintained.
Thorpy - a GUI library for pygame.
pyscroll - Scrolling maps. Fast scrolling images easy.
pyTMX - Reads Tiled Map Editors TMX maps. Can use a Map editor easily.
spritesheetlib - loading sprite sheets.
animation - Tasks and tweening using pygame groups. No framework needed to smoothly move sprites or execute things over time.
pyknic - collection of useful tools (tweening, animation, context, timing, fonts, spritesystem, skeleton, ...) for games.
pytmxloader - Map loader for tmx files
pygame-text - Greatly simplifies drawing text with the pygame.font module.
Wasabi2d - cutting edge python game framework.
pgzero - game framework built on top of pygame. Intended for education.
moderngl - Modern OpenGL bindings for python. pygame-menu - A menu for pygame, simple, lightweight and easy to use.
Can recommend PyScroll / PyTMX - made it very easy to make an RTS interface: https://github.com/EamonnMR/OpenLockstep
Yup! I've worked a bit with pyGame to build a robot interfaced with a PS3 joystick. By far the easiest library I've used for interfacing Python scripts with a joystick.
I built a game engine and some games on top of Python, way back in the day when I was still learning programming.
Pygame on its own really gives you none of the features that a proper game engine needs, such as support for animated sprites, a map loader, a camera system (in Pygame, everything is in screen coordinates, and you can't zoom in or out), a real physics engine, a particle system, tweening, and so on. And unfortunately, back then, because it was still running on top of SDL1, it used a software renderer, which made it very painful to implement these features as well. Features that require whole-screen updates, such as smoothly zooming in on a tilemap, were just impossible to implement in a way that would still give you 60fps. This may have improved with the switch to SDL2, but the fact that you have to handroll a lot of things has not.
I consider Pygame to be a good toy for beginners: it has relatively little complexity, while at the same time still feeling like an actual API and in principle gives you a foundation that really cool and fun things can be built on (unlike turtle or other things that are only toys). But if you're not looking to play, you're looking to make a game, it's obviously a wrong choice.
Pygame on its own really gives you none of the features that a proper game engine needs, such as support for animated sprites, a map loader, a camera system (in Pygame, everything is in screen coordinates, and you can't zoom in or out), a real physics engine, a particle system, tweening, and so on. And unfortunately, back then, because it was still running on top of SDL1, it used a software renderer, which made it very painful to implement these features as well. Features that require whole-screen updates, such as smoothly zooming in on a tilemap, were just impossible to implement in a way that would still give you 60fps. This may have improved with the switch to SDL2, but the fact that you have to handroll a lot of things has not.
I consider Pygame to be a good toy for beginners: it has relatively little complexity, while at the same time still feeling like an actual API and in principle gives you a foundation that really cool and fun things can be built on (unlike turtle or other things that are only toys). But if you're not looking to play, you're looking to make a game, it's obviously a wrong choice.
Pygame is great if you want to enjoy the process of low-level game programming but also want to abstract away the lowest levels. If your goal is to build a product (rather than enjoy a process) picking up a game engine is probably going to yield faster results.
I wanted to counter some of the child comments who say that it's a bit of a child engine with some real world results. After all, people are making great games today with Pico-8 or on a Game Boy, surely there must be some great indie Pygame games. Now, these aren't AAA developers, but it seems to have as much capability as something like Love2D does.
Sure enough, there's quite a few = https://itch.io/games/made-with-pygame
(Side note, when I first searched for the 'pygame' tag on Itch, I got nothing. It didn't even suggest it as a tag, wouldn't let me search for it. However Googling "games made with pygame" provided the Itch tag as the first result, not sure why that was)
Sure enough, there's quite a few = https://itch.io/games/made-with-pygame
(Side note, when I first searched for the 'pygame' tag on Itch, I got nothing. It didn't even suggest it as a tag, wouldn't let me search for it. However Googling "games made with pygame" provided the Itch tag as the first result, not sure why that was)
To go even further, here's a breakdown on engine use on indie games on Itch.
- Unity - 25,954 tags
- GameMaker - 6141 tags
- Godot - 4192 tags
- RPGMaker - 3979 tags
- Unreal Engine - 3915 tags
- Pico-8 - 2446 tags
- LÖVE - 1581 tags
- PyGame - 226 tags
- Unity - 25,954 tags
- GameMaker - 6141 tags
- Godot - 4192 tags
- RPGMaker - 3979 tags
- Unreal Engine - 3915 tags
- Pico-8 - 2446 tags
- LÖVE - 1581 tags
- PyGame - 226 tags
Having used both Love2D and Pygame, Love2D is far and away more capable than Pygame used to be, because it can actually use GPU acceleration, and because Lua's features (like coroutines) make for a far more expressive way to write games.
Which isn't to say that people can't use Pygame to good effect, but that you're working uphill with it a lot more.
Looking at other comments here, though, it sounds like newer versions of pygame stepped up significantly in terms of what can be done. Kudos!
Which isn't to say that people can't use Pygame to good effect, but that you're working uphill with it a lot more.
Looking at other comments here, though, it sounds like newer versions of pygame stepped up significantly in terms of what can be done. Kudos!
I self learned pygame in high school, 15 years later I’m still using it for mapping and rendering - I probably shouldn’t, but I find the library just so damn intuitive.
Congrats To the pygame team, and thank you for being the core tool which truly taught my objective code, and many UI design concepts (:
Congrats To the pygame team, and thank you for being the core tool which truly taught my objective code, and many UI design concepts (:
That's cool, what kind of mapping and rendering are you doing with it?
Again things I shouldn’t be using it for. I plotted latency/ping on a map When I was having pretty bad internet trouble in early Uni. I rendered some pixel-perfect shapes when building a stub website (At the time I didn’t know how to use Inkscape). I think at some point I visualised exponential mathematical algorithms too.
My initial project was to build a media center similar to Kodi. It was horrible, pseudo-objective, and built UI components from event and pixel blitting primitives. It was a year 12 project (in a ‘pick your project’ non IT class). It probably actually pushed me to complete year 12, and gave me a good foundational basis for IT at uni. I was a ‘troubled’ student who hated school, was bullied pretty bad, and hung out with people actively abusing drugs and alcohol. 15 years on am thankful I’m not a methhead, I’m sure that Kodi project had a part in saving me no matter how unstable and poorly written it was.
My initial project was to build a media center similar to Kodi. It was horrible, pseudo-objective, and built UI components from event and pixel blitting primitives. It was a year 12 project (in a ‘pick your project’ non IT class). It probably actually pushed me to complete year 12, and gave me a good foundational basis for IT at uni. I was a ‘troubled’ student who hated school, was bullied pretty bad, and hung out with people actively abusing drugs and alcohol. 15 years on am thankful I’m not a methhead, I’m sure that Kodi project had a part in saving me no matter how unstable and poorly written it was.
Wow, this is still being worked on? Amazing, keep up the good work!
Any uses of it for things that aren't games?
We used it (first directly, and then via PsychPy) for running vision experiments.
You need to be a little careful about timing, but otherwise it's not bad....
You need to be a little careful about timing, but otherwise it's not bad....
Impressive (http://impressive.sourceforge.net) is a PDF slideshow viewer based on Pygame.
My wishlist:
* Integration with numpy/scipy/matplotlib/etc.
* Integration with Python Mode for Processing
* Integration with either the Arduino or the Micro:bit ecosystem
* Integration with Pygame Zero (so there are smooth, documented ways to transition -- low floor/high ceiling, rather than two modes of working)
* Eventually, integration and wrapping of OpenCV
In other words, Pygame would benefit from integrating with the broader ecosystem one might wish to use to teach kids to code. Writing games involves a lot of math, image processing, and similar, and 2020 computers are fast enough kids can do that without writing optimized assembly. It's nice if games can be physically embedded (Arduino/Micro:bit).
Right now, there's a collection of projects, but they don't play well together. The level of contortions one must go through to move a sprite from being a numpy array to an image in whatever library, to an image in another library, is well beyond what most kids (or even teachers) can handle.
* Integration with numpy/scipy/matplotlib/etc.
* Integration with Python Mode for Processing
* Integration with either the Arduino or the Micro:bit ecosystem
* Integration with Pygame Zero (so there are smooth, documented ways to transition -- low floor/high ceiling, rather than two modes of working)
* Eventually, integration and wrapping of OpenCV
In other words, Pygame would benefit from integrating with the broader ecosystem one might wish to use to teach kids to code. Writing games involves a lot of math, image processing, and similar, and 2020 computers are fast enough kids can do that without writing optimized assembly. It's nice if games can be physically embedded (Arduino/Micro:bit).
Right now, there's a collection of projects, but they don't play well together. The level of contortions one must go through to move a sprite from being a numpy array to an image in whatever library, to an image in another library, is well beyond what most kids (or even teachers) can handle.
Are you serious? At least opencv is odd ...
A pygame volunteer here.
Wish lists are fun. True, integration is important. We should do more. Luckily some of yours already came true!
:)
For image sharing, there's a surfarray, and sndarray modules for integration with numpy. pygame.image.frombuffer/tobuffer to going to and from buffers. PIL(low), opencv, and other python image and audio libraries can be used pretty easily this way. There's articles, books and videos on how to integrate with most other libraries. Since python 3.3 or so there's been a much better buffer interface at the C and python API levels which many python libraries are using for integration. There's currently a gap in typing around this, but there's some progress.
If you don't like the 11MB download for numpy, we have a builtin pixel array module that can do a lot of the same stuff for images. There's also some built in Vector math objects (modeled closely on the GLSL ones).
The pixel array stuff is usually a hit in class settings because doing visual affects is very easy to write. As you say, computers are fast enough. Better (although more advanced) is probably the shadertoy website :)
Mu Editor, has built in support for pygame/pygame zero. It even comes with a pygame+arduino example. There's tutorials about for teaching it with microbits (and other little devices).
CircuitPython comes with some built in game libraries. This is probably better to use than pygame. It's best place to look probably for python on micros if you're into crafting games on very small devices. pygame comes preinstalled with raspberry pi, so that's also an option considering some of them can be found for $5 (or for free if you go hunting around dusty drawers).
We have some Python Mode for Processing users. There's a big community of video artists using pygame, and pygame comes built into some of the most popular video synths in recent years.
Python Mode for Processing does a lot of cool things right, and is definitely better than pygame for what it does. It would be great if some of the integration work done in this direction would continue. It's one of the most compact and readable ways to go. pygame zero follows this style a little bit, but being able to reuse code and concepts from both communities is even better.
Wish lists are fun. True, integration is important. We should do more. Luckily some of yours already came true!
:)
For image sharing, there's a surfarray, and sndarray modules for integration with numpy. pygame.image.frombuffer/tobuffer to going to and from buffers. PIL(low), opencv, and other python image and audio libraries can be used pretty easily this way. There's articles, books and videos on how to integrate with most other libraries. Since python 3.3 or so there's been a much better buffer interface at the C and python API levels which many python libraries are using for integration. There's currently a gap in typing around this, but there's some progress.
If you don't like the 11MB download for numpy, we have a builtin pixel array module that can do a lot of the same stuff for images. There's also some built in Vector math objects (modeled closely on the GLSL ones).
The pixel array stuff is usually a hit in class settings because doing visual affects is very easy to write. As you say, computers are fast enough. Better (although more advanced) is probably the shadertoy website :)
Mu Editor, has built in support for pygame/pygame zero. It even comes with a pygame+arduino example. There's tutorials about for teaching it with microbits (and other little devices).
CircuitPython comes with some built in game libraries. This is probably better to use than pygame. It's best place to look probably for python on micros if you're into crafting games on very small devices. pygame comes preinstalled with raspberry pi, so that's also an option considering some of them can be found for $5 (or for free if you go hunting around dusty drawers).
We have some Python Mode for Processing users. There's a big community of video artists using pygame, and pygame comes built into some of the most popular video synths in recent years.
Python Mode for Processing does a lot of cool things right, and is definitely better than pygame for what it does. It would be great if some of the integration work done in this direction would continue. It's one of the most compact and readable ways to go. pygame zero follows this style a little bit, but being able to reuse code and concepts from both communities is even better.
Neat! Thank you for the pointers.
That makes me really happy.
I'll narrow my request to a suggestion for something easier (indeed, easy enough I can do a bit myself): more documentation and tutorials. I think I'll get on that (although on my own pages; I'm not ambitious enough this month to contribute upstream). I did a fair bit of searching at one point, and didn't find this stuff. Now, I can try to come up with good kids activities.
I will also mention: Most kids can do pretty advanced stuff, if introduced correctly. We've been wedded to a particular order of teaching math for a very long time, which places things like convolutions as late college-level math, and long division as late elementary. In fact, convolution is a lot easier than long division. That's true for a lot of "advanced" math.
That makes me really happy.
I'll narrow my request to a suggestion for something easier (indeed, easy enough I can do a bit myself): more documentation and tutorials. I think I'll get on that (although on my own pages; I'm not ambitious enough this month to contribute upstream). I did a fair bit of searching at one point, and didn't find this stuff. Now, I can try to come up with good kids activities.
I will also mention: Most kids can do pretty advanced stuff, if introduced correctly. We've been wedded to a particular order of teaching math for a very long time, which places things like convolutions as late college-level math, and long division as late elementary. In fact, convolution is a lot easier than long division. That's true for a lot of "advanced" math.
It's really nice to see how type hints are spreading. I've been surprised how natural my adoption of them has been.
Indeed! I despised them initially thinking typing made code unreadable. But I've grown used to it and I only use type hints when necessary. I use Pydantic when I need more than just "hints" and when validating config file schemas.
Pydantic is extremely useful for validation and tab-completion. We've begun using it everywhere.
Pygame was one of my initial drivers for learning Python then using Linux and become a professional programmer. Congratulations!
Circa 2007 I started messing with pygame. Just this week I dug up some of my old code and typed `python main.py` thinking, no way this'll work. But it did.
The first feature on the Pygame 2 page is "Backward compatibility". Pygame's been way behind the times and I'm excited to see it getting some attention. But major kudos to the team for maintaining that priority.
The first feature on the Pygame 2 page is "Backward compatibility". Pygame's been way behind the times and I'm excited to see it getting some attention. But major kudos to the team for maintaining that priority.
An alternative, but much more disappointing explanation for this is that Pygame saw almost no development from '09 until about a year ago: https://github.com/pygame/pygame/graphs/contributors
It's a valid theory, but the page you linked says 2.3k commits over that period. More than enough to annihilate backwards compatibility unless you're very deliberate about it.
[deleted]
Blast from the past. I created a simple UI system for pygame a long time ago. It would be fun to hack on that again.
https://github.com/fictorial/pygameui
Wow. Pygame was one of my first forays into game development. I'm emotional now.
I think Python Arcade (https://github.com/pythonarcade/arcade) is/was a bit more active, right?
https://arcade.academy/pygame_comparison.html
When I checked PyGame, that was ages ago, and it looked a lot like a (higher-level) SDL wrapper to me, but more Pythonic. Although, coming from C++ and having used SDL before, I decided to use a more direct SDL wrapper instead. So I created my own simple ctypes-based wrapper (https://github.com/albertz/PySDL). But this is not really updated, and there are newer ones (e.g. https://github.com/marcusva/py-sdl2).
Anyway, I don't want to say these are better. It's great that PyGame is still active (again).
It's great to have such simple libraries to write games. Also for educational purpose, or just for fun. E.g. I wrote this (https://github.com/albertz/PyOverheadGame).
https://arcade.academy/pygame_comparison.html
When I checked PyGame, that was ages ago, and it looked a lot like a (higher-level) SDL wrapper to me, but more Pythonic. Although, coming from C++ and having used SDL before, I decided to use a more direct SDL wrapper instead. So I created my own simple ctypes-based wrapper (https://github.com/albertz/PySDL). But this is not really updated, and there are newer ones (e.g. https://github.com/marcusva/py-sdl2).
Anyway, I don't want to say these are better. It's great that PyGame is still active (again).
It's great to have such simple libraries to write games. Also for educational purpose, or just for fun. E.g. I wrote this (https://github.com/albertz/PyOverheadGame).
This blog based project home page obscures the relevant in favor of the recent.
Found the relevance on the About page.
"Pygame is highly portable and runs on nearly every platform and operating system."
Would appreciate a list but Ok.
Oh snap here we go:
"Truly portable. Supports Linux (pygame comes with most main stream linux distributions), Windows (95, 98, ME, 2000, XP, Vista, 64-bit Windows, etc), Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS and OS/2, but these are not officially supported. You can use it on hand held devices, game consoles and the One Laptop Per Child (OLPC) computer."
Wonder if it supports an HTML player?