Monday, October 30, 2006
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!
I wonder what the +4 ratio is.......
Sunday, October 29, 2006
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
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
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
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
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...
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
jsr SETNAM ; Set file name
jsr OPEN ; perform OPEN command
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
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
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
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.
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
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
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
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.
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
Saturday, October 14, 2006
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)
$f5a2-$f5ef Sprite address table (built at runtime)
$f6f0-$fd00 Spare.... (1.5k)
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....
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.
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 ; Since the bullet is only 4 high, we can
sta (Temp+12),y ; just copy the remaining lines.
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.
lda #$a0 ; Get graphic data
sta (Temp+12),y ; Store in bitmap
iny ; move to next line
lda #0 ; Since we know we are over a space, we can
sta (Temp+12),y ; just force in zero's all the time.
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
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!
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
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!
Or should we do a normal game and let it get hacked live every other game does?
Wednesday, October 11, 2006
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
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
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.
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
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
; \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
cpy #\0 ; is this the Hardware sprite we're after?
bne NextHWSprite\0 ; not THIS sprite ->jump to next
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
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!
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.
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
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.
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
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.
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
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
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 :)
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
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
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!!!
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.