[SpellWeavre]

All right, lesson learned: strings as makeshift arrays are a pain. So I rewrote the thing to use... I think... a decent approximation of Wervyn's and OldSckool's suggestions to this point, arrays and all. I think the 0-indexed thing is still hurting my brain, so I fully expect there's some error related to that in here.

. "put the deck graphics on the vlayer"
set "deck_x" to 0
set "deck_y" to 2
put "@Deck2.mzm" Image_file p02 at "deck_x" "deck_y"
. "define constants for deck: number of cards, number of ranks per suit, and card dimensions"
set "deck_size" to "(52-1)"
set "hand_size" to 0
set "card_ranks" to 13
set "card_width" to 10
set "card_height" to 9
. "sprites stack left to right, like cards fanned in hand"
set "spr_yorder" to 1
. "Initialize the deck"
loop start
set "deck_card&loopcount&" to "loopcount"
set "card&loopcount&_suit" to "('loopcount'/'card_ranks')"
set "card&loopcount&_rank" to "('loopcount'%'card_ranks'+1)"
set "spr&loopcount&_vlayer" to 1
set "spr&loopcount&_refx" to "('card_width'*('loopcount'%'card_ranks')+'deck_x')"
set "spr&loopcount&_refy" to "('card_height'*('loopcount'/'card_ranks')+'deck_y')"
set "spr&loopcount&_width" to "card_width"
set "spr&loopcount&_height" to "card_height"
loop for "deck_size"
end

: "keyd"
. "make sure we still have a card to retrieve"
if "deck_size" < 0 then "deckedout"
. "local = deck position of card we're about to pick up"
set "local" to random 0 to "deck_size"
. "add the card to the hand"
set "hand_card&hand_size&" to "deck_card&local&"
put c?? Sprite "hand_card&hand_size&" at "('hand_size'*2)" 0
inc "hand_size" by 1
. "remove the card from the deck"
set "deck_card&local&" to "deck_card&deck_size&"
dec "deck_size" by 1
end

: "deckedout"
* "No more cards to draw!"
end

Current problem: sprites still aren't stacking nicely. Cards seem to be picked just fine, but the display is a mess. Sometimes they fan perfectly for a few draws, and then spaz out. I need a "spr_xorder" instead of "spr_yorder"...

[SpellWeavre]

Gave up for the moment on proper sprite stacking, setting the x-increment for sprite placement to "card_width" so they just go side-by-side. Then ran a test where I taught it to wrap to the next line every 8 cards (thanks, guys, for the tip about modulo operations!), displayed the suit and rank from the "hand_card" array for each draw, and kept hitting "d" until every card was pulled. Flawless! 52 cards, no duplicates, and every card spat out the correct suit and rank.

OldSckool, why is it a good idea for the suits to be zero-indexed? It seems to me it'd be a little safer to go from 1 to 4 for a thing like that, since there's no distinction between 0 and null in MegaZeux. I'd always be nervous, if I checked for a thing's suit, that I got a 0 result for the wrong reason.

Next up for this project: instituting a discard pile. I might also begin the rudiments of UI, where the player clicks on the deck to draw a card, and clicks a card in hand to discard it. Beyond that I'll need to plan ahead a little more--what other operations I code will depend in part on just what the rules of the game itself will be. Things are going well enough and quickly enough (thanks so much to all who've patiently helped me!) that maybe I can aspire to turn this into a video poker game, something I initially thought would be out of scope! A near-term target for that would be making code to recognize sets and runs in the hand... I'd need to study up on sorting algorithms? o.O

I've not forgotten Project 2, by the way! I talked with a friend about it, and he suggested that a perfect scenario for this sort of thing would be a hostage crisis, where the player chooses the dialogue options for a negotiator. Will you be able to talk the hostage-taker down, or will it all end in blood and bullets? We'll collaborate on the writing for it, and if the one-shot demo goes well, we could expand it to a whole game about this negotiator protagonist and the escalating crises he or she faces. Could be cool, yes/no?

[Wervyn]

On the sprite-sorting thing, the best way I can think of to do this is with what I call the "y-order hack". Basically, as you've heard, set "spr_yorder" to 1 causes all sprites to be sorted by their y position on the screen instead of their ID. The trick is that it's not actually their visual position being used to sort, but the position of their collision rectangle. That is, not simply spr#_y, but spr#_y + spr#_cy. This means you can modify spr#_cy for each sprite to change their display order, as long as you don't care about those sprites colliding when they run into each other. Since having sprites overlap and having sprites collide are usually mutually exclusive goals, you're generally in a position to pull this off. It's a bit tricky to get right, though.

For your case, I imagine you have all of the sprites in a horizontal hand. Further, you should probably have a way to tell which sprite is in each position in the hand, otherwise I don't know how you're getting them there to begin with. These positions are numerically 0-4, or maybe 1-5 if you're still attached to that, but either way, in this configuration the y-order trick is as simple as setting the _cy value for each sprite in the hand, to its position in the hand. That way, even though they're in a horizontal row display wise, they behave as if they're in a vertical row overlap wise.

Note that this means the right-most card will appear on the top of the stack (assuming your positions are numbered from left to right). If you want it to work the other way, set each _cy to negative hand position instead. Also be aware that this is fairly implementation specific, and you will still have to pay attention to displaying anything else on the screen to be sure it doesn't conflict with this display method. For instance, if you have a system set up where the user can drag a card around with the mouse, it makes sense to always have that card draw on top, so you should temporarily set its _cy value to 127. I have asked for this value cap to be increased many times for exactly this purpose, but it still hasn't been changed.

On value sorting, depending on the size of the hand this won't be a big deal no matter what method you use. But you're right that the best way to check for both sets and runs is to sort the hand by value. A poker straight has all values in the hand consecutive (though be sure to catch the special case for 1, 10, 11, 12, 13), and an N-of-a-kind set has N cards of the same value right next to each other. These traits are easy to discern when the hand is sorted.

"Quicksort to the rescue!"

[SpellWeavre]

Wervyn, on 08 May 2010 - 10:10 AM, said:

For your case, I imagine you have all of the sprites in a horizontal hand. Further, you should probably have a way to tell which sprite is in each position in the hand, otherwise I don't know how you're getting them there to begin with. These positions are numerically 0-4, or maybe 1-5 if you're still attached to that, but either way, in this configuration the y-order trick is as simple as setting the _cy value for each sprite in the hand, to its position in the hand. That way, even though they're in a horizontal row display wise, they behave as if they're in a vertical row overlap wise. Note that this means the right-most card will appear on the top of the stack (assuming your positions are numbered from left to right).

Yeah, the hand is now an array, with "hand_cardN" holding the sprite ID, which is also the card ID from 0-51. I'm using 0-indexes like a good boy, except for the suits and ranks, since I didn't see the utility there (but it'd be as simple as deleting a "+1" from two lines of the deck initialization routine to make those go 0-3 and 0-12 instead of 1-4 and 1-13). I'll try setting the _cy value--I actually thought of that once I reread the documentation on spr_yorder, and tried it once to no effect. I must have had something wrong in the expression.

This post has been edited by SpellWeavre: 08 May 2010 - 03:34 PM

[SpellWeavre]

Ah! Got it. I had to use a temporary local variable to get my expression for setting sprN_cy to work, but it's straightened out. Only remaining problem with the display: transparency issues. The card edges frequently end up ugly where they overlap: see attached screenshot. Is it just c00 that gets treated like this, or any black color? If it's just c00, I could probably retool the MZM with fairly little effort (doing it programmatically even!).

Attached thumbnail(s)

• 

[Old-Sckool]

Yes, any part of the sprite that either has the color c0? or is Char 32 is transparent, regardless of what the palette colors are

[Wervyn]

To clarify a bit, any overlay or sprite character 32 is transparent, regardless of color. Any overlay or sprite color c0? will have the background color replaced by the background color of whatever is "below" it on the board. The quickest way to fix this in your MZM is to invert the colors and characters used for the borders of the cards, so that the border becomes cf0 instead of c0f. This way, no color will bleed through. Since most of the border is just the standard horizontal and vertical halfchars, you can just switch to the opposite characters to flip the colors. For the corner pieces, you will have to invert the character, but you weren't using those for anything else anyway.

"Drink your ovaltine."

[SpellWeavre]

Not a lot of progress this weekend, but it's still coming along. Cleaned up the transparency issue with the sprites, per Wervyn's suggestion. For a video poker thing I might not end up having them overlap much anyway, but it will be useful for other projects using the engine, or if I do any animations, that sort of thing.

Need to poke my collaborator on Project 2, I haven't heard from him since the initial brainstorm. I'll have a chance to talk with him in person on Wednesday.