By Andrew Braybrook
Monday 15th June
ST had been trying to cure our data transmission problems last week. Itís now quite rare that we successfully download
a file for testing, and theyíre getting quite large so the chances of getting an error has increased. By keying
in a quick analysing routine we discovered that sometimes the Opus doesnít switch its data-ready signal off very
cleanly, so much so that it causes a second trigger. This only occurs briefly, but long enough to fool the C64
that another byte of data is ready. Therefore our receiving program reads in the supposed new data, and when it
comes to check-for-errors time it discovers that someone has madea boo-boo. By checking the CIA latch a second
time after the data is accepted, and ignoring it we have alleviated these Ďghostí images. No errors have occurred
in the ten or so downloads since.
Iíve fixed the bug that allowed the ship to pass through charge orbitals in two directions, and Iím reasonably
happy that everything is working correctly. Iíve put in an extra piece of information at the beginning of each
phrase which shows the current level and what Iíll call the current Ďtimesliceí. This is an indication of real
time taken playing games, which is used to to derive the effectiveness of your weapons against the enemy. A weapon
built in timeslice ten will be fairly ineffective by timeslice 20. Each timeslice will represent about two minutes
Tuesday 16th June
Half day today. Got to grips with the compacted sprites and organised the ones that Iíd drawn already. I then noticed
that that many of the images were symmetrical top to bottom. This led me to try further compaction by only keeping
the top half, and then reflecting the required images prior to use. The routine turned out to be quite small, and
certainly simpler than reflecting left to right, which I had to do in Paradroid. Unfortunately the decompaction
system went slightly wrong when the Ďit was written so long ago itís bound to workí sprite header routine failed
miserably! It was supposed to nip through the compacted sprites and note where each one starts, which saves me
either reading through them all every time I want one header, or holding all the headers in a table all the time.
However, it managed to miscount so it got out of step with the actual images, so by the time the individual sprite
decompacter got there it was picking up the wrong data completely.
Wednesday 17th June
Iíve never written one before but it suddenly dawned on me that an automatic sprite animation system would be a
good idea. A lot of space has been wasted in previous programs by objects each having their own bit of animation
code, like Ďevery fourth cycle add one to the sprite frame and if itís bigger than ĎXí then subtract seven from
it.í This can be done on a similar basis to the automatic sprite colour system, which relies on any one sprite
being used for one purpose only. This may require some duplicate sprites, but since theyíre all cornpacted I donít
I had a discussion at the CBM show on Sunday about the merits or otherwise of high-ish level languages - mainly
C. Personally I think itís a pig of a language, as it is totally wrapped up in its own syntax structures. It has
two ways of specifying equals, either Ď=Ď or Ď= =Ď depending on whether itís in the equivalent of a BASIC LET or
IF. Every other language Iíve come across manages with only one symbol, they know which one youíre talking about
by the context of the line. C also makes you put curly brackets round multiple statements within an IF-ELSE structure,
something which COBOL achieves by use of nothing more than a carefully placed full stop.
Thursday 18th June
The sprite animation system is playing up. Objects disappear, flash on and off and go through the wrong sequences
- anything to get out of working properly. I checked the object handlers and the animation routine, found a fewerrors
but all to no avail. It took until 4:30 to find the cock-up. It was the animation instructions that were wrong.
Apparently eight plus three is not 83 at all! This causes sprite sequences to jump about wildly, sometimes picking
Ďsuicide framesí, causing
objects to automatically delete themselves on the final frame of explosions etc. I thought it would be tidier if
objects cleared themselves away.
Friday 19th June
Spent much of the day on the sprite editor. I want a design for the charge supervisors, which will travel around
looking for trouble - that is, as soon as an orbital is attacked they will head towards it. However all I managed
to design were a few more roamers.
I havenít had any transmission problems at all this week so it looks as if we have correctly diagnosed the fault
as being cheap and untidy electronics at the PC end.
Got a rough draft of the artwork from Hewsonís today. Theyíve been looking at my Amiga artwork, so their artwork
is quite closely related to what Iím intending for the game. Iím reasonably impressed by the layout, but they didnít
use my logo, just some old Paradroid-style lettering. They said my logo looked like a row of coffins in space.
Monday 22nd June
Tidied up a number of loose ends and fixed all known bugs. I had to make the Universe slightly bigger as some particles
were intent on leaving it. I also reduced the size of the fastest polar speeds, the fastest bullets were just flashes
across the screen, not very practical for collision detection.
Went on a programmerís fitness course at the weekend,which involved transferring graphics from the C64 (downstairs)
to the Amiga (upstairs) for enlargement and enhancement. This involved memorising graphics on the C64, racing upstairs,
and redrawing them on the Amiga - I bet itís still faster than RS-232. the net result is that Iíve drawn the 16
system units in 32 glorious colours at double the size for inclusion in an accompanying booklet.
Tuesday 23rd June
Toyed with the smart bomb weapon to get it to work. Itíll be a medium-term weapon rather than a once-off blast.
Itíll start off at maximum strength and decay to zero after firing, so itíll affect meanies arriving on the screen.
Also it wonít necessarily kill meanies outright, especially if the weapon is getting old.
Also put in the collision detection for my own bullets. Having a maximum of eight, and there
being eight bits in a byte makes things quite simple. The bullets are small but are moving quite fast, up to eight
pixels per move, so character accuracy is all that is required. Each meanie will check the character position under
its centre for the presence of a bullet. Iím not using sprite to sprite hardware collision detection for a number
of reasons, mainly that it isnít all that helpful in multiple collisions knowing that sprites one, two, six and
seven have collided somewhere. Which one has collided with which, or have they all met in the middle? Many collisions
are irrelevant and neednít be checked.
I also worked out all the data forthe weapons development table, all 57 weapons. Each has its own firing type,
bullet fired, reload time, construction time, graphic number, and cost to build. Any volunteers to check that theyíre
all present and correct?
Wednesday 24th June
Been doing some random spot checks on the weapons. Iíd managed to ruin the sequential fire system. It fired one
bullet, waited for ages and then released the next seven in quick succession. Apparently it had waited for the
gun to reload before firing the remaining bullets.
Iíve started putting in all the bits that nick the energy, including collisions with orbitals,
and firing the guns. Yes, the guns take energy to fire, lifeís like that. They donít take very much though, without
any energy replenishing systems the ship is still good for some 1500 bullets. This will become virtually unlimited
once a solar cell or other device has been installed.
Iíve also improved the smart bomb system. It kept firing by accident as I left the unit, which isnít damaging with
normal guns, but the smart bomb can drain up to a fifth of the total energy so something must be done. It requires
a delay beforeit fires, so l decided to use this delay properly, not just a delay for delayís sake. It counts a
timer upwards and will fire when it reaches the bombís preset value. However, as it counts up, it checks itself
against the current energy level. On firing it will use up the amount of energy equal to the timer, so if there
is insufficient energy available during build-up it will abort firing. The later smart bombs will build up quicker
and thus useless energy - theyíll reload quicker too. Iíll use sonics to show this build-up and itíll be possible
to abort firing at any time.
Thursday 25th June
Some of the charge orbitals were appearing a bit late on the screen. It seems that updating one every 32 cycles
wasnít quite enough so líve doubled them up so that two are updated every
16 cycles. This seems to be running everything more smoothly, except that now theyíre all decaying twice as fast,
This means that I have less time to find them. This wonít be
the case in the finished game as the charger rejuenator will be visiting all the orbitals in turn, but heís not
coded up yet. Itís quite difficult to find the orbitals at the moment, so I rigged up one of the systems to glow
when thereís one nearby. This should be useful on later levels.
Iíve enhanced the shieldís generators so they show their current status with colour, and you can also buy another
systern which shows the current status of the whole shipís shields. I have three remaining systems that donít have
a current purpose.
For the first time I can now score points to earn money to buy weapons and systems. Iíve currently got a cheat
version that gives me buckets of money anyway and allows me to build any of the weapons instantly. The systems
donít decay with time, as itís really the meanieís growing immunity to the weapons which causes the weapons to
fail, but the systems can be blown up if the shields collapse.
Friday 26th June
Put in a new system device - a direction to nucleus indicator. This should help navigation tremendously. Begin
an eight directional indicator, I thought Iíd borrow a calculation routine from Paradroid that decides which laser
bolt frames to use. One problem though - ST and I realised that it didnít work... well not quite anyway. We also
realised that it only has to calculate four directions, it has noticed to differentiate between up and down as
the bolts are reversible. We therefore decided to work it all out from first principles.
At first our marvellous indicator was incapable of showing diagonals. We had used the line equations the wrong
way round when working out whether a point is above or below 2X = Y and 2Y = X. The direction finder could turn
out to be useful, so Iíve made it a separate routine from the indicator so that I can use it later for other functions.
For better between-game continuity I think Iíll rig it such that upon demise the playerís funds remain for the
next game. This will allow a quicker building up of a new ship.
Monday 29th June
Put in some close manoeuvring to stop the ship if itís moving very slowly. This helps with close positioning of
the ship and also lessens the times when stars are moving very slowly. It took me a while so suss out that this
was not working in the engines section, as it has a quite get-out clause normally to check for dematerialisation.
I put in a toplimit for the amount of money that can be carried forward to the next game. I can just see some idiots
playing level one and then quitting for half the night to build up a mega-fortune for one game. Tough luck, cheats!
Over the weekend I spotted a double star flitting between two places on the screen at high speed. Iíve been running
the game for a while hoping to reproduce this error so that I can investigate, but will it happen again? No chance!
Actually got recognised in Tescoís, so to ensure that l donít get run over by a shopping trolley next time, hi
to Rob and John!
Tuesday 30th June
Put down on paper all the ideas for meanie movement and initiation. This is the last big push to get the game in
a playable state, the rest will just be tuning up and adding some frills. Most meanies will be generated as a result
of altering the change of an orbital. I shall start them off on preset launch patterns and then switch them over
to manual control where I hope they will behave with a bit of character. I want a more varied spread of speeds
through the levels, and meanies will be able to generate bullets or other meanies.
Bought Slapfight last Saturday. Great game in the arcades so I had high hopes of a good game. Itís been converted
very well, good playability and visuals, well done, but what about all the program refinements? No pause mode,
no quit game, and to cap it all it uses sprites in the top border for the score. Well l canít see the score on
my TV set, itís off the top. Black mark for that one, why is it up so high?
Wednesday 1st July
First day of overtime, I was scheduled to complete Morpheus yesterday, but Iíve missed a number of days work for
one reason oranotherand I really want this game to be something special - so itíll come out when itís ready. This
is an artistic expression, not something off a production line.
Started coding the meanie initiator and control routines. I didnít feel like coding a lot of routines up again
slightly differently, so I decided to adapt the ones that already run the bullets and the remote. This saves code
and simplifies things (famous last words).
Sure enough I ended up with no bullets and an invisible remote. Havenít the faintest idea why. The objects are
getting initiated in the correct places, they just die immediately. Last time anything did that it was the animatorís
fault, but not this time.
Thursday 2nd July
Found the no-bullets bug last night by staring at the listing. Apparently someone had put on in the wrong order.
Wait until I find out who that was. The disappearing remote took a while longer, but was another typing error.
Iíd taken the Y co-ordinate of the remoteís position, added the Y movement and then stuffed the result in the X
co-ordinate by mistake. When youíre convinced that a piece of code at working you just read what you want to see,
not whatís actually there.
Continued to write the bullet and meanie initiator and handlers. Since meanies can fire other meanies
instead of bullets, I can have a whole sequence of meanies. They have differrent conditions for generating others,
randomly, only when wounded, or only when killed. Generally meanies will only take one shot to kill, but outdated
weapons will be less effective. Injured meanies will have different flight pasterns, usually wild retreat, but
slightly scratched ones may well get vicious. The smart bomb should ha can interesting effect on them, especially
an outdated one.
Was interested so read in this monthís ZZAP! that multiloads are okay if they load the next level while youíre
playing the current one , even if itís deliberatly lengthened to give the loader time! This type of loader is loading
data by getting the cassette to cause interrupts rather like Novaloed docs. This leaves about 50% of the CPU power
to the main games and no interrupt capabilities. You could get more CFU steam up by slowing down the loader, and
you could try to split the screen using NMIs, but I suspect that screen splitting would be impractical as it is
heavily tied into the progress of the raster, which stops for no man. So this type of loader is fine for games
with no raster splitting and little CPU usage, but donít expect that sort of thing in Uridium PIus 2 and Alleykatís
Revenge which would use all available CPU wellie most of the time, This said, there are moments in games where
very little is happening, for example when ĎPlayer Readyí messages appear, so short bursts of I/O are possible.
Seaching tapes is not really practical though, and waiting for CBM disk I/O is like watching paint dry. I think
the short-term answer is better data compaction. I could have loaded each Uridium dreadnought from disk into its
9K buffer, each is 512 characters wide by 17 deep, but by compacting this data I could specify each one in about
600 bytes. Thus I could fit 16 layouts into about 12K with overheads. If that were all decompacted at once it would
take 144K, more than two C64s full!
Many multi-load games donít bother to compact data like background pictures, because they have already accepted
that disk I/O is inevitable, so whatís another ten seconds of load time, if they donít have to spend anytime working
out how to get the best use from data. If they thought about it more they could cut multi-load I/O times down by
75%, but the perceived value of a game that loads from disk is much higher because you think youíre getting more
for your money.
Friday 3rd July
Finished off the meanie and bullet handlers today, now all Iíve got to do is get them to work. I want the bullets
to hit the shields and explode if the shields can take the hit, otherwise the bullets will skid across the surface
of the ship doing more damage. I also want the meanies to bounce off the ship in a realistic manner, or get squashed
against it if they canít get out of the way, such is the power of a large ship.
Realistic bouncing is always a problem, because although itís fairly easy to detect when the ship has been hit,
it is not so easy to decide what direction to bounce off at. I got round this by defining a perpendicular direction
from the face of each ship character. Any meanie approaching a block can be reflected across this perpendicular
axis and pushed away. I also enhanced this by adding that if a meanie approaches from an unusual angle it will
be allowed free passage.
Fired up the game alter a multitude of assembly errorshad been fixed. All was going well until I fired at a charge
orbital which is supposed to release from one to eight meanies or bullets. This however did not happen. What did
happen is that the game totally froze. Now Iíll have to take out the routines one by one to find out which one
caused it. This is always a problem when you add lots of inter-dependent routines at once. The code seems intact,
it restarts okay after reset without reloading any files. There may well be an infinite loop coded in there,
Monday 6th July
There I was, checking all the routines for possible reasons why the machine locks up, and I came across a JSR $0000,
a call to a routine at the 6510 data direction register? I think this could be the cause. The jolly old linker
has left a gap in the code because it didnít know what the real address was supposed to be. It didnít bother to
tell me that it didnít know because ever since day one it has whinged about not being given a transfer address.
I donít even know what one of them is. Iíd gladly let it have one but I donít know how to tell it either. The manual
doesnít mention transfer addresses. I got so fed up with it telling me to give a transfer address that I told it
to keep messages like that to itself, so it kept two unresolved labels to itself too. This is altogether more serious,
it works without a transfer address, but it sure as Hell wonít work with unresolved labels in it.
Tuesday 7th July
Debugged most of the meanie routines, and now Iíve got enough data in the game to generate several different types
in a number of different ways. They are firing flak at me which can blow up onboard systems and damage the ship.
Their manual movement patterns are switching in, but arenít yet positive enough to force them to move in any particular
way, itís just a question of line adjustment.
The main problem that weíve come across is that the game consists of moments of high activity followed by longer
periodsof travelling to another orbital. Finding theorbital is a bit haphazard. There area number of systems toaid
navigation, but I donít want to make them all available at the beginning. Iíve come to the conclusion that I need
a medium range radar display.
Wednesday 8th July
I didnít want to put a radar screen in, but if the game requires one then it shall have it. Now, where shall I
put it? I canít incorporate it into the main ship design, itís too big. I refuse to make it a sprite or two and
bung it in the top border. Iíll hang it below the game logo. I drew some scales round the edge to makea border
for it but it looked rather sketchy. The actual coding didnít take very long but on firing up it didnít work. Not
a radar plot in sight. Upon moving about I could occasionally get a dot to momentarily appear and that was all.
I studied the code for ages and there was no way at all that it could possibly fail, but it did.
By 6.30 I was getting very cross indeed, the C128 nearly got thrown out of the window. It then suddenly dawned
on me what I had done. Since I am plotting two orbitals every cycle it takes 16 cycles to prepare all their positions.
I then spent the next 16 cycles copying one row of the radar to the screen, so this also takes 16 cycles to complete.
This copying process is spread over some time to avoid doing time-consuming operations all at once - it also carries
out the function of clearing out the old radar images once they have been copied to the screen. All this was jammed
into the one routine, the first 16 cycles prepare the radar, the next l6 copy it to the screen. Now the problem
is that this routine is called twice each cycle, so it copies the radar across, clears the old image, copies the
now cleared image across again and finally clears it again. The setup needs to be done twice, but the copying and
clearing must only be done once. How could I be so stupid? Donít answer that.
Thursday 9th July
Changed the radar surround to a more solid border and built it up into more of a crest to fill it out. ST suggested
that it be a different colour from space to distinguish it from the background so we eventually decided on blue.
It looks quite neat now and serves its purpose very well.
Paul Hughes dropped by to discuss some new anti-cartridge techniques and loader. He left his Koalapad with me as
I intend to use a bit-map picture as a loading screen, hopefully for the disk and tape version. Iíve done a mock-up
on the Amiga-beast and it all looks feasible, trouble is I donít know how to use the Koalapad. Iíve tried turning
it upside down and rolling it about on the table but I donít have big enough area.
Friday 10th July
Spent much of the day thinking about how to run the charge rejuvenators, the ships that periodically ferry charge
from the central nucleus to the orbitals to counteract their decay. This involves getting the craft to the orbital
(easy), carefully driving round it (not so easy) and finally docking with it from above (difficult). As the orbitals
are positioned in a circle or other pattern around the nucleus then some are easy to approach from above, others
are much harder and require more complex guidance.
Iíve changed my mind about the charge supervisors, apart from deciding that l only need one at a time. Iíll make
it appear in the distance and slowly approach to use the 3D depth effect a bit more. Itíll appear after a while
around any attacked orbital.
Monday 13th July
Put in some enhancements that Iíd thought of over the last couple of days. I had to reduce the number of active
meanies to six as they are eating up the CPU time. This isnít too much of a problem as Iíve also thought of a way
of keeping them on screen without them crashing into the ship, they now run circles round it like Nigel Mansell
I put in the code to run the rejuvenator, and after teaching them a bit of basic navigation they can now find their
way from the nucleus to any of the orbital. They have to move quite slowly as they arrive, so that they can find
their target accurately. Then I reveal my coup-de-grace, the 16 frame animation sequence to drop their charge and
replenish the orbital.
Iíll have to write the game instructions out soon, Iíve already done the page numbers, now all I have to do is
fill in the rest.