Monday, October 30, 2006

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.......

Sunday, October 29, 2006

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.

Wednesday, October 25, 2006

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.

Tuesday, October 24, 2006

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.

Monday, October 23, 2006

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.

Sunday, October 22, 2006

XeO3: The games afoot...

Luca and I have been hammering out the how the actual weapon system is going to work and I have to say its one of the few times where internet development really sucks. Trying to chat about something like this and get the details right so that we both agree is hard enough, but having to type every line into Windows Messenger is just a nightmare. If we were in the same room, it could be done in about 5-10 min since we could discuss it easily, draw diagrams on a bits of paper, and basically get to sorted quickly. But over the net, it took us the better part of an hour to go through it and make sure we both understood what the hell we were talking about. Oh well, its all sorted now - I'll let Luca go through it all though.

I've also been trying to figure out how to erase files from a floppy using the kernal. Little bit of a pain, since theres hardly anything telling you how to execute disk commands from assembler. I know you can do this in DOS...

  open 15,8,15,"S0:FILE"
close 15

But, I wasn't sure how to actually do it in assembler. I finally found some code after a bit of hunting around and this is now what I do...

    lda  #15                   ; file handle
ldx #8 ; device
tay ; command channel
jsr SETLFS ; set channel details
lda #8 ; length of filename ("S0:SCORE")
ldx #LO(HISCORENAME) ; pointer to score
ldy #HI(HISCORENAME)
jsr SETNAM ; Set file name
jsr OPEN ; perform OPEN command
lda #15
jsr CLOSE ; and close the channel

And thats all there is to it. When we have the turbo installed we'll have to issue a save with overwrite and get the turbo (on the disk drive side) to erase the file first. This is all to avoid the SAVE "@0:filename" bug. However, after all this is done, it'll mean we can save hiscores to disk for a proper record - which is cool.

Saturday, October 21, 2006

XeO3: Not as stupid as I look!

After yesterdays head-banging moment, I sorted out exactly what I'd need to do in order to get a proper double buffered star field. Then after groaning inwardly at the effort involved just to get a bloody star field running, I slapped myself hard across the face with a virtual fish - and got on with it. I now needed another two 100 byte tables (CPU built, so theres stack of memory for that), 4 star routines in total (2 to draw, 2 to clear - ouch!), but could reduce the size of my logo drawing code to almost nothing - much better.

So...What does the new Star code do? Well, picking up from yesterday... It now copies the current index into a SAVE_STAR table (2 of these, 1 fro each frame), checks to see if it can draw a star at the desired location, and then draws the correct character, and colours it with a random colour (multicoloured stars are much nicer than depth queued gray ones) at the same time making sure its in HIRES mode (top half of the screen is in MCM mode). This is fine... Now comes the really annoying part. To wipe them, I read from one of the SAVE_STAR tables, check to see if a star is actually there, and if so wipe it. I dont need to wipe the colour, as theres nothing else going to go there.

Now for 360 stars, this is horrible, much slower than clearing screen and blasting it on. However.... for the original 100 stars, its much faster. So...strike a little bit of a middle ground (240 stars or less - undecided just yet), and the fact I no longer have to continually draw the text and the logo, means I win out over all. So the original idea wasn't that dumb after all, and while I may actually be as stupid as I look, at least this time I get to keep my head firmly attached to my shoulders - but theres always tomorrow.

Friday, October 20, 2006

XeO3: Stupidity abounds....

I often wonder why programmers are never given protective head gear, since every now and then we do something so stupid then you either bang you head off a desk, or get someone to hit you with a hammer. I've been thinking about rewriting the front end star field so that it goes in between the stuff thats already there. This means I wouldn't have to clear the screen and then redraw it every frame! Quite a saving.

So I set about doing this thinking all I need to do is double buffer the star locations and then clear anything thats in the "clear" list. Sounds easy doesn't it. The problem being, that my star field is actually in 4 places at once. A star can have a location of 0 to 255, which I then store in $0c00,$0d00,$0e00 and $0f00. This means I get 4 stars for the price of 1, and when a star leaves one zone (goes from 0 to $ff) it smoothly enters the next and you never know.

The problem being, to clear the stars, I can't just store a location, I need to check to see if a star is actually there because it might be visible in one bank, but hidden in another. When you add this time to the increased time taken to actually plot the stars, it'll probably come out longer than the current method! Idiot. I'll have to sit down and think about it a bit more. Theres always the chance that because I dont redraw the logo or the text, that this doesn't matter, but I'd like to be able to have lots of time to spare so I can scroll stuff onto and off of the screen - and Im not convinced I can do that knowing how long it'll take.

Its a pitty as well, I increased the number of offsets from 24 to 90 (giving me 360 stars in total) thinking that since I'd saved stacks of time, I could now bump up the number - WRONG!. Idiot!!.... Wheres that baseball bat when you need it.....

BTW - this star routine was pinched from Delta on the C64, I spent a while hunting it down years coz I thought it was fab.

Thursday, October 19, 2006

XeO3: Death of a Parallel port....

Well, looks like I've fried part of my parallel port; damn. Pin 11 (busy line) doesn't appear to work anymore. This is probably why I wasn't able to get the C64 to set it - or at least the PC to notice. The plus/4 downloader is now also dead because it also uses that bit; damn. I know the machine and cable are okay as I've currently got the Plus4 plugged into my server and it can upload from there; damn. Although....its VERY odd that only 1 pin has died - I'd have expected the whole thing to go, but since the C64 still happily displays values getting sent TO it, I know its still a little bit alive!

Oh well, this means I'll have to go buy a plug in card - but if I get a dual port, then I can have the C64 and Plus4 both plugged in at once. At least some good has some out of it. I remember reading about doing hardware stuff. You dont just pay with your time while you debug it, you pay with your wallet. Oh so true. Still, it also means my C64 cable is now ready to go....all it needs is a downloader! It should be around twice the speed of the plus4 one which can currently download XeO3 in around 7.5 seconds. 3 seconds, 7 seconds... doesn't really matter I guess - fast is fast.

If I get around to doing my remote debugger, it might be nice to have a proper bidirectional port - even if it is a nibble. When I was doing a playstation debugger with the PSone action replay's I was using a bidirectional serial port on that and it was great, it made its communications very robust. I'm still determained to do a full, proper remote debugger for both the C64 and the Plus4. Theres something very satisfying about debugging on actual hardware. Of course...emulators have some BIG advantages - like being able to debug interupts, being able to stop and view hardware registers at any point...well... pretty much everything! But its still not a real machine your controlling. Oh I dont know...it would just be cool.

XeO3: A work in progress...

I've added the new front end logo, made sure the game cycles properly and all the usual stuff. So I've decided to treat every one with a video of the current state of play. Its nothing fancy but shows the game running and lets you hear the sounds and music togther. The paths and animations aren't final, but it does show you it all working. Hope you can view it okay.

I've now got a grand total of 440 bytes left. This means the big squeze is on again! I also need to shuffle the memory map once more so that I can use large space at the top of memory to store the logo and character map. I hoped to keep this space, but it looks like its now about to get all used up. Bugger.

The only free or at least flexible space is now the sprite cache. This area can take a little bit of a pounding since if its not in the cache it'll just redo it. However, it does take more CPU time to re-cache something so I'm reluctant to do so.

Edit: The direct youtube link is: www.youtube.com/watch?v=W-DtKhk6qFw

Wednesday, October 18, 2006

XeO3: Front End..

So after a couple of days squeezing the front end down as much as I can, I've now spent today putting much of it back in - bugger. I got a logo from Luca to try and tart the front end up a bit, and it means I have to start double buffering the front end a bit. Since the logo itself takes up almost 1K, it also means I'll have to try and free up even more space. Its worth it though as it does help make the front end a bit nicer. I hope to finish this up tomorrow, and then I can take stock of the damage its done to the memory. At least if we do need to trim it, theres at the very worst we could just reduce its size.... It also means my nice and simple 3 layer starfield isn't nice and simple anymore. I now need to double buffer that as well so I dont need to redraw the logo all the time! Its never easy.....

I've had to redo my C64 parallel cable as I got the pins backwards! Doh. Idiot. All the diagrams I found to tell me the pins never actually got around to telling me that it was describing the back of the computer, and not the cable itself. I had assumed that it was descibing the cable, since thats what everyone wants to know! But no... wrong again. Anyway, I've built my own cable rather than the PC64 one, and once I manage to get the PA2 line working, I'll be able to download a whole byte at a time, rather than a nibble which all the other cables seem to do. Not sure why... it might be to do with old parallel ports not being bi-directional or something, but I don't really know. If I can't get the PA2 line working, then I'll have to drop down to a nibble and use some of the datalines as handshaking - which I'd rather not do; although if Im desprate, I could do 7 bit.... but thats horrible!

Edit: Oh! And after finding the old instructions to my SID card, I've discovered it has an adjustable volume! FAB!! I can now balance out the TED and SID music without having to turn TED music down to virtually nothing! Hurrah!!

Tuesday, October 17, 2006

XeO3: C64 Transfter

I've spent the evening building a PC64 transfer cable for the C64, and after looking around for the simple transfer programs, found none. I was pointed at a couple but every one I look at needs to be compiled, typed in.... something. Sod that - I'll port my Plus4 one. All it needs is the GetAByte function. Its tiny (around 256 bytes), and the PC command line is very simple - download and/or run. Easy.

I've also started looking at the editor again, but this time I'm making it a bit more flexable to help with the spectrum version. Before I was just storing MCM pixels as a single colour byte and assuming it was MCM. I also kept the sprite a fixed size since I was only interested in 16x16. But Russell can have any size on the spectrum - which would be nice - also quicker. When making larger sprites I have to join several 16x16's together. This sounds okay, but because a 16x16 is in fact a 24x24 due to the scroll region around each sprite, theres a lot of overlap and over drawing - which isn't good. The only problem with making a sprite system that could handle larger sprites is the cache would have to somehow autosize....It is possible, and for larger objects would be quicker - but it'd be a pain in the arse to write.

So I'll play with the C64<->PC transfer cable for the rest of the night, and then start back onto the editor tomorrow - saying my son gives me enough free time that is! It would be nice to get a debug stub onto the C64 as well, and finish my remote debugger. I got pretty far on the plus4 side, downloading, executing, stopping, stepping etc... not bad. I think I'd probably take all the code into C# now. Things like screen drawing and GUI's are just easier in that.

Monday, October 16, 2006

XeO3: The full cycle...

I'm on holiday at the moment, and I've been having fun playing with XeO3. I've spent the day cleaning up the code and trying to keep the memory usage down. I managed to strip around 150 bytes of code from the front end of XeO3 which is good, because I do hope to add more to it; a high score table along with a load/save to disk if possible.

I've been disapointing Luca with the latest restrictions. Like any game, as things start down the home straight, things get tight and the restrictions get tighter still. Hope I haven't upset him too much....

I've now completed the cycle. You can now start the game on the front end, play, die, and go back to the front end. "The circle is now complete, now I am the mast...." no hang on... thats not right. Anyway, it feels good to get it going in and out the frontend, and its starting to feel more like a game. I'm not sure what I'll do next... possibly back to the editor - Russell's gonna need it soon too.

XeO3: The Frontend


Now that I've saved a couple of K, I thought i'd better use it for a frontend before I use if for something else. I've already said that the front end will be pretty basic looking, theres just about enough memory to do one without having to load stuff in. Even with a turbo loader, I just dont really like having to load in the front end. You should be able to get there without having to load first. The game flow will be spoiled once you leave level 1 since if you die on level 2, you're going to have to load level 1 to start again - that can't be helped. But at least while you get used to the game, it's a pretty smooth and quick turn around.
So, here it is... basic, but functional. The text might change, but this is the basic look.... a logo would probably help I guess....

Sunday, October 15, 2006

XeO3: The memory hunt continues.

Just having a quick look over my memory map, correctly it here and there. I think what I really want to do is try and move all the variable sources like PathData and PreRotations together, these could vary if I really need the space. I’m not sure how much space the path data will take up, but traditionally I've set aside 4k and been struggling. However, these levels are quite a bit shorter than what I've had before so I make be able to shave as much as 1k off the paths. PreRotations is a total guess. I have no idea really how much I need in the cache. It all depends on alien speed, rotations, animation frames...lots. What I really need to do is add a flag to the cache for debugging to see just how busy it is, then I might be able to cut it down - there could be a lot of space to be gained in there.

Saturday, October 14, 2006

XeO3: The Big Sqeeze!

Well, there comes a time in every project where all you seem to do is try and get a few bytes of memory back. It's usually a slow, grueling process where you look through virtually every line of code for the odd byte that you can save, and hope its enough. XeO3 has hit this point. Since I started doing the loading, I thought it was about time I did a front end, but before I did that, I needed memory - a lot more memory. My current code budget had around 300 bytes left which isn't enough to make toast, never mind a front end. The data block still has around 1k left so the first thing to do is try and merge them. This means rearanging the whole of memory to try and pack free areas together. Never fun.

Certain areas must still sit on certain boundarys (character sets, screens etc.) but the rest is free game. I've managed to move the data down by moving the sprites and character sets up, and the character animation down. So the current memory map looks like this:-


$0800-$17ff 2 Screens
$1800-$27ff Music (4K)
$2800-$65ff Game Code and DATA (15872 bytes)
$6600-$67ff Character bitmap animations
$6800-$77ff Game charactermap (double buffered) (4K)
$7800-$97ff Sprite graphics (167 16x16's) (8K)
$9800-$9fff Barrel shifter for sprite caching system (MCM version)
$a000-$a2ff Panel Character Set (95 chars + space)
$a300-$aea7 Level Data-13 screens (7*13 - 3x3=91*13=$49F, 200 3x3 blocks=$708) ($ba7)
$aea8-$aeff Spare (88 bytes)
$af00-$bfff PATH data... (4k+256 bytes)
$c000-$efeb 141 pre-rotations... ($2feb - 141*87)
$f000-$f578 ScrollBuffer
$f5a2-$f5ef Sprite address table (built at runtime)
$f6f0-$fd00 Spare.... (1.5k)
$fd00-$ffff IO/Hardware/Vectors


I moved the fixed table of sprite addresses out of the data area and into a bit of free space right at the top of memory, but instead of a table, I build it with a little code at runtime. This keeps the EXE down and saves loading diddy little tables. I also stripped out the last bits of the save/replace sprite system (it's still there, just commented out) which freed up a little more space.

So all in all I now have 2,721 bytes left. Still not a lot... Now it gets tricky....

XeO3: Turbo.

I've been looking at turbo loaders today, since we hope to include at least a basic one. We simply don't have space to put one in the code, but since I don't use any RAM below $0800, if we find one or two that sit below there, then we should be able to use them. To this end I've been doing a basic game loader. It install's FLoad, and then loads the game - pretty simple stuff. Its a shame it switches off the screen, but thats a small price to pay I guess. Luca has said that its a little unreliable, but until I find one as small then I'm stuck with it. Since it installs itself prior to the game, any turbo loader should work - or none! So if you have problems, you should be able to skip the loader and load the game directly. Well, thats the plan. If anyone knows of any turbo loader that resides completely under $800, then please point me to it. I'd also like to have a few loaders for different drives if possible - but they must all follow the <$0800 rule.

I've also found my beloved C16 Rom disassembly book which went missing for a while, so I'm pleased to see its return. Its got a great hardware register map, and all the 6502 instructions with timings - all in a neat little book. I bought it back in 86 and it helped me code Freek Out, start Minus4 (all versions!) and now XeO3. I'm also in backup mode just now. Its been a while since I did a proper backup, so Im busy burning a few disks of all the important stuff - although I have copies on my server anyway.

Oh...and to top all this off, my 1581 drive has started whistling when it spins, and suddenly changed from device 8 to 10 for no reason I can figure. Not good.

XeO3: Alien Bullets

I've sped up the alien bullet's a little using the same trick I used for the software sprites. Whenever a bullet is over space (character $00) I don't bother masking, I just copy the character data in. If I had another 4 characters spare, I would just poke a character on screen, which would mean that 70% of the time it would be as fast as it used to be. But this way, its still about double the speed. Heres the code for the normal masking of a bullet.


BullGFX1:
lda (Temp+10),y ; Get data from character we're
and #$0f ; about to overwrite, and mask it.
ora #$a0 ; now OR in the bullet graphic
sta (Temp+12),y ; and store into its new bitmap
iny ; and move on....
lda (Temp+10),y
and #$0f
ora #$d0
sta (Temp+12),y
iny
lda (Temp+10),y
and #$0f
ora #$b0
sta (Temp+12),y
iny
lda (Temp+10),y
and #$0f
ora #$a0
sta (Temp+12),y
iny
lda (Temp+10),y ; Since the bullet is only 4 high, we can
sta (Temp+12),y ; just copy the remaining lines.
iny
lda (Temp+10),y
sta (Temp+12),y
iny
lda (Temp+10),y
sta (Temp+12),y
iny
lda (Temp+10),y
sta (Temp+12),y
jmp RetMaskBull


Now this is pretty quick anyway. I have 4 routines like that to deal with the bullet in each of its positions (since a bullet takes up a quarter of a character, it can be in 4 places in a character). But the masking and copying still takes time. So heres what happens when I detect the bullet is over a space character.


BullGFX1_2:
lda #$a0 ; Get graphic data
sta (Temp+12),y ; Store in bitmap
iny ; move to next line
lda #$d0
sta (Temp+12),y
iny
lda #$b0
sta (Temp+12),y
iny
lda #$a0
sta (Temp+12),y
iny
lda #0 ; Since we know we are over a space, we can
sta (Temp+12),y ; just force in zero's all the time.
iny
sta (Temp+12),y
iny
sta (Temp+12),y
iny
sta (Temp+12),y
jmp RetMaskBull


This function should be the case most of the time, and help balance out the game and make it a bit more even. The faster routine's only added around 170 bytes to the code, so its well worth doing. Overall, the new bullet's take around 450 bytes extra of code - quite a lot, but worth it for the results it gives. There is always the chance that all the Aliens are over the background and so are all the bullets and this would cause the game to slow down. However, since we script the baddie movement, and can place the turrets where we like, we can simply design it all so that this worst case never happens, and you never experiance it. The only thing we can't design around is the player movement, and firing of his own weapons - we just have to leave as much CPU time as possible for that.

Friday, October 13, 2006

XeO3: Turrets Attack!!


What a night! I've spent the remainder of the night trying out a solution to alien bullets. There are up to 8 alien bullets at any given time and all they do is pick one of four characters and poke it to the character map screen. Now while this is fast, it does mean that theres usualyl a big black box around them. However since we dropped the turret rubble we freed up 4 more characters so I though I'd try doing actual sprite bullets - well, masking them on at least. I expected them to look pretty, but ultimately be too slow to use. The result is shown in the circle opposite. Much nicer than the big black box.

I got a nice surprise, because while expensive, it wasn't unmanageable! Even with a whole heap flying around it only takes around 8-16 scanlines tops. This is great! What it means is that where we WANT lots of turrets, we'll simply cut down a little on the number of sprites to compensate; and where we want lots or sprite, cut down on the turrets. If we had both, it would probably be too hard anyway!

Great stuff!

XeO3: Background Collisions!


Well, I decided tonight was the night. I was going to do the background collision detection. I've been thinking about it for a while and I'm finally happy with the method I've chosen. The problem you see is that I dont have anywhere near the CPU time left to do pixel-perfect collision. This is in fact, like drawing another sprite; and even if I had the CPU time to do that, I'd still rather draw another sprite!

So we're stuck with detecting characters under the player. This is nice in that its very quick, but bad because its terribly crude! If you look at the image shown, number 1 shows the sprite sitting in its 3x3 character block. Now although it's only a 16x16 sprite (2x2 characters), the sprite has to scroll through these to move around - such is the lot of a software sprite. Now, looking at image 2, you can see that if the sprite has move say 4 pixels along, and 4 down we are now sitting right back smack in the middle of a 3x3. So the question becomes - what do you hit?

If we were to simple use ANY chars from the 3x3, then you could be a whole character away, and still get hit. This isn't good. But, if you use a 2x2, then by the time the sprite has scrolled 8 pixels along, and 8 down, then we again are hitting the block above this time, but we aren't actually anywhere near it! It would also mean we could go completely into the block below, and not get hit! Neither of these is desirable.

The solution? Well, looking at image 3 - we'll only deal with Y movement for now. if we move 3 pixels down, what we'll actually do is use the TOP 2x2 (as shown in image 4), then if we move past that and go 4 or more down, we'll switch and start using the lower characters (as shown in the final image). We then apply the same theory to the X coordinate - simple!

This actually works out great! It gives us a natural 4 pixel boundary around the ship where we can "edge" into a block without getting hit, and it keeps us from hitting things miles away! All in all, a pretty nice solution.

So, the big question! What does this mean for the game? Well, the game's a foot...and pretty smelly too! You now have to avoid being hit by aliens, the turrets now shoot at you - and hit! - and you now have to move around the scenery! All we really need to do now, is add all the baddies in Luca's been working on, and do the weapon systems!

Thursday, October 12, 2006

XeO3: Don't bug me now....

Spent a little time fixing a couple of minor bugs.

The first happens when sprites cross stars - they disapear as though the sprites wheren't masked at all. Odd, because I spent some time making sure the stars would show correctly behind the sprites. I remember this because of the optimisation I did to the sprites where if the character its about to overdraw is $00, it doesn't "mask" it in, it copies it. This was quite a saving and it does 9 of these checks per sprite. Now since the stars are basically characters, I made a choice and accepted the slow down invloved. It would have been quicker for have the stars vanish. Anyway, after shuffling code around trying to figure out what the hell was going on, I discovered that it was indeed a simple bug. The stars were being drawn to the wrong screen. They got drawn to the front buffer, and not the back one. The reason it didn't look terrible is because the stars check to see that theres nothing there before they draw themselves - this is simply so that they'll draw behind the scrolling back ground. Anyway, I changed it to the backbuffer and PING! all is well.

The second was obviously a simple one. once you shot a baddie, he sometimes drops a coin. If you pick up this coin, you get money. However, if you then shoot the space where the coind was, the bullet hit something. Obviously, the coin wasn't as dead as I thought. Turns out when adding the NOSHOOT flag, I'd tried to optimise the bullet collision, and it hadn't worked. It could have, if I'd set that flag on every dead baddie - but I dont want to, so the extra check for it actually being active has to go back in.

Oh well... couple of minor fixes today only... Still, its good to get these things found before any games players find them and complain!

Oh, and with Russell deciding to do a spectrum version, Retro Edit has become even more important...*sigh*... so much for my idea of a simple tool to do the job. This means I'll have to do hires editing, and a spectrum tile editor. Russell has a lot of restrictions for his tiles, so a custom editor is needed. At least the sprite editor will be simpler, but it does mean I've to do it properly and do MCM with bit patterns rather than just numbers - bah!

XeO3: Play the game....

An interesting topic has come up on Lemon64; since this isn't a normal game that is going out to the public but more a game for the scene, should we automatically add cheat modes ourselves, and then every couple of months release a new code for say better weapons, money, shields, infinite lives etc.

Or should we do a normal game and let it get hacked live every other game does?

Wednesday, October 11, 2006

XeO3: And then there were 3.....

It seems like there may be another member of the XeO3 family! Russell Kay (author of PC Lemmings) who I currently sit beside at work and harass like a badger with a sore bum, has been persuaded to have a play with some old spectrum stuff again. He has actually written a spectrum game years and years ago called Zone Trooper . It wasn't wonderful, but he was just doing a port so it's not his fault, the code however was fab, and he did love the old speccy. So now, he's back - at least for a while - to have a play at doing a spectrum version of XeO3. Great Stuff!! Could it be the first multi-platform games release on the +4, C64 and Spectrum in well over 10 years?? Time will tell....

So, after that great news....I've nothing much to report. I've had an evening off and sat down and watched a film. I have imported the Plus/4 colour map into the editor and tomorrow I hope to start making the editor more usable - rather than just an animation tool. Still I'm a little sort on energy, so I think its an early night.

So...nothing done and it's STILL been a great night for XeO3 news!!

Tuesday, October 10, 2006

XeO3: Retro Edit


After talking to Luca, I feel somewhat ashamed. He described the process he uses for creating sprites and it was so bad, I was virtually blushing. I am now even more amazed at the superb animations he's manahed to create despite the terrible tools he's using. So, I've vowed to correct this as fast as I can. To this end, I've changed the focus of the editor, it really will now become a Jack of all trades. I'll do +4 sprite editing first, then add C64 editing so that I can get those streachy sprites, and then onto character and tile map editing and so on.

However,m before anyof that, I need to get Luca some tools he not only could use, but really wants to use. The problem with any developer is that we get so used to using our old tools that we just don't want to change, so I need to give him a tool that feels like his old slippers, buthas a whole new set of features that empower him.

The first on the list was loading in the current sprites and then being able to play back certain animations in various modes. This is now done. He can now scroll through the whole set, pick start and end frames, then play them back forward, backwards and in "pingpong" mode (where it bounces back and forth). This should at least allow him easier viewing until I can actually get editing and saving in place.

In the future, I think a realtime linkup with an actual machine would be very cool, as the anim plays on the PC, it also plays on your Plus/4 or C64 on the Tv... also theres no reason why when you plot a pixel on the PC you dont SEE that on the actual machine as well. I wonder how many people would use that......

Monday, October 09, 2006

XeO3: Editor


I've managed to get the Plus/4 sprites up and visible which is fine - fairly easy in C#, so next I'll need to get them scaling. I'll probably change a couple of bits internally so that I can have either 12x21 or 8x16 MCM sprites, this will let me view/edit either C64 or Plus/4 objects.

I released a new version of my assembler yesterday as well, I don't think very many folk use it, but I find it's really handy - particually the macro support which lets you do quite a lot.Turns out though that I don't test it nearly enough! One of the chaps on Lemon64 has managed to crash it a couple of times with ease. I guess without testers this kind of this will happen. Anyway, if you want to play with it you can grab it from my minus4 site.

XeO3: Editors.

I'm taking a small break to play a bit more with my C# stuff. I've gotten the Plus/4 sprites loading in, so now all I need to do is scale them. But to see the results, I thought I'd extend the program I was doing into something a little more useful. Something that can load in sprites, characters and XeO3 style maps. I may even add editing to it at a later date.

Once I have the drawing working, I'll write a quite scale function that'll allow me to save out full size C64 sprites - although they'll be a bit rough around the edges. The biggest issue I have with XeO3 on the Plus/4, is that I can't view or edit sprites easily, Luca has to make little Plus/4 programs that show his work animating in a self contained PRG, which is far from ideal - so I hope this will help a bit more.

Level editing is also a concern as the current one was created by "FatMan", and he has long since vanished. So now we really need to be able to create one outselves, particually if we want others to make new levels or even games out of it.

I'll have to watchout when doing this program, as the temptation is to make an all singing all dancing app, which will take longer to write than the game itself. If I was doing an editor to "sell", I guess I would make everything variable and portable. But the idea is to keep the goal in mind, and not get too carried away with what should remain, a simple XeO3 editor.

Sunday, October 08, 2006

XeO3: C#

So, I thought it was about time I got the full benifit of the Multiplexor, so I'm about to do a small c# program (my latest language of choice) to convert into the proper format, and scale it up to the required size. Now the aspect will obviously change, and it will look a bit naff.... but it'll help "fill" the screen with sprites AND give me a basis for converting over Luca's art in the future.

On another note, I was speaking to TNT over at Lemon64 and we got into chatting about old programming diarys from ZZap days, anyway he reminded me about the Citadel one as well as the Morpheus one I've just read. I seem to remember this one being pretty cool to. He's currently doing a supped up version of Paradroid and I'm trying to persuade him to do a diary as well. I love reading techy stuff like this, and I'm sure others do to. These days games are such a closely guarded secret that you never get to hear the gritty details which is a shape. Also things are now so complicated that it can take weeks to do the smallest thing which doesn't make for good reading.

If you have an opinion on this, or if you like reading this kind of stuff, then let me know and perhaps I'll start to try and push more people to keep retro coding blogs.

Saturday, October 07, 2006

XeO3: A job well done....

Okay, I spent a little bit of time optimising the IRQ side of the multiplexor, and I can now get a sprite within 10-11 lines of the other set. Thats not bad, not bad at all (I seem to remember Blood Money being almost 20). This should be more than enough for a game. I more or less copied Dan's IRQ model for this (although I did a macro with some paramaters rather than having to maintain a whole chunk of code) and I've gotten it down to the barest minimum I can get away with. Heres the macro I used, which if you compare with Dan's, you'll find it quite close with only minor changes. If I had a couple of these, I could save an extra 4 per sprite - but thats excessive :)

;
; \0 = sprite number ( 1,2,3,4,5,6,7 )
; \1 = x+y offset ( 2,4,6,8,10,12,14 )
; \2 = NEXT sprite ( 2,3,4,5,6,7,1 )
; \3 = "b" for bcc or "j" for jcc
;
sub_amount equ 10 ; number of lines before a sprite needs to be setup


SetUpSprite macro
DoSprite\0:
cpy #\0 ; is this the Hardware sprite we're after?
bne NextHWSprite\0 ; not THIS sprite ->jump to next


SkipCPY\0:
lda XTable,x ; Store the sprites "X" coordinate in the
sta $d000+\1 ; VIC hardware sprite register


lda $d010 ; get all sprite significant bits
and #~(1<<\0) ; mask OFF this one
ora XSig,x ; already set for the correct bit!
sta $d010 ; so we OR in this sprite and store it!


lda YTable,x ; Get sprite Y coordinate
sta $d001+\1 ; store in VIC hardware register


lda XShape,x ; get the sprite graphic
sta HWShape1+\0 ; Since we have a double buffered screen,
sta HWShape2+\0 ; we store it in BOTH locations.


lda SprCol,x ; Get sprite colour
sta $d027+\0 ; store in VIC hardware


inx ; next sprite in list
ldy #\2 ; next hardware sprite


lda YTable,x ; Get sprite Y
jeq EndOfSpriteList2 ; 0? If so all finished
sbc $d012
cmp #4 ; do we HAVE enough time for another IRQ? (magic number)
\3cc SkipCPY\2 ; if not do it now!


;
; If we've lots of raster time until the next sprite
; but the sprite we will be copying over was already drawn
; by the VIC, then just copy it over NOW!
;
;sec ; Carry is ALREADY set
lda $d012 ; Get the current raster
sbc #22 ; -22 gets us the last "safe" sprite
sbc $d001+(\2*2) ; location. Now subtract the next sprite Y
\3cs SkipCPY\2 ; is > last sprite, then setup NOW!



;
; If its further down the screen, and the current sprite
; is still being drawn, then setup a new IRQ just above the
; sprite to handle it
;
;sec ; dont set carry, we'll offset this in the SBC
lda YTable,x ; if we can't copy now, then we set up
sbc #sub_amount-1 ; a new RASTER IRQ based on the next sprite (-1 for SEC)
sta $D012 ; and its Y coord.
jmp EndMultiIRQ ; and then this starts all over again!


NextHWSprite\0:
endm


I may not have mentioned this to the C64 guys, but once the game is finished, I plan on giving the source out, along with some documentaion that should allow others to either skin it quickly into another shooter, or to hack it into something completely different. I've always thought that the main problem with the scene was that good games take time, so no one can usually be bothered to make one - and when they do, they feel completely attached to the source and want to keep their master-peice. So I decieded from Day 1 of the Plus4 version that it was all going to get released. There no money in it, so why hold on to it when it could do so much good the scene.

That supercpu shoot-em-up is a good example - I wonder how much they actually made from it.... whats the point? I'm even trying to keep the comments up to date!! So don't say I'm not good to you all!!

Also, if theres anything I've touched on that anyone would liked explained, then just drop a comment letting me know, and I'll try to post something more about it.

XeO3: Multiplexor V1.0

Well, the first version is done and although it still needs seriously optimised, it's in and working. I ended up using a slight hybrid between the one from Blood Money, and Dan's one from Armalyte. I loved the way he gathers sprites into blocks IF the hardware sprite your going to overwrite next has finished rendering, then it doesn't bother with a new IRQ, it just does it anyway! Very cool. I'll probably unroll the multiplexor IRQ and that'll help me get sprites closer to other ones. It looks like I'll have to redo a few paths from the Plus4 as they are a little close for the multiplexor (since they're 16x16 and not 24x21); theres an advantage to having software sprites... Still, it'll probably make the games a little different so you can have fun playing them both!

I'll probably try and get a C64 teaser done soon now, but I still have a couple of bugs to fix on it - and the sprites are still all actually only 16x16, even though its displaying 24x21! I might just "scale" them for now, just so they fill more of the screen.

Luca has also said he's not really interested in doing any changes for the C64 version - he's a Plus/4 man through and through, so nearer the time I'll be on the look out for a dedicated C64 artist to add some spit and polish.

Friday, October 06, 2006

Xeo3: Vice...


Well, thanks to the comment made the other day, I've managed to add symbols to VICE. Since I use my own assembler, it was a quick 10 min job to get the symbol table exported in the VICE format. This does help when trying to track down odd bugs so its very much appricated - whoever it was (names on the comments would help!). Although not being able to have a memory window is prehistoric!!

I've got the basic flow of the Multiplexor in, so now I need to test the start of it, and then start generating interrupts. I can test the beginings since I copy in the first 7 sprites in the list to save having to do early interrupts. Its also a good way to start, it lets you see if things are progressing the way you expect.

Xeo3: Multiplexor...

I've been sitting here playing with a C64 multiplexor - boy has it been a long time since I did this! Actually, reading about Dan's one from Armalyte is what got me doing the port in the fist place. Armalyte was probably the best looking game to come out on the C64, so I had a read through his source and got back in the mood. Pretty interesting it was too, I'd never really used the stack much since I tended to stick to zero page lda/sta as it was one cycle quicker, but his multiplexor sort approach was novel. So, I did some tests on it and compared it to the one I had in Blood Money... His varaied quite a lot and either gained a few scanlines or lost a few depending on sprite order etc. Mine is pretty much static (unless theres < MAXSPRITES on screen, in which case it gains) so I've decided to stick with mine for now, particually since it does a proper sort, while Dan's is an approximation (which is usually good enough for a multiplexor).

So now that its all sorted, I'm just about to start on the actual fun stuff! Building new raster interrupts based on where a sprite needs to go. When I first used this in Blood Money (after hacking Armalyte to find out how he did it), I thought it was very cool indeed. In fact, it took me a while to actually believe thats what he was doing - very cool stuff. In Ballistix, I'd gone with a static array as documented by Braybrook in Morpheus, and since I HAD to control 32 sprites for that, it was probably a fairly wise course of action. But for Blood Money, I could use something more flexible, and after seeing Armalyte, I just had to know how he did it.

Anyway, I'm about to do it again. I'm not quite sure if I'll follow his IRQ routine either, as I hate maintaining large unrolled loops. Im sure at some point in the future I can unroll it if I need to.

OH! And I've just discovered a 4th C64 that I have, and its the older ones with the original SID chip in it, so I can at last listen to all the old classics on the machine itself! Ahh...bliss.

Thursday, October 05, 2006

Xeo3: Sprite time...

Luca's given me a new batch of sprites to bundle together so while I've been doing that, I've also been updating Luca's scripting build so that he gets all the latest features. While doing so I've fixed the parent+child system. This allows small sprites to be joined and act as a single BIG sprite. Luca's been playing with a large mid level baddie, but it wasn't working right. Turns out when I had rewriten the killsprite routine I had inadvertantly broken the link system. I'm not terribly happy with the fix however, as it means I have to loop though all the sprites every time one is killed. Its not the end of the world, but I dont really have any spare FLAG bits to enable me to fix it.
I've only 2 left, and I think I need these for other features. Luca wants to be able to orbit baddies around parents, and I'll need a flag for that, I also need a flag for something else...but that escapes me just now. I may well have to admit defeat and add another FLAG byte, but I really dont want to do that.

I got my Retro Replay today!! Very cool! I think I'll probably get the RRNet and SilverSurfer add on as well as it'll let me squirt stuff down rather than having to copy it to the MMC card all the time. Using a RetroReplay and the MMC64 I can now mount a D64 image and read it like a normal disk, which is very funky - its now a pitty that so many have "custom" loaders that dont work with it! At least Blood Money and Ballistix seem to, well... they manage to load, but blood money then crashes when you start playing, no idea why - seems to have all the graphics and code it needs.

Xeo3: Playing shuffleboard with the C64....

I've been shuffling around the C64 code and data for a couple of reasons really. 1st It means I can use the music as is without having it relocate it, and second buy changing the VIC bank to $4000-$7fff it gives me a few extra sprites. It got me going for a while though until I discovered a bug in my IRQ code which was always setting a bit in the screen address, this meant I could only have screens at $0400 and $0c00 and it took me a while to track down exactly why this was. Vice came to the rescue with a reasonable debugger, although I really wish they would add some basic symbol table support. Being able to put a breakpoint on a label address is a godsend! Anyway, bug fixed, code and data all moved around... and I now have 160 sprite slots, and a few more above the panel.

I also workout out that if I changed the format of the +4 sprite a little, I could squeze in 199 sprites, quite a bit up on the 167 we already have! It depends if I get around it it... its not a huge change as it just involves making a 300 byte xply table and changing the cache pointers from pointers to indexes (theres only 147). But that would save 8 bytes per sprite * 167 sprites... a lot! I hope I get a chance to make the change, although Luca might not thank me, he already has a lot of space to fill!

Wednesday, October 04, 2006

XeO3: C64 sprites....


I'm having a little coding break at the moment. I thought I'd have a quick play and see how much bigger the sprites feel when theres a proper C64 sized one in the level. It's not a lot bigger really, but I suspect a few of these larger ones and it'll start feeling a little cramped. I was pleased as punch when I discovered an old copy of Tony Crowthers 3in1 graphics editor that I used to use, it does sprites, characters, backgrounds and has a scratch page for playing with ideas.... great little C64 editor. I've not really seen it on the NET anywhere so I really should upload it somewhere for folk to use, coz it really is fab.

Tuesday, October 03, 2006

XeO3: C64....


Not a bad evenings work! I've managed to get the sprites converted over as well! Although at somepoint I guess I'd have to get them redrawn since they are only 16x16 but still, it looks great with the added colour! I'll probably release a C64 teaser in the near future as well, lets see if any C64 guys get interested :)

XeO3: Surprise Surprise!!!


Well, in only 2 days, I've done the main part of the port to the C64! Although there are no sprite graphics yet, and no multiplexor, its running through the game and its paths. Alien Bullets are off a bit for some reason, but that should be an easy one, unfortunately because the Plus/4 one has been designed to run in 2 frames, the C64 one runs a bit quick. I can slow it down to 2 frames as well, but I'm not sure I want to yet. Past experiance says that when you're PLAYING the game, you dont notice, and 2 frames gives you a lot of free time to do cool things. Because of Hardware Sprites, I can however move the players ship every frame, which will help make it seem like's going quicker than it is... I could also scroll the screen by 1 pixel a frame as well, but I dont think thats gonna work becasue sprites that are supposed to be attached to the background will judder - I think.

I've just been thinking, if I move the VIC bank to $4000-$7fff, then I'll be able to use more or less the same memory map, and use Luca's SID music as is (since it sits at $1800 - currently right in the middle of my sprites!) It would be nice to use his music, as it helps round out a demo.....

Monday, October 02, 2006

XeO3: C64

I'm having fun with the C64 just now while Luca gathers together some sprites for me to use, but I've hit my first snag.... The MCM on the plus4 uses differnt bits than the C64! Damn. So, I've done a bit flipper to swap bits $01 and $10. This lets the colour RAM on the C64 do the bright colour (since in MCM on the C64 you only have a choice of 8), and the 2 full colour registers then make up the rest... This will work fine for the game graphics, but......... The panel has some HiRes graphics in it...Damn, damn.....

So looks like I'll have to do a character index and tell it the ones I WANT to swap...bugger. However, once thats done it should just be a matter of importing Plus4 graphics and using them directly! Initally I'll do a port routine for the Plus4 sprites as well, then I'll get them resized. The C64 sprites are 24x21 (or 12x21 in MCM), while the Plus4 ones are 16x16 so there quite a bit of extra space there! The reason for the odd sizes is simpky that it lets the C64 have a sprite every 64 bytes, making 256 in a VIC bank.

I think I can get the whole thing up and running (without sprites) pretty quickly, then I'll need to get a multiplexor going... and then that "should" be it! :)

(in theory....) Imagine doing a "dual" retro release!! How cool is that!!! Now... if only I could persuade Russell (Kay - Lemmings PC programmer) to write the spectrum one...Mmmmm.... That WOULD be a complete rewrite though...

Sunday, October 01, 2006

XeO3: bits and bobs...

Sound is interesting.... you can work away trying to get perfect pitch and volume and then when its working just the way you want, you can sometimes make it really course and never notice the difference. I put keys for volume control into the game, and all the work spent on the ADSR (a whole day of it...) is reduced somewhat to a whimper depending on the volume. Now, when playing back on the actual machine TED sounds are far FAR louder than Solder's SID chip addon, so I need to set a volume of around 2 or 3. This means all my ADSR values of 7 down to 0 are now just 2 or 3 down to 0. Not a lot... But they do still count, because if you dont use ADSR at all, it sounds terrible... weird.

I have to confess, I've been playing with some C64 code tonight.... I found the source to the Armalyte Multiplexor on (Lemon64), and thought I'd go through it... and perhaps get it up and running. However, this has lead me to look back at my Blood Money multiplexor (which itself was based on me hacking Armalyte - although I wrote it myself once I had the gernal idea), and its not bad either... theirs is a bit larger with the loops unrolled a lot, but mine wasn't too bad at all. Anyway, I think with very minimal work (and a working multiplexor) I can get XeO3 up and running pretty quickly on the C64. I'm kinda half waiting on Luca to do some more sprites now anyway, so I've an excuse to play a little... well... thats my reason and I'm sticking to it! It will be a little harder to get .PRG's onto the C64, although my MMC64 will help a bit, but a download cable would be much better.....

So, after looking through the source, I've started to macro it a bit more to make it easier to follow - for the sort at least, I may well write my own multiplexor bit again... but I suspect I'll try and get something running first. The great thing about doing a C64->Plus4 or a Plus4>C64 conversion is that being 6502, it'll just run - I won't have to rewite it all the way I used to do when doing a port. This means I get to do all the fun stuff and dont have to do ANY of the boring stuff again!!! Great!!!

XeO3: Sounds....V2

Weel, I've gotten 2 channels...almost - but good enough I think. Basically, I now have 2 full effects playing and both use ADSR envelopes, however channel 1 (Square wave only channel) will now check to see if its ADSR value is bigger than channel 2's sound. This means that either channel can get louder if sounds overlap, but you don't really notice that much, and having 2 channels is much nicer.

I'm also starting to feel the pinch, and memory is becoming tight. I've had to do my first code shuffle since code space was over running, so I've moved lots of local function variables into the games DATA area, which I've now expanded by 2k to make room for it. This isn't something thats gonna improve, it'll just get worse. It also leads me to wonder what the hell Im gonna do for a front end! Theres just NO space left for one, let alone character sets and all. I'm not a big fan of "loading" front ends since this is really bad news when you first start playing a game and get killed a lot, long load times don't make for a fun game.....

Speaking of long load times... I'm looking at the memory map and ralise that I'll need to load 3 seprate files per level; it would be much nicer if I could make it one big one, load times would drop quite a bit. I'll have to see if its possible to shuffle things around to be able to do that.