5 replies to this topic

[jbs30000]

OK, because I haven't quiet figured out how to do a two line, asymmetrical kernel I did the next best thing. I made an interlaced kernel. It works, except for one thing; The sprites.

What I did was make a kernel that draws sprites on the first line, and then every other line after that, with sprites being drawn on the second line, and every other line after that. File Interlaced_A.
I then made a kernel that did the opposite, drawing sprites on the first line and every other line, and then drawing the screen on the second line and every other line. File Interlaced_B.
Something I noticed was the sprites turned out the same in both programs. Seeing as how one program should have been reading every odd line and the program should have been reading every even line this shouldn't have happened, but for whatever reason, it did.

Anyway, I combined the two programs, Interlace_C and sure enough, while the playfield pixels (and background) are just fine, the sprites aren't whole. They still display every other scanline.

I try my best to solve my own problems, but this has me stumped. If anybody can help I'd really appreciate it. Thank you.

P.S. The joystick moves the smiley face.

 Interlaced_A.asm   11.17K   17 downloads  Interlaced_B.asm   11.76K   16 downloads  Interlaced_C.asm   16.78K   16 downloads
 Interlaced_A.asm.bin   4K   16 downloads  Interlaced_B.asm.bin   4K   22 downloads  Interlaced_C.asm.bin   4K   25 downloads

Edited by jbs30000, Tue Jan 10, 2012 5:39 AM.

[RevEng]

jbs30000, on Tue Jan 10, 2012 5:26 AM, said:

Something I noticed was the sprites turned out the same in both programs. Seeing as how one program should have been reading every odd line and the program should have been reading every even line this shouldn't have happened, but for whatever reason, it did.

I'm not sure where the confusion is, but both A and B load data from (Player0PTR), which is initialized the same in both programs. The fact that they're displayed on odd or even lines doesn't change the data source.

jbs30000, on Tue Jan 10, 2012 5:26 AM, said:

Anyway, I combined the two programs, Interlace_C and sure enough, while the playfield pixels (and background) are just fine, the sprites aren't whole. They still display every other scanline.

This is because you're clearing them on half of the lines. Ditch the lines that store #0 in GRP0 and GRP1 in your kernel - remember that values stored in registers persist until you store another value in them. So if you set the player data on one line, you can skip it during the next line. (for a 2 line kernel)

I noticed there was another issue - your 2 kernels seem to position the players differently, causing them to flicker between frames. eg. Player0 isn't displayed on even frames, but not on odd frames. Moving player0y to a large value caused the situation to reverse itself - player0 on odd frames but not on even frames - so it's definitely the vertical positioning code.

[jbs30000]

RevEng, on Tue Jan 10, 2012 8:26 AM, said:

I'm not sure where the confusion is, but both A and B load data from (Player0PTR), which is initialized the same in both programs. The fact that they're displayed on odd or even lines doesn't change the data source.

Sorry, let me try to explain this way. The sprites are 8 lines high. Interlaced_C alternates between two frames. Frame 1 should be reading the even lines of sprites
line 2
line 4
line 6
line 8
and displaying the pixels on even numbered scanlines.
And frame 2 should be reading the odd lines and displaying them on odd scalines, so that the sprites interlace, and (with a lot of flickering ) appear to be solidly drawn.

This isn't a problem for the playfield. It does this just fine.

RevEng, on Tue Jan 10, 2012 8:26 AM, said:

This is because you're clearing them on half of the lines. Ditch the lines that store #0 in GRP0 and GRP1 in your kernel - remember that values stored in registers persist until you store another value in them. So if you set the player data on one line, you can skip it during the next line. (for a 2 line kernel)

Right. But this is an interlaced kernel. I'm clearing every other line because, as stated above, the even and odd numbered scanlines are supposed to interlace together.

RevEng, on Tue Jan 10, 2012 8:26 AM, said:

I noticed there was another issue - your 2 kernels seem to position the players differently, causing them to flicker between frames. eg. Player0 isn't displayed on even frames, but not on odd frames. Moving player0y to a large value caused the situation to reverse itself - player0 on odd frames but not on even frames - so it's definitely the vertical positioning code.

Sorry, I'm not quiet catching what you're saying. Would you mind explaining a little bit more? Thank you.

[jbs30000]

Oh, and I feel like an idiot now. Since I posted the source code, I should have also posted the playfield picture file
 TPic.asm   11.59K   11 downloads

[RevEng]

jbs30000, on Tue Jan 10, 2012 12:48 PM, said:

Sorry, let me try to explain this way. The sprites are 8 lines high. Interlaced_C alternates between two frames. Frame 1 should be reading the even lines of sprites
line 2
line 4
line 6
line 8
and displaying the pixels on even numbered scanlines.
And frame 2 should be reading the odd lines and displaying them on odd scalines, so that the sprites interlace, and (with a lot of flickering ) appear to be solidly drawn.

I guess I got hung up on the "why" one would do this with the players and not just the playfield, and assumed it was the problem you were after. Carry on.

jbs30000, on Tue Jan 10, 2012 12:48 PM, said:

Sorry, I'm not quiet catching what you're saying. Would you mind explaining a little bit more? Thank you.

If you enter the Stella debugger and advance one frame at a time, you'll see that the face only gets displayed on the even frames. And when you push down and wrap the Y position of the face from the bottom of the screen back to the top of the screen, you'll see it only on the odd frames.

Anyway, it turns out that you've setup your Player#SkipY values at the beginning of the first kernel (as you should), but you haven't done so at the beginning of the second kernel. Once you add this, you should get the interlacing you're looking for.

[jbs30000]

Thank you very much. I'll fix that and see what happens.