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.













