XeO3: Problems....problems................problems

Still no advance on this graphics corruption and crash; I spent all of last night looking through code and playing with Minus4 to try and replicate the bug there, all with no luck. I still think it's to do with the new sprite cache initialisation code because if I run it once only, it seems to be fine. Problem is, the code looks okay to me, which means I'll have to step through all 137 sprite slots being initialised.

You know in a way, this restores my faith in development. When I started this, I had come to the conclusion that either I'd just gotten way better than when I was doing this stuff profesionally, or things were just not that hard now. But this shows that really nasty bugs can still rear their ugly heads, and are still a fag to track down. Thats not to say that its not easier over all - if I hadn't improved in the 18 years I've been doing this for a living, I'd be really worried!

XeO3: Damn bugs.......

I'm still trying to find this bug, and without much luck. I thought I'd found it earlier, but no joy. I'm fairly sure its something to do with the new cache, but I just can't track it down. If I could get it to do the same in Minus4, I could debug it properly, but it runs okay there; that leads me to think its hitting an undocumented opcode that yape and a real Plus4 won't do, but that Minus 4 does do. When adding the codes, I just added them all....I didnt really stop to think that it might not work on the actual machine. I hope to build a new version of Minus4 tomorrow without the undocumented op's - or rather without all the extra ones XeO3 doesn't use.

RetroEdit: reliving the past....

I was busy building a shed today, so I didn't get much done, but I did have a look trough the source of RetroEdit and wasn thinking that it needs cleaned up a bit. I started to write this right back when I was only just starting to use C#, and it shows. I currently use it day-to-day at work so I know a lot more about it, and I can make it much nicer inside. So I may try and clean uo the code before extending it in the near future - like putting editing in for example.....

XeO3: damn.....damn........................damn....

Just proves you should never say "finished" on anything.... After assuming I'd fixed all bugs, a real topper comes along and kicks me on my arse! After a couple of restarts (and this varies!) it looks like theres MAJOR corruption going on, and its killing all the graphics. The game itself looks like its playing away fine, but graphics (sprites, backgrounds and everything else) looks like they've been tosted by something. I can't get this to happen in Minus4, only Yape and on a real machine, so it looks like it'll be a bugger to find.

Damn.....damn..................................damn.

XeO3: Whoops! -*Blush*-

See.... Now I just feel really embarrassed! The reason it only shows up when I have 2 or 3 (or as it turns out less than 8) cache entrys, is because the INIT loop uses the number of cache blocks to clear the array! Heres the start of the init() call..

InitCache:
           ;
           ; First wipe cache data
           ;
           ldx  #0
           txa
!Lp1       sta  Cache_GraphicLo,x
           sta  Cache_GraphicHi,x
           sta  Cache_Index,x
           sta  Cache_8Bytes,x       ; clear first 8 bytes (and more) of cache
           inx
           cpx  #CacheBlocks         ; number of cache entrys to init
           bne  !LP1
    

Now.... those Cache_8Bytes are really important, thats how I scroll sprites up and down cleanly without having to store/cache extra space for vertical movement. Because sprites are stored in characters you have to rotate horizontally, and in theory - vertically; so that you can move it around the screen.

However.... if you store the sprites in columns (which is faster anyway), you can then store 8 bytes before the sprite and just move the start address backwards a byte to move the sprite downways a pixel. This means you only ever copy in 3x2 characters, and the rest are blank. Each column moves up 1 byte and gets the space from the previous column (a colunm is 24 pixels high, but the lower 8 bytes are always blank).

Now the next sprite in the cache doesn't have these 8 spare bytes in front, it does however have the previous sprites last empty character - so uses that!

So... anyway... turns out this bug wasn't clearing the whole of the 8byte cache space simply because I had lowered the number - DOH! I could "fix" it so that it will cope with caches lower than 8, but thats virtually useless anyway, and this way uses less memory - so as long as I now know WHY its doing it, I'm happy.

XeO3: Bug time..

So... I finally found some time and energy to boot up the project again, and low and behold - another bug. If you look at the image you'll see the litte white lines above some of the sprites, this I think is due to the first or last sprite not being setup correctly, but Im having a little trouble pining down as to why. This is running with only 3 cache entrys, which is pretty cool really as it means its using virtually no memory (saving 10k!), but it does slow down a lot when the screen gets busy and the cache is emptied on a regular basis.

Once I fix this, I think that'll be all the bugs out of it, and I can once again start on the weapons system.If you recall, I did start on that before, but it went slightly pair-shapped, and I had no idea why so I had to undo it all and hope to start again fresh later.

Anyways... I'm off to try and find this one, its been around for a while, but with 137 cache slots its hard to spot - at least with only 2 or 3, its right there in front of me.

Life goes on....

I got an interesting link to a blog which I found pretty funny, it seems the DMCA has a really odd loophole which means that if enough people break a copyprotection, then its no longer considered as copy protection!?!?!? Check out the link HERE for more.

I started looking at the stuff I was (supposed) to do for Solder a while back - sorry dude - last night, so I hope to be able to send him something soon. I never did get round to finishing updating my Plus4 to a 128K Flash chip - I really should. I;ve discovered the biggest problem with these things is the sheer amount of soldering! Man theres a lot.... Oh well..

You wait....Time passes.......

Yep, not done anything for a while - so much for getting on with the weapons system! But as usual life catches up. I've been busy cataloging all our DVD's and man, do we have a lot. I didn't realise until we started listing them! Oh well.... need to cut back. I've also started porting my spectrum emulator over to C# and XNA, which means I could put it on the 360 - which would be nice. I also want to put my C64 and Plus4 on there as well. Once I have a framework for emulators, it shouldn't take long to do.... I hope, and C# is a really REALLY nice language for doing stuff in, so much so, I've almost completely stopped using C++ now.

XeO3: Yet another bug...

Damn it... just when I've fixed one but, another appears to have crept in, and this time I've no idea how. I cant appear to be able to shoot turrets any more, which implys the bullet code has been changed somehow.....but how is the question!

Thinking about it.....

Not been doing much just now, I've been mainly thinking about the weapons system and how Im going to implememt it. I suspect its going to be table driven with a new table for each weapon as that makes it easy to power up/down.

I've been fitting a new extractor fan to our downstairs loo, and been reading up on UK mains wiring and power. Mains power scares the shit out of me, as one slip and your basically dead! However, after reading stuff on the net for an hour, and unscrewing a couple of light switches here, I figured it all out and wired it up okay...worked 1st time too! It's a new leason I've learnt from doing electronics...tripple check, then check some more - make sure everythings right, or you pay with yout wallet! (or in this case, your life!) Still, all done now.

I'm eagerly awaiting the results of the limiTED demo comp on the Plus/4, its been pretty good and had some great entrys, and voting has been pretty good as well! Theres been talk of doing it once a year which would let folk know about it and get even more entrys and votes next time! I like these small demos (64, 128 adn 1024 bytes) as they mean coders can try stuff without them having to look too fancy; great fun. I wish they'd add a 256 and 512byte entry as well....1k is too much for me!