So much to do, so little time...

[+johnnywc]

Hello all,

 

I'm knee-deep into my first 2600 game called RealSports Hockey (or something like that) and I'm quickly learning that 76 cycles is NOT alot of time...

 

Since this is my first kernel, I had a few general questions that I was hoping someone could give some insight to:

 

- first off, this game is a vertical scroller. I'm using PF1 and PF2 for the rink (PF0 is always 0xF0) to gain some cycles. The playfield is symetrical.

 

- the complete length of the rink is 240 pixels, with 160 being displayed at once (32 pixels are used for score, clock, etc.).

 

- I have tables for PF1 and PF2 data. Each table has 60 entries representing 4 lines of the rink (60*4=240 total rink length)

 

- I am changing the background color to simulate the RED lines and the BLUE lines. I'm pretty sure I won't have the time to do this in the final release but for now it looks cool!!! For now, I have another 60-byte table holding the background color changes for each set of 4 scanlines.

 

- I am using the ball sprite for the puck

 

- I plan on having vertical separation for the players (like Activision hockey) except that there will be four sets of players instead of 2 - the goalie, 2 defensemen in tandem (2 copies medium), the center, and 2 wingmen in tandem (2 copies wide). The maximum number of sets of players that can be on the screen at once is 2 (per team).

 

- I want to use P0 for team 1's players and P1 for team 2's players

 

- I'm thinking of using M0 for team 1's hockey sticks (I think this is what is done in Activision's hockey) and M1 for team 2's hockey sticks. Like Activision, this will only be drawn for the player (or set of players) that are being controlled (based on puck location).

 

- I know I'm asking for a lot here, but I would also want to be able to change the player colors on each scanline to simulate uniforms (much like Activision's Hockey)

 

- I would like to fit this all into 4K but 8K is not out of the question.

 

The good news:

 

- I have the clock, period lights/indicators and score display working

- I have the rink display working with full vertical scrolling via UP and DOWN

- I have the puck displaying and moving (just up and down the screen for now)

 

The bad news:

 

- after optimizing, I only have a few cycles left (about 9) before cycle 28 (the cycle before PF1, the puck, players, missiles, etc.) need to be set up by. I can't see how I'm going to check for and display GRP0, GRP1, M0, and M1!!!

 

I've heard people talk about VDEL, double-scanline resolution, even/odd scanlines etc. to try to accomplish something like this. Does anybody have a general direction that they would suggest? What I'm looking for is some proof-of-concept that someone might be able to offer up that might be able to be used.

 

Here are some of my thoughts and observations.

 

- I purposely made it so that each scanline in the rink has either a change to PF1, PF2 OR COLUBK, but never more than one. For example, the first scanline has a change in PF1 but PF2 is 0 and COLUBK is the default color of the ice.

 

- With the above, it may make sense to divide the kernel up into sections in such a way to draw specific scanlines of the rink so that only one of the three registers (PF1, PF2 and COLUBK) needs to be updated. Is this feasible? I've only seen kernels (in demos) that step through all 192 lines and do the same thing on each line. Is this common?

 

- I've already divided up the kernel into sections to display the clock, score, etc. but dividing up the main kernel would require a lot of code duplication since players, the ball, etc. would have to be drawn in each section also. Does this make sense?

 

- Since the "resolution" of the playfield and the background color changes is 4 lines, it makes sense that I would only have to update these registers every 4th scanline, leaving the other 3 scanlines to do other things like draw the players, puck, do a RESP0 and HMOVE for repositioning the multiplexed sprites, set the player copy register, etc. Is this the common approach?

 

- How would using a double-scanline kernel help with the cycles? I know it limits the sprite resolution to 2 scanlines (drawback) and the playfield too (not a big deal since the resolution is 4 scanlines anyway). Is this where VDEL for the sprites comes into play?

 

- To all of the experts out there - does this even sound feasible? I'm really trying to make a good hockey game with emphasis on gameplay) so I'm willing to give up things like the COLUBK changes or the multi-colored sprites to make this work.

 

- If you've made it this far - thanks!!! Any suggestions on the kernel (or even on gameplay ideas) is welcomed!!!

 

JohnnyWC

 

PS I've a attached a screen shot of the current build.

[Thomas Jentzsch]

I'm knee-deep into my first 2600 game called RealSports Hockey (or something like that) and I'm quickly learning that 76 cycles is NOT alot of time...

Yup, but that's the fun part.

 

- the complete length of the rink is 240 pixels, with 160 being displayed at once (32 pixels are used for score, clock, etc.).

You can display a few rows more than 192. 200 is a good compromise.

 

- after optimizing, I only have a few cycles left (about 9) before cycle 28 (the cycle before PF1, the puck, players, missiles, etc.) need to be set up by.  I can't see how I'm going to check for and display GRP0, GRP1, M0, and M1!!!

You don't have to setup everything at the start of each line. E.g. you can update PF1 at the end of the previous scanline (@70) and you can also preload the graphics data value there.

 

I've heard people talk about VDEL, double-scanline resolution, even/odd scanlines etc. to try to accomplish something like this.  Does anybody have a general direction that they would suggest?  What I'm looking for is some proof-of-concept that someone might be able to offer up that might be able to be used.

Yup, VDEL is IMO very useful, because it makes your kernel much more flexible, i.e. you can update the VDELed register at any time.

 

- With the above, it may make sense to divide the kernel up into sections in such a way to draw specific scanlines of the rink so that only one of the three registers (PF1, PF2 and COLUBK) needs to be updated.  Is this feasible?  I've only seen kernels (in demos) that step through all 192 lines and do the same thing on each line.  Is this common?

Yes, that's very common, e.g. Pitfall uses nine different kernel loops. It costs ROM space, but today that's no problem anymore.

 

- Since the "resolution" of the playfield and the background color changes is 4 lines, it makes sense that I would only have to update these registers every 4th scanline, leaving the other 3 scanlines to do other things like draw the players, puck, do a RESP0 and HMOVE for repositioning the multiplexed sprites, set the player copy register, etc.  Is this the common approach?

Yes, that's also very common. If you e.g. look at Thrust, you can see that I am updating the playfield also each 4th scanline.

 

- How would using a double-scanline kernel help with the cycles?  I know it limits the sprite resolution to 2 scanlines (drawback) and the playfield too (not a big deal since the resolution is 4 scanlines anyway).  Is this where VDEL for the sprites comes into play?

A double scanline kernel (2LK) reduces the number of TIA writes significantly. VDEL is often used together with a 2LK, but is it not necessary.

 

- To all of the experts out there - does this even sound feasible?  I'm really trying to make a good hockey game with emphasis on gameplay) so I'm willing to give up things like the COLUBK changes or the multi-colored sprites to make this work.

Maybe you have to make some compromises, but it doesn't sound impossible.

 

- If you've made it this far - thanks!!!   Any suggestions on the kernel (or even on gameplay ideas) is welcomed!!!

Maybe you should post your (commented, incl. cycle counts!) main kernel loop here. That would make discussing about the kernel easier.

 

And I suggest subscribing and posting your very intelligent questions to [stella] too.

[+johnnywc]

Thomas -

 

Thanks for all the information and suggestions!!! I've already started re-writing my kernel and it's all starting to make a little more sense. I've changed it so that PF1, PF2 and COLUBK are all being updated just on the first scanline per every four. Much cleaner and now I have a ton of cycles (at least for the other 3 scanlines). I also made sure that I update PF2 after cycle 60 and PF1 after cycle 70 on the *previous* scanline (as you suggested) and I even have enough time to load up the COLUBK register too! Next step is to mess around with trying to get the ball (puck) displayed in the new kernel and then the players.

 

One quick question: When you said that I could have 200 visible lines - does this mean I just add 8 more lines to my display kernel (for a total of 3+37+200+40=270) or do I need to keep a count of 262 (and take 8 away from the overscan)?

 

Anyway, there should be a warning posted saying that once you get into this stuff it CONSUMES you!! I'm counting scanlines in what little sleep I'm getting!! I'll post my kernel (what I have so far) in a few days once I've hit the next of many brick walls.

 

Thanks again for the suggestions and the encouragement - they are both very much appreciated!!

[Thomas Jentzsch]

One quick question:  When you said that I could have 200 visible lines - does this mean I just add 8 more lines to my display kernel (for a total of 3+37+200+40=270) or do I need to keep a count of 262 (and take 8 away from the overscan)?

You can go both ways. While 262 is the NTSC standard, e.g. Thrust displays 270 scanlines and I have heard no complaints yet.