13th of April – more overlay thoughts…

The more I think about the overlays – the more I begin to realize – this is really my fault.

• I didn’t give it as much thought as I should have
• I didn’t give Jacek any specifics (because I didn’t think about it enough)

Now if the bug hunt is at some stage over, I will have to live with it and do the best.

But first lets summarize what is “wrong” with vectorblade.

1. the overlay has at the top a larger opaque area than on the bottom
2. all graphics of vectorblade are more to the top oriented than to the bottom

Both together tend to obscure some of the images.

Number 1. is a design choice of Jacek and is definitly not his fault!

Number 2. is a technical choice of mine – which is my “fault”. Let me explain…

Let us assume, this is a drawing of the Vectrex CRT.

Than:

The inner drawn rectangle are the screen positions reachable with a scale of $80.

Now due to easy colision detection routines… all sprites start at the bottom of the sprite, like:

Once you put the screen and the sprite “together”…

You see… that the sprites can easily reach above the “$80” rectangle, but they NEVER EVER go below the -$80 position.

So the center of the whole game is 1/2 sprite height above the middle point!

---

Possible solution (not tried out, only theoretically):

a) change all sprites & all colision detection

b) something along the following…

With the above sprite definition, it is not possible to move the sprites lower as the drawn “barrier” with just one MOVE, because we already are at the bottom. So to reach any position lower than the $80 bottom line, we need an additional move.

Let us say, we want to move “everything” down $20 “pixels”. Than we have to insert an additional move “$20” to every sprite.

WRONG!

For most positions – (all above -($80-$20)) we can just subtract $20 from register a in the move. No need for any second move!

Also due to timing issues – if we really HAVE to do a second move – it will not be done in $80 scale. We would (aproximately) do the reverse… we would use scale $20 and move -$80 (to save precious time!).

Also…
There are “fixed” objects – which we can just “relocate” without additional move.
The fighter – is always on the very bottom. Here we would simply use a scale of say $90 and move it.
The UFO, the mothership, all biggies… we know these NEVER ever go below a certain postion, we can just relocate them once and been done with.
The stars in the background… they just stay as they are.

ALL I need to really change are “shots” (player and enemy) and all “normal” enemies.

A pitty these are the majority of objects :-(.

So – how might I do that “efficiently” as in not lose to many cycles?

Thoughts….

Each object in Vectorblade (sprites, stars, shots, bonus…) has the same overall programming frame.
They all consists of data in ROM, data in RAM and a “behaviour” routine.

Each and every such behaviour routine is structured the same – the very first thing I do is start the MOVE to where the object is located. Within the move I process whats necessary (collision detection, update position etc.).

E.g. a simple shot behaviour start looks like this:

It is also important to know, that each such behaviour routine is always called with register D containing the position information, so the first thing that is really immediately done – is the positioning.

So – here I already need to intercept. I need to do the additional move in advance to the real move. I can’t do it the other way around (without changing a whole lot more code), because in general I do not know what is all done within the “moveto” phase – and what register contents I might destroy.

My thought at the moment is this… within the “moveto” – I also update the position information of the object… again the “simple shot” as an example:

Now… if I add a test at the position update information, whether the new coordinate is less than -($80-$20) and if so change the behaviour to another behaviour (a “relocation_simpleShotBehaviour”) – than in the next update round “automatically” the new behaviour would be called – and position update done correctly.

Needless to say – very few objects (in their lifetime) really ever need the updated behaviour.

Also – the new behaviour could be (code wise) located directly in front of the old behaviour – so it would “slide” right into the “old” behaviour by execution.

Still…

• I have to test it all out
• it will still cost hundreds of cycles
• I will have to do the additional move without changing register “D”
• this is no “calibration” – just a fixed relocation

But I think this might be the best/cheapest solution I will come up with.

If it is still sufficient speed wise – I don’t know.

I will have to program it and see what comes of it…

Malban