Collectible Card Game Headquarters

friarsol wrote:Hey Dan,

I noticed the new filters don't save their state when closing and returning to them. Was this intentional? It was a bit surprising to me the first time I had to refilter the Card Shop as I got used to not needing to do it in the middle of a session.

That's only because I haven't implemented filter saving yet. It's on my TODO list.

By the way, the new FDialog is definitly still an issue on Linux, not sure what's up but it doesn't work on either of my Linux installations...

- Agetian

drdev wrote:Looks like setShape is not currently supported on Mac: http://stackoverflow.com/questions/8472273/java-code-does-not-work-on-mac-os-x

I just committed a fix (r24039) to surround the setShape call in a try/catch block. That way the dialog's corners won't extend beyond the rounded border on any OS that supports setShape, such as Windows (not sure about Linux). For Mac, the background and titlebar will just have to extend slightly beyond the rounded border, but that shouldn't look too bad. If it does look bad, let me know and I'll update the code to show a non-rounded border on Mac.

Thanks for letting me know about the crash.

EDIT: Committed a tweak to the fix in r24040 to avoid a try/catch block after reading this article about the use of setShape: http://docs.oracle.com/javase/tutorial/ ... ndows.html

 
updated to rev 24040 and I still get the crash:

UnsupportedOperationException | Open

Code: Select all

Forge Version:    SVN
Operating System: Mac OS X 10.7.5 x86_64
Java Version:     1.7.0_21 Oracle Corporation

java.lang.UnsupportedOperationException: PERPIXEL_TRANSPARENT translucency is not supported.
   at java.awt.Window.setShape(Window.java:3692)
   at java.awt.Dialog.setShape(Dialog.java:1344)
   at forge.view.FDialog.paint(FDialog.java:75)
   at javax.swing.RepaintManager$3.run(RepaintManager.java:807)
   at javax.swing.RepaintManager$3.run(RepaintManager.java:784)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:784)
   at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:757)
   at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:706)
   at javax.swing.RepaintManager.access$1000(RepaintManager.java:62)
   at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1651)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:688)
   at java.awt.EventQueue$3.run(EventQueue.java:686)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:154)
   at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:182)
   at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:221)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:219)
   at java.awt.Dialog.show(Dialog.java:1082)
   at java.awt.Component.show(Component.java:1651)
   at java.awt.Component.setVisible(Component.java:1603)
   at java.awt.Window.setVisible(Window.java:1014)
   at java.awt.Dialog.setVisible(Dialog.java:1005)
   at forge.view.FDialog.setVisible(FDialog.java:107)
   at forge.gui.deckeditor.controllers.CCurrentDeck.importDeck(CCurrentDeck.java:126)
   at forge.gui.deckeditor.controllers.CCurrentDeck.access$6(CCurrentDeck.java:120)
   at forge.gui.deckeditor.controllers.CCurrentDeck$8.run(CCurrentDeck.java:111)
   at forge.gui.toolbox.FLabel._doMouseAction(FLabel.java:311)
   at forge.gui.toolbox.FLabel.access$4(FLabel.java:308)
   at forge.gui.toolbox.FLabel$4.onLeftClick(FLabel.java:353)
   at forge.gui.toolbox.FMouseAdapter.mouseReleased(FMouseAdapter.java:184)
   at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
   at java.awt.Component.processMouseEvent(Component.java:6505)
   at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
   at java.awt.Component.processEvent(Component.java:6270)
   at java.awt.Container.processEvent(Container.java:2229)
   at java.awt.Component.dispatchEventImpl(Component.java:4861)
   at java.awt.Container.dispatchEventImpl(Container.java:2287)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
   at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
   at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
   at java.awt.Container.dispatchEventImpl(Container.java:2273)
   at java.awt.Window.dispatchEventImpl(Window.java:2719)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:688)
   at java.awt.EventQueue$3.run(EventQueue.java:686)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
   at java.awt.EventQueue$4.run(EventQueue.java:702)
   at java.awt.EventQueue$4.run(EventQueue.java:700)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


Oops. I checked for PERPIXEL_TRANSLUCENT instead of PERPIXEL_TRANSPARENT. It should be fixed now in r24041.

drdev wrote:Oops. I checked for PERPIXEL_TRANSLUCENT instead of PERPIXEL_TRANSPARENT. It should be fixed now in r24041.

 
Thank you Dan.

Rev 24041 does not crash and it looks good:
 

Chris H. wrote:

drdev wrote:Oops. I checked for PERPIXEL_TRANSLUCENT instead of PERPIXEL_TRANSPARENT. It should be fixed now in r24041.

 
Thank you Dan.

Rev 24041 does not crash and it looks good:
 

Good to hear. Will somebody let me know if Linux is fixed too?

No, Linux issues are not fixed - moreover, they've gotten worse with the latest changes, now not only the sideboard window is screwed like it was before, but also the "quit Forge" and many other dialogs are screwed in the same fashion (I think it's simply due to the fact that these dialogs now use the new FDialog though). Moreover, it's impossible to even see many buttons unless you hover the mouse over them... I can't say the game is completely unplayable, but it's visually screwed and its playability is hampered by non-visible buttons in some windows Something has to be done with this issue, it's almost a dealbreaker for an upcoming beta release. Wish I could help, but I have no experience with the GUI functionality you're implementing, so I'm probably not the best person for that - the best I can do, I guess, is test for you and tell you if anything changes for the better or for worse...

Some examples of screwed up windows:

Quit Forge - usable, but visually screwed:


Concede - usable, but visually screwed:


Sideboard - fubar, not too usable until some mouse motions are performed over the buttons area:


P.S. I like the idea of the new skinned look very much. Wish it was actually usable and not glitchy under Linux, it looks beautiful otherwise.

- Agetian

Dan, have you tried setting the corners back to square to see if that has anything to do with the issues on linux? I'm honestly just guessing without any kind of knowledge to back it, but as it is one of the changes, it might be worth testing.

drdev wrote:That's why I used the HashMap as you had suggested back when I did the Workshop and we went through this for CardScriptInfo. I admittedly didn't considered adding another module, however at this point I will wait to do so until these new preferences would need to be referenced by the Android module.

The main problem was changing the core classes interface (there emerged some new methods to fetch user preferences from the very cards)

drdev wrote:Is there a document or wiki out there that describes what should go where in this new module structure? If not, might I suggest one be created. That would provide a good reference for me and other developers to make sure we're not putting code in the wrong place in the future.

Was discussed as far as I remember.
Core is the minimal set of classes to build deckeditor and/or trade cards between players (or just manage assets that persist trough games)

Game and AI are not set in stone yet. Game is to hold all data needed to simulate a game (or maybe the whole match?) with variants included but without quest specifics. AI should contain all code used to make decisions by computer... don't know how to reach that yet, since AI thinking code is interleaved with game state changes... with its rollback in some cases (such as mana payment).
AI is to be decoupled from game a bit later (yes, I hope to extract the game+ai part into a single module first)
Will try to keep the minimal needed set of classes in each of those modules.

drdev wrote:For now, I'll just stay out of forge-core, forge-game, and forge-ai if possible, and run any changes by you if I would need to make any. I'm really not trying to make your job more difficult. I respect your dedication to keeping the code organized and paving a path towards network play and now mobile support with this modularization project.

Thanks!

Agetian, can you see if the Linux FDialog paint issue is fixed in r24052. I moved the setShape call out of paint and into a resize handler, which I'm hoping will fix it. Even if it doesn't fix it, it performs better this way, and we can rule out one possible cause.

I'm glad to hear you like the new look otherwise.

r24052: Nope, still no go - the same visual artifacts as before...

- Agetian

Agetian wrote:r24052: Nope, still no go - the same visual artifacts as before...

- Agetian

Ok, I temporarily commented out the custom paint code for FDialog in r24055 (which removes the rounded border but leaves the dialog with a rounded rectangle shape). Can you please update to that revision and see if you still see visual artifacts?

Note that I immediately committed the borders back in r24056, so don't update to the head revision.

Thanks.
-Dan

r24055: Looks fine, no visual artifacts. The only problem is that dialogs have no visual borders with this setup, so they blend a bit with the main window, but there is no "static" like in the previous builds, and the windows are fully usable (the buttons are not covered by weird stuff).

- Agetian

Agetian wrote:r24055: Looks fine, no visual artifacts. The only problem is that dialogs have no visual borders with this setup, so they blend a bit with the main window, but there is no "static" like in the previous builds, and the windows are fully usable (the buttons are not covered by weird stuff).

- Agetian

Good, that was the problem then. Thanks for checking into that.

Based on that, it seems clear that overriding paint doesn't work for Window objects on Linux. I'll have to find a different way to display the rounded border that will work on Windows and Linux, and if it's possible, I'll see if I can get it working on Mac too. Stay tuned.

No problem at all! By the way, not sure if you're going to find it relevant, but I think the culprit on Linux is exactly the drawRoundRect call - leaving the Paint method in FDialog overridden but substituting drawRoundRect with drawRect (like you do on systems that don't support setShape) seems to cause no static to appear (but the border looks weird because it doesn't match the shape of the window, which makes the corners appear off).

- Agetian