Still here!!!

Just a quick note to say I'm still here, but now very busy at work again. I have hardly been on my machine at home the past month and I'm not totally sure when thats likely to change. However I haven't given up hope, and with another trip to Seoul next month I might at least get a little bit dont on the plane... maybe... perhaps... who knows, stranger things have happened!

Life goes on.....

Well, yes...January hasn't been a good month this year. Flu and close family bereavements have all added up to just a bad start to the year. This means I've not been doing much on the XeO3 front; its far from dead again, I've just not been able to (or had the will to) carry on just now.

To top this, work pressures have started to build once more, and they are only going to get worse. I've had to start looking at stuff at home which means even less time to do my own hobbies.

This will (as it always does), ease off at some point and we can carry on, but until that happens progress will be slow. I'll try and keep you all updated as time goes one, and to reassure you I've not forgotten or grown bored with it all.

Still here.........

Yep, I'm still around if only just. I've had the flu so haven't been feeling like doing anything these past few weeks, but I hope to get back to it soon. The demo is still on going and still has work to be completed before release - but it is coming I promise!

I am about to be very busy at work again, so I hope to release the demo before that happens....hope to at any rate.

Happy New Year!!!

I've given up on trying to get each LED unit passing on the packet from the previous one if its intended for a unit further up the stream. For some reason, it just isn't working, and I really just can't put my finger on it. I could build some special hardware with mini screens or something to pin it down, but I really dont want to do that; way too much effort.

So, I've gone the lazy route and assigned each unit an ID at compile time. This means each unit will have to have its own compiled version, a pain but not un-livable with. It also makes the code much MUCH easier....

Still, since the hardware design doesn't change, if I ever figure it out, I could change it later. The Master code doesn't change either, its just how the serial line is passed on It may be I have to boost the serial signal as it'll have to go quite a ways. This would mean it has to pass through some sort of AND or OR gate just as a booster, I'll wait and see.

If anyone out there has experiance with PIC's and want to look at the unworking source, let me know..... No idea why its not working - it was pretty elegant as well....

Anyhow, I've created a 3 unit board and Im busy drilling all 261 holes! (eak!) I'm about 1/2 way through, and I'll finish it off tomorrow and then solder it all up, that part shouldn't take long, although I do have to solder 24 jumper wires along with the actual components. I think once this is working, I'll replicate the design in another package, and then see about getting some real baords made!

On a little side note....Its almost a YEAR since I started this project - looks like another one thats gonna run and run. Where HAS this year gone!!!!

Led Scrolly

I've been playing with electronics stuff again. Just before stopping for the Christmas break, Russ was moaning that I still hadn't finished my big scrolly message board, so I thought I'd have a crack at making a real life board using some some printable solder mask I got a while back. It took me a while to get things right (and I had to go and buy a cheap disposable Iron for it too), and the nerve to break out the chemical solution for the copper board, but once all that was done, I mananed to get a reasonable 1st attempt at a board.

It's taken a little bit of time to get it all working, as I'd made a right hash of some of it, so I had to cut some tracks and solder in wires to bypass mistakes. However, its working now, so in theory, I could now think about sending off to get real boards made!

I still need to work on the master PIC side, along with the PC comms. The idea is I'd use a TCP/IP or UDP interface (perhaps even wireless) and allow simple bitmaps to be sent. The mastr pic would then send this to the correct module.

I do have the basics working just not the PC comms side. The image on the right is the finished (one sided) PCB, and as you can see it still has quite a few jumpre wires. I dont want to make double sided boards at home, way too hard. If I ever get my milling machine, then I might give that a go - in fact I simply expect that to work.

Still, its nice seeing the actual PCB in all its glory, and I may end up making a board that can hold 3 modules just to see what it looks like!

One thing I would say, is that with the software Im using just now, it really doesn't route very well, and I do end up putting a lot in by hand. It could just be because this is a cheap bit of software.... I dont know.

XeO3: Late again....

Well, what would this project be if I actually managed to do something on time...*sigh* Oh well. Family and a stinking cold have knocked me around a bit and I'm no further forward, so I;m simply unsure as to when I'll manage to finish it now. I had hoped that I'd have loads of free time over Christmas and new year, but as it turns out, my wife is working, so I'm looking after the kids. Oh well...

That said, rest assured that we are still doing this 1 level test and it is coming soon; just not as soon as I had hoped for. On the plus side, Luca has been making some scripting doc's which you can find on the main page, so that when it IS released, you'll be able to make your own level if you wish.

If you happen to read MicroMart, you'll notice Shawn's 5th year there has ended, and still no XeO3 in sight - sorry dude. Lets hope I get a little free time soon, and we can finish this and progress onto the main event...

Edit: Oh, and I've also decided things are a little too easy on the test level, which leads me to think that the baddies should shoot at you - as well as the turrets. So I'll probably add that after the demo level is done.

XeO3: Damn....

Damn, damn....damn..............damn.

Running out of time; so much for getting a level done by Christmas! I have done a little more on it, so its not totally dead in the water. I'm also now on holiday so I hope to be able to do even more. However....a couple of things still left to do.

1) Finish the paths - I HATE doing paths.
2) Update the weapons system so that it has a power bar and it downgrades as you play. This idea is still a work in progress, so it'll be interesting to see exactly how it'll work in practice. I suspect it'll need some tweeking as we go.
3) Strip out all unused baddies for the demo.

And thats about it. So not a lot, but a lot to do in a couple of days. It may be I have to aim for NewYear, and not Christmas - but I'm not giving up just yet.

XeO3: Path debugging.

Almost there. My 1st pass of the Path Fast Forward is just about done, but it doesn't seem to quite match up. My timing appears to be out by a quite a few script cycles as paths are coming on too early. If you remember a while back I was talking a bit about my script engine, and each instruction was 0 or 1 cycles. Well I've built some code to skip over instructions and process PAUSE's by subtracting them from the number of pixels I have to scroll.

Anyway, while it appears to be roughly correct, its not perfect. If I skip $10 macro blocks (=384 pixels) then sprites are simply coming on too early. That said, its realy nice to be able to skip forwards like this.

There is a downside though. If you stop the scrolling, the FastForward will try and find the next one that starts it again (as you can't advance in pixels while the screen is paused). BUT if you stop the scroll and dont start it again, then keep the master path going with an infinite loop (using a pause and goto), then the FastForward will lockup as it never finds a restart. However, as long as this is know, it should be okay.....

Commands like PAUSE/NOP are the fastforward's bread and butter, since it simply subtracts the pause count from the number of pixels to move (1 PAUSE/NOP = 1 pixel scrolled). But for some reason they aren't matching up properly - yet.

XeO3: More debugging stuff.

Well, not DEBUGGING as such, but stuff to help making paths that little bit simpler. The current problem I have with creating new paths is that I have to scroll through the whole level to see the path I'm doing. This means everytime I make a minor change, it takes a few seconds good seconds to get to the point where the path is even before I see the alteration. This is a pain.

So, I've decided to add some code to try and fast forward the level before the game starts which means I should be able to design the paths where the are supposed to be, without having to use YAPE's warp feature to get there.

For the scroll this is pretty simple; draw tiles until I'm there. But for the path script its a little harder. I need to have a dummy process where I look at the command and process its cycle count, but dont process the path. Basiclly run the master path in TURBO mode too. This means when the screen fades on, there won't be baddies there, but all the counters and locations will be right.

Well, thats the theory...


On a little side not, I was thinking that now I have the SuperCPU drawing a software character map into a bitmap, theres nothing stopping me drawing lines right over the top of it all - or even polygons! Because I don't have ANY character problems, I can use the screen like the bitmap it is and possibly draw R-Type style lasers with lines that bounce around the screen, or perhaps draw a 3D baddie; although that might look very odd....

SuperCPU: Scrolling...

I've managed to get Level 1 of XeO3 scrolling on the SuperCPU using my software character map - well, a test anyway as the map is still 8bit, but that would be a simple change. What this now means is I can now load up and convert the sprites into a BITMAP system, and then see how many I can draw!

The other thing I was thinking was, why am I sticking to the normal 40x21 layout? Why now 21x40? Storing the screen in columns makes sprite drawing much easier and would fit a lot better with the internals of the sprite system.

One thing that "may" now break is the optimised sprite render as I no longer know if a space has been printed. I guess I could carry on as normal using a character system since I now have no limit on the characters available, but Im not sure. My gut tells me that in the long run, it would be slower, still that "space" optimisation is very cool and speeds things up hugely....

Watching the scrolling go its a little dishartening as it looks just like a normal C64 version. But I know its far cooler as being a bitmap I can now have 3 colours per tile AND since its a software charactermap I can animate ANY tiles I want and have the whole screen move without batting an eye!