Jump to content

Star Castle brainstorming

Posted by Thomas Jentzsch, in Atari 29 July 2010 · 2,169 views

Star Castle
With the recent thread about the never to be released, new Star Castle homebrew, I first tried to understand from the available videos and screen shots, how it is done.

The rings and gun are drawn using the 48 pixel routine, using large, precalculated ROM blocks. I described that a bit more detailed that in the very thread. All other objects are probably drawn with the ball (though I am not 100% sure here).

The result looks pretty impressive, but there is one pretty obvious difference from the arcade original:
The rings are spaced much wider, making the inner ring very small and the outer ring a bit large.

So I though about a way to make the spacing narrower and the overall size a bit smaller to give the player more room to maneuver and came up with the setup displayed in the attached picture.

You can see that there are 7 kernels, with all but the center kernel being rather simple to draw. For the center kernel, for GRP1a and GRP0c, the data of the precalculated inner and middle ring segments has to be merged. Usually this would require too much CPU time, so I cheated and only merged GRP1a inside the kernel. GRP0c is merged outside and pushed to the stack (14 bytes).

I also did a coarse calculation of the bytes required for the precalculated ring data. About 2800 bytes, which should leave enough room for the kernel and the gun data.
Note: The attached demo doesn't have this data, since I was too lazy to calculate it and to write the setup routine. :) Instead I just display the full rings, to give you the idea. Press fire to see the kernel areas.

The biggest current problem is the current RAM usage just for displaying the rings. 74 bytes! Ouch!
I suppose Scott had similar problems, so maybe the remaining space is good enough. :ponder:

So lots of problem still to solve. Anyway, I thought I share my results with you.

EDIT#1: Added 3 more kernel layout graphics, one for 40 pixel with 5 pixel spacing and two for 40 pixel with 4 pixel spacing, drawn with 5 and 6 sprites.

EDIT#2: One more graphic, displaying the kernel overlapping pointers for 42 pixel rings. Plus binary and source code.

Attached Thumbnails

  • Attached Image
  • Attached Image
  • Attached Image
  • Attached Image
  • Attached Image

Attached Files

Not sure if that helps much, but if you make it 2 pixels smaller it could be drawn with 5 sprites.
  • Report
Good idea. :lol:

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?
  • Report
I don't know how acurate those are, but maws has several screenshots:


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

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.
  • Report
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. :lol:
  • Report
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.
  • Report
You mean the gun? I would like to have that a bit larger than 8 pixel, maybe 12 pixel.
  • Report
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.
  • Report
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. :lol:
  • Report
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?
  • Report
Pretty sure VDELPx has no effect on missiles, or am I misunderstanding what you mean?
  • Report

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.
  • Report

Search My Blog

Recent Entries

Recent Comments

February 2019

1011121314 15 16


0 user(s) viewing

0 members, 0 guests, 0 anonymous users

Latest Visitors