XeO3: Background Collisions!

Well, I decided tonight was the night. I was going to do the background collision detection. I've been thinking about it for a while and I'm finally happy with the method I've chosen. The problem you see is that I dont have anywhere near the CPU time left to do pixel-perfect collision. This is in fact, like drawing another sprite; and even if I had the CPU time to do that, I'd still rather draw another sprite!

So we're stuck with detecting characters under the player. This is nice in that its very quick, but bad because its terribly crude! If you look at the image shown, number 1 shows the sprite sitting in its 3x3 character block. Now although it's only a 16x16 sprite (2x2 characters), the sprite has to scroll through these to move around - such is the lot of a software sprite. Now, looking at image 2, you can see that if the sprite has move say 4 pixels along, and 4 down we are now sitting right back smack in the middle of a 3x3. So the question becomes - what do you hit?

If we were to simple use ANY chars from the 3x3, then you could be a whole character away, and still get hit. This isn't good. But, if you use a 2x2, then by the time the sprite has scrolled 8 pixels along, and 8 down, then we again are hitting the block above this time, but we aren't actually anywhere near it! It would also mean we could go completely into the block below, and not get hit! Neither of these is desirable.

The solution? Well, looking at image 3 - we'll only deal with Y movement for now. if we move 3 pixels down, what we'll actually do is use the TOP 2x2 (as shown in image 4), then if we move past that and go 4 or more down, we'll switch and start using the lower characters (as shown in the final image). We then apply the same theory to the X coordinate - simple!

This actually works out great! It gives us a natural 4 pixel boundary around the ship where we can "edge" into a block without getting hit, and it keeps us from hitting things miles away! All in all, a pretty nice solution.

So, the big question! What does this mean for the game? Well, the game's a foot...and pretty smelly too! You now have to avoid being hit by aliens, the turrets now shoot at you - and hit! - and you now have to move around the scenery! All we really need to do now, is add all the baddies in Luca's been working on, and do the weapon systems!

XeO3: Don't bug me now....

Spent a little time fixing a couple of minor bugs.

The first happens when sprites cross stars - they disapear as though the sprites wheren't masked at all. Odd, because I spent some time making sure the stars would show correctly behind the sprites. I remember this because of the optimisation I did to the sprites where if the character its about to overdraw is $00, it doesn't "mask" it in, it copies it. This was quite a saving and it does 9 of these checks per sprite. Now since the stars are basically characters, I made a choice and accepted the slow down invloved. It would have been quicker for have the stars vanish. Anyway, after shuffling code around trying to figure out what the hell was going on, I discovered that it was indeed a simple bug. The stars were being drawn to the wrong screen. They got drawn to the front buffer, and not the back one. The reason it didn't look terrible is because the stars check to see that theres nothing there before they draw themselves - this is simply so that they'll draw behind the scrolling back ground. Anyway, I changed it to the backbuffer and PING! all is well.

The second was obviously a simple one. once you shot a baddie, he sometimes drops a coin. If you pick up this coin, you get money. However, if you then shoot the space where the coind was, the bullet hit something. Obviously, the coin wasn't as dead as I thought. Turns out when adding the NOSHOOT flag, I'd tried to optimise the bullet collision, and it hadn't worked. It could have, if I'd set that flag on every dead baddie - but I dont want to, so the extra check for it actually being active has to go back in.

Oh well... couple of minor fixes today only... Still, its good to get these things found before any games players find them and complain!

Oh, and with Russell deciding to do a spectrum version, Retro Edit has become even more important...*sigh*... so much for my idea of a simple tool to do the job. This means I'll have to do hires editing, and a spectrum tile editor. Russell has a lot of restrictions for his tiles, so a custom editor is needed. At least the sprite editor will be simpler, but it does mean I've to do it properly and do MCM with bit patterns rather than just numbers - bah!

XeO3: Play the game....

An interesting topic has come up on Lemon64; since this isn't a normal game that is going out to the public but more a game for the scene, should we automatically add cheat modes ourselves, and then every couple of months release a new code for say better weapons, money, shields, infinite lives etc.

Or should we do a normal game and let it get hacked live every other game does?

XeO3: And then there were 3.....

It seems like there may be another member of the XeO3 family! Russell Kay (author of PC Lemmings) who I currently sit beside at work and harass like a badger with a sore bum, has been persuaded to have a play with some old spectrum stuff again. He has actually written a spectrum game years and years ago called Zone Trooper . It wasn't wonderful, but he was just doing a port so it's not his fault, the code however was fab, and he did love the old speccy. So now, he's back - at least for a while - to have a play at doing a spectrum version of XeO3. Great Stuff!! Could it be the first multi-platform games release on the +4, C64 and Spectrum in well over 10 years?? Time will tell....

So, after that great news....I've nothing much to report. I've had an evening off and sat down and watched a film. I have imported the Plus/4 colour map into the editor and tomorrow I hope to start making the editor more usable - rather than just an animation tool. Still I'm a little sort on energy, so I think its an early night.

So...nothing done and it's STILL been a great night for XeO3 news!!

XeO3: Retro Edit

After talking to Luca, I feel somewhat ashamed. He described the process he uses for creating sprites and it was so bad, I was virtually blushing. I am now even more amazed at the superb animations he's manahed to create despite the terrible tools he's using. So, I've vowed to correct this as fast as I can. To this end, I've changed the focus of the editor, it really will now become a Jack of all trades. I'll do +4 sprite editing first, then add C64 editing so that I can get those streachy sprites, and then onto character and tile map editing and so on.

However,m before anyof that, I need to get Luca some tools he not only could use, but really wants to use. The problem with any developer is that we get so used to using our old tools that we just don't want to change, so I need to give him a tool that feels like his old slippers, buthas a whole new set of features that empower him.

The first on the list was loading in the current sprites and then being able to play back certain animations in various modes. This is now done. He can now scroll through the whole set, pick start and end frames, then play them back forward, backwards and in "pingpong" mode (where it bounces back and forth). This should at least allow him easier viewing until I can actually get editing and saving in place.

In the future, I think a realtime linkup with an actual machine would be very cool, as the anim plays on the PC, it also plays on your Plus/4 or C64 on the Tv... also theres no reason why when you plot a pixel on the PC you dont SEE that on the actual machine as well. I wonder how many people would use that......

XeO3: Editor

I've managed to get the Plus/4 sprites up and visible which is fine - fairly easy in C#, so next I'll need to get them scaling. I'll probably change a couple of bits internally so that I can have either 12x21 or 8x16 MCM sprites, this will let me view/edit either C64 or Plus/4 objects.

I released a new version of my assembler yesterday as well, I don't think very many folk use it, but I find it's really handy - particually the macro support which lets you do quite a lot.Turns out though that I don't test it nearly enough! One of the chaps on Lemon64 has managed to crash it a couple of times with ease. I guess without testers this kind of this will happen. Anyway, if you want to play with it you can grab it from my minus4 site.

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.