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....
6 comments:
Nice work Mike,
I am seriously thinking of using your engine in one of my next games. If I get to understand how it works that is :D
Well, its not hard really. And if you got stuck all youd need to do was to access the sprite values and the rest would just magically happen for you :)
How about collision detection?
Collision detection is another one thats very game specific. But I guess some kind of player to everything else using box collision would be fine....?
Sure I could add that - although again I expect most games will ditch it and do their own... still it's not a bad idea....
In case someone needs all sprite-sprite collisions, it will help a lot if he uses the sorted list to reduce number of comparisons. With seven multiplexing sprites only player sprite and previous and next six sprites need to be checked. Even better, checking one direction can be stopped as soon as vertical delta > 20.
Player collision check can also be sped up with the help of sorted list. First skip all sprites more than 20 pixels above player, then do checks until sprite is >20 pixels below.
Making collision boxes smaller will reduce checks further.
Thats very true... This goes for everything in a game though. Know your data and know what it is your wanting to do.
The sort I've put in is quick and simple, nothing fancy - you can mod it as you need to, but its a good starting point. If you specalise it too quickly, then its not as useful as a starting point.
Also with 16 sprites you'd need to do 7 above you and 7 below (possibly)... and if they are bouncing randomly (not attached to paths etc) then you may have a full 16 to check - even if a couple have disappeared.... But like you say - once your past player+21, you can stop.
Anyways... the rule of a frame work is keep it simple, and then specialise it to hell when you know what your doing.
Post a Comment