C64 Framework progress

I'm doing pretty well with this so far and have managed to get 30 sprites being multiplexed using 7 hardware sprites. I usually prefer to leave one sprite for the player so that theres never any danger of them glitching or tearing, and also that being sprite one they will always appear over the top of the rest of the sprites. However if you wanted to multiplex all the hardware sprites, it should be pretty easy to modify things to do so. I've ended up putting both sorts in just in case theres a case where the old one wins out which may be possible in some rare instances, but mostly I expect folk to use the new one. I might also put in Dan's one from Armalyte as it has a differnt range as well and may provide yet another option given a games unique circumstanstances.

If no one gives anything else they'd really like to see added, then I'll simply add a single sprite being controlled by a joystick and that'll be it really. What's here is a good head start for any new game, as a solid multiplexor is always first on the list of things to write. Thats not to say this is the best option for every game mind. In Ballistix (and also Morpheus if memory serves), I used fixed IRQ bands and a sprite was inserted into a band the "Y" coordinate fell into. This has the added advantage that the SORT is virtualy instant as its basically a bucket sort. Take the Y coordinate, shift it down a bit, and store it at the end of the bucket list. Easy. However this multiplexor is very flexible and will allow for large joined sprites to move in sync which a fixed banded one wouldn't.

I will at somepoint do this for the Plus4 as well, but I'll need to untangle the software sprite system from XeO3 first, and that'll take time. I also don't expect people to use 30 sprites either, but its what this can manage when pushed to the limit - unless your on a super CPU of course, in which case you can use it incredibly high. I will also at somepoint release a proper SuperCPU framework but I suspect theres less demand for that since theres only a couple of folk that even HAVE one!

XeO3: A job well done....

Okay, I spent a little bit of time optimising the IRQ side of the multiplexor, and I can now get a sprite within 10-11 lines of the other set. Thats not bad, not bad at all (I seem to remember Blood Money being almost 20). This should be more than enough for a game. I more or less copied Dan's IRQ model for this (although I did a macro with some paramaters rather than having to maintain a whole chunk of code) and I've gotten it down to the barest minimum I can get away with. Heres the macro I used, which if you compare with Dan's, you'll find it quite close with only minor changes. If I had a couple of these, I could save an extra 4 per sprite - but thats excessive :)

;
; \0 = sprite number ( 1,2,3,4,5,6,7 )
; \1 = x+y offset ( 2,4,6,8,10,12,14 )
; \2 = NEXT sprite ( 2,3,4,5,6,7,1 )
; \3 = "b" for bcc or "j" for jcc
;
sub_amount    equ     10     ; number of lines before a sprite needs to be setup

SetUpSprite macro
DoSprite\0:
   cpy  #\0                  ; is this the Hardware sprite we're after?
   bne  NextHWSprite\0       ; not THIS sprite ->jump to next

SkipCPY\0:
   lda  XTable,x             ; Store the sprites "X" coordinate in the
   sta  $d000+\1             ; VIC hardware sprite register

   lda  $d010                ; get all sprite significant bits
   and  #~(1<<\0)            ; mask OFF this one
   ora  XSig,x               ; already set for the correct bit!
   sta  $d010                ; so we OR in this sprite and store it!

   lda  YTable,x             ; Get sprite Y coordinate
   sta  $d001+\1             ; store in VIC hardware register

   lda  XShape,x             ; get the sprite graphic
   sta  HWShape1+\0          ; Since we have a double buffered screen, 
   sta  HWShape2+\0          ; we store it in BOTH locations.

   lda  SprCol,x             ; Get sprite colour
   sta  $d027+\0             ; store in VIC hardware

   inx                       ; next sprite in list
   ldy  #\2                  ; next hardware sprite

   lda  YTable,x             ; Get sprite Y
   jeq  EndOfSpriteList2     ; 0? If so all finished
   sbc  $d012
   cmp  #4                   ; do we HAVE enough time for another IRQ? (magic number)
   \3cc SkipCPY\2            ; if not do it now!

   ;
   ; If we've lots of raster time until the next sprite
   ; but the sprite we will be copying over was already drawn
   ; by the VIC, then just copy it over NOW!
   ;
   ;sec                      ; Carry is ALREADY set
   lda  $d012                ; Get the current raster
   sbc  #22                  ; -22 gets us the last "safe" sprite
   sbc  $d001+(\2*2)         ; location. Now subtract the next sprite Y
   \3cs SkipCPY\2            ; is > last sprite, then setup NOW!


   ;
   ; If its further down the screen, and the current sprite
   ; is still being drawn, then setup a new IRQ just above the 
   ; sprite to handle it
   ;
   ;sec                      ; dont set carry, we'll offset this in the SBC
   lda  YTable,x             ; if we can't copy now, then we set up
   sbc  #sub_amount-1        ; a new RASTER IRQ based on the next sprite (-1 for SEC)
   sta  $D012                ; and its Y coord.
   jmp  EndMultiIRQ          ; and then this starts all over again!

NextHWSprite\0:
   endm

I may not have mentioned this to the C64 guys, but once the game is finished, I plan on giving the source out, along with some documentaion that should allow others to either skin it quickly into another shooter, or to hack it into something completely different. I've always thought that the main problem with the scene was that good games take time, so no one can usually be bothered to make one - and when they do, they feel completely attached to the source and want to keep their master-peice. So I decieded from Day 1 of the Plus4 version that it was all going to get released. There no money in it, so why hold on to it when it could do so much good the scene.

That supercpu shoot-em-up is a good example - I wonder how much they actually made from it.... whats the point? I'm even trying to keep the comments up to date!! So don't say I'm not good to you all!!

Also, if theres anything I've touched on that anyone would liked explained, then just drop a comment letting me know, and I'll try to post something more about it.

XeO3: Multiplexor V1.0

Well, the first version is done and although it still needs seriously optimised, it's in and working. I ended up using a slight hybrid between the one from Blood Money, and Dan's one from Armalyte. I loved the way he gathers sprites into blocks IF the hardware sprite your going to overwrite next has finished rendering, then it doesn't bother with a new IRQ, it just does it anyway! Very cool. I'll probably unroll the multiplexor IRQ and that'll help me get sprites closer to other ones. It looks like I'll have to redo a few paths from the Plus4 as they are a little close for the multiplexor (since they're 16x16 and not 24x21); theres an advantage to having software sprites... Still, it'll probably make the games a little different so you can have fun playing them both!

I'll probably try and get a C64 teaser done soon now, but I still have a couple of bugs to fix on it - and the sprites are still all actually only 16x16, even though its displaying 24x21! I might just "scale" them for now, just so they fill more of the screen.

Luca has also said he's not really interested in doing any changes for the C64 version - he's a Plus/4 man through and through, so nearer the time I'll be on the look out for a dedicated C64 artist to add some spit and polish.

Xeo3: Vice...

Well, thanks to the comment made the other day, I've managed to add symbols to VICE. Since I use my own assembler, it was a quick 10 min job to get the symbol table exported in the VICE format. This does help when trying to track down odd bugs so its very much appricated - whoever it was (names on the comments would help!). Although not being able to have a memory window is prehistoric!!

I've got the basic flow of the Multiplexor in, so now I need to test the start of it, and then start generating interrupts. I can test the beginings since I copy in the first 7 sprites in the list to save having to do early interrupts. Its also a good way to start, it lets you see if things are progressing the way you expect.

Xeo3: Multiplexor...

I've been sitting here playing with a C64 multiplexor - boy has it been a long time since I did this! Actually, reading about Dan's one from Armalyte is what got me doing the port in the fist place. Armalyte was probably the best looking game to come out on the C64, so I had a read through his source and got back in the mood. Pretty interesting it was too, I'd never really used the stack much since I tended to stick to zero page lda/sta as it was one cycle quicker, but his multiplexor sort approach was novel. So, I did some tests on it and compared it to the one I had in Blood Money... His varaied quite a lot and either gained a few scanlines or lost a few depending on sprite order etc. Mine is pretty much static (unless theres < MAXSPRITES on screen, in which case it gains) so I've decided to stick with mine for now, particually since it does a proper sort, while Dan's is an approximation (which is usually good enough for a multiplexor).

So now that its all sorted, I'm just about to start on the actual fun stuff! Building new raster interrupts based on where a sprite needs to go. When I first used this in Blood Money (after hacking Armalyte to find out how he did it), I thought it was very cool indeed. In fact, it took me a while to actually believe thats what he was doing - very cool stuff. In Ballistix, I'd gone with a static array as documented by Braybrook in Morpheus, and since I HAD to control 32 sprites for that, it was probably a fairly wise course of action. But for Blood Money, I could use something more flexible, and after seeing Armalyte, I just had to know how he did it.

Anyway, I'm about to do it again. I'm not quite sure if I'll follow his IRQ routine either, as I hate maintaining large unrolled loops. Im sure at some point in the future I can unroll it if I need to.

OH! And I've just discovered a 4th C64 that I have, and its the older ones with the original SID chip in it, so I can at last listen to all the old classics on the machine itself! Ahh...bliss.

XeO3: Surprise Surprise!!!

Well, in only 2 days, I've done the main part of the port to the C64! Although there are no sprite graphics yet, and no multiplexor, its running through the game and its paths. Alien Bullets are off a bit for some reason, but that should be an easy one, unfortunately because the Plus/4 one has been designed to run in 2 frames, the C64 one runs a bit quick. I can slow it down to 2 frames as well, but I'm not sure I want to yet. Past experiance says that when you're PLAYING the game, you dont notice, and 2 frames gives you a lot of free time to do cool things. Because of Hardware Sprites, I can however move the players ship every frame, which will help make it seem like's going quicker than it is... I could also scroll the screen by 1 pixel a frame as well, but I dont think thats gonna work becasue sprites that are supposed to be attached to the background will judder - I think.

I've just been thinking, if I move the VIC bank to $4000-$7fff, then I'll be able to use more or less the same memory map, and use Luca's SID music as is (since it sits at $1800 - currently right in the middle of my sprites!) It would be nice to use his music, as it helps round out a demo.....

XeO3: C64

I'm having fun with the C64 just now while Luca gathers together some sprites for me to use, but I've hit my first snag.... The MCM on the plus4 uses differnt bits than the C64! Damn. So, I've done a bit flipper to swap bits $01 and $10. This lets the colour RAM on the C64 do the bright colour (since in MCM on the C64 you only have a choice of 8), and the 2 full colour registers then make up the rest... This will work fine for the game graphics, but......... The panel has some HiRes graphics in it...Damn, damn.....

So looks like I'll have to do a character index and tell it the ones I WANT to swap...bugger. However, once thats done it should just be a matter of importing Plus4 graphics and using them directly! Initally I'll do a port routine for the Plus4 sprites as well, then I'll get them resized. The C64 sprites are 24x21 (or 12x21 in MCM), while the Plus4 ones are 16x16 so there quite a bit of extra space there! The reason for the odd sizes is simpky that it lets the C64 have a sprite every 64 bytes, making 256 in a VIC bank.

I think I can get the whole thing up and running (without sprites) pretty quickly, then I'll need to get a multiplexor going... and then that "should" be it! :)

(in theory....) Imagine doing a "dual" retro release!! How cool is that!!! Now... if only I could persuade Russell (Kay - Lemmings PC programmer) to write the spectrum one...Mmmmm.... That WOULD be a complete rewrite though...

XeO3: bits and bobs...

Sound is interesting.... you can work away trying to get perfect pitch and volume and then when its working just the way you want, you can sometimes make it really course and never notice the difference. I put keys for volume control into the game, and all the work spent on the ADSR (a whole day of it...) is reduced somewhat to a whimper depending on the volume. Now, when playing back on the actual machine TED sounds are far FAR louder than Solder's SID chip addon, so I need to set a volume of around 2 or 3. This means all my ADSR values of 7 down to 0 are now just 2 or 3 down to 0. Not a lot... But they do still count, because if you dont use ADSR at all, it sounds terrible... weird.

I have to confess, I've been playing with some C64 code tonight.... I found the source to the Armalyte Multiplexor on (Lemon64), and thought I'd go through it... and perhaps get it up and running. However, this has lead me to look back at my Blood Money multiplexor (which itself was based on me hacking Armalyte - although I wrote it myself once I had the gernal idea), and its not bad either... theirs is a bit larger with the loops unrolled a lot, but mine wasn't too bad at all. Anyway, I think with very minimal work (and a working multiplexor) I can get XeO3 up and running pretty quickly on the C64. I'm kinda half waiting on Luca to do some more sprites now anyway, so I've an excuse to play a little... well... thats my reason and I'm sticking to it! It will be a little harder to get .PRG's onto the C64, although my MMC64 will help a bit, but a download cable would be much better.....

So, after looking through the source, I've started to macro it a bit more to make it easier to follow - for the sort at least, I may well write my own multiplexor bit again... but I suspect I'll try and get something running first. The great thing about doing a C64->Plus4 or a Plus4>C64 conversion is that being 6502, it'll just run - I won't have to rewite it all the way I used to do when doing a port. This means I get to do all the fun stuff and dont have to do ANY of the boring stuff again!!! Great!!!