XeO3: Final cleanup!

I was looking through the game and spotted a couple of things I want to try and fix tonight - pretty minor, but it would still be nice to fix them for the demo. Once I've done that, I'll get a package ready for Luca to post tomorrow night (whenever we're both home and ready).

However... I was thinking.... IF I really wanted to... I could probably speed the game up quite a bit. For example: The engine redraws the screen every frame - this is slow. It DOES mean I dont have to save+replace stuff, but it would be much quicker to slowly redraw a screen over several frames, THEN flip. I blit the screen each frame because I wanted to have large character sprites that cover large areas of the screen - but that would be too slow to replace. However, due to memory we've dropped that idea. (The source is still there so someone else can play with it!)

So... lets look at HOW you could speed it up.

If when drawing sprites I did collision of baddie sprites to bullets the same way as I do the player to the background, then I could remove the N*N loop I have which does bounding box checks. I could also draw a lot more bullets! (Dan did this in Armalyte, and I suspect its common practise with C64 shooters).

Next.. If I did a Save/Replace system for bullets and sprites I wouldn't have to redraw the screen. (this would save a large screen buffer anyway).

That way I only ever copy a couple of lines a frame rather than 21!! That would be a massive saving, possibly freeing up enough time to draw another couple of sprites! (which would make 12!) OR (more likely) allow drawing of more complex weapons!

Now... I could do this... But I think we have finally passed the point where major changes are allowed, otherwise we'd NEVER finish! If I ever do an XeO3-II, then I might alter some ideas.

Still while I'm talking about that.. After the Plus4 version, I'll finish the C64 one (possibly taking some of the above ideas on board), and then do a TG16 and PCEngine version, as I love BOTH those machines! Since they are both basically 6502, I dont expect them to take very long and I might be able to move to other platforms... like the Amiga/ST.

Still...its taken long enough to get here, so I'll worry about all this later!

XeO3: Almost there!!!!

I've ironed our the remaining issues, and Luca is reasonably pleased with the level layout. We've also tweaked a few graphical things and tweaked the BOSS's nose.

I wouldn't get too excited about killing the BOSS though... it'll just restart :)

So, all going well, and barring any major issues the demo + scripting test will be released on FRIDAY NIGHT! (Friday the 13th!)

PLEASE remember to give feed back on one of the many forums (C64, Plus4, spectrum etc..)

XeO3: An interesting side effect....

Now that its all working, it appears to be quite a bit harder.... Closer inspection shows that the changes to the bullet collision have actually made it tougher! This is because coins can now be hit! So its pretty tough to shoot a line of aliens if they all drop coins, and means you really need to shoot it close to you, and then quickly pick up the coin so you can shoot the next one in line!

This is pretty hard, particually if your being hammered from all sides by turrets! I could change it now, but I think I'll wait and see what the feed back is. Of course, the temptation of gamers it to make it reasonably easy so they can finish it, so all comments will have to be taken with a pinch of salt, but lets see what you all say.

XeO3: At LAST!!!

Well, its offical....I'm a prat. Let the word go forth.... I am a moron. Yes, I've fixed my bug, and wouldn't you know it... it was the change I made a few hours before when altering the collision flags. I was simply branching to the wrong location when I detected a NOSHOOT flag. What a prat.

Oh well... Debug code now removed and we're back on track! Now I just need to finish this level off, and build a scripting framework.... almost there!

*sigh* oh well at least its fixed, but I still feel like a twat.

XeO3: I knew it!!!

Oh well... I knew it was going to smoothly... I've discovered a bug thats gonna delay things until I manage to find and fix it. Shooting at the boss you eventually stop firing for some reason. No idea why, but it looks like your bullet counter goes negative, and then is unable to fire any more. No idea why - theres only 2 places which reduce the counters, and I cant see how this is possible - fek.

XeO3: The finishing touches!!

I'm now putting the final touches to the demo! Yep, I'm almost there... I'm adding a simple BOSS to get the end of level some meaning, although while doing so it threw up a couple of bugs and issues.

First, I've changed how the NOSHOOT and NOCOLLISION flag works. NOSHOOT now simply means that while the bullet hits, it won't cause any damage, while NOCOLLISION now means it has no collision AT ALL! So neither Bullets or players will hit it. This makes a little more sense and allows for baddies to be shot at while coming on screen, but take no damage.

I've also changed the parent system, so that a sprite marked as a CHILD now uses the path/sprite than SPAWNED it as its parent. This feels more logical when building paths.

I've also fixed a bug where by if you kill a sprite that was PAUSED, the BOOM animation was over running.

So... there you go... Almost there! Just need to finish the level off, and then make up a batch file to allow you to build your own levels, an that'll be that! (I think...)

TG16 fun...

With XeO3 being easy to port to the C64, I started thinking about other 6502 platforms... SNES is one I'd like to lookat, particually as I have a couple of old DevKits AND a couple of magicoms. these were copy devices, but I used to use them for homebrew development as you could squirt code down to them from a PC/Amiga.

So, I started reading up on some old PC Engine stuff, and was trying to find something (outside an emulator) that would let me code for it again. I was hunting for something called TurboRAM which was a prototype device to let you download to the TG16, but I couldn't find anything - I guess its long gone now. But this would be cool, so I started hunting for info on the expansion bus to see whats invloved.

I actually found info on the Cartridge port, and its quite interesting... It's only address+data lines, it doens't appear to be encrypted at all!! This means it shouldn't be too hard to make a RAM card that you can download to! So thats another thing on my to-do list, see if i can hack together a RAM card for a PCEngine, then I could actually code for this great little machine again!

(I also have an old MegaDrive devkit! It should work, but i've haven't used it in over10 years now).

XeO3: Scripting....

Not doing much but cleanign up the script for the demo. I manged to 148 bytes by swapping from

    PFor  10
       Move  -2,10
    PNext

to...

    MoveLoop  10, -2,10

And the code looks much nicer too. Of course I added around 100 bytes of code for the new function, but theres more space there as the script only has 3k to play with!

XeO3: Move commands...

I've just finished adding the MoveLoop command, so I hope this helps to make script writing simpler. Now I need to go through and change all the demo levels scripts to use this new command.

I've also started to fill in the code documentation on the grounds that if I leave it to last, then even when I finish I'll not be able to release the source for months after - until the documentation is complete. So if I start now, it shouldn't be long after the game comes out that the source code is released too! It should be fine though as the code isn't going to change hugely at this stage, so documenting it now I suspect is fine.

XeO3: Script Docs complete!!!

Well, I've finished the 1st pass of the scripting docs!! Didn't take too long at all, I'm quite pleased about that. I do still have a couple of examples to do, but they can be added anytime really....

I also just realised I should really add a MoveLoop command since 90% of move commands are surrounded by For/Next loops!

       PFor   50
          Move  -2,0
       pNext

This takes 6 bytes. But if I were to do this....

       MoveLoop  50, -2,0

It would only take 4. Now, 2 bytes doesn't seem like much, but I have 91 loops in level 1 at 2 bytes per loop which makes 182 bytes saved. Not only that but you'd have less typing, and the code would just look nicer!

;-----------------------------------------------------------------------------
; tear drops...
;-----------------------------------------------------------------------------
Drop_1:
    DRIFT -1
    Move 0,1
    Move 0,1
    Move 0,2
    Move 0,2
    Move 0,2
    PFOR 4
       Move 0,3
    PNEXT
    PFOR 5
       Move 0,4
    PNEXT
    PFOR 6
       Move 0,5
    PNEXT
    PFOR 200
       Move 0,6
    PNEXT
    KILLSPRITE

becomes....

;-----------------------------------------------------------------------------
; tear drops...
;-----------------------------------------------------------------------------
Drop_1:
    DRIFT -1
    Move 0,1
    Move 0,1
    Move 0,2
    Move 0,2
    Move 0,2

    MoveLoop 4,   0,3
    MoveLoop 5,   0,4
    MoveLoop 6,   0,5
    MoveLoop 200, 0,6
    KILLSPRITE

Which is much nicer!! Not only that.... But that would give you VERY simple loops in loops.... So a Square path that would look like this...

  PFOR 90
      Move -4,0  
      Move -4,0  
      Move -4,0  
      Move -4,0  
      Move 0,4  
      Move 0,4
      Move 0,4  
      Move 0,4  
      Move -4,0  
      Move -4,0  
      Move -4,0  
      Move -4,0  
      Move 0,-4  
      Move 0,-4  
      Move 0,-4  
      Move 0,-4  
  PNEXT    
  KILLSPRITE

becomes - THIS! (which obviously saves even MORE memory!)

  PFOR 90
      MoveLoop 4,  -4,0  
      MoveLoop 4,  0,4  
      MoveLoop 4,  -4,0  
      MoveLoop 4,  0,-4  
  PNEXT    
  KILLSPRITE