Stuff and not stuff

13/02/2011

meh..

Faffed about with image formats doing insane things then me doing insane things until I finally got Ste’s new revision of the decal graphics grabbed. Now I just need to sort out the positioning/colouring of them all in the 2 borders and fill in the data tables.


Spent most of today doing not Invaders :) I have however finally added the decal border sprites and the lives display..


15/02/2011

Nothing done yesterday, other things happening.. Back at it today :)

Bit the bullet (that’ll be a pun later..) and got mame to spit out a long enough mng (it’s own video format) to get all the stuff i need to check movements (long enough for the mothership to come on). Converting that lossless file to lossless pngs has resulted in 2721 files :/

11:00
Gone through a LOT of frames and picked out ones I need and now know all the movement, pauses, speeds, sizes of bullets and explosions (and hopefully have the enemy bullet explosion frame too).

15:00
Code done to replace the mothership and tank drawing. Tank needed to be pixel/frame and also didnt’ need to mask like the aliens does, same with the mothership (no mask that is). Code also done for enemy bullets, needs tidying up a bit as it was one of those start typing without thinking things, in fact the main sprite routine has some of that in that can be optimised with a table (at 3k code/sprites so far it’s not like there isn’t room).

--Stuff--

I’ve also been doing preliminary work for the next project over the past couple of days so Ste had something to do ;) Hopefully it’ll be the best 8 bit version (and certainly the best C64 version) of the game (not saying what yet, not till after Invaders is done).

23:00
Made a todo list to get at least the game part of Invaders finished which includes sound effects, adding explosions of all types (your tank, enemy invaders and mothership, bullet on bullet, bullets from both sides on nothing and both sides on the shields) graphics are now found and grabbed ready. The shield destruction needs a slightly different routine as it draws the explosion then masks it back out again (in the same shape) to create the hole.

Hopefully I’ll get most of this stuff done tomorrow :)

Lazy weekend

12/02/2011

10:00
Moving the code to the main loop today instead of all running off the IRQ. Not sure why it doesn’t work like that anyway...

Ok, that’s done. I also need to change the IRQ stuff to bypass the Kernal. It’s not doing anything I need and anything I might need later I’ve got code lying around for (keyboard entry etc) and not calling he kernal will save CPU (still nowhere near running out, but...)

That’s done too now.

Made sure it runs on NTSC. It’ll actually play closer to the arcade on NTSC because the movement is based on the framerate, which sounds obvious because that’s the same with everything but it looks even more so with Invaders because it only updates the 1 ship per frame (so you get the Mexican wave effect). It just “feels” more arcadey on NTSC with it being 60fps.


13:00
Started to think about sound effects. I can see I’m going to have to write an effects player. I started one for another project (Taipan) but stopped working on it when I thought someone else was going to do the fx for me, then they didn’t :/ I’d contemplated samples, it’s not like there’s no RAM free (whole game atm is around 3k)

21:00
Wow, lazy day today :) Catching up on TV (whole load of good stuff to watch), cooking, eating, cleaning, wasting time investigating other arcade games to see what I might do next (pretty sure I’ve decided, shhh, secret)..

Some behind the scenes coding done to help the collision detection decide what it’s hit and some code added to make sure things happen like the arcade, eg the shots between motherships stuff. Every new attack wave, if you hit the 1st mother ship with your 23rd shot you get max points, after that it’s every 15 shots till the end of that wave..

Also worked out which graphic it is your shots cut out of the shields. The enemy shots, I’m not sure about, I can see generally what it looks like but can’t find that graphic in the roms..

--zzzzzzz--

Prettier Invaders

11/02/2011

11:30
Late start today. Fixed a few little issues and now started working on the bullet code.

--Blah blah, various other things, cooking cleaning blah--

15:00
Bullet code is done. It’s amazing how complex something can become when you start writing it if you don’t think about it properly to begin with.. That’s why some places I’ve worked they don’t like my method of planning everything out before starting to code. It may take longer to get going but it’s way faster in the long run. I’ve not done it with Invaders though and now I’m wishing I had..

When the routine is called it takes the current X/Y pos of the bullet and clears it by ANDing the background with an inverse (EOR #$FF) of the bullet graphic. It then moves it up 1 in Y (4 pixels) and draws the new bullet. While it’s drawing it also does a quick AND with the bullet graphic and the background. The reason for this is to see if a bullet pixel and another pixel (anything else on screen) intersect. If so, collision!! So there’s pixel accurate collision detection.

Next up is to take that collision info and the X/Y and extrapolate from that just what’s been hit. Above a certain height it can ONLY be the mothership. Below that it’s going to generally be the enemy ships until really low down which will be the shield/base things but I can’t rely on that because the enemy ships might have dropped down to base level. The X/Y and row/column min and max will all come into play here.

--Why does my chicken from asda smell like feet?--

17:00
Just noticed after a play of the arcade version (on MAME) that the attack wave stops redrawing while an explosion sprite is being displayed. I can see I’ll end up doing another vid output from MAME with thoooousands of frames just so i can check how many frames that happens for..


20:00
Ok, now the enemy sprites don’t leave a copy of themselves when they move down a row... I’d totally forgotten about needing to deal with that and hadn’t put the “move down” code in till earlier because it’s easier to test everything else without the enemies advancing on me. Anyway, a quick think and a quick few lines of code to set a flag on row advance which the sprite routine then checks and clears the previous sprites position if the flag was set (ie when it’s moved down a line).

It’s starting to look like a game :)

22:00
Ste has done some “decal” graphics for the free space at the sides of the screen. I mentioned it to him yesterday but that I was worried unless I also put it in the borders it might look a bit odd with a + shaped screen (320 wide but bottom border sprites inside the 224 wide center area). It actually looks ok and really does look like a decal and I “should” be able to use free sprites to continue it into the border anyway :)

He's also persuaded me to add a 2 player co-op option a-la the Atari 2600 version. He's right, it was LOTS of fun, especially as you're both the same colour which causes endless hilarity as you try to shoot an alien with your friends ship! :) There will also be a normal 2 player mode.

More Invaders

10/02/2011

8:30
Stuff to do today; fix the mothership glitch, grab the enemy bullets, write bullet code, work out how the shields are destroyed (seems to cut a chunk out in the same shape every time). Other “game” related things.

Just noticed the bottom row of ships is going out of sync. Weird, not sure if it was doing that last night.. The initial pass draws them all on correctly lined up then the next pass forgets the bottom row and updates all the others, then it updates everything including the bottom but those guys are now 2 pixels behind...

--Housework--

11:00
Top border sprites have sorted and are in place. After closing the gaps in the font it’s ended up taking only 6 sprites so I might space it out a little again.

Bottom enemy row is fixed too. The code to get the global X position didn’t actually reset the current row X pos until the end of a row (ready for the next row) so after the 5 rows it’d change the global X then.... oops, needed to reset the row X there as well. :)

Fixed a bug in the “don’t draw him, he’s dead” part of the code. It was rather wrong ;)

16:00
Decided to go with hardware sprites for the bullets, I could do software and I may still do so but hardware will do it all and it still shows collisions between sprites and background pixels so there’ll be pixel perfect collisions which would also work with the before mentioned software AND method..

19:00
Changed my mind about bullets being hardware :) I’ve got some ideas for using the sprites for something else.

20:00

Got around to fixing the mothership glitch only to decide I'll probably have a separate routine for the mofo and your "tank" because they don't really need to mask so can just be blocked on. It's not like I'm running out of CPU but you never know in the long run...

Apart from that, slowwwww coding day, too much other stuff to do.

--Bed--

Invaders from Mars!

Dev Log 09/02/2011

14:00
Ok, so I decided to do something reaaaaaaly retro. Space Invaders. I’m going to have a go at recreating the (an) arcade version as closely as possible on the C64.

First up was working out how much and when everything moves. To do this I used the MAME video output then converted the resulting file into a series of PNGs. After that it was possible to single step through the series of frames (losless luckily) and see how the screen is updated.

What happens is only one enemy ship is drawn per frame. They move 2 pixels left/right and also switch between the two animation frames every update, the period of which depends on how many enemy ships are left to be drawn. ie 55 ships takes 55 frames, 10 ships, 10 frames, down to the single ship.. The dum dum dum dum sound is also updated at set times during the update so that speeds up too.

I’d thought about doing it all with character graphics and if I cheated a bit and made the screen wider I could space out the ships more so there was always a character gap between them. Not good enough imo. I’ve decided to do it “properly” on a bitmap. Characters would've still been possible but seems like as much hassle to sort it all out as it is to do it right.

The way I’m going to draw the ships is by having 4 sets of each ship (*3 ships) each offset 2 pixels and switching anim every frame like 1/2/1/2. They’re laid out in C64 bitmap (same as characters) format as 3 characters wide as this is needed for the lower largest ship (the top ones are only 8 pixels). I’m then creating a mask from those which is basically solid filled outside of the width of the graphic (not an inverse because that will leave the last frames graphic behind when it moves ) which masks the background before dumping the new data on so that neighbouring ships don’t get wiped out.

--PAUSE FOR FOODS--
16:00
After a bit of coding I’ve now got a method in place to draw the ships, properly masking, moving and animating. The “bases” or “shields” are also drawn into the bitmap. The plot sprite routine takes about 10 scanlines (so much for this being hard because the arcade is 2mhz lol). The top/bottom border is also turned off ready for the score/lives etc. This is necessary for arcade completeness because The arcade screen is 260 pixels high while the C64 is 200. unfortunately there’s not quiiiiiite enough sprites to fit the whole top line of text in :( I’ve got 192 pixels of sprite to play with and it needs 208, there’s not even the possibility to shift a sprite in X because the 2 characater spaces either side of HI-SCORE aren’t on the edges of new sprites.. It might be possible to squeeze the font up a bit as it seems it’s only 6 pixels wide but it’s drawn every 8 pixels. Doing it every 7 pixels instead still leaves a pixel gap and might make the difference but without working it out I don’t know (still depends on how many sprites each string takes)

18:00
Checking out bullets now. Your ships are 4 pixels and travel 4 pixels per frame. To draw these it’ll be a similar(ish) method to everything else, mask, draw only there will be an extra step, collision mask. This will logically AND the background data with the bullet, if there’s anything but 0 you’ve hit something, from there I can work out what you’ve hit by the X and Y positions of the bullet and the enemy ships. The enemy bullets will work similarly but they seem to only move (and animate) every 4 frames (so 3 frames of each position/frame).


19:00
Grabbed the “tank” graphic. It’s being done in the same way as the enemy ships so 4 offsets of 2 pixels each, no animation built in this time though.. Doing it like this means I can reuse the enemy drawing code to draw the tank too, so now he’s “type 4” 0 being nothing, 1-3 the 3 normal enemy types, no doubt 5 will be the mother ship and probably some explosions will get shoved into the list too..

--Interruption for 2hr phonecall and some life stuff--

21:30
Realised I’d broken something after adding in the colour ram rows for the red top, white middle and green bottom. I was calling the subroutine with the interrupts running and both routines used the same ZP locations... CLI now comes AFTER all setup :)

Need to snag the mothership now..... Done. Same format, 4 offsets. It probably doesn’t need that many as it moves fairly fast, I’ll have to check...

23:30
Enemy “sheet” now draws, moves, animates. Looks ok, could be faster, I think the arcade is 60fps.. oh well. The mothership is leaving a couple of pixels behind it, no doubt because it’s a full 16 pixels wide so as it moves character (8 pixels wide) it leaves the 2 pixels from the end of the previous character behind. This is because I wrote the code to use the fact the ships weren’t 16 wide to allow the edges of them to clear the previous frames data...


--I went to bed--

Tape mastering.

I'm currently coding a C64 tape mastering tool that runs on PC. Pretty sure there isn't currently any such thing as they all run natively on the C64 which seems kind of counter productive if you've got a full cross development thing going on.

Some folk think I'm crazy for doing this and whyyyyyyyyyy would you want to load games from tapes (or emulated tap files)?!? Well, it's all part of the nostalgia to me and seeing my games loading the way they would've back in the 80s (I actually wrote a tape turbo for ESP in 87 or so, think it was used on Lunari???) just seems right :)

Anyway, it creates tap files atm but will do WAV too for real mastering. The Kernal save routine is done which has been the hardest part to suss, then after reverse engineering some tap files to work out just wtf the Kernal was saving and finally getting a tap converted to a hex dump of bytes that were being saved I found a site that explained it all...... grr! waste of an afternoon!

So now it'll save a file you give it in Kernal "SLOW" mode then switches to my chosen pulse speeds for the turbo bit. The loader is relatively easy. I say that, it's not coded yet, but the accuracy of creating pulses in a tap rather than via the C64 means the loader doesn't have to worry too much, just trigger an interrupt when it gets a pulse, set a timer going and if the next interrupt from the pulse triggers before the timer runs out it's a 0, if not it's a 1....

There will be flags and things for turning bitmaps on and off, playing music, etc etc all the stuff you'd expect from a loader plus the possibility to have it run game code or something (like Invadeaload or whatever it was called).

"Interrupts" for the main loop, I've seen some people make the terrible mistake of waiting on $D012 (the raster counter) and it sometimes missing the check.. Easiest thing to do is turn off raster interrupts but still set $D012 to where you want to trigger then just check $D019 to see if the interrupt "would" have happened. It'll stay pending till you clear it so no chance of missing it :)

When it's done and I've made a tap of Taipan I'll post a vid :)


Pete

Almost..

...forgot about this place. That tends to happen with blogs I start. I get more into what I'm coding and start to forget that I was posting about it too until I finally totally forget about having a blog..

The last mentioned port of Taipan took a turn for the worse (lethargy, over complicated code and some idiots who think they're right about everything nearly killed it) then a turn for the better when I decided to just do a line by line BASIC port last week. It's now had a week and half of "testing" (hmm, less said the better) and is about ready for release, just some sound effects to drop in.

Lots of other stuff going on. I may or may not post about them on here. Nobody reads it anyway :)