This seemed promising at the beginning, but do yourself a favor and skip to the end to see the hilariously slow end result.
Fun fact: a bouncing ball was one of the first programs that the C64 User Guide taught you: <a href="https://archive.org/details/commodore-64-user-guide/page/n57/mode/2up" rel="nofollow">https://archive.org/details/commodore-64-user-guide/page/n57...</a><p>Yes, that's right kids: the C64 came with a manual that didn't just teach you where to flip the power switch of your computer but actually how to program it!
Nice!<p>Why not just go full character mode?<p>The smooth motion is nice, but a bit of overkill, also it adds complexity to the collision code.<p>I suspect this can be done using a variation of Bresenham's line algorithm for the trajectories (keeping delta X and delta Y for each ball) and avoid most/all of the complex trig and math. Just addition and subtraction and a few sign changes.<p>The delta can be kept at a higher resolution than the grid (i.e. 16x so a mask can be used instead of division), so you can fudge the collision with small delta changes on impact using the SID as a RNG.
Hey, thanks for checking this out. I wanted smooth motion to keep close to the JS piece that inspired this; it seemed like it should be eminently possible to get smooth motion, after all.<p>And yeah, I was reminded of Bresenham's algorithm a few days back, and had a suspicion that I've basically redone it independently (and inefficiently) by doing the trig. As mentioned at the end there, the math isn't where I'm losing most time in rendering though.<p>The Mastodon release post (cite 0) has comments talking about doing the score recalculation only at time of collision, but the worst thing I do is use a block of RAM for the playing field and another block of RAM for the _display_ of the playing field. Copying those blocks of 20 bytes, gosh it's slow.
I think it's easier to implement with sprites, but the complex trig and math is unnecessary either way.
Over the years I've written a bunch of things in the orbit of retrocomputing, the largest of which was an incremental game based on a C64 emulator. Somehow I've never written anything substantial for the C64 itself; this post documents my learning while implementing a graphical effect in assembly language, over the course of twelve thousand words and three digressions into side quests.<p>Let me know if this was entertaining, useful or even both.