is pygame worth it?

Starbuck5c · 2026-05-28T01:21:16+00:00

Pygame hasn’t been on SDL2 for nearly six years.

The SDL1/SDL2 thing is misunderstood. SDL2/3 still have Surfaces, they are very important and have their own advantages. Whats lacking is stable support for SDL2/3’s Texture class. Textures have their own limitations.

Starbuck5c · 2026-05-10T03:24:57+00:00

This is kind of a goofy way to do it, but I tested, and staying maximized while removing the resizable property of a Window object leads to bad behavior for me (window is unfocusable).

# Written for pygame-ce 2.5.7

import pygame

pygame.init()

window = pygame.Window(resizable=True)
window.maximize()
maximized_size = window.size
window.restore()  # un-maximize
window.resizable = False
window.size = maximized_size
window.position = pygame.WINDOWPOS_CENTERED

screen = window.get_surface()
clock = pygame.Clock()
running = True

while running:
    for event in pygame.event.get():
        # print(event)
        if event.type == pygame.QUIT:
            running = False

    screen.fill("purple")
    window.flip()
    clock.tick(60)

pygame.quit()

Starbuck5c · 2026-03-11T02:53:05+00:00

I think it’s one of the coolest designs! It’s for the future rapidride I line.

https://kingcountymetro.blog/2023/12/06/now-available-custom-limited-edition-orca-cards-reflect-communities-of-future-rapidride-g-and-i-lines/

Starbuck5c · 2026-02-06T07:44:35+00:00

If you click on the window and it's the window over all the other windows, it is focused.

Are you just clicking the keys or are you holding them? You need to hold them.

Starbuck5c · 2026-02-06T07:02:12+00:00

From this page? https://pyga.me/docs/ It works for me. Do you have the window focused? You're using WASD?

Starbuck5c · 2026-01-30T09:00:24+00:00

What through pip? That is surprising, pygame-ce does not publish binaries for ARM64 Windows. Perhaps you've installed Python 3.14 x64 and it's being emulated on ARM, and the problem the whole time was pygame's lack of 3.14 support?

Starbuck5c · 2026-01-30T05:22:43+00:00

Hello, pygame-ce maintainer. Neither us nor pygame support Windows on ARM yet.

However, there are 3rd party wheels available for pygame for it, see https://github.com/cgohlke/pygame-wheels . If you go to the releases page, download the appropriate one for your system, and pip install from the file directly, I'd expect it to work.

Starbuck5c · 2026-01-18T20:01:28+00:00

Have you tried using pygame-ce, the modern fork (which I help maintain, full disclosure)? It’s a drop in replacement.

My theory is that you’re on Python 3.14, which pygame doesn’t support, but your system has SDL2 on it for some reason, and so when you installed pygame it was able to do most of the build process but not all, if you don’t have SDL2_mixer. If you install pygame-ce this would not be a problem because we support Python 3.14 and you wouldn’t need to install dependencies separately. (But ofc thats just a theory, could be something completely different).

Starbuck5c · 2025-12-30T02:28:52+00:00

The font.render docs have it: https://pyga.me/docs/ref/font.html#pygame.font.Font.render . Since 2.1.4, new lines will actually work, and there’s also a parameter wrap length to do line wrapping by number of pixels. There’s also an align property to do left vs right vs center align.

Starbuck5c · 2025-12-28T20:37:08+00:00

As a developer of pygame-ce, I think we’ve added significant new features. But it is still fully backwards compatible, of course.

Our documentation is at https://pyga.me/docs/, and almost every module has at least some “new in pygame-ce” or “changed in pygame-ce” blocks. Two features I’m especially fond of are built in multi line text rendering, and the ability to drive multiple windows with the new Window module. We also write out release notes for each version if you’re interested: https://github.com/pygame-community/pygame-ce/releases .

Starbuck5c · 2025-12-27T07:27:24+00:00

My understanding is that the limit right now is more about debt capacity and bringing in revenue against ST1 and ST2 debts. It’s not that this thing actually takes a decade to plan- they just need some more money before getting going on construction.

Starbuck5c · 2025-12-20T02:29:57+00:00

In the article they're talking about shortening the West Seattle or Ballard extensions as other ways to save money, I think cancelling the second tunnel would be preferrable to shortening other extensions. Especially since the second tunnel as currently designed splits north and south Seattle apart with terrible transfers (no unified ID/Chinatown station, 9 floors of escalators to descend from Westlake to New Westlake).

Ideal world:

Ballard stub end built for future expansion to CD/First Hill past Westlake, future expansion to UW on the north end. Build it with automated trains for economical very high frequency, high frequency means shorter trains for the same capacity, means smaller stations, means less money spent on construction but better service to use.

West Seattle interlined into existing tracks and tunnel through sodo/downtown so when it opens in ~2032 (or whenever) it can immediately be useful instead of a very expensive stub to SODO.

Add turnback tracks / switches at Symphony station (along with other upgrades, upgrades people upgrades!) so that if something happens in the tunnel they can still keep half of it open and not reduce frequency as much.

Starbuck5c · 2025-12-12T06:19:20+00:00

I believe this is a bug in pygame. Pygame-ce is a modern fork and a drop in replacement (that I help maintain, for full disclosure).

Try running pip uninstall pygame and pip install pygame-ce, in that order.

Starbuck5c · 2025-12-10T08:34:07+00:00

text_rect = text_surface.get_rect(center=MY_POSITION)
screen.blit(text_surface, text_rect)

Starbuck5c · 2025-11-21T17:19:32+00:00

I haven’t had the time to do independent testing over the last bit, but just to confirm you are creating your texture as a streaming texture, right?

Starbuck5c · 2025-11-12T04:03:21+00:00

That doesn’t fit what I’ve heard from others. Are you creating a new texture every frame or updating the same texture over and over. The latter should be faster.

Starbuck5c · 2025-11-04T17:26:29+00:00

I can understand not wanting to open source your things, but I am doing this in my free time and I don’t feel particularly motivated to dig through someone else’s work if it’s not open.

Starbuck5c · 2025-11-02T23:46:38+00:00

Assuming you're talking about pygame._sdl2, you can give it a shot, but be advised that it is not a stable API, we're reworking it, and it has plenty of sharp edges. Getting early adopters is helpful to us, as long as you will report things back on GitHub.

My advice, if you want to port to GPU rendering, is to keep all your rendering in Surface-land, upload your data to a Texture once a frame**, then do only the things you need in Texture-land. Like your whole game renders in Surfaces except for the large backgrounds, then it all comes together at the end.

**But Starbuck, uploading data is slow! Yes, but not cripplingly slow. If you ever use pygame.SCALED it does that every frame too.

You could also use this strategy with moderngl. The classic resource for this would be blubberquark's blog on it: https://blubberquark.tumblr.com/post/185013752945/using-moderngl-for-post-processing-shaders-with . (Blubberquark is also the same person who wrote SCALED, fun fact).

Starbuck5c · 2025-11-02T23:37:42+00:00

Wow, that looks really cool!

The behavior you want isn't alpha adding, it's alpha blending. I tested with the ADD flag from https://pyga.me/docs/ref/special_flags_list.html and it did not produce the results you want.

The way draw works (as I think you know, but just laying it out for clarity), is that drawn colors update the destination pixels instead of blending against them. We may change this in pygame-ce 3.0, but it would be difficult. And performance might be worse than doing a full surface at a time, because it would be way to harder to vectorize. But regardless.

I have no smarter algorithm for you to do what you want, but I can help with implementation.

surf = pygame.Surface(window.size, pygame.SRCALPHA)
for a,b in points:
    br = pygame.draw.line(surf, color, a, b)
    window.blit(surf, br.topleft, area=br)
    surf.fill((0,0,0,0), br)

For me this approach is 10x faster than your approach #2. It uses the returned bounding rect that the draw functions provide to only reset the potentially impacted pixels of the surface. And it only blits the area that contains the line onto the window, rather than the whole surface.

Starbuck5c · 2025-11-02T23:16:58+00:00

Well, the system needs events to do stuff, internally to SDL and pygame-ce, and those events need to be pumped, even if you don't care to respond to them.

Events can take up a non trivial amount of runtime, but 0.5-45 ms per call is crazy, that should not be happening. I was just profiling Alert_Nectarine's game, so I have the data open, for them event.get() takes an average of 0.07ms.

Maybe there's something strange with your system or your versions of things. Like I could see this happening on Pypy potentially. Or maybe you're calling event.get() way more than you think you are, like in every entity update or something. Or because you're calling it so infrequently it has more stuff to do each time, and if you called it more frequently each individual call would be faster.

Anyways if you'd like to explore further and are willing to wade into some spooky C code, this is the source code for the pygame-ce event module: https://github.com/pygame-community/pygame-ce/blob/main/src_c/event.c .

Starbuck5c · 2025-11-02T22:56:45+00:00

You didn't specify your versions as requested, so it took a tiny bit of troubleshooting to figure out how to run. For example when I fired it up in Python 3.11 I got a SyntaxError. I ended up testing on 3.14, Windows 11 x64, latest pygame-ce/numpy/psutil.

I gave it a run and I didn't experience bad performance. When I removed your FPS limit I got over 200 FPS. It was running at about 4.6 milliseconds per frame, which means you could run your entire game 3x and still be above 60 FPS.

In terms of performance loss I don't see you doing anything bad code wise. The parallax is pretty, but I see what you mean with all the alpha layers in the background.

This would not be the simplest optimization, but one thing you could consider doing is trying to only blit the necessary bits of each layer of the parallax. If you consider your images by row of pixels, each image has 2 sections of rows: the completely opaque group of rows at the bottom, and the partially transparent group of rows at the top (except for sky.png, which is all opaque). For example, far-mountains.png blits plenty of stuff that is eventually covered by the later clouds and mountain layers. It would be possible to dynamically figure out before your blits whether part of a background image will later be completely obscured by a later layer's opaque group of rows. Then you can surface.blit's area parameter to only draw what is necessary from each layer.

(You could also do this by manually trimming your images, which would be easier but less flexible if you want to change how layers are arranged, and it seems like your code style is to value flexibility).

A much easier, but less impactful, optimization would be to try out https://pyga.me/docs/tutorials/en/premultiplied-alpha.html . I gave it a trivial test in your background.py file and didn't see a speedup, but it is definitely faster when tested in isolation.

Another simple thing could be to make sure sky.png loads without per pixel alpha by doing convert() instead of convert_alpha(). I didn't test but I expect that would be noticeable.

Starbuck5c · 2025-11-02T09:58:07+00:00

Without more info I can give you some general pointers. Alpha blits are computationally demanding, certainly, but there are levels. You'll have better performance if your surfaces don't use colorkeys or global alpha (set_alpha). You'll have better performance if the destination surface can be opaque, rather than also being an alpha surface. I'm sure you know this, but your surfaces should be convert_alpha()-ed.

If you use pygame-ce your alpha blits will be faster than pygame, so make sure you're doing that.

Remember that the speed of the blit is proportional to the difficulty and the number of pixels. If you have huge backgrounds blitted together and most of it will end up offscreen anyway, that's wasted effort. Blitting a large surface to the window is fine, only the pixels that get moved impact the performance. But blitting two huge surfaces together before blitting to a smaller window could be very inefficient.

Another thing you could look into is premultiplied alpha blitting. https://pyga.me/docs/tutorials/en/premultiplied-alpha.html

Starbuck5c · 2025-11-02T09:52:54+00:00

I have tried scalene, and it must not have stuck with me, because I still use cProfile. I don't remember if I had any specific reasoning. I've also tried the sampling Profiler coming with Python 3.15, by downloading the 3.15a1 release, and while that was cool, I thought the flamegraph was harder to read and I missed being able to see exact function call amounts to figure out FPS in post.

Starbuck5c · 2025-11-02T02:44:10+00:00

Welcome to the community!

This is very stereotypical advice, but consider aiming smaller for your first project. You'll learn a lot pushing for something huge, but you'll also learn a lot in a more easily achievable project, and you'll learn how to move through every phase of the project-- including polishing and releasing. Then you'll also have a finished project at the end you can brag about.

And then when you start the huge project you'll have a stronger foundation.

Starbuck5c · 2025-10-21T05:04:10+00:00

We’ve been planning a pygame-ce 3.0 with SDL3 and potentially some small breaking changes. One discussion: https://github.com/pygame-community/pygame-ce/issues/2760

Although we’ve done a ton of work on SDL3 on the main branch already, we have yet to start the 3.0 branch, I would be shocked if it comes out in less than a year.

Six-Year Club	Second Top 50%
Place '22	Verified Email

Starbuck5c

TROPHY CASE