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!
Friday, May 16, 2008
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.
Anyway... I now store a masked version of the scroll counter and the sprites use that - so all fixed.
Thursday, May 15, 2008
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!! :)
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!! :)
Monday, May 12, 2008
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)
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)
Friday, May 09, 2008
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.
Monday, May 05, 2008
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.
Saturday, February 23, 2008
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!
Wednesday, February 06, 2008
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.
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.
Saturday, January 19, 2008
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.
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.
Tuesday, January 01, 2008
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!!!!
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!!!!
Subscribe to:
Posts (Atom)