Time for a quickie?

I've been playing with a bitmap to C64 convertor after several images I tried didn't convert very well. It seems for simple images the more complex convertors just dont gvet it right at all. Anyway, it was no more than a simple diversion but image processing is always good fun.

I've also started a little game and although I may not finish it, a sample app with realistic usage should provide some entertainment to folk. once I get a little further I'll post some piccys, but I wouldn't get too excited its just a sample app really.

Am I done yet?

I have now added some basic gameplay keyboard routines and a sample collision detection routine. I stress these are samples and need to be adapted for whatever game you might end up writing.

So what do GAMEPLAY keyboard routines look like? Well it doesn't scan the full keyboard for a start - that takes ages. You basically list the keys you want and it'll scan for them and set a BIT somewhere for you to check in the gamecode. This means you do minimal keyboard reading and spend all your valuable CPU time doing game stuff.

And how about the collision code? Well it's basically the same as I had in Blood Money, and have in XeO3. If you imagine 2 spheres colliding, to work out if they've hit, you subtract the centers and get the distance between them, then add the radii together and if the total of the radii is larger than the distance between the centers, they've hit. I do basiaclly the same thing but with squares. Each sprite has a center point and I subtract them (one at a time - no Square roots here!), then I add the two X widths (from the center) and compare with the distances between the X centers. If the 2 widths are greater than the to centers subtracted, then we've hot on X, if so we do the same with Y. For a little more speed, the X centers are divided by 2 so we can get rid of the significant bit of X - one less thing to worry about. SO! The current setup consists of:

16 sprite bouncing around with 3 compile time sorting options.

1 player sprite being controlled by the joystick (in either port)

A gameplay keyboard routine

Some basic collision detection.

And there you have it. If theres nothing else I'll start doing a little game of some sort or other and when thats done, I'll release it. Not that I really need to do a game though, but it'll give others time to ask for additions while I'm doing it...

C64 Framework...

So what I'm thinking, is that I should write a very small, very simple game using the framework so that people see how you could modify it. Even if its not a complete game to be honest, just something really simeple where you run around and shoot things, or pickup things or something simple.

So no idea what I'll write... but something....simple.... This also means I'll add simple collision detection that you can butcher to do something else later.

if you have any ideas of simple games that'll not take long (and I MEAN won't take long...) let me know...

C64FrameWork: Holy smoke Batman!

I've now added the sort Dan used in Armalyte as well, so theres now 3 different modes there all available as an option for when you start your game. To select them all you need to do is change a single equate value (setting it to 0,1 or 2) and the code will build the correct version (Try doing THAT with in a monitor!).

In the case of randomly bouncing sprites Dan's clearly win's out even over my shiny new one, to the sum of 42 freely bouncing sprites all on a STOCK C64. Thats damn impressive I have to say. However, I'll emphisis that it really, Really, REALLY depends on the game and how your sprites are setup, banded, spawned, moved and all the rest - BUT with 3 separate sorts now here, you should be in good standing to pick the right one without having to mess around. The image shown here is actually the worst case (the red bar taking up top and bottom borders), normally it only takes up the lower border which is superb.

I'll also make the point that this is a frame work. Its NOT a finish bit of code. You should take this as a basic core, and shape it to target your game/applicate better. For example, if you want to have a 2 player game, you should modify the code to multiplex only 6 sprites, or if you WANT to multiplex 8 to allow for a player with multiples above and below again you should extend the code to do so.

The code is pretty well commented but due to a couple of bugs in SNASM (namely nested IF/ENDIF's dont work) I cant get the code fully auto generating yet.

I've also now added a player sprite which is controlable via the joystick and flashes away over the top of all the rest. So, barring anything else being requested (and I'll give it a couple of days) I'll write up some doc's and release it next week sometime....

Oh, and as a little aside.... when running this on a SuperCPU without even coding it in 65816 assembly, it takes up around 16 scans in total - including ALL the IRQ's....

C64 Framework progress

I'm doing pretty well with this so far and have managed to get 30 sprites being multiplexed using 7 hardware sprites. I usually prefer to leave one sprite for the player so that theres never any danger of them glitching or tearing, and also that being sprite one they will always appear over the top of the rest of the sprites. However if you wanted to multiplex all the hardware sprites, it should be pretty easy to modify things to do so. I've ended up putting both sorts in just in case theres a case where the old one wins out which may be possible in some rare instances, but mostly I expect folk to use the new one. I might also put in Dan's one from Armalyte as it has a differnt range as well and may provide yet another option given a games unique circumstanstances.

If no one gives anything else they'd really like to see added, then I'll simply add a single sprite being controlled by a joystick and that'll be it really. What's here is a good head start for any new game, as a solid multiplexor is always first on the list of things to write. Thats not to say this is the best option for every game mind. In Ballistix (and also Morpheus if memory serves), I used fixed IRQ bands and a sprite was inserted into a band the "Y" coordinate fell into. This has the added advantage that the SORT is virtualy instant as its basically a bucket sort. Take the Y coordinate, shift it down a bit, and store it at the end of the bucket list. Easy. However this multiplexor is very flexible and will allow for large joined sprites to move in sync which a fixed banded one wouldn't.

I will at somepoint do this for the Plus4 as well, but I'll need to untangle the software sprite system from XeO3 first, and that'll take time. I also don't expect people to use 30 sprites either, but its what this can manage when pushed to the limit - unless your on a super CPU of course, in which case you can use it incredibly high. I will also at somepoint release a proper SuperCPU framework but I suspect theres less demand for that since theres only a couple of folk that even HAVE one!

C64 Framework

I'm currently cleaning up my new C64 framework and just now its pretty simple. A basic multiplexor with "N" sprites multiplexed (currently 16) and rasters going and I was wondering what else I should add?

Got any ideas as to what the basic frame work should contain? It should be fairly broad scope as theres no point in specialising stuff since it would get ripped out pretty quickly by anyone actually using it, but if you can think of some common stuff you always use, like keyboard routines, joystick functions and the like... then I'll probably add them in too.

So let me know what you think would be handy....

Back to work tomorrow....

I've had a reasonably fun week or so off, but it'll be back to the usual grind tomorrow which will mean fewer updates and less playing around. Oh well, its been fun :)

I'm currently playing with lots of different things just now, flicking back and forth as the mood takes me. Currently I've got my SuperCPU hooked up as I was playing with a true dual-playfield system. Its got 2 bitmaps and masks one onto the other if you can believe it! I've said it before but Metal Dust I don't think used the power very well and does look like just a nice C64 game. To my mind the new Enforcer 2 actually looks just as good but is on a stock machine. I think you need to do something really different - something that would be impossible on a stock machine, and I'm still playing around with what that could be.

The problem with TRUE dual playfields is that you can't make best use of colour, in fact your pretty much back to 3 colour displays or you end up with huge colour clash again, and thats not very SUPER. Also to make it simpler, you really need to manually smooth scroll the front layer and that means you can't make them up from a software character map meaning you can't have it all animating away which would also be a shame. Still, I'm working away on it...

On the C64 XeO3 front I've obviously been pluggin in my new multiplexor and speeding that up, although there is one more major speed up needed here and thats when I do the sprite copy to the IRQ buffers, I also copy in the first seven sprites, however these then immediately get copied into the hardware. This means an obvious speed up is to skip that and copy the first seven sprites into the hardware directly. This will slow down the copy a little, but not having to duplicate it will be a big speedup over all - I hope.

PC Engine.... I've almost got my assembler going although I need to add a few more addressing modes to deal with TEST #??,blah types. After that I can start to play properly, however my PC Engine has started to act up and it looks like its dying, so I'll need to find my TG16 in the loft at somepoint.

Lastly... XeO3 on the Plus4... After playing Blood Money a little again, I'm starting to sway towards the player dying but the action keeps on going. You then come back on flickering or something to give you a little bit of a shield and then carry on from there. This means you won't be thrown back to the start of the level, but you WILL lose some weapon power (not all). The reason for my sudden reversal is that after playing and watching Blood Money I realise that its gonna get hard later on anyway, so even if you don't get thrown back to the start, you're not gonna finish is easily anyhow - so what the hell. It will hopefully mean most folk won't get too frustrated early on, but it does mean it'll get pretty hard later on, which was to be expected anyway I guess. I'll try this out and get a few peoples feedback, or we might even release another test although I think that unlikely for now.

Oh... and a quickie. With the C64 codebase getting pretty stable, I think I'll be releasing a framework sooner rather than later. So it won't be the full XeO3 source yet, but it will be a nice framework for starting a game in, complete with a production quality multiplexor. People can then strip it to bits and bend it into thier own idea of a framework and make some toys with it..... we can hope.

And thats where things stand for now! Fun, fun, fun!! Any questions/suggestions/gripes/feedback, please just post a comment.

C64 raster splits

C64 sprites are great and all, but they really screw with your raster splits. Depending on how many sprites are over a raster, what character line we're on you may end up with virtually NO cpu cycles left at all! Looking up some timing info on the VIC (HERE) shows that BAD lines+ all sprites leaves you with less that 10 CPU cycles a scanline, and only 4 write cycles at the start.

Theres a few ways to get a cleaner split, but most use too much memory. However, I've got a reasonably stable raster for now and although it flickers a little now and then (when LOTS of sprites scross the panel raster) its mostly okay.

I guess the best way would be to count the number of sprites that cross then do some kind of variable delay depending on the count. Thats faffy stuff, and I could spent LOTS of time trying to get a clean raster split, so I'm happy enough just now with a basic flicker... I might fix it one day....

Actually.... If I lose the 1st pixel of the panel, the flicker won't be visible, thats probably the best solution.

EDIT: Well, removing the 1st pixel of the chars at the top of the panel actually works pretty well. I now have a solid raster split no matter what crosses the raster - cool.

XeO3: C64...

I've spent this evening plugging in the new sprite multiplexor sort to XeO3 which has given it a little speed boost as well. It's nice when all these things come together like this, bit of code here... function there. I've also sped up some of the other functions in the IRQ although these are all pretty minor. Still, faster IS faster...

I've had to start freeing up some zero-page though as I've started to run out. Right at the start I allocated 30 bytes for TEMP usage, and that was a bit silly, as it now means that temp+?? is used everywhere and its going to be very hard to reduce that count - even though I suspect that less than 15 bytes are actually used. Damn.

I've also shuffled some variable usage around so that most of the sort now accesses Zero-Page which helps with speed a little too. However, the multiplexor IRQ doesn't and that means its just a little slower than is possible, but ZeroPage is severly limited really so....

Sprite expansion....

You know I don't think I realised just how expensive X and Y sprite expansion was to the multiplexor. It's used twice (that I can remember), the reverse control radio transmitter, and the giant grab claws, and while its nice every sprite in the multiplexor has to store and process these bits! If I remove this feature the copy section of the sort is reduced by another 6 scanlines - SIX!!! Now that means each sprite pays around 1/3 a scanline for it in the copy which isn't much, but the more you have the more you pay.

On top of that we also have the display IRQ's which again has to pay the cost for only a couple of sprites in the whole game! Now I'm wondering if its worth the expense, or should I just drop those baddies altogether? Actually... only the CrabClaws need to be dropped (or reworked) since the tower would only require 1 extra sprite which is hardly expensive!

Anyway, I know when I was coding them I thought it was cool to allow expansion in a multiplexor as no one else did, and it allowed for HUGE baddies (oh..come to think of it, the level2 BOSS used it as well), but is it really worth the lost CPU time?