Planet Bob

The shield looks a bit strange in this version - like it is counting through the memory. I am guessing this is just to show how the shield can take damage on each layer? Anyway, it looks like it is coming along nicely. This is clearly another one of those 2600 programming tasks that looks straightforward, but is a real pain to do!

 

Chris

Hi Chris!

 

Yes, it's just some counters running at the moment to create some dummy data for the shields. That way I can quickly confirm wether all PF writes are done in time

 

I started out a bit silly here with reflected PF. Now after switching to repeated PF for this section the timing is a lot easier and I got rid of a lot of SLEEP time. (It may complicate collission detection later on though... )

 

Greetings,

Manuel

There is also an A8 game called "Colony 7":

 

http://www.atarimania.com/detail_soft.php?...VERSION_ID=6678

 

Your game is looking good!

Hi there!

 

There is also an A8 game called "Colony 7"

 

Oh dear!

 

Never heard of that... phew...

 

Greetings,

Manuel

Hi Chris!

Yes, it's just some counters running at the moment to create some dummy data for the shields. That way I can quickly confirm wether all PF writes are done in time

I started out a bit silly here with reflected PF. Now after switching to repeated PF for this section the timing is a lot easier and I got rid of a lot of SLEEP time. (It may complicate collission detection later on though... )

Greetings,

Manuel

 

Hi Manuel,

 

I usually start with a reflected PF and ignore PF0 as it normally makes things a lot easier. However, every rule has an exception! I think you may be able to use the same code for the ground damage in Balloon Bomber if you restart that project in the future?

 

Chris

Hi there!

 

I usually start with a reflected PF and ignore PF0 as it normally makes things a lot easier.

 

Same here. This is after Gunfight the first game where I'm trying to utilize the whole 160 pixel width (at least for the bottom ). I hope it works out...

 

However, every rule has an exception!   I think you may be able to use the same code for the ground damage in Balloon Bomber if you restart that project in the future?

 

I think I can partially recycle the playfield destruction code from Gunfight for that. The bottom of Balloon Bomber would probably be reflected again though

 

Greetings,

Manuel

Looking very nice, Manuel!

 

I was very confused at first - why does he need to unroll the *shield* lines? - and then I remembered that the shields take localized damage! This should be a fun one when you are all through

Hi Bob!

 

Looking very nice, Manuel!

Thanks!

 

I was very confused at first - why does he need to unroll the *shield* lines? - and then I remembered that the shields take localized damage!

 

Yeah, it's pretty wasteful. Especially for the 2 PF pixels at the left end of the shield. But I thought I can afford that this time

 

This should be a fun one when you are all through

 

I hope so. The *action* kernel will be very tough. Unlike Star Fire, I want to have single line resolution on the sprites this time ;)

 

Greetings,

Manuel

I hope so. The *action* kernel will be very tough. Unlike Star Fire, I want to have single line resolution on the sprites this time 

What are you envisioning for the "action" kernel? Are you going to draw the crosshair with the ball/missile?

Hi there!

 

What are you envisioning for the "action" kernel?  Are you going to draw the crosshair with the ball/missile?

 

Particles are already reserved: Two for enemy shots and one for your own shots. The crosshair is supposed to be drawn with GRP0 constantly and all other stuff on the screen is GRP1 multiplexed.

 

I thought a while about multiplexing everything using two sprites, but then decided to not flicker the crosshair, since the eyes attention is constantly focused on it

 

What I think will be troublesome is (once again ;) ) transporting information over the repositioning line.

 

I need to draw three particles and update both sprites before the 4th pixel of PF0 starts

(Star Fire was a lot easier here, as the crosshair was fixed in the middle and with 2LK sprites I had a whole extra line to prepare the write )

 

Well, I have a lot of reserve plans, if it doesn't work out, so I will have *some* solution after a while

 

Greetings,

Manuel

Particles are already reserved: Two for enemy shots and one for your own shots. The crosshair is supposed to be drawn with GRP0 constantly and all other stuff on the screen is GRP1 multiplexed.

 

I thought a while about multiplexing everything using two sprites, but then decided to not flicker the crosshair, since the eyes attention is constantly focused on it

 

What I think will be troublesome is (once again ;) ) transporting information over the repositioning line.

 

I need to draw three particles and update both sprites before the 4th pixel of PF0 starts

(Star Fire was a lot easier here, as the crosshair was fixed in the middle and with 2LK sprites I had a whole extra line to prepare the write )

 

Well, I have a lot of reserve plans, if it doesn't work out, so I will have *some* solution after a while

I hope you don't mind me making suggestions, but the first thing I would sacrifice if it doesn't work is non-flickering shots; i.e., flicker the enemy shots at 30 Hz or something. Save you 6-10 cycles right there

Of course, hopefully you can fit everything in

Hi there!

 

Phew... I tried some things last night and it looks like the only thing that has to go is the resolution. With 2 line resolution everything just seems to work out. So for the next step I'll try and convert some sprites to see how they'll look in that resolution.

 

(Your suggestion was already part of the plan, all three particles will flicker at 30Hz.)

 

Greetings,

Manuel