Collectible Card Game Headquarters

that worked perfectly..thanks!

@Korath - Been struggling with the card art alignment with the single black pixel outline in the large card.

When the outline is drawn it sometimes appears a pixel within the bottom outside edge of the card art. And although its possible to adjust it out so it lines up with the edge of the picture. I can find a setting to correct it in both the deck builder and the duel screen simultaneously. A single point of adjustment to the ArtHeight corrects it in one, throws it out in the other. I've tried shifting the pic vertically using ArtTop, and then resizing the height - but still to no avail.

If you do have a trick to help for the next update... I'll just adjust if for the deck builder for the moment.

I see what you mean. Looks like a difference of opinion between GDI (how I draw the outline) and GDI+ (how Cardartlib draws the main art image), even though they're given identical coordinates. I'll see if drawing it through GDI+ helps any.
---
One is annoyed.If anything, the GDI+ version should be further inward than GDI - Cardartlib has an off-by-one error, using rect.right - rect.left instead rect.right - rect.left + 1 for width (and similar for height), which I'm doing to match.

Had fun with the TranslucentColorless option. You had warned me my little trick of using the text box behind the small card art to maintain the original cards textured background along the sides and the bottom edge of the small card wouldn’t work with the overlays.
So, new trick required.

TitleSourceTop = 7
TitleSourceHeight = 160
TitleDestHeight = 1078
FrameSourceTop = 438
FrameSourceHeight = 10
FrameDestTop = 1078

Expand the title source to include part of the cardart box and border, then stretch it so it aligns with the bottom of the small card art. The remaining section is then completed with the bottom of the template art cropped just inside the lower border of the text box to complete the lower horizontal colored border of small card art frame.
It works OK on everything apart from on the land cards. Because of the large section effectively being cropped out from about halfway down the templates artwork box to a few pixels inside the lower text box border, there's quite a noticeable contrast change in the background card texture on the left where the two sections meet at the bottom of the small card. It shows fractionally on the gold, but it’s neigh on invisible in everything else.



I did make a small mistake with the original colorless overlay. I hadn’t made allowances for the fact the overlay would be composited over the artwork rather than behind it in translucent mode. And forgot the frame would need a transparent box inside the border where the black card background originally was. All the other overlays are entirely filled the border color behind the artwork at the moment.

Your original trick should work if you set option 4 in TranslucentOverlay, which I added to fix it. That'll draw the art over the whole card, then draw the rules box over it, then draw the art over the rules box again.

Korath wrote:Your original trick should work if you set option 4 in TranslucentOverlay, which I added to fix it. That'll draw the art over the whole card, then draw the rules box over it, then draw the art over the rules box again.

Been playing with option 4. Personally I think Option 1 with the card art in the large card at normal size looks best.
I think what I'll do is keep the new small card setup for the moment - at least that way the guys aren't limited to only using Option 4 and can experiment themselves with the other 2 options.

They're combinable (which is why there's no 3) - 5 will draw the art in its normal place on fullcards and redraw the art over the rules box in smallcards.

Done any experimenting with a partially-transparent CardOv_Colorless yet?

Yeah, just gave it a bash.

Looks well trick. Although, I think I've discovered what you meant by 'impractical' in the bug fix thread. It drags the card redraw speed down quite noticeably. Plus it would need separate full artwork for the cards to really do it justice.

Gonna stick with the new small card trick. The hybrids gradient looks better with a slightly thicker colored border in the small card. Using the old small card setup, in making the card art smaller to achieve the effect this then exposes the black drop shadow on the inside of the text box.

This stuff is getting more and more kickass as the time passes !
Have you decided something about the stuff we discussed via e-mail ?

i agree man lots of cool stuff that i never thought would happen in this great game..

I don't need a decision on types7 for a while yet, since A) planeswalkers/planes/avatars/schemes can be found by inspecting values already in the other subtype fields; B) classic frames can be determined through expansion, and C) watermarks can be transferred in from watermarks.csv at any time.

It'll probably turn out to be the right solution for planeshifted, tombstone, miracle, and transform cards; of those, miracle cards are low priority, and planeshifted and transform cards will need support for complete multiple-frame types first (so not until classic and planeswalker frames are done, which is a significant chunk of work). The tombstones for flashback and Anger etc. are an easy, independent issue, and would be nice to have, though.

Korath wrote:I don't need a decision on types7 for a while yet, since A) planeswalkers/planes/avatars/schemes can be found by inspecting values already in the other subtype fields; B) classic frames can be determined through expansion, and C) watermarks can be transferred in from watermarks.csv at any time.

It'll probably turn out to be the right solution for planeshifted, tombstone, miracle, and transform cards; of those, miracle cards are low priority, and planeshifted and transform cards will need support for complete multiple-frame types first (so not until classic and planeswalker frames are done, which is a significant chunk of work). The tombstones for flashback and Anger etc. are an easy, independent issue, and would be nice to have, though.

Personally, I think the decision on Types7 is entirely yours. As gargaroz confirmed, the data for that field is open for development and doesn't affect any of the current coding. I'd assume the csv2dat.exe includes the data for the currently blank field in the rarity.dat file - so that shouldn't be an issue. Although, we've had problems in the past with the csv2dat.exe baulking when we've tried to play outside the remit of the current types codes - so this would probably need investigating.

From a data entry point, it's just the form of any new code, say 9xxxh for example (with note to the csv2dat issue above), and to establish how to generate the new field data for Type7 from that existing currently in the manalink file.

Maybe a stupid question - but you do have Mok's srcmok.rar archive with his source files for the csv2dat.exe and a number of other stuff he did before he left?

Yes; I found srcmok in one of the old patches - after getting about a third of the way through working from a straight disassembly of drawcardlib.dll, it occurred to me it must have been rewritten by someone already at least once, if for no other reason than the colored artifacts' frames.

There's two places that look at types7 in C (has_new_types() in functions/has_creature_type.c and is_aura in functions/functions.c) and one in drawcardlib/drawcardlib.c (DrawFullCard(), to see whether a card with type artifact is an artifact creature and so should get power/toughness numbers drawn). Those are trivial fixes (minutes). There's almost certainly a couple in deck.dll (filtering for artifact creatures, and filtering by power or toughness), which'll be a little harder (hours). Guaranteeing csv2dat will accept anything we give it for this value will take several hours to a day. Making absolutely sure that Mok didn't make anything in the exe look at types7 at the same time he widened the structure will take two or three days minimum. Trying to skimp on these last couple is just as likely to cost even more time in the long run, in the form of weird, apparently-unrelated bugs.

So we're looking at a week of work to make that practical; I want to get through some of the other things I've already committed to doing first.

I've been over some of Mok's old posts and found something which maybe useful:

The new types are a simple conversion of the type line into values from stypes.h from src directory (just open the file and use it to get the values for each word in type line). I see now that Gargaroz extended them somewhat which I consider not really a good idea as it was planned to only use official types from current rules but I don't really care as to be honest the fields won't be useful too much. They won't work with any type changes without major changes in the exe that will likely never happen. So the fields can be used (maybe) in C code that checks types on original/unchanged card but any effects that change card sub/type won't be correct as the data is read-only.

I don't know how much this helps, but the part which I found a bit disturbing is:

"They won't work with any type changes without major changes in the exe"

As we'd assumed it was only the csv2dat.exe that was preventing us expanding on the codes.

Korath, I removed the check from "new_types7" in the subtype check code.