Jump to content
  • entries
  • comments
  • views

Star Castle brainstorming

Thomas Jentzsch


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.


Recommended Comments

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?

Link to comment



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.

Link to comment

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:

Link to comment

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.

Link to comment

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.

Link to comment

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:

Link to comment

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?

Link to comment
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.
Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...