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!
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.
Let me know if this was entertaining, useful or even both.
That's absolutely great read - especially recently I'm trying to get back to the childhood fun with C64 myself and re-learn some of the little programming I did back then, learn something new. Articles like this are a treat, thank you!
Yep, it's astoundingly inefficient. I've been meaning to pull the code back into working memory and do the things I mention in Future Considerations, but it took long enough just to do this write-up; could be years before I get around to it.
The smooth motion is nice, but a bit of overkill, also it adds complexity to the collision code.
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.
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.
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.
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.
This would make a pretty sweet screensaver back in the days when screensavers were more common. I could see myself as a kid staring at pong wars for quite a while.
Fun fact: a bouncing ball was one of the first programs that the C64 User Guide taught you: https://archive.org/details/commodore-64-user-guide/page/n57...
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!
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.
Let me know if this was entertaining, useful or even both.
That's absolutely great read - especially recently I'm trying to get back to the childhood fun with C64 myself and re-learn some of the little programming I did back then, learn something new. Articles like this are a treat, thank you!
This seemed promising at the beginning, but do yourself a favor and skip to the end to see the hilariously slow end result.
Yep, it's astoundingly inefficient. I've been meaning to pull the code back into working memory and do the things I mention in Future Considerations, but it took long enough just to do this write-up; could be years before I get around to it.
Nice!
Why not just go full character mode?
The smooth motion is nice, but a bit of overkill, also it adds complexity to the collision code.
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.
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.
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.
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.
This would make a pretty sweet screensaver back in the days when screensavers were more common. I could see myself as a kid staring at pong wars for quite a while.