Thanks for your constructive criticism!

The window size is actually 4 times the framebuffer size; 3/4 of the current size should work fine.

Yes, the sound effects are actually generated on sfxr, I didn't actually played around much, after I had found some sounds that were good enough. I can change that, I get your point :)

And with the collision detection: I actually use a discrete approach. So yeah, tunneling is an issue which I could fix by just restricting the maximum velocity the ball can move. My approach is that I first check if a collision occurs and if it does, I handle both axis separately to resolve the collision. I might have a clue why collisions are resolved in the wrong direction. I will have a look at that. After all, I will have a look on continuous collision detection, that's something I want to learn about anyway.

I'm a software engineer with a strong focus on computer graphics, but actually never got my hands dirty on game programming, which is a hole different beast. I used an data oriented approach instead of a "classical" object oriented approach. This way I didn't end up with overengineering things, like I tend to do with my never ending side project of a 3D game engine (which is actually more a 3D rendering framework, but who knows the difference nowadays, right? :)

I didn't really care about the size. 200kb is actually pretty much for such a small game. BMP/WAV for ease of use isn't the go to decision when you aim for compression haha.