Collectible Card Game Headquarters

slapshot5 wrote:I think we have a skinning problem on Mac OS X (Snow Leopard at least. Chris would have to check Lion). Here is what I see in the WinLoseFrame:

Screen shot 2011-10-08 at 5.04.35 AM.png

It looks fine for me on X11 running on FreeBSD. Haven't checked Windows, but I assume it looks fine there.

-slapshot5

Edit: I already fixed the sizing issue, but the problem I meant to describe was the lack of visible text or graphics on the buttons.

`
I see the same thing on Mac OS X Lion. At the end of now game it looked like a button had text inside of one of the buttons ... but the text was an almost white color on a white color background and was not very visible. But I may have been seeing things.

I have gui.skin=default in forge.preferences, but it is still using the Yoda splash.

Thanks, fixed r11028. This is the fallout from

For some reason I couldn't upload the other fonts and images of the theme so it may not work right yet, but that problem will sort itself out soon enough.

There's something missing between my understanding of Subclipse and what Subclipse actually is doing.

Update Ahh, it's "Add to version control" that I was missing. That will clear up a few things!

=====

About the other issue, I don't have access to a Mac box so sorry can't help very much...but the error is apparently coming from FButton in forge.gui.skin. It can't find the resources defined in FSkin (also in forge.gui.skin)...

On Mac OS X Lion the progress bar for the startup screen is not fully overlapping the image:

`

Chris H. wrote:On Mac OS X Lion the progress bar for the startup screen is not fully overlapping the image:

That's a graphics issue only; ideally all splash screens will have an empty space at the bottom for the load bar, which soon will mimic the colors in the skin.

That screen's text is rastered into the image, so I couldn't change it quickly. Functionality was the goal.

I have gui.skin=default in forge.preferences, but it is still using the Yoda splash.

The "Rebel" skin should be available now in r11029. Thanks for the testing support. Time for bed, back in the mornin'.

Doublestrike wrote:

Chris H. wrote:On Mac OS X Lion the progress bar for the startup screen is not fully overlapping the image:

That's a graphics issue only; ideally all splash screens will have an empty space at the bottom for the load bar, which soon will mimic the colors in the skin.

That screen's text is rastered into the image, so I couldn't change it quickly. Functionality was the goal.

As soon as I'm finished with my system maintenance I'll post the non-mockup graphic. At least I can still follow things here from my phone...

Here's an interesting update to the Mac OS X skinning problem:

After losing 2 games (on purpose, c'mon), the disabled version of the Continue button looks good.



-slapshot5

Hey Doublestrike,

What are you planning on doing about the Input boxes? They've been a struggle to work with for a year and a half now. It sounds like they are going to disappear mostly, but are they still going to be used for certain things? Or are they being completely replaced?

Apologies ahead of time for the huge post - got started and couldn't stop!

friarsol wrote:What are you planning on doing about the Input boxes? They've been a struggle to work with for a year and a half now.

Interpretation 1
Do you mean the "Input", "Stack", and "Combat" areas? The input will remain, since it's important for yes/no/ok/cancel stuff. The stack and combat areas are placed in a vertical tabber with some other non-critical-but-still-important elements. This tabber has six tabs at present: Stack, Combat, Console, Player information (for multiplayer), Map (also for multiplayer), and Dev Mode. When new input is delivered to any of these areas, the tab will show itself and highlight the new information.

Interpretation 2
If you mean the phase marker checkbox inputs in the menu, there's a graphical phase monitor/toggle area with each player field.

Interpretation 3
If you want them gone altogether, this can happen too, but later. Right now, I'm building an MVC architecture for the entire UI, which encompasses the whole operation in a single JFrame with a top-level controller for each display state (home, match, deck editor, Shandalar, etc.) and child controllers for various components (player fields, user hand, input area, etc.)

The current codebase is fairly well split between model and view, but view controllers are mixed in with the swing, resulting in convoluted piles of enormous undocumented files 1500 lines long. Hellish to work with and debug. So, soon enough, the "input boxes" of which you speak can be easily sliced out of control and view, if that is the goal.

In other news...
While I'm writing this long post, I might as well mention the UI structure for multiplayer will be in place when people need it. I've got a standard playing field for each player, one of whom is the user, with mana, keywords, and card management info visible, and a controller to access each field (or global control from the top level). Any number of these fields can be instantiated as necessary, and a scrolling/jumping functionality can be added to the battlefield to move around the fields (visible on the Map tab, summarized in the Player Info tab).

Also, toying with the idea of having a tabber in the hand area, allowing the user to see the hands of teammates, but this would happen much, much later.

Documentation whinge
Also, could I make a general request for better documentation, specifically, please explain what the heck a method does. For example, I'll be on line 1234, looking at

Code: Select all

new VeryImportantSomething.VagueCriticalAction(); // critical for game operation - don't screw this up

and hover for more information about this class, only to get

Code: Select all

<b>VeryImportantSomething().</b> The VeryImportantSomething class.

and

Code: Select all

<b>VagueCriticalAction</b> Does vague critical actions.

which usually means I frown, curse under my breath, kick my dog, and start a hunt to find what's so important, which instance it's using (arcane? forge? a different package?), why it's child code is important, blah blah blah. Anyway, the final result is obfuscated code, which sucks for the next guy... </complain>

(I don't really kick my dog, that was just an instance of DramaticLicense.)

CardPrinted?
A quick question too: I'm using instances of Card whenever a card is displayed. Should I be using CardPrinted since it's lighter?

Arcane?
Could someone fill me in on the history and future of the Arcane packages? What it looks like to me is that the Forge and Arcane packages hold old stuff, waiting to be transitioned into the multiple package structure endorsed by Maven. What's the deal there?

Incidentally, as I go, I'll be phasing out the UI parts of these packages, in favor of the architecture described above, and a more unified organization.

Lowest screen resolution?
The UI fully supports resizing, tested for resolutions down to a minimumSize of 800W x 600H. If someone needs lower, or for vertically-oriented screens, shout it out and I'll work it in now.

Screenshot?
When I have enough progress on the graphical side, I'll post a screenshot. Right now still in the code trenches.

I was talking about Input (and InputControl) specifically. I'd love to see them completely removed/upgraded to something appropriate once the time is right. It's going to be a fairly big workpiece in it's own right, just wanted you to keep it on your radar since it's related to all this (and it sounds like it already is).

As far as the documentation goes, Braids and Dave were trying to add javadocs incrementally. In the cases of the code you are looking at, most of this stuff just hasn't been touched in forever, and whoever originally did it is no longer active, so I wouldn't hold your breath. We can do a better job at the parts we are currently coding up to improve documentation.

friarsol wrote:I was talking about Input (and InputControl) specifically. I'd love to see them completely removed/upgraded to something appropriate once the time is right

Ahh, the ol' forge.gui.input package. That looks to me like "model" type stuff, setting up match flow and whatnot. I'm trying very hard to keep my grubby fingers off all of that core functionality stuff. My job description mostly involves view and control, which will be ready for any slicing and dicing.

Doublestrike wrote:About the other issue, I don't have access to a Mac box so sorry can't help very much...but the error is apparently coming from FButton in forge.gui.skin. It can't find the resources defined in FSkin (also in forge.gui.skin)...

I don't think that's what is going on. If I create a AlphaComposite and specifically assign it to enabled, the buttons become somewhat readable:

Code: Select all

private AlphaComposite enabledComposite = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.75f);

For the record, saying I know *nothing* about this graphics stuff would be overstating my knowledge. I don't know what the rule or the alpha params do or what to expect when I tweak them. If anyone has thoughts, I'll gladly test them on my Mac.

-slapshot5

slapshot5 wrote:If I create a AlphaComposite and specifically assign it to enabled, the buttons become somewhat readable:

Code: Select all

private AlphaComposite enabledComposite = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.75f);

Oooh that's a good clue. Alpha composite is the transparency of the button. It's dropped down to 25% for disabled buttons. Maybe the buttons aren't showing because a composite isn't defined for them...so your code would work, but should use 100% opacity (1.0f).

From that clue, could you try this - in the inits section:

Code: Select all

private AlphaComposite disabledComposite =
            AlphaComposite.getInstance(AlphaComposite.SRC_OVER,0.25f);
private AlphaComposite defaultComposite =
            AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1.0f);

In the paintComponent override:

Code: Select all

if(!isEnabled()) {
    g2d.setComposite(disabledComposite);
}
else {
    g2d.setComposite(defaultComposite);
}

Doublestrike wrote:CardPrinted?
A quick question too: I'm using instances of Card whenever a card is displayed. Should I be using CardPrinted since it's lighter?

I think that the Card object is the way to go.CardPrinted is for the deckeditors that don't need the ingame things that Card provides like pumped keywords,current PT (After static effects) and such.

Hellfish wrote:

Doublestrike wrote:CardPrinted?
A quick question too: I'm using instances of Card whenever a card is displayed. Should I be using CardPrinted since it's lighter?

I think that the Card object is the way to go.CardPrinted is for the deckeditors that don't need the ingame things that Card provides like pumped keywords,current PT (After static effects) and such.

THEORETICALLY, the heavy Card object should only exist while in the card game - in a game zone, ie battlefield, library, exile, etc. SO it may be required for the card game UI to use the Card object.