3 ms·

For me it was my big brother passing his Commodore 64 down to me as he got himself an Amiga. First it was just playing games, then doing some stuff in the built

For me it was my big brother passing his Commodore 64 down to me as he got himself an Amiga. First it was just playing games, then doing some stuff in the built-in basic, and then following an assembly language course in a monthly magazine. By the time I managed to display eight sprites on the upper part of the screen, trigger a raster interrupt, move the same sprites to the lower part of the screen and thus have it appear as sixteen sprites on screen, I was hooked. It was like being able to wield magic.

ggambetta 8y ago
Similar story here, but on a ZX Spectrum :)
Flow 8y ago
My thing was sprite-multiplexers. In theory it's very simple. You sort the sprites by y-position, then use raster interrupts to reprogram the sprite registers for "(spriteN++ & 7)". The hardest part is sorting. It takes quite some time to sort data on a 6502. I "invented" my own sorting routine for this, but I later learned that most coders used bubblesort since most of the time sprites move just a little so it's mostly sorted already. My routine used half the stack. I took ypos >> 2 and used that as an index to the bottom half of the stack. If the position was occupied I used the next pos etc. To collect I simply used a PLA(pop) instruction. There were holes of course, so you had to check for empty slots. That routine took about the same time every frame. 32 sprites was not very hard to do, sorting-wise.
- BurningCycles 8y ago
  Yes, bubble sort was an obvious choice given it's easy to understand and implement, I came across this article some time ago which goes through many different ways to sprite sort for general multiplexing and presents 'continous insertion sorting' as the winner, was a fantastic trip down memory lane. http://selmiak.bplaced.net/games/c64/index.php?lang=eng&game=Tutorials&page=Sprite-Multiplexing http://selmiak.bplaced.net/games/c64/index.php?lang=eng&game...

ggambetta 8y ago

Similar story here, but on a ZX Spectrum :)

Flow 8y ago

My thing was sprite-multiplexers. In theory it's very simple. You sort the sprites by y-position, then use raster interrupts to reprogram the sprite registers for "(spriteN++ & 7)". The hardest part is sorting. It takes quite some time to sort data on a 6502. I "invented" my own sorting routine for this, but I later learned that most coders used bubblesort since most of the time sprites move just a little so it's mostly sorted already. My routine used half the stack. I took ypos >> 2 and used that as an index to the bottom half of the stack. If the position was occupied I used the next pos etc. To collect I simply used a PLA(pop) instruction. There were holes of course, so you had to check for empty slots. That routine took about the same time every frame. 32 sprites was not very hard to do, sorting-wise.

BurningCycles 8y ago
Yes, bubble sort was an obvious choice given it's easy to understand and implement, I came across this article some time ago which goes through many different ways to sprite sort for general multiplexing and presents 'continous insertion sorting' as the winner, was a fantastic trip down memory lane. http://selmiak.bplaced.net/games/c64/index.php?lang=eng&game=Tutorials&page=Sprite-Multiplexing http://selmiak.bplaced.net/games/c64/index.php?lang=eng&game...