Forge version 1.5.8
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
33 posts
• Page 2 of 3 • 1, 2, 3
Re: Forge version 1.5.8
by drdev » 23 Dec 2013, 18:58
That's only because I haven't implemented filter saving yet. It's on my TODO list.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.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.8
by Agetian » 23 Dec 2013, 19:24
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
- Agetian
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.8
by Chris H. » 23 Dec 2013, 19:46
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
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Forge version 1.5.8
by Chris H. » 23 Dec 2013, 21:40
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:
- Attachments
-
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Forge version 1.5.8
by drdev » 24 Dec 2013, 02:44
Good to hear. Will somebody let me know if Linux is fixed too?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:
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.8
by Agetian » 24 Dec 2013, 03:57
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
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
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.8
by moomarc » 24 Dec 2013, 13:05
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.
-Marc
-
moomarc - Pixel Commander
- Posts: 2091
- Joined: 04 Jun 2010, 15:22
- Location: Johannesburg, South Africa
- Has thanked: 371 times
- Been thanked: 372 times
Re: Forge version 1.5.8
by Max mtg » 24 Dec 2013, 17:34
The main problem was changing the core classes interface (there emerged some new methods to fetch user preferences from the very cards)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.
Was discussed as far as I remember.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.
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.
Thanks!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.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Forge version 1.5.8
by drdev » 24 Dec 2013, 18:12
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.
I'm glad to hear you like the new look otherwise.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.8
by drdev » 24 Dec 2013, 19:08
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?Agetian wrote:r24052: Nope, still no go - the same visual artifacts as before...
- Agetian
Note that I immediately committed the borders back in r24056, so don't update to the head revision.
Thanks.
-Dan
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.8
by Agetian » 24 Dec 2013, 19:13
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
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.8
by drdev » 24 Dec 2013, 21:32
Good, that was the problem then. Thanks for checking into that.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
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.
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.8
by Agetian » 25 Dec 2013, 06:24
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
- Agetian
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
33 posts
• Page 2 of 3 • 1, 2, 3
Who is online
Users browsing this forum: No registered users and 19 guests