HMOVE intricacies

[supercat]

I'm trying to code a SuperCharger kernel to show 13 playing cards in a row (flickerless venetian blinds). Everything is gorgeous except that I can't get the second playing card at exactly the right spot--it's one pixel left or two pixels right of where it should be. The left most card would have been similarly mispositioned except that I was able to time the RESPx to position it two pixels to the right of target and then use a cycle-74 HMOVE to shove it back with no "HMOVE bar" at the left. Since the HMOVE operation itself doesn't occur until noticeably into the horizontal blanking interval, is there any way on a real 2600 to get the second playing card positioned where it should be (16 pixels from screen left)? In Z26, the HMOVE seems to take effect immediately while on a real 2600 it doesn't; would an RESPx immediately after a cycle-74 HMOVE leave the 'moving' latch enabled on a real 2600, or would it clear it?

 

If worst comes to worst, I could limit myself to using the left 7 pixels of each playing card icon and right-shift the data for the second card. This would work fine for the card labels (though I would prefer to have all eight pixels available) but the smaller specialized kernel I use for the card suits would not support such a technique (at least not with any opcodes I know of).

 

Incidentally, like real playing cards, these ones come in red and black lettering on white card faces; the background between the cards is green. It will be possible for red and black cards to be freely mixed in any order. The alphanumeric kernel requires about 1/3 page per pair of scan lines; the suits kernel requires 2/3 page total for all seven. Using both, it should be possible to implement a game like Montana solitaire (four rows of cards) using 3K for the card kernels. An alternative would be to use 12 double-scan-lines per card (with a blank row added after the 7th) in which case the kernels would take 4K and the suits wouldn't look as nice.

 

I'll probably be posting some code after I get things a little nicer.

Edited August 15, 2005 by supercat

[Thomas Jentzsch]

Yes, some commented and timed code would be much easier to understand. At least for me.

[SeaGtGruff]

I'm trying to code a SuperCharger kernel to show 13 playing cards in a row (flickerless venetian blinds).  Everything is gorgeous except that I can't get the second playing card at exactly the right spot--it's one pixel left or two pixels right of where it should be.  The left most card would have been similarly mispositioned except that I was able to time the RESPx to position it two pixels to the right of target and then use a cycle-74 HMOVE to shove it back with no "HMOVE bar" at the left.  Since the HMOVE operation itself doesn't occur until noticeably into the horizontal blanking interval, is there any way on a real 2600 to get the second playing card positioned where it should be (16 pixels from screen left)?

[...]

I'll probably be posting some code after I get things a little nicer.

911432[/snapback]

 

If I'm picturing this correctly in my head, you're trying to get 4 blank pixels on the left side of the screen, then an 8-pixel card, then 4 blank pixels, then another card, etc., with a total of 13 cards across the screen, each one being separated from the others-- and from the screen edges-- by 4 pixels. Is that right?

 

4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4+8+4

= 12x13+4 = 156+4 = 160 pixels

 

If you can get that to work, I'd like to use it in my humongous adventure game, for text messages!

 

I know you want to "get things a little nicer" before you post some code, but can you post the main loop now? I might be able to help if I can see what you're doing.

 

Michael Rideout

[SeaGtGruff]

I know you want to "get things a little nicer" before you post some code, but can you post the main loop now? I might be able to help if I can see what you're doing.

 

Michael Rideout

914231[/snapback]

 

supercat, thanks for letting me check out your code. I'm replying here because it might be helpful to others, so I hope you don't mind.

 

First of all, I haven't examined your code closely (because I'm not used to reading assembly code with a lot of macros in it-- something I should probably start doing myself), but it was very helpful to see the code in action.

 

The other night I had tried playing around with RESP0 myself, before I saw your code, and I noticed that it can be quirky when used to put many copies of a player on the screen. So I don't know if it's possible to adjust the timing to get the second card positioned correctly, without destroying the positioning of the other cards in the process.

 

So let's assume for now that it can't be done. The next question is, how might you work around it?

 

One idea would be to reduce the width of the numbers to 7 pixels, which I think you had mentioned. The suits are fine, it's only a problem with the numbers, so that might be okay.

 

But another idea-- which would require some recoding, and might be tricky to pull off-- would be to use a missile for the rightmost pixels of card two. You would need to have a second table for the numbers/letters and suit symbols for card two, or else just load the normal player value and then shift it right for that card. In other words, bits 0 through 6 of the player would be pixels 1 through 7 of the card, and a missile would be used to get pixel 0 of the card, if you see what I mean. I don't know if it would be too difficult to accomplish in a tightly-timed loop, because you'd have to turn the missile bit on or off. You're SLEEPing for several cycles anyway, so you could do it then; but if you're using multiple copies of the player, doesn't it also create multiple copies of the missile? However, if you're using only one player on each scan line (isn't that what you're doing?), you could use the other player's missile for that scan line if need be, so that you can display just one copy of it.

 

Does that make sense?

 

Michael Rideout

[supercat]

One idea would be to reduce the width of the numbers to 7 pixels, which I think you had mentioned. The suits are fine, it's only a problem with the numbers, so that might be okay.

 

Well, the suits are seven pixels wide already, but having the second card's suit shifted is a bit ugly. It may be possible to fix the second card's suit to line up with the rest, but since the suits use special code that takes advantage of the fact that there are only three shapes on a line, it may be trickier (three shapes, not four, because the top halves of spades and diamonds are identical, and the bottom halves of hearts and diamonds are identical).

 

But another idea-- which would require some recoding, and might be tricky to pull off-- would be to use a missile for the rightmost pixels of card two.

 

If the ball were available to be colored to match the column-two card, that would be a good approach. Unfortunately, the playfield color is already being used for something else. Missiles have the problem that they're duplicated like players (one of my retrospective wish-list items for the TIA would be an extra bit in the NUSIZ register which would 'unclone' the missiles). Even though the first copy of a player doesn't show up following a RESPx, unless I RESMx the missile every line (for which there's no time) I'd be hosed.

On the other hand, if I set the priority register so the playfield shows up in front of the player, I could position things so that the playfield covered up the extra copy of the missile.