Interlace problem

[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.asmInterlaced_B.asmInterlaced_C.asm

Interlaced_A.asm.binInterlaced_B.asm.binInterlaced_C.asm.bin

Edited January 10, 2012 by jbs30000

[RevEng]

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.

 

 

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]

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.

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.

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

[RevEng]

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.

 

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.