Realistic Card Renderer

[stravant]

(Crossposted from the main forum, didn't see this section at first when I came here)

I'm interested in picking up implementing full realistic card rendering in XMage. I've already done some work on it, progress sample:

| Open

Progress Sample

And it doesn't seem too hard, but there's a lot of issues to address:

* Legality concerns: Are we allowed to render cards very similar magic cards at all in the program in the first place? (as long as we use no exact copies of parts of the cards, such as background textures / frame pieces etc)

* Should it be toggleable: Should it be possible to toggle between using card rendering and using the existing card images solution? And if so, how should that be implemented. (Extract a common CardPanel as a common base class and move the current JComponent based rendering and Detailed card rendering into two separate subclasses with some sort of global factory that reads the setting and creates the appropriate one at the usage sites?)

* Card Art - To get card images right now, I'm just using the existing card images and slicing a region out of the middle to use for the card art. This isn't ideal, since I still have to load all of the full images, and for things like Devoid cards, I can't get the full art that way (for rendering the transparent card frame), same thing for future sight cards (no nice square art region to cut out). Is there any way we could reasonably get the actual card arts to use? MTGO obviously has a folder with all of those images, but presumably we aren't allowed to just rehost those somewhere and use them.

* Card Face - Should we just render all of the cards in the same card face (The M15 frame, presumably), or do correct rendering of old border cards / future sight frames etc too, even though they aren't as clean / readable and harder to render nicely on a computer?

* "Changed" characteristics on cards. On MTGO, characteristics of a card that don't match the "base" characteristics of the card (for example, added abilities, or pumped power) are shown in a different color. This seems to be pretty tricky to implement at present, because it doesn't seem like the CardView has any access to the true underlying card. Is there some easy way to access that info that I'm missing?

* Currently I'm just using getRules() to get the rules for the card. But this requires some hacks like checking if the rule contains any spaces to tell if it's a Keyword ability or not. There's also other cools things I could do with a reference to the actual ability itself. How feasible would it be to give the card rendering actual references to the ability objects (not just textual through the view)?

* Caching strategy: The current ImageCache + "Key" struct approach gets a more tricky if extended to the full card rendering strategy. Basically the entire info about the card needs to be included as a Key, at which point hashing it isn't exactly trivial. It's still probably faster than re-rendering, but it's a bit awkward. Begs the question of if there's some way for the engine to tell the client when it thinks the card has changed rather than the renderer trying to figure it out.

* How to abbreviate things. Can the card's name be abbreviated to "~" when short on space? Not many people would know what it means, but they're probably reading the full card text in the popup anyways in that case and realizing shortly, so maybe it's fine?

* Rendering performance: Full card rendering will be a bit more expensive than the current approach. Is there any performance level that's mandated right now? Like, a number X of cards that should be able to render comfortably at once on the screen? Any suggestions on how I should be keeping track of performance to make sure it's fast enough?

* Fonts: What font to use? Are we allowed to package the Beleren font with the program to use for M15 card frames? What font for the body text? The actual font used on Magic cards, or one that's the most readable on small cards on a computer screen?

* Card rules syntax: What all syntax elements are there used in the card rules text? In doing the full rendering I'm doing a custom parse and layout of the rules text rather than just throwing it as-is into a JTextPane or something like that, but I'm not sure what all syntax is used. I've found {this}, italic and newline tags, and the mana symbols, and and tags like "mdash". Is there a full listing of what's used somewhere?

[escplan9]

Cross-commented from that same thread:

I'm not knowledgeable enough to answer most of these. We chatted on Gitter for a while about some of this as well. If it's overly complicated to try to make it toggleable to the point its preventing you from making any further progress, at this point I say to code as if it does not need to be toggleable. Hopefully if all goes well, it'll look polished and there won't be a reason to want to toggle it on/off. Ideally of course we get tests in for the areas where changes that need to be made, then refactor it for better reusability like this case, then test again. After that it'll be easier to make it toggleable. I don't see anyone going to this much labor over the task as likely though.

Also on legality issues, we talked about it. I think as long as we stay away from having the gameplay look the same as MTGO we should be in the clear. Not sure on the extent of the legal concerns for XMage as I haven't been working on the project long enough.

Paging LevelX2...

[emerald000]

* Legality concerns: Are we allowed to render cards very similar magic cards at all in the program in the first place? (as long as we use no exact copies of parts of the cards, such as background textures / frame pieces etc)

* Fonts: What font to use? Are we allowed to package the Beleren font with the program to use for M15 card frames? What font for the body text? The actual font used on Magic cards, or one that's the most readable on small cards on a computer screen?

No idea at all about the legality of it. I'm pretty sure the whole concept of xmage is disallowed, so I don't think it really matters in the end. PS: Not a lawyer or anything close to one.

* Should it be toggleable: Should it be possible to toggle between using card rendering and using the existing card images solution? And if so, how should that be implemented. (Extract a common CardPanel as a common base class and move the current JComponent based rendering and Detailed card rendering into two separate subclasses with some sort of global factory that reads the setting and creates the appropriate one at the usage sites?)

If we go that way, I really don't think it should be toggleable. If there is an issue with the display of something, fix it rather than making a cumbersome workaround.

* Card Art - To get card images right now, I'm just using the existing card images and slicing a region out of the middle to use for the card art. This isn't ideal, since I still have to load all of the full images, and for things like Devoid cards, I can't get the full art that way (for rendering the transparent card frame), same thing for future sight cards (no nice square art region to cut out). Is there any way we could reasonably get the actual card arts to use? MTGO obviously has a folder with all of those images, but presumably we aren't allowed to just rehost those somewhere and use them.

Image sources always has been a problem. The best way to go about it would be to create a totally separate website that would act as a magiccards.info replacement where we could fetch exactly what we need. That's a lot of work though.

* Card Face - Should we just render all of the cards in the same card face (The M15 frame, presumably), or do correct rendering of old border cards / future sight frames etc too, even though they aren't as clean / readable and harder to render nicely on a computer?

It would be nice to be able to render every card as they were printed, but as a first step, a single border type is fine.

* "Changed" characteristics on cards. On MTGO, characteristics of a card that don't match the "base" characteristics of the card (for example, added abilities, or pumped power) are shown in a different color. This seems to be pretty tricky to implement at present, because it doesn't seem like the CardView has any access to the true underlying card. Is there some easy way to access that info that I'm missing?

I sadly have no idea how the UI work, but there has to be a way to make it work. If you have access to the Game parameter, maybe you could find what you want in there?

* Currently I'm just using getRules() to get the rules for the card. But this requires some hacks like checking if the rule contains any spaces to tell if it's a Keyword ability or not. There's also other cools things I could do with a reference to the actual ability itself. How feasible would it be to give the card rendering actual references to the ability objects (not just textual through the view)?

Not sure I get what you are looking for. Technically, ability words should be added separately to the ability, but most of them do not.

* Caching strategy: The current ImageCache + "Key" struct approach gets a more tricky if extended to the full card rendering strategy. Basically the entire info about the card needs to be included as a Key, at which point hashing it isn't exactly trivial. It's still probably faster than re-rendering, but it's a bit awkward. Begs the question of if there's some way for the engine to tell the client when it thinks the card has changed rather than the renderer trying to figure it out.

No idea.

* How to abbreviate things. Can the card's name be abbreviated to "~" when short on space? Not many people would know what it means, but they're probably reading the full card text in the popup anyways in that case and realizing shortly, so maybe it's fine?

The main idea is to convey the most information possible in the small textbox. I feel like this is an appropriate concession.

* Rendering performance: Full card rendering will be a bit more expensive than the current approach. Is there any performance level that's mandated right now? Like, a number X of cards that should be able to render comfortably at once on the screen? Any suggestions on how I should be keeping track of performance to make sure it's fast enough?

There isn't much guideline about anything. As long as there isn't serious performance issues for most users, it shouldn't be a problem.

* Card rules syntax: What all syntax elements are there used in the card rules text? In doing the full rendering I'm doing a custom parse and layout of the rules text rather than just throwing it as-is into a JTextPane or something like that, but I'm not sure what all syntax is used. I've found {this}, italic and newline tags, and the mana symbols, and and tags like "mdash". Is there a full listing of what's used somewhere?

From what I know, there's {this}, the mana symbols, {source} (have yet to figure out what this one does). Otherwise, it is standard HTML.

[Fenhl]

I'm in favor of rendering everything in the M15 frame. Makes things look more consistent. It's also how Magic Duels does things.

[ShivaFang]

I'm in favour of this. It would make cards look a lot nicer if for some reason the art won't download/load.