I've now added the sort Dan used in Armalyte as well, so theres now 3 different modes there all available as an option for when you start your game. To select them all you need to do is change a single equate value (setting it to 0,1 or 2) and the code will build the correct version (Try doing THAT with in a monitor!).In the case of randomly bouncing sprites Dan's clearly win's out even over my shiny new one, to the sum of 42 freely bouncing sprites all on a STOCK C64. Thats damn impressive I have to say. However, I'll emphisis that it really, Really, REALLY depends on the game and how your sprites are setup, banded, spawned, moved and all the rest - BUT with 3 separate sorts now here, you should be in good standing to pick the right one without having to mess around. The image shown here is actually the worst case (the red bar taking up top and bottom borders), normally it only takes up the lower border which is superb.
I'll also make the point that this is a frame work. Its NOT a finish bit of code. You should take this as a basic core, and shape it to target your game/applicate better. For example, if you want to have a 2 player game, you should modify the code to multiplex only 6 sprites, or if you WANT to multiplex 8 to allow for a player with multiples above and below again you should extend the code to do so.
The code is pretty well commented but due to a couple of bugs in SNASM (namely nested IF/ENDIF's dont work) I cant get the code fully auto generating yet.
I've also now added a player sprite which is controlable via the joystick and flashes away over the top of all the rest. So, barring anything else being requested (and I'll give it a couple of days) I'll write up some doc's and release it next week sometime....
Oh, and as a little aside.... when running this on a SuperCPU without even coding it in 65816 assembly, it takes up around 16 scans in total - including ALL the IRQ's....
No comments:
Post a Comment