Scrolling shoots and Attacking Waves

[José Pereira]

Regarding Attacking waves on horizontal shoot'em'ups I would like to know how the Enemys are normally (most of times) done.

This picture we have, for example, the Enemy wave moving following the red line:

Here on this picture they would cross the that Mountain gfx.

 

Will they normally, in most of the shoots (for example XEO3 or Armalyte) always appear at the same time and if going over gfxs, always the same Atacking wave cross the same gfxs?

Or it depends the delay caused by our ship movement (like if we pull the Joystick back to decrease speed) and then they can enter screen in diferent parts?

 

Other situation, for example because of C64 nº of sprites for Enemys, normally the Enemys go out of the screen to enter new ones or they stay there untill they kill you or you shoot them?

[José Pereira]

I don't know if this is in all this type of games but Armalyte it's exactly always the same Attacking waves, always at the same time, always the same Bonus,...

Just put the two videos on screen and go playing and stop them and you'll see this:

http://www.youtube.com/watch?v=NUFAmJPqxK8

http://www.youtube.com/watch?v=WXPoi3_ccYQ

 

Now I am wondering if this isn't an advantadge to build a game like this on A8.

Attacking waves always the same and at the same places you can do that by fixing chars, pre-shifted and at fixed positions (if destroyed then that same char nº replaced by explosion shape).

If Attacking waves the same at same fixed x,y then it would be just chars replace (sky char replace by char ship).

And if it is chars replace then it couldn't even be consider a soft sprite routine.

It would/could be something like, for example, on a Status Area when you replace the numbers of the score...

 

Now, and if possible, just char replace aren't lots of cycles less than if you do real soft sprite routine?

And if just char replace then the Multiple lines charsets wouldn't even be a problem in eating more cycles.

 

Only problem would be Memory as you'll need thousands of frames/tiles Data but then it would be possible if using those large space carts.

Am I thinking right?

Edited December 13, 2011 by José Pereira

[Rybags]

Where enemy movements are fixed as such, "scripted" is one way to refer to it.

 

Enemies moving diagonally will likely use every possible shape type anyway.

Enemies moving over terrain will generate thousands of possible shape types.

 

Getting optimisations is kinda tricky. For e.g. an up/down movement where the object stays on a character boundary, then the object has to move left at the same rate as the terrain.To move right, then the object is moving 2 pixels right relative to the terrain. To move up/down and appear static onscreen, the object is actually moving 1 pixel at a time relative to the terrain, so there's no saving at all in that case.

 

Probably the best strategy is to minimize the times that enemies overlap terrain. *

 

* Overlap = not necessarily touching but sharing a character cell or byte of bitmap data.