XeO3: Editors.

I'm taking a small break to play a bit more with my C# stuff. I've gotten the Plus/4 sprites loading in, so now all I need to do is scale them. But to see the results, I thought I'd extend the program I was doing into something a little more useful. Something that can load in sprites, characters and XeO3 style maps. I may even add editing to it at a later date.

Once I have the drawing working, I'll write a quite scale function that'll allow me to save out full size C64 sprites - although they'll be a bit rough around the edges. The biggest issue I have with XeO3 on the Plus/4, is that I can't view or edit sprites easily, Luca has to make little Plus/4 programs that show his work animating in a self contained PRG, which is far from ideal - so I hope this will help a bit more.

Level editing is also a concern as the current one was created by "FatMan", and he has long since vanished. So now we really need to be able to create one outselves, particually if we want others to make new levels or even games out of it.

I'll have to watchout when doing this program, as the temptation is to make an all singing all dancing app, which will take longer to write than the game itself. If I was doing an editor to "sell", I guess I would make everything variable and portable. But the idea is to keep the goal in mind, and not get too carried away with what should remain, a simple XeO3 editor.

XeO3: C#

So, I thought it was about time I got the full benifit of the Multiplexor, so I'm about to do a small c# program (my latest language of choice) to convert into the proper format, and scale it up to the required size. Now the aspect will obviously change, and it will look a bit naff.... but it'll help "fill" the screen with sprites AND give me a basis for converting over Luca's art in the future.

On another note, I was speaking to TNT over at Lemon64 and we got into chatting about old programming diarys from ZZap days, anyway he reminded me about the Citadel one as well as the Morpheus one I've just read. I seem to remember this one being pretty cool to. He's currently doing a supped up version of Paradroid and I'm trying to persuade him to do a diary as well. I love reading techy stuff like this, and I'm sure others do to. These days games are such a closely guarded secret that you never get to hear the gritty details which is a shape. Also things are now so complicated that it can take weeks to do the smallest thing which doesn't make for good reading.

If you have an opinion on this, or if you like reading this kind of stuff, then let me know and perhaps I'll start to try and push more people to keep retro coding blogs.

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: Sprite time...

Luca's given me a new batch of sprites to bundle together so while I've been doing that, I've also been updating Luca's scripting build so that he gets all the latest features. While doing so I've fixed the parent+child system. This allows small sprites to be joined and act as a single BIG sprite. Luca's been playing with a large mid level baddie, but it wasn't working right. Turns out when I had rewriten the killsprite routine I had inadvertantly broken the link system. I'm not terribly happy with the fix however, as it means I have to loop though all the sprites every time one is killed. Its not the end of the world, but I dont really have any spare FLAG bits to enable me to fix it.
I've only 2 left, and I think I need these for other features. Luca wants to be able to orbit baddies around parents, and I'll need a flag for that, I also need a flag for something else...but that escapes me just now. I may well have to admit defeat and add another FLAG byte, but I really dont want to do that.

I got my Retro Replay today!! Very cool! I think I'll probably get the RRNet and SilverSurfer add on as well as it'll let me squirt stuff down rather than having to copy it to the MMC card all the time. Using a RetroReplay and the MMC64 I can now mount a D64 image and read it like a normal disk, which is very funky - its now a pitty that so many have "custom" loaders that dont work with it! At least Blood Money and Ballistix seem to, well... they manage to load, but blood money then crashes when you start playing, no idea why - seems to have all the graphics and code it needs.

Xeo3: Playing shuffleboard with the C64....

I've been shuffling around the C64 code and data for a couple of reasons really. 1st It means I can use the music as is without having it relocate it, and second buy changing the VIC bank to $4000-$7fff it gives me a few extra sprites. It got me going for a while though until I discovered a bug in my IRQ code which was always setting a bit in the screen address, this meant I could only have screens at $0400 and $0c00 and it took me a while to track down exactly why this was. Vice came to the rescue with a reasonable debugger, although I really wish they would add some basic symbol table support. Being able to put a breakpoint on a label address is a godsend! Anyway, bug fixed, code and data all moved around... and I now have 160 sprite slots, and a few more above the panel.

I also workout out that if I changed the format of the +4 sprite a little, I could squeze in 199 sprites, quite a bit up on the 167 we already have! It depends if I get around it it... its not a huge change as it just involves making a 300 byte xply table and changing the cache pointers from pointers to indexes (theres only 147). But that would save 8 bytes per sprite * 167 sprites... a lot! I hope I get a chance to make the change, although Luca might not thank me, he already has a lot of space to fill!

XeO3: C64 sprites....

I'm having a little coding break at the moment. I thought I'd have a quick play and see how much bigger the sprites feel when theres a proper C64 sized one in the level. It's not a lot bigger really, but I suspect a few of these larger ones and it'll start feeling a little cramped. I was pleased as punch when I discovered an old copy of Tony Crowthers 3in1 graphics editor that I used to use, it does sprites, characters, backgrounds and has a scratch page for playing with ideas.... great little C64 editor. I've not really seen it on the NET anywhere so I really should upload it somewhere for folk to use, coz it really is fab.

XeO3: C64....

Not a bad evenings work! I've managed to get the sprites converted over as well! Although at somepoint I guess I'd have to get them redrawn since they are only 16x16 but still, it looks great with the added colour! I'll probably release a C64 teaser in the near future as well, lets see if any C64 guys get interested :)