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

XeO3: Wiki

I'm slowly updating the wiki just now, and documenting the scriping system as best I can. I was going to keep the wiki quiet for now, but Luca's let the cat out the bag so what the hell!

You can get to the wiki either via the main XeO3 web site, or directly at wiki.xeo3.org. All I'm doing there just now is script documentation, but feel free to go and have a read and give me some feedback. Remember the whole reason for doing this was to get a modern game engine out there for people to be able to MOD and release more games! So for that there needs to be some good documentation, and that means people have to understand when the hell I'm talking about!

Still we're on target and things are progressing well (for a change).

I also finished updating my DMADESIGN.ORG site to use my new CGI script, and I did my first perl script as well...very odd - oh well.

Bandwidth Leachers!

I've just spent an hour getting an image script working so that I can stop people leaching bandwidth. Now, dont get me wrong, I actually have stacks of bandwidth left, and I don't even mind them using the images! But what really gets me is when they point directly to one of my images for use as an avatar! If they're a moderator or something, then this image could get pulled down thousands of times! More to the point, if they're a moderator, then they should have the good manners to copy the image onto their own bloody servers! It's not like I'm going around demanding they take down stuff thats on my site, I'm pretty open about people using stuff.. *sigh*

Actually... I downloaded a nice little script, then spent an hour debugging it and making it work! It had several errors in it - typical. :)

(Fek... Now I have to update all my sites so that they can't just pinch another one!)

XeO3: Polls!

I've added a couple of poll's on the right, please take a moment and fill them out. I'm also interested in what other platforms people are interested in seeing XeO3 ported too... I'd like a SNES version myself, and Amiga... aside from that I know there was interest in the Atari 400/800.

I'm busy writing scripting documentation, and will open it up to public viewing soon enough. Once this is done, I just need to clean up some internal code and then we can release it!

XeO3: Wiki!!!

I'm busy setting up an XeO3 wiki (with restricted user access) so that Luca and I can document everything in XeO3 properly. Previously Luca started out doing it on the main site, but that's hard to maintain. I use MediaWiki at work for blogs and its pretty flexible, not to mention that people can edit live and simoltaneously. So no longer will Luca or I (or Russell eventually) spot an error and have to wait for the correct person to edit it, we can do it directly outselves. Which is nice...

Aside from the fake BOSS at the end of the level, the scripting documentation is the only thing now holding up the release (I think). So I hope to push on and get it at least in a semi-usable state so we can finally get a working demo out there for you to play and play with!

XeO3: Mmmmm.....

I've been making more minor fixes in the game code as I come across them so the C64 port is almost complete. In fact all thats really left is the player Death sequence and the front end. Now, the death sequence will be the same but I'd like to do a new front end - mainly because I was so pushed on the Plus4's, so I hope to do something nicer.

I was doing some calculations to see how many sprites I'd have space for on the C64, particually since they take dounle the space (64 bytes over 32). I thought I was going to have to drop some, I dont want to get into doing a sprite cache on here and have to start copying data around - I did that in Blood Money and I dont think it really helped all that much. Sure I got a few extra sprites, but I lost a lot of RAM because of it. So the idea is to use ALL the 16K VIC space for graphics, then use the rest for other things.

Now the Plus4 has 167 sprites - quite a lot! So heres how the C64 stacks up...

Screens x2 = $400*2 = $800
CharacterSets x2 = $800*2 = $1000
Panel Characters = 96*8 = $300
Total space left ($4000- $800+$1000+$300) = $2500
Total sprites left = $2500/64 = 148.

Thats almost 20 less.... Oh well... I will probably push that a little when I move the panel into another VIC bank and swap banks as well as the character set. That gives me another 12 taking the total to 160. Still, these will be bigger, but thats still 7 less. Oh well....

I've also tried the C64 version on NTSC emulation, and the lack of vertical blank raster time really hurts! So I may have to try and come up with another solution... I guess... if I can setup the first 8 sprites quickly, I can overrun with the rest.. still its far from ideal. I wonder if its worth supporting NTSC... Always hated it...

XeO3: Another day... another bug fixed!

So I started to look into adding the panel functionality, and what do you know - its working already; its simply drawing to the wrong screen! The plus4 version sits the panel on screen 2, but on the C64 one I'd used screen 1...simple. However while fixing this, I happened to spot another bug and one thats again in the Plus/4 version.

The panel is only supposed to get updated when it needs to, in fact theres a set of flags set aside to enable updates of certain components of the panel. This means that when nothings happening, its all very quick. However, the flags don't appear to be getting set and the only reason it was working, is because they weren't getting cleared either! So, I've now got to go and set the flags whenever the panel needs changing (like adding to the score, losing a life etc...). Pretty simple fixes, but one that means Im not spending time doing stuff I simply dont have to do!

On the plus side, the panel code is unchanged from the Plus4 to the C64, which means I can fix it on the Plus/4, then simply copy it over and have a working C4 one too... cool :)

XeO3: Almost there!

I've made pretty good progress this evening and have managed to get all the player controls in and working; along with the player ship of course! This means you can now play the C64 version almost fully, shooting things and picking up coins etc. This now also now includes the shooting of turrets and mines, and they even explode correctly. I took a little while to get the player ship on as I had a bug in the Plus4 to C64 sprite conversion routine (all graphics are converted at startup so I can use the same data files), but once that was solved, I was able to move the ship around and start blasting away!

This leaves a few things left before its on par with the Plus4 version; Panel - power bar (shield and weapons), score, lives and coins, and testing ship to background collision. Once thats all done, it'll be at the same level as the Plus4 version. Its a pitty I dont have the old demo level still as I could make a video of it playing. Oh well...

I'd set myself 4 days to update and complete the port, and still expect to finish on time (for a change!) - although its probably because I've got a couple of days off which is making it easier...

However... don't get too excited, the Plus4 version will still be the only one released for now, but I might release the C64 version a few weeks after if theres enough demand.

XeO3: Things move a' pace!

I've been making pretty good progress last couple of days... As it was my Birthday on Friday I took the day off and did quite a bit of retro coding, and I've managed to progress even further today! The C64 version now runs through the whole demo level with aliens and bullets flying around just like the Plus/4 version, and while the C64 version is smoother, they are very similar when you watch them side-by-side.

I've been busy tracking down a bug in the multiplexor, but it turns out I simply wasn't clipping the sprites once they went below the panel. This was causing a new interrupt to be generated in the middle of the panel causing some nasty flicker. That solved, there does still seem to be an issue somewhere, but I'll leave it for now as its not that important.

I also found a bug in the Alien Bullets where they were being clipped too early, so fixed this in both the C64 and Plus4 versions.

I did hope to be able to make a single source set that would compile for both, but theres many very small changes all over the place, so this now looks unlikely - but I'll wait and see nearer the time.

I'm also wondering if doing this demo is the right thing... it actually looks pretty good, and would be a valid "level1", but I guess the whole point was to release a level I could tweak then start again so that people would get a full proper game to play without having seen/played small sections so I'll carry on for now as planned.

The extra sprites on the C64 version are proving a boon as I can extend wave's a little and make them link a little better with the next wave coming, losing some dead space while I go - all in all, its progressing pretty well now.

And just a reminder when you look at the C64 screen shots; these are all using 16x16 sprites (or 8x16 if your a puirest!), so the final C64 game will look fuller as the sprites will simply be bigger! The player ship will probably reamain 16x16 so that we can keep the smaller gaps and passageways.

XeO3: C64 stars!

I've just spent an hour playing with the C64's starfield. I've never been terribly happy with it as it shimered a lot due to the 1 pixel smooth scroll. So I've finally gotten round to making them HIRES rather than MCM stars. This involves doing the stars in the VBlank and setting/clearing the colour depending on whats already in that location.

It also takes a good few scanlines to run, but I can't see anyway of making it faster! It simply has lots to do so I'm probably stuck with it! I'll have to be careful though, because if the multiplexor gets busy then it's probably going to need the time the stars are eating up. Theres probably a couple of places I can stick the stars routine, but due to the colour writes it has to be in the FLIP vblank!

Oh well, its okay just now as the multiplexor isn't getting taxed very much - in fact it hardly every gets used! This is because the Plus/4 version keeps sprites free so that if coins are falling, I can still bring on new baddies without having to worry about the coins eating up slots. Still, it looks reasonably busy and I can always add more I guess.

I'm wondering if I should upload a video of the C64 version playing... but I dont really want to spoil the demo by letting people see it play through. So I'll probably wait until the Plus4 version is out for a little, then release a video afterwards.....

So stars done.... Panel next!

XeO3: C64 progression

I've managed to get the bullets working on the C64 now, in much the same way as the Plus/4 version. So while its masked onto the screen, its no smoother really. However, because of this though it means I have to double buffer the character set as well now - pooh. Im not sure if its worth it though...I could do 8 proper masked sprites (8, 8x8 pixel sprites) which would allows bullets to move better... but I'd rather spend the CPU time elsewhere.

On the plus side though, its much smoother than the Plus/4 version thanks to its hardware sprites and theres plenty of CPU time AND memory left!

I need to get the player working next so that I can actually play it, then it would be only missing the front end. In the end, the C64 version will be better but thats to be expected... but I do hope that they are so different that you'll enjoy playing them both!

XeO3: C64 version lives again!

I've spent an hour or so porting the current code base over to the C64, and it IS running the demo, but there are lots of issues to solve. The scrolling works, but tile drawing has serious issues and is rendering corrupted tiles. All the firing and player movement/collision etc. is commented out (although the code compiles). Background animations work (so turrets rotate etc.) and the multiplexor is working properly.

All in all for an hours work not too bad.... I am tempted to now try and keep both in sync; not so that I do a dual release, but so when the plsu4 version is finished, Im, only really waiting on graphics for the C64 version. Most of the code is now written, so keeping it up to date shouldn't be too hard - but of course I still have lots of work to do to get it running properly in the 1st place....

IF I get it running okay, then I'll probably release the demo on the C64 as well (although at a later date).

XeO3: Busy night!!

Well, I've gotten on well tonight and no mistake! I've added a heap of new paths which means I only have to do the BOSS!! How cool is that!! I've also just added the FIRE flag to the baddies so I can now selectively pick which baddies I want to shoot. But what this means is that I'm actually almost done!!

I need to add a boss (kind of... SOMETHING at the end...).
Scripting Documentation.
Cleaning out the sprites(its a demo after all!)

And..errr... thats it I think... So almost there!!! Remember we are releasing a test suit not JUST a demo level! You will be able to play with paths and make your own level if you want to!

What I really hope is that we'll fine someone really good at making levels, and they can help on the actual game! (I HATE making levels... I may have mentioned this before...)

XeO3: A pleasant surprise!

I suddenly realised that the bug Luca discover and I subsequently fixed might have been the reason for level Fast-Forward not working, after all it would alter the cycle count things would be active for. So I resurrected it and gave it a few tests and hay presto! It works perfectly!! This means I no longer have to fast forward through the whole level to check a path, the level will just fade on at the correct spot! Very cool! And a great surprise at that!

Who knows...I might actually get more paths done tonight....maybe... if the TV isn't too good. :)

XeO3: Enemy fire....

I've been finishing off the firing of baddies and was playing with the actual bullet direction stuff. I short-cut most of the work by not using a line draw, but a best guess. That is if we're 200 pixels away on X then I give it a steep angle, if Im zero pixels away on X then it fire directly up or down. Now this works pretty well but now that baddies shoot I've been extending it to be a little more prescise. However, with each tweak, I'm making the code bigger and more complex, and its all just a fudge anyway.... so I'm wondering if I should rip it all out and just use a line draw.

The thing about a line draw is its nice and prescise, but the good thing about mine is that it isn't! I know that sounds a bit strange so let me explain. If someone shoots at you're position, you simply move out the way. If 5 baddies shoot at your position, then again... its a little harder, but move and your probably safe. If 5 people shoot in your general direction then moving out of the way of one bullet, will probably throw you into the path of another! This makes it harder to avoid bullets which is the idea.

So... should I just leave the spaghetti code and think "well, it does what its supposed to, even if it is a bit unreadable..." or should I have a nice neat bit of code (that might take longer to run) but may also make the game easier.... Mmmmm.

The only way really is to try and see, but its a fair amount of work, so I'm not sure....

XeO3: Action!

I've just spend they past hour or so adding in baddie shooting, and it makes a real difference! It's now tough! And in places; REALLY TOUGH! I've still some tuning to do before I can call it V1.0 but its looking pretty good.

This means you can no longer line up a whole row of baddies and blast them while automatically following in to pick up coins, as one or more of them may be shooting at you and you'll run right over the bullets! I plan to make this optional in baddies so that at the start of levels I can ease players in then make it tough later on.

It also means that I can make the end of level baddies even harder if I need to, as I can bet them to shoot at you without using sprites! So while I can use a sprite to fire a large rocket or something, I can fire out up to 8 bullets at a time forcing you to dodge all over the place! That could be fun! (or a nightmare!)

Oh, and on a side note... I've also allowed turrents(and baddies) to shoot horizontally. This means again you cant fly directly at a turret/baddie worry free anymore!

XeO3: Weapons!

I have just finished adding in the new weapons system! So now what happens is theres a GREEN and RED section to the RIGHT hand power bar. This is your weapons power.

IF you get enough coins (fill your coin bar) while the weapons bar is in the green - you power up!!
IF you fill your coin bar when the power bar is in the RED you only recharge.
IF you DONT get enough coins to do either, you drop a power level.
IF you are on level 1 and the bar drops to 0 - it STAYS zero until the coins bar is full and then recharges.

This should mean that you HAVE to kill baddies and dive in to collect coins making you dice with death! Otherwise, you could just sit back and shoot which would be too easy.
It'll be interesting to get feedback once the demo is released....

XeO3: The future...

I was sitting here updating the panel so that the power bar on the right wasn't the player shield anymore, but a weapon energy bar and I got to thinking.... what other games could you use this engine for?

Well, aside from more shoot-em-ups, platform games spring to mind! You could update the scrolling so it goes both directions, and change player input so that it stands on the background, and hay preso! A platformer!

I sped the scrolling up to 8 pixels a game tick to see just how fast I could push it, and it managed that pretty well, so you could be moving really fast too! It also occured that if you DID update the scrolling to go both ways, you could do a full Uridium clone! Uridium only had 7 baddies and you, so it should work pretty well!

Theres nothing to say of course you dont update the scrolling to go vertically either so that you can do vertical scrolling games. Hell, you could ditch the scrolling and have static screens and puzzle or adventure (Atic Atac style) games!

I really do need to get on with it so that others can play with the source and we get some good NEW games out there!

XeO3: Luca's bugging me again...

Luca found another little bug, this time coins were wobbling if you got them in a specific place. After a quick hunt, I discovered that while the screen scrolls 2 pixels at a time, I do in fact scroll it at 1. The hardware then drops a bit for displaying, but the sprite system was adding it to the coordinate before masking off the bottom bit. This means if the sprite was on an odd pixel, it could wobble as the screen scrolls.

Anyway... I now store a masked version of the scroll counter and the sprites use that - so all fixed.

XeO3: Begining again.....

So... finally found a little time (and will power) to sit down and do a little work. I started out by changing the colours on the panel so that I now have the GREEN zone on the weapon's bar that I wanted, but Luca and I also changed some other colours, and it just looks "nicer" over all I have to say.

After sending Luca the latest version he spotted a stutter in the movement of the sprites which I was just not seeing. Still, after him slapping me with a wet fish called bernard I finally spotted what he was seeing. Very odd.

I stuck on some colour bars thinking that perhaps it was over running raster time but no... a whole frame left!

Next we downloaded it onto a real machine thinking it could be the emulator (since its not on a real TV and would judder a little), but no... exactly the same! While on real machine I moved the player ship around and it was smooth as silk, even when the judder in the baddies happened!

So I tried to capture what was happening in Yape and do a frame step - and there it was!! But it wasn't just the baddies stuttering - oh no! It was some baddies stuttering!

Damn...

I tried a couple of things thinking that it might be a MCM sprite on an odd pixel boundary due to scrolling and sprite coordinates, but no....nothing!

Time to break out the debugger... First I ran it to just before a sprite stalled then jumped in to watch its coordinates. Yep! For 1 frame they dont change! How weird is that!

After all this I finally discovered that an optimisation Id done to in-line a function into the PATH system (I made a function a macro) had missed a RTS!! WHen a sprite was killed due to being clipped (gone off screen) it was returning. Now before it was a macro it would return to the PATH routine, but now it IS a macro, it was returning to the main loop, effectively missing the update for last few sprites - DOH!

Oh well... all fixed and looking better. Well spotted Luca!! :)

Xeo3: Whats missing?.....

I was sitting here watching the teaser we did and trying to put my finger on what was missing. I notice a while back that it wasn't quite right and I finally figure out what makes it so easy to play... Badies dont shoot at you! Sure the turrets fire and all, but they are easy to avoid/shoot.... but if I add the ability for baddies to shoot at you, then I suspect it'll get a lot more interesting! This means that even when a formation passes you by you still have to dodge and be careful.

I was also trying to remember what I needed to do on the weapons front, and I need to add a weapons power bar! Currently both bars are used as a shield and just make it look pretty; but what I need to do now is change the one on the right to be a weapon power bar! The idea is that this will decrease over time (or per-shot, Im not sure) and you need coins to keep it charged. Now I was thinking on the way to work today that if its over 1/2 full, then getting a full coin bar as well means you get a new power up, while if its under 1/2 full, then you only top up the current weapons power! If the bar runs out, then you drop a weapon level and the Bar starts again.

This means you WILL have to get into the thick of things to just to keep your weapons powered up, or else you run the risk of powering down to a pea shooter again! (in theory)

New release

Ive update Minus4 and SNASM. Minus4 had a crash I assume caused by a windows update - this is now fixed. SNasm had several opcodes in 65816 mode spelt wrongly, and this is also fixed. Both these programs can be found on my minus4 site.

Long time no work...

Yep, long time now since I posted anything - let alone did any work! Oh well, tick tock and all that. i've still not done anything but I have looked out the source again and started to try and remember what the hell I was doing. I currently look to be just past the half way mark in the demo level, so I guess whenever I get a chance the 1st thing to do is finish the paths off before looking to clean it all up and release it.