XeO3: Surprise Surprise!!!

I've spent the evening playing with the main game again, this time adding a couple of new cool features that we'll keep quiet about for the time being. However I was also adding the speedup I was on about yesterday to the X axis this time and in doing so I managed to speed up Y a bit as well. Doing this then led me to this new feature - its pretty cool, and its somthing that a C64 would struggle to do properly - if at all! The current thinking is that each port of the game will actually have quite a bit different, to the extent that some would say its not a true port, but a different game. While I could cripple one version to make anothers more like it, I don't want to - I want each machine to be pushed to its limits, even if that means adding features that the other versions won't have!

Purists will complain that they want XeO3 ported exactly, but I think having a great game - regardless of what the original looked like - is more important. It also means there may be several new games fo people to play which look only vuagely like each other. The style and baddies will be the same, but I suspect the levels and probably the paths they follow will all differ - weapons should be fine though. If someone wants an identical port - they can do it themselves by mixing code from one playform to the others.

However, this also free's me up to use the C64 sprites better, have more detailed backgrounds and all that this entails, and it also means that the spectrum version can push its own strengths - should be good!!!

One thing has occured to me though, I'm going to have to untangle the sprite routine from the Plus/4 version into some sort of framework so others can use it properly! Its a bit intertwined just now and some might have difficulty extracting it....

XeO3: Go faster sprites....

Just had a small brainwave..... Normally 16x16 sprites actually draw 24x24 due to rotation, however when the sprite "fits" perfectly inside a 16x16 (say its coordinate is 0,0 and hence has no actual rotation), you can drop the surrounding characters. While drawing the chars themselves don't take long, they still have to get masked. BUT! becasue +4 sprites are character based, so is my clipping routeing, which means I can drop any individual character from the sprite simply by flagging the character its about to overdraw as $FF. This is how I do clipping off the top and edges, I just have a table of indexes some of which point to $FF characters.

  Normal    NoY      NoX    NoX&Y
  -------------------------------
  ADG       ADG      AD     AD
  BEH       BEH      BE     BE
  CFI                CF

Anyway, what I now do is check to see if the Y coordinate has a fractional component, and if not, I set the bottom row to be clipped! If we still have to draw the full 24x24 sprite (which is most of the time), then this only adds 30 cycles PER sprite(300 over all), which isn't much - really. However, if we find we're dipping below our desired framerate I now have another tool to help speed things up. Take a sprite that simply flys across the screen, well if I make sure this sprite does this on an 8 pixel Y boundary, then its always going to be significantly faster due to the fact it will never draw the lower row.

I could do the same on X where I drop the last row, but because of the scrolling, this won't happen very often... I'll probably try it and see, but I think the Y check is good enough.

RetroEdit: Cleaning up.

Okay, back to real work again.... I'm cleaning up my RetroBitmap control and converting the rest of the application to use it, which is taking a little longer than planned. I now also have to re-evaluate whether I want to have a per-sprite HIRES/MCM switch. While not really important for a C64/Plus4 it might be down the line if I decided to add Amiga editing and add a "number of colours" mode. This might mean you couldn't edit 16 and 32 colour sprites in the same project. However, changing each sprite can be a pain depending on what your doing. I'm still not sure how I'll handle this, but Im edging towards each sprite still having their own mode.

The Control now renders everything correctly and I can now play animations back as before, although I've still to add the all important keyboard short-cuts. The control can now also be any size (although, there may be invalid combinations like a 13x13 in MCM etc.) and can render to any size bitmap. The bitmap is public so that you can replicate it in other controls; I for example scale it and use it to display the various sizes of the sprite without having to re-render it. I hope to add some sort of custom exporter-pluging system (at somepoint) so you can save your own formats. I was reading the discussion on WorldOfSpectrum forums and they were talking about a funny zig-zag format. I'll try and add all the common ones from the start, and then let you do plugin's for any new formats.

All this is pretty far down the line....Possibly even after XeO3 is finished. Also, I plan to save everything in some sort of IFF format (project files that is) so that they are easy to disect; if anyone else has an opinion, nows the time to object. I was considering just using some of C#'s native serializing stuff, but I want folk to be able to extract stuff from it if then need to.

Oh...and one last thing..... Do people just want a load of sprites that the can "view" as animations, or do they want a list of anims that the program orginises nicely for them? Just now I have (say) 167 sprites, and I set IN and OUT points and then view the anims. This is very easy to use, but it means I cant set up say a "baddie" animation and save out delays etc. But usually these numbers are different for each program so its not worth it..... anyone have an opinion on that?

Uploader....

I've now finished my new uploader, and it's actually turned out to be a fairly good idea. I've been using my MMC64 to upload and play C64 games. It turns out however, that it just isn't very good as some file - anything really big I suspect. I have several .PRG files which I thought had gotten corrupted because the MMC64 wouldn't run them properly, however, my download program manages fine. This could be for a few reasons though. The MMC64 hasn't actually started BASIC yet, so it may not have everything ready to run these programs, or it might be that its not setting up certain BASIC addresses for the unpackers or something. Or it could just be that its too big and simply won't work.

Whatever the case, my uploader manages these games fine! It takes around 6 seconds to transfer a full sized C64 program which is pretty quick. I currently use the MMC64 to load the boot program which is much quicker than loading off disk, and then my command line tool to send the .PRG file I want to run. I'll probably expand this to include .P00 and .T64 files as well as these are pretty simple and would be quite handy. I could write a little GUI tool I guess, which would be particually handy if all you're doing is running games. But I suspect most people have other ways of getting stuff to the C64 (let alone having to build the cable( so I'll not worry about it just yet.

Anyway, if you want it.... you can download it from my minus4 site, minus4.plus4.net. It includes the to .PRG files for the C64 and the +4, both are tiny and if need be, could be typed in. The wiring diagram is in the text file - Enjoy!

I'm also planing to port my DEBUGSTUB I have for the Plus/4 over to the C64, as this will let me control the C64 fom the PC. The initial plan was to write a full and proper remote debugger, complete with source level debugging. I got as far as being able to start/stop programs, and then single step them but it needs lots of work. However, as a side line, this program lets me control the Plus4 completely from the PC side, meaning I can download images, sounds and tools to it and use it as a slave for editing. Imaging having a PC editor that shows you the graphics on the PC AND on the Plus/4 as you draw them. This would be extremely handy as viewing on a TV changes things hugely. If I ever learn enough electronics to be able to build a Spectrum interface, then I'd probably add this kind of thing there as well.... RetroEdit could be turn out to be extremely cool.

XeO3: C64 time....

I got my new dual parallel port today, so I spent the evening updating the Plus/4 downloader to allow me to change port address, and writing the new C64 downloader. The piccy shows the new cable before I've tidied it all up and put the casing on; but now that I know it all works, I can do that whenever.

The C64 cable is cool as it sets a whole byte at once (unlike the +4 that sends nibbles). But it only seems to match the +4 speed, probably due to the higher clockspeed on the +4. I suspect I could knock a second off the +4 one if I blacked the screen, but 6-7 seconds for 64k is quick enough. This should allow a quicker turn around of testing on the C64 version as it downloads under the ROM's and VIC chip, which in turn means I dont HAVE to pack it to run/test it.

Once I've cleaned it all up I'll post the new C64 downloader, along with the wiring diagram - although I suspect its the same as a few others, its very simple: 8 Data wires, 1 signal, and 1 busy - easy. I know loads of folk will simply point out that theres already 1,000,000 downloaders, but from what I saw, they were all far too complicated - I just want download and run!

XeO3: Selling an idea.....

I was over at Lemon64 and they have a really handy poll there which asks what you do you C64-ing on, an actual machine, VICE,CCS64 or another emulator. I'd expected it to be around 15-20:1 in favour of emualtor (based on people I know), but I'm happy to be proved wrong again! Its early days on the poll (I think), but currently around 44% of you play on a real machine!! wow! Thats great, and pretty cool. It also brings up the question of selling disks again since my original argument was that ony a handful would want to buy an actual disk, I'll need to start another pool and see what people actually want but it may be we have to start thinking about making an actual product to sell to folk so they can play on their actual machines.

I wonder what the +4 ratio is.......

RetroEdit: Back again...

After a short break - where I more or less did nothing but sleep, I've come back to RetroEdit and decided to shuffle things around yet again. While it's been going fairly well one thing thats been lurking at the back of my mind is that I'm going to have to do this all again - but this time with characters. The one thing I hate doing is repeating the same work, even if its cut and paste job, its just horrible. So, I'm about to move the rendering part (and probably the editing side) over to a user control. In VB and C# you can write your own controls that you can then drop into your windows form. This is pretty handy since on most retro machines the rendering for sprites is the same as the rendering for characters. i.e. The Spectrum is still HIRES, the C64 still has HIRES and MCM - as does the +4. So, I'll move all this code into its own display (RetroBitmap) and then I'll be able to use it for drawing/editing both sprites and characters (or chars+tiles on the spectrum).

It also means that once released, others can simply swipe the .DLL file and use it themselves inside their own C# or VB project - which is also nice.

And.....rest....

Done nothing at all tonight.... well, not quite nothing. I got an Opus Discovery disk drive for the spectrum months ago from ebay for a steal (around £14 I think), problem was it didn't work. I've spent the past few nights tinkering with it and I finally figured out what was wrong. The disk drive itself simply wasn't working. After pulling it apart and putting it back together the drive started up and kinda worked, but I got disk errors. So, I dismantled it again and saw it was more or less a standard PC floppy drive, but plugging in a PC floppy didn't work. Probably because back then they were XT drives. So I was trying to think of a way to get an old XT drive to try, and searched the web for one, but with no luck. Or rather no luck I want - $170!! No thanks.

Then I had a brainwave. I'd just gotten an 1581 drive assembly (without drives) where it stated the drives were removed for use in the Amiga, so I thought...what about an Amiga drive? I was a bit reluctant to destroy an Amiga to get this working, but I thought try and see - I could always keep an eye open on ebay for a dead Amiga. Then it stuck me: The Atari ST reads and writes PC disks... Anyway, since I have a huge amount of crap, I of course have a dead Atari ST, so I removed the drive and plugged it it - BANG! works a treat! It seems to have all the jumpers the PC XT drives have as well, so if your ever after an old XT drive, try an atari one first - they're cheaper!

So, job done - back onto Retro Edit tomorrow I hope.

RetroEdit: Clean up.

I've not done that much tonight, just cleaning the code up and putting in the machine selection system I was yattering on about yesterday. Now if I load in some sprites and I select SPECTRUM as the global machine state, it sets all the sprites to hires. Same goes for PLUS4 and C64. On SPECTRUM mode, it also disables MCM selections and so on. This is the kind of things I've been doing, nothing earth shattering.

I've also added in an Enable Mask tick box, and an Edit Mask tick (which becomes active when masks are enabled - of course). This means on spectrum sprites, you can edit masks along with the sprites. I'm thinking of putting in a basic "light box" mode as well, to let you see the next (and possibly the previous ) frame so animation is a little easier. I'll also allow this mode for MASK editing, so you can see the shape you're trying to bring out. All these kinds of features till take time to do which is a bit of a pain, but its back to the problem of a single state that then effect the almost every other state, and you have to make sure its valid. Yuck.

I hope to start basic editing tomorrow so that it'll actually become useful, so once I get HIRES and MCM drawing it, I can let Luca lose on it, and see how it holds up. I need to figure out how to detect key presses in c# first so I can use things like + and - to change sprites, and 'm' to toggle the mask view on and off, that kind of thing. So still lots to do.

RetroEdit: HiRes Appears...

I've spent the evening changing the editor into something a little bit more sophisticated, it can now do Hires and MCM sprites - although I still can't edit them. I've also added C64 and Spectrum modes so that once I allow you to select it, you'll now be able to edit using those colours. Internally, its almost completely changed. before I had a simple C# List<byte[]> for my sprites, but now I've gone and made a nice Sprite class that contains everything about a sprite - the basic array that makes up the pixels, its width and height, and which editing system its using (Plus/4 and C64 in MCM or Hires, and Spectrum).

While this actually lets me have every sprite different in the animation sequence - even down to different systems(!), its actually a little impracticle. I suspect what you actually want is a global editing mode, so that you when select C64, Plus/4 or spectrum the whole project swaps to that. I think what you really want is to be able to load in sprites from one system, and convert it to another - as best it can. This will mean that C64_MCM->Spectrum conversion gets the HIRES version of the sprite, but it gives a starting point for editing; rather than having to do each one by hand.

However, I will allow each sprite on the same system to vary - because thats perfectly valid. So MCM/HIRES isn't a global state, but one for each sprite. This means you could create many C64 MCM sprites, and then create some HIRES overlays for them, all within the same project.

This is actually the thing that pisses me off most about editors. Theres so many dependencies. Change one radio button or drop down menu, and you have to do shit loads behind the scenes, and make sure every combination works!.... pain in the bum. However... I hope to be able to use the same basic classes in the character editing which means you should be able to edit 16x16 characters for the spectrum - or Plus/4. Internally, its stored as a simple array, but when you save it out, it'll convert it to the correct output format. Plus4 Sprites, chars, sprectrum sprites, C64 hardware sprites; well...thats the theory.