Request for newbie help; 2 line kernel

[lrom]

Needing some help with lining up players vertically in a 2 line display kernel, so I joined the forum. Thanks to readers/responders in advance.

 

I have only basic knowledge so far. I have been using the Stella manual and some other internet posts as references. I picked Atari's "Space Race" as a starting point for a simple, 2 player, time based VCS game. If it gets finished, it might be used for a future local gaming event. The original arcade version is simulated in the Dice emulator: http://sourceforge.net/projects/dice/

 

This demo is rough and obviously missing most things. 20 lines at the top are reserved for a score display that will be the same style as combat or air sea battle; I don't know how to do this yet so I left it out. It may be relocated to the bottom of the screen to be more like the original.

 

How I'm going to make the asteroids is currently undetermined also. I'm thinking about playfield graphics, 20 rows; with alternating rows going 10 left and 10 right. I don't have a handle on working with pf graphics yet either, so I'll probably demo something separately and see what I can do.

Joystick is read for moves to p0 only at the moment, p1 is locked. Horizontal positioning is not being done yet.

 

Question1: I think this is what the Stella manual describes as the "two line kernel". As you can see by the starting positions of the sprites, one ship is one scan line higher. The manual mentions delaying sprites by one line, but I haven't been able to figure this part out based on their description. Given this example code, can someone provide easy to understand hints on how to implement this? I don't know about 1 scanline movement; this game is probably ok with the doubled resolution - but I'd like the opinion of those who have already solved this problem, maybe it looks smoother or has some other benefit.

 

Questions 2: I should only need to position the sprites horizontally once. I've seen some other examples on this (divide by 15 w/ RESP0?) I will try later, but could I put this in my setup code (outside the display kernel)?

 

Any suggestions for optimization or removal of redundancies is appreciated. Keep in mind I'm a beginner with VCS and 6502 code, so I won't have a handle on advanced concepts. I'm pretty sure this game can be done without many tricks; it seems like just a timer, scoring and collision detection once the graphics problems are out of the way. Fair warning - I don't understand the cycle counting yet (and where I should be counting) but I'm working on it. What you see here is trial and error, and even the basic structure is mostly guesswork and learned/copied from example.

 

Thanks,
Lee

spr001.asm

spr001.bin

[SeaGtGruff]

I haven't studied your code in depth, but the easiest way to solve this would be to add the following lines to your Setup code:

 

 

   LDA #1
   STA VDELP0

 

This will have the result that writing to GRP0 won't change player0's graphics right away-- instead, the new graphics shape will be held "in reserve" and won't take effect until you write to GRP1, such that player0's new shape will appear at the same time that player1's new shape does.

 

VDELP1 works similarly, but the other way around-- when you write to GRP1 the new data will be held "in reserve" and won't take effect until you write to GRP0.

 

If you're writing a two-line kernel, you need to enable only one of these-- VDELP0 or VDELP1. But if you're using the "score trick" to display a "48-pixel sprite" then you need to enable both of them at the same time.

 

If you enable VDELP0 (and disable VDELP1, which will be done automatically by the CLEAN_START macro), both players will be updated on the *second* line of your two-line kernel. If you instead want to update both of them on the *first* line of your kernel then you'll want to enable VDELP1 rather than VDELP0-- but this wouldn't be as simple of a solution, because then player1's sprite would be off from player0's by *2* lines instead of only 1, since the new value you write to GRP1 on the second line of your loop wouldn't take effect until you write to GRP0 during the *next* pass through the loop, if you follow me.

 

As for positioning the sprites horizontally, you can do this once per frame during the vertical blanking period, not during your initial setup. For instance, you could put it after the vertical sync, right after you set the timer for the vertical blank interval.

[+SpiceWare]

I've started work on an example of developing a 2600 game for a presentation in August. I'm planning to use a 2 line kernel as I've not used one before. I'll be posting it in my blog if you'd care to follow along. There will be number of posts done over the next few weeks, and I'm hoping to have the first one up this evening.

Edited June 22, 2014 by SpiceWare

[+SpiceWare]

It's been posted. I've created also created a new category, Collect, to make it easier to find future updates.

 

The first entry is just to establish the goals for the project. I plan for the next update to be posted by Wednesday, it will contain actual code - though do note that it'll be a while (say a week or two) before the 2 line kernel code is posted.

[lrom]

I haven't studied your code in depth, but the easiest way to solve this would be to add the following lines to your Setup code:

   LDA #1
   STA VDELP0

This will have the result that writing to GRP0 won't change player0's graphics right away-- instead, the new graphics shape will be held "in reserve" and won't take effect until you write to GRP1, such that player0's new shape will appear at the same time that player1's new shape does.

 

VDELP1 works similarly, but the other way around-- when you write to GRP1 the new data will be held "in reserve" and won't take effect until you write to GRP0.

 

If you're writing a two-line kernel, you need to enable only one of these-- VDELP0 or VDELP1. But if you're using the "score trick" to display a "48-pixel sprite" then you need to enable both of them at the same time.

 

Thanks for that reply SeaGTGruff. I had actually tried enabling VDELP0; this does solve the problem as long as the ships are in the same scanline pair or "row" (one actual scanline apart), as they are when the demo starts. As soon as one ship moves and they are separated by more than one scanline, and player 0 ship (GRP0) disappears with the code I posted.

 

I've started work on an example of developing a 2600 game for a presentation in August. I'm planning to use a 2 line kernel as I've not used one before. I'll be posting it in my blog if you'd care to follow along. There will be number of posts done over the next few weeks, and I'm hoping to have the first one up this evening.

 

Thanks Darrell, I'll be checking on your posts. Seeing a working example may help clear up the things I don't understand, and I'm not really in a rush.

[SeaGtGruff]

 

I had actually tried enabling VDELP0; this does solve the problem as long as the ships are in the same scanline pair or "row" (one actual scanline apart), as they are when the demo starts. As soon as one ship moves and they are separated by more than one scanline, and player 0 ship (GRP0) disappears with the code I posted.

 

Ah, I think I know what happened. Remember that if you're using VDELP0, writing to GRP0 won't cause any change to player0's graphics-- the new value won't show up until you write to GRP1. That means if you don't ever write to GRP1, player0 will be drawn with its "old" value, which will probably be all zeros. So if you're using the "skip draw" method or something similar, such that you aren't writing to GRP1 on the lines where player1 doesn't appear, then on those lines you'll likely have an issue with player0's graphics. The solution is to always write to GRP1-- on lines where player1 doesn't appear, write zeros to GRP1.

[+SpiceWare]

Just posted the beginnings of the 2 line kernel. In that build VDELP0 and VDELP1 are controlled by the difficulty switches so you can get a better feel for why you use VDELxx. The next build will update them based on the Y value of the players.

[+SpiceWare]

New build posted that automates the setting of VDELxx for the 2LK.