Understanding Memory through Pong (C + SDL2)
Building a Ping Pong game in C using SDL2 to understand how real-time systems behave at the memory level.
I built a Ping Pong game in C using SDL2, not as a nostalgia project or a beginner exercise, but to understand how real-time systems behave at the memory level.
The Illusion of Movement
The most important realization was that nothing on screen actually “moves.” Paddles, ball, and score are just structs in memory, and each frame the program mutates a small set of values like position and velocity. SDL simply renders whatever state currently exists. Once this clicks, game programming stops feeling magical and becomes deterministic.
The Game Loop
The program is driven by a classic game loop that strictly separates input sampling, state updates, and rendering.
2. State updates apply rules.
3. Rendering is a pure visualization step that never mutates logic.
This separation is what keeps behavior predictable as complexity grows.
State Machines & Clean Code
The game uses an explicit state model: waiting, playing, and paused, so physics runs only when allowed. Pausing does not freeze input or rendering; it simply halts state mutation. This small state machine eliminates scattered conditionals and scales cleanly.
Pointers & Persistance
Pointers are central throughout the code, not as a low-level gimmick but because passing structs by value would silently break behavior. Movement, collision, and scoring persist only because functions operate directly on shared memory.
Physics: Velocity vs Position
Ball physics reinforced another subtle lesson: collision response should act on velocity, not position. Walls and paddles reflect velocity vectors, which produce stable motion. Even then, correctness is not automatic without explicit vector normalization; otherwise, the ball slowly accelerates after repeated collisions. This bug is common, accumulative, and easy to miss.
Conclusion
Scoring is implemented as a controlled state transition: when the ball exits the screen, the score increments, the ball resets, and the game returns to a waiting state. Rendering remains unaware of why values changed; it only reflects current memory. Even text rendering follows this model, converting state into textures through an explicit pipeline.
The project is small by design, but it reinforced ideas that scale far beyond Pong: why game loops are structured the way they are, why state machines matter, why pointers exist, and how small mathematical decisions can destabilize systems over time.
Concurrency vs Parallelism (and why you're confused)
→Concurrency is about how a program is structured. Parallelism is about how a program runs. Mixing them up doesn’t make you clever.
Best Practices for Prompt Engineering: A Practical Guide
→Ten practical rules for designing reliable, repeatable prompts for large language models, with clear explanations and copy-pasteable examples.