Life after floppies....

I've spent a little time trying to chat up my MMC64, but it just won't respond to my tender words, at least I wasn't having much luck until about 5 minutes ago. I was following the documentation completely - cut and paste actually - but with very little to show for it. It then occured to me that since I'm loading from it, it must already be enabled and ready to go. So I've dispensed with the full initialisation and jumped straight in with sector reading, and what do you know! It works! I'm not quite sure what would happen if you have to re-initialise the thing as I can't seem to get that going at all, but as long as the cards in and you've just loaded the main program from that, its all funky.

For a first pass, not having any error state is probably fine, after all its not like you have to swap disks (err...MMC cards) during a game or anything, and if you remove the card then its probably your own fault. Still sometime down the line doing a better fault tolerant system is desirable - but lets get the bugger working first! I still expect this to be released in V1.1 of the framework, but its good to see it shouldn't be too difficult.

I've also added a simple animation system to the framework even though I said I wouldn't. I figured you can always rip it out, and in the end the ones I write are almost exactly the same over and over again so sod it. This means theres now the multiplexor, a few sorts, basic collision, animation, joystick and keyboard input and a very simple test app - which is a good start. Actually, theres 2 test apps. The Frame work has code to bounce sprites around in a simple manner, and then theres the playformer framework which gives a little more realistic usage. Still the more the merrier.

I'll now have to do another web page to download all this rubbish, and expand my wiki page to have some simple documentation...and I mean simple...

C64 framework V1.1?

I've thought of one more thing I'd like to add, but its not a quickie by anymeans so I'll leave it till version 1.1 so that I can get this version released. After speaking about using the MMC card as a loader, I suddenly realised that it would be awesome to have a proper file loader built into the framework. That way these no excuse as to not use it, and it'll make development MUCH simpler. Simply bung your files onto an MMC card in a folder or something, then load them - how simple would that be! It might also mean we would start getting some more games that load directly from the MMC rather than floppy/tape, which would be very cool.

I also suspect V1.2 will be when I start to add remote debugging features through RR-NET. As I've mentioned in the past I do have the beginings of a remote debugger on the Plus/4 and would like to get that onto the C64 but using the ethernet adapter rather than the user port. Although since the upload/download part is prett much GetByte()/SendByte() I can probably have both in case people don't have an RR-NET. It would be good to get a proper devkit again as I was reading about the old PDS system I used to use and starte getting a little homesick for it...

You can read about it HERE if you wish although its in spanish. HERE'S a translated version via Babelfish. It really was an amazing little system and I miss it hugely.


Oh and as a little side note, I've managed to get WWW.XEO3.COM again. I'd let this expire and some bugger pinched it which is why I went to the .ORG, but I've now got it back again so I'm happy.

C64 framework and sample

I've now finished the sample app that I was doing for the frame work; well, as much as I intend to. As you can see its a platformer in bitmap mode, and you run around collecting the bombs. Its basically a simple version of the first level in bomb jack (without the baddies). It uses the built in player-2-sprite collision routine as Ive been lazy and done the bombs as sprites, but it does help to show how to use the framework better. Also remember that I've only really spent a couple of days on the sample, so dont expect too much.

I've done it in bitmap mode because platformers should never really be restricted by character count or colours, so having a full bitmap is nice. It also let me have a pretty background, although it turned out to be harder than I thought at the time. I had to rip the bitmap off an old Ballistix floppy and then I discovered that I had stored it compressed! So I then had to rip the decompression code from Ballistix into the sample. Still it was only byte run so it was easy enough.

Anyway, with this done, I now only need to clean both up, write some very basic doc's and then upload it somewhere. Perhaps someone will even finish the platformer sample... who knows... It would be cool if you did a built in MMC loader and you could load each levels bitmap from an MMC card really quickly. I think any games you do these days should take advantage of new tech that everyone's buying, and that in turn would help sell more and move things along. If nothing uses a new bit of hardware, no one will buy it!

Last chance for anything to be added though. I can't think of anything, but feel free to suggest. I'm not sure when this will get released, but I dont expect it to be long now. Hope you all enjoy it, or at the very least have fun looking though the source...

Super CPU ideas....

Theres been several comments on the last post so let me go through them here...

First parallax scrollers. Games that have done these in the past have been limited to character blocks to do it's parallax effects and these have worked pretty well for the most part, but perhaps if you actually MASKED a full bitmap onto another you could produce something pretty special looking. Of course doing this would negate the use of the full attibutes as you would get colour clash... still dual playfields is always nice. You COULD stick to doing character based parallax and do a full bitmap scroller which would look pretty good, but not THAT much different from a stock C64 game using characters i suspect. This is what MetalDust does (I think) and its...okay... but we've come to expect games doing that kind of parallax.

Sprites. Now its true that anything I do I'll immediately load it up with as many software sprites as I can, and that I expect the screen to be crawling with baddies+effects. C64 games do this usually with lots of cheats, but if you can draw large sprites, you can push the boat out a little. However these will obviously suffer from colour clash again, which is never good. I suspect that if I arrange the bitmap better (straight rows rather than the funny character mode way) I can seriously increase the number of sprites I can actually draw. I'd then convert the screen on the fly as its copied down the VIC memory. Since the SuperCPU has a 1 byte write cache that gives me 20 cycles to get the next byte, and thats more than enough to convert the straight row format into the silly Commodore one. Of course on top of that, I now have 16bit registers allowing me to load and mask things on better, and upto 4Mb RAM (although mine has 16Mb, I think 4Mb is a good limit - anyone have less?) allowing me to pre-rotate everything at the start.

Now its also been suggested that you could do a full PROPER Lemmings game, and this is also true. You wouldn't be able to get the lemmings as the blue/white/green we all now and love, but a full white would be possible. In fact the best way (and to avoid colour clash) would be to use the full bitmap mode for the backgrounds and multiplex Hires-expanded sprites (on X at least) for the lemmings. That would have MCM resolution but it hires. Thats doable and gives a full dual playfield for drawing sprites + explsions easily. Not only that but because the SuperCPU can quickly multiplex sprites, you're only going to lose a few scanlines making this new playfield. On top of that... It only takes 7 sprites to do the playfield, leaving 1 hardware sprite for the cursor! Using the Commodore mouse you could finally replicate the proper lemmings game on the C64 - complete with the full 100 lemmings!

Lastly.... I suspect this will become a pet project and would be the ULTIMATE game for a SuperCPU, as theres no WAY a stock machine could even hope to do it.... GTA. Yup, I've been giving it some thought, and I think I could replicate the graphics engine I did on GTA1 on the SuperCPU. Im not sure I'd zoom in and out in the same way, but I think I can certainly do the perspective buildings... They may or may not be textured though... that Might be asking too much, but you would certainly get the effect GTA had of zooming around a 3D city... now that WOULD be cool....

Having a play.....

Okay, so I'm not doing my mini-game thing, I've been playing with my Super CPU instead. One question thats always got me thinking is what can you do with a superCPU that you can't do with a stock C64 (3D aside...).

Well, heres one: full screen overscan bitmap scrolling. Not using expanded sprites or anything, but using the full bitmap screen AND sprites in the side border. Now... I thought you might actually manage to do that with delayed DMA etc. but drawing into a full screen height would be virtually impossible surely, particually since you have to scroll through 4 sprites.

Well... okay... you COULD kinda do it... kindof... Imagine this...

FULL screen bitmap, delayed DMA scrolls that - great. Now how about the edges? Well, you need sprites there of course. BUT that means you've to smooth scroll through 4 sprites (2 on each side). Well no. Sprites can move in pixels after all, so just move in bytes and move the sprites in pixels to sumulate a normal scroll.

This still means you have to redraw the sprites though, and thats 4 sprites, (say) 189 pixels each. Quite a bit.... well...no...

IF you used another extra sprite on each side, then you can scroll the sprites and bring on new empty ones each frame too, then your only drawing 2 colums or sprites 189 pixels high over 8 frames (along with the bitmap) - which is perfectly doable.

Could make for a pretty cool C64 demo - standard MCM res, full screen/overscan scroller...neat. Course... since you can't change the colours very well in sprites, you'd have to pick 3 normal colours (sades of blue etc)... but still. You could also use character maps of course, which would make scrolling them much easier and would mean you didn't have to use delayed dma, as long as you double buffered the character map.

So the outcome.....A cool demo on a normal 64, and I still need to find an impossible task for the SuperCPU. It's pretty amazing what a stock machine can do if you poke it a little....


(and before you ask...no I have actually written it all, I've just been playing and know HOW to write it....)

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!