making apps, making webs.

Drawing different types of pixels can be quicker if you know about the image you are drawing, and if you know that drawing parts of the image with specialised blitters is quicker. A good example is if your image is 25% areas of large blocks of either white or black. Using a specialised fill routine to just draw those big blocks of color is lots quicker. This is because there is usually an optimised, and hardware accelerated fill routine. See all this whitespace? (all the white parts on your screen) These can be drawn really quickly with ASIC fill hardware rather than a slow GPU running a general purpose image blitter. Another example is like this Alien image. The edges of the image are transparent, but the middle has no transparency. Since drawing transparent images is slow, using a different drawing routine for the middle part than the edges turns out to be faster. Alien graphic used in Pygame Zero teaching framework documentation.   Here is a proof of concept which d

There's four things I'd like to work on for faster pygame apps on slower computers (like the Raspberry Pi/Orange Pi). Dirty rect optimizations, to speed up naieve drawing. SDL2, for better hardware support. C/Cython versions of pygame.sprite Surface.blits, a batching API for drawing many images at once. The general idea with all of these is to take techniques which have proven to improve the performance of real apps on slower computers. Even though, for some of them there are still open questions, I think they are worth pursuing.  Even though more advanced techniques can be used by people to work around these issues, this should be fast even if people do things the easy way on slower computers. Anyway... this is a summary of the discussions and research on what to do, and a declaration of intent. Dirty Rect optimizations. First a couple of definitions. "Dirty Rect" is a technique in graphics where you only update the parts that changed (the dirty parts

Help? Since asking people to use pip to install things, I get a lot of feedback on pip not working. Feedback like this. "Our fun packaging Jargon " What is a pip ? What's it for? It's not built into python?  It's the almost-default and almost-standard tool for installing python code. Pip almost works a lot of the time. You install things from pypi. I should download pypy? No, pee why, pee eye. The cheeseshop. You're weird. Just call it pee why pee eye. But why is it called pip? I don't know. "Feedback like this." pip is broken on the raspberian pip3 doesn't exist on windows People have an old pip. Old pip doesn't support wheels. What are wheels ? It's a cute bit of jargon to mean a zip file with python code in it structured in a nice way. I heard about eggs... tell me about eggs? Well, eggs are another zip file with python code in it. Used mainly by easy_install. Easy install? Let's use that, this is all too mu

Some notes about the current state of comments, and thoughts about future plans are below. 0) Spam. So far there hasn't been comment spam on the new comment system(yet!)... but eventually some will get through the different layers of defense. Which are a web app firewall (through cloudflare) (which helps block bots and abusive proxy servers), user signups required, limits on the number of accounts and comments that can be posted per hour, making the spam useless for SEO(nofollow on links) and then a spam classifier. The spam classifier is pretty basic. It only uses the message text so far, and not other features like 'how old is the poster account', or 'does the user account have another other accounts linked'. Despite that, and only having been trained on a few thousand messages it seems classification works pretty well. It scores 0.97 for ham, and 0.76 for spam when it is cross validated on the test set. It's sort of weird having sour

"BULLSHIT! That bullet didn't even hit me!" they cried as the space ship starts to play the destruction animation, and Player 1 life counter drops by one. Similar cries of BULLSHIT! are heard all over the world as thousands of people lose an imaginary life to imperfect collision detection every day. Do you want random people on the internet to cry bullshit at your game? Well do ya punk? Bounding boxes are used by many games to detect if two things collide. Either a rectangle, a circle, a box or a sphere are used as a crude way to check if two things collide. However for many games that just isn't enough. Players can see that something didn't collide, so they are going to be crying foul if you just use bounding boxes. Pygame added fast and easy pixel perfect collision detection. So no more bullshit collisions ok? Code to go along with this article can be found here ( https://github.com/illume/pixel_perfect_collision ). Why rectangles aren