For whom it may concern

Not sure if that helps much, but if you make it 2 pixels smaller it could be drawn with 5 sprites.

Good idea.

 

Originally I wanted the GRPx copies aligned to the PF and use the PF color for coloring the rings. But then I realized that that would cause large all black areas around the rings.

 

With just 40 pixel, I would sure save quite some pointers.

 

I have attached two new layout graphics for 40 pixels (3 and 4 pixel gap).

 

BTW: I couldn't find a screenshot, which shows the full screen in relation to the ring size. Do you know that relation?

I don't know how acurate those are, but maws has several screenshots:

 

http://maws.mameworld.info/maws/romset/starcas

 

Try those "artwork" links in the "snapshots" row. They're all different resolutions though...

Thanks.

 

Looks like the arcade rings are a bit less than 1/4th of the width and 1/3rd of the height of the screen. And the rings are ~1/40th of the screen width apart.

 

So a 40 pixel outer ring should be big enough. 36 pixel would be the best match, but I think that might become a bit too small. And the rings should be 4 pixel apart.

After thinking about it some more, I don't think going to just 5 GRPx writes will help much (if any). There will be too many sprites, where two rings have to be merged. With 6 GRPx writes, especially the central 2 sprites (where later the gun will be too) can always be drawn from just one pointer and left and right from that due too more sprites, the overlapping is reduced.

 

Hope that makes sense.

The advantage of 40 pixel with 4 pixel spacing drawn with 5 sprites is the center is just aching to be used for the center baddie IMHO.

You mean the gun? I would like to have that a bit larger than 8 pixel, maybe 12 pixel.

Hm... if a clever cannon animation would be used, it should never need the extra two pixels on both sides at once I think, even if its full rotation occupied 12 pixel. It'd then always only require the center sprite and just one of the adjacent sprites.

That would save one pointer, but make the kernel a bit more complicated.

 

Anyway, I optimized my original layout. I removed the stack usage (which costs some CPU time) and by using the same pointer in more than one kernel (see colourful picture above), I reduced the pointers to 30 (=60 bytes).

 

The two middle kernels could be merged, but then the drawn parts would become too large, causing the necessary precalculated data to increase massively. Just imagine the possible combinations of 3 or more rotating on/off segments!

 

Scott sure had some fun with optimizing his setup too.

Before detailing the ring kernel any further, a decision has to be made how to draw the other objects. The sprites cannot be used here, so that only leaves the ball and the missiles.

 

The other objects are:

a) player's ship

b) player's shots

c) mines

d) gun shot

 

I can see two options:

1. Draw everything with the ball and reposition it inside the kernel to reduce flickering. Since the most busy parts of the ring kernels already extend a bit into the other line, this will become pretty tricky.

2. Use the missiles too (for player's shots and mines). One had to disable and re-enable three-copy mode and probably VDELPx (not 100% sure) for this. Also the missiles can only be drawn in the other lines, where no shield is displayed.

 

What do you think? Any other options you can think of and which option is the better one?

Pretty sure VDELPx has no effect on missiles, or am I misunderstanding what you mean?

Pretty sure VDELPx has no effect on missiles, or am I misunderstanding what you mean?

No, that's what I meant.I suppose I confused them with the ball.