Star Castle, anyone?

Posted by supercat, 03 August 2008 · 377 views

Here's a rough kernel test for the 'rings'. This should be quite workable in a real game if everything is flickered at 30Hz (player ship, one shot, enemy fireball, and two chaser mines). Hold player 1 fire to slow down the animation; hold player 2 fire to disable the shift-in data. Color/BW toggles 30Hz flicker. The funny 8x8 block in the middle would be the enemy space ship, which could be drawn at 1lk or 2lk resolution. The plan is probably for rings to have 32 or 48 segments which would be in groups of 3 or so, possibly with some small gaps so that even a full 'ring' would seem to rotate.

The kernel code is horrible and bloated, but should be good as a feasibility test.

Attached Files

starcas.bin (4K)
downloads: 356

Nathan Strum
Aug 3 2008 6:43 PM

Cool!

Report

Cybergoth
Aug 4 2008 1:11 AM

Wow, this looks amazing! :ponder:

Report

Thomas Jentzsch
Aug 4 2008 1:16 PM

I like it! :ponder:

Report

cd-w
Aug 4 2008 3:35 PM

Very impressive - are you calculating the ring on-the-fly, or do you have a large table of possible positions?

Chris

Report

supercat
Aug 4 2008 6:13 PM

cd-w, on Mon Aug 4, 2008 3:35 PM, said:

Very impressive - are you calculating the ring on-the-fly, or do you have a large table of possible positions?

The rings are 40, 32, and 24 pixels wide. The outer ring has five bytes, one per column, for the 'top' half of its state; the middle ring has four bytes, and the inner ring three. Total 12 bytes. Another 12 bytes are used for the bottom half. Some extra storage will be needed to handle the straight vertical parts of the rings.

My plan is to have a routine that will map 4 or 6 bytes for each ring onto the 24+ bytes of ring 'display' storage, with each bit representing 1/32 or 1/48 of a circle. Doing things that way might be a little more work than manipulating the ring data directly (and ignoring the differences in spacing between vertical, horizontal, and diagonal pixels) but using a fixed number of segments for all the rings would allow for inner rings to move outward when the outer ring is destroyed.

Also, btw, right now the display of the rings is all done with straight-line code. No loops--just some bulky macros. Code usage could probably be almost cut in half by changing all loads of mask data to use ,x addressing and then doing something like:

l0_exit
  rts
l0_entry:
line_0:
  draw_line
  txa
  bne l0_exit
line_1:
  draw_line
  txa
  bne line_0
line_2:
  draw_line
  txa
  bne line_1

I wonder if anyone else has ever done anything like that (FYI, I have enough spare cycles that I STA WSYNC on every line, so the extra cycle(s) from the branch taken are not a problem).

Report

djmips
Aug 11 2008 10:25 AM

Nifty! If you added the mines and player ship would it necessarily flicker?

I guess it would have to but, it wouldn't look too bad I don't think. The original kind of flickered anyway.

I really think you should consider more collaboration, you make the awesome display kernels and collaborators can do the gameplay / art!

Report

supercat
Aug 12 2008 11:08 PM

djmips, on Mon Aug 11, 2008 10:25 AM, said:

I really think you should consider more collaboration, you make the awesome display kernels and collaborators can do the gameplay / art!

If someone needs a kernel, they should ask me. Kernels are the part of coding I find to be the most fun, though doing the design and gameplay programming for Toyshop Trouble was pretty amazing as well (Nathan Strum did most of the graphics).

Report

Albert
Oct 1 2008 9:21 PM

Holy cow, I just ran this for the first time. It's beautiful! The local arcade I grew up with had a Star Castle and I played the hell out of it. Never thought I'd see a reasonable facsimile of it on the 2600, but it's looking pretty promising now!

..Al