Booster Pack Images
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Booster Pack Images
by Xitax » 21 Mar 2013, 02:44
I didn't expect to succeed, but I've collected all the booster pictures. Turns out it's not easy to find good quality pictures at all.
I've edited them all for orientation/size/saturation/contrast/etc. to my own tastes and I hope you all find them acceptable.
EDIT: See newest post for images posted 4/2022
I've edited them all for orientation/size/saturation/contrast/etc. to my own tastes and I hope you all find them acceptable.
EDIT: See newest post for images posted 4/2022
Last edited by Xitax on 22 Apr 2022, 01:02, edited 1 time in total.
Re: Booster Pack Images
by myk » 21 Mar 2013, 04:42
I must say, I'm impressed : ) That was really fast, too! Thanks, Xitax! @moomarc, could you upload these images (minus booster/Thumbs.db) to the server? The filenames are good as-is. The underscores help clarify where the edition string ends and the art index begins (otherwise we'd have filenames like M121.png). I'm thinking of the following integration:
- align res/lists/booster-images.txt with this new image list
- add number of art indices for each set to res/blockdata/boosters.txt
- read and store the data in the CardEdition
- when we generate a booster pack, choose an art index at random, which will affect the image key it returns
- boosters with different art indices don't stack in the card shop (if that's easy to do)
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Booster Pack Images
by Max mtg » 21 Mar 2013, 06:59
Xitax, that's very cool!
Myk, I like your plan.
To prevent stacking of Boosters with different artIndices I expect it will be enough to define 'getHashCode' and 'equals' methods that take artIndex into consideration in BoosterPack class.
Myk, I like your plan.
To prevent stacking of Boosters with different artIndices I expect it will be enough to define 'getHashCode' and 'equals' methods that take artIndex into consideration in BoosterPack class.
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: Booster Pack Images
by myk » 24 Mar 2013, 14:15
implementation done in the varied_booster_pics branch. I'll merge to trunk when the new images are available on the server.
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Booster Pack Images
by Max mtg » 24 Mar 2013, 16:18
I like the idea of precalculating the hashcode.
But myk, why have you put artIndex into OpenablePack? Other descendant entites (FatPacks and Tournament packs) never had more that one art design. It would be enough to keep artindex right in BoosterPack
But myk, why have you put artIndex into OpenablePack? Other descendant entites (FatPacks and Tournament packs) never had more that one art design. It would be enough to keep artindex right in BoosterPack
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: Booster Pack Images
by myk » 24 Mar 2013, 17:56
this is true. The only real reason I had for putting it in OpenablePack is that I only had to write one equals/hashcode pair that way, and less code is good code. The other reason was that I thought fatpack might, someday, have more than one art index, but that was a pretty flimsy reason. I can get it moved to BoosterPack.
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Booster Pack Images
by Max mtg » 24 Mar 2013, 21:00
I cannot agree about 'less code is good code'. Look at out hashtables string-to-string that are used to (1) store subabilities - SVar records for a card, (2) pass trigger parameters, (3) hold parameters of all Api-based abilities.
That is less code - one map instead of set of fields declared in their classes, but it's impossible to learn all the possible keys and the values each key may hold without digging through all the code that uses maps of one of these types.
As for OpenablePack - it would be better to remove the artIndex field from OpenablePack class, then add equals and getHashCode overloads to BoosterPack that will use results of superclass's methods as a starting point.
- Or - another option, if you like art indices that much, let OpenablePack's methods use getter for artindex field, meanwhile the very method in Openable pack always returns 0 and BoosterPack's overload returns an actual value. Your equals and getHashCode from OpenablePack will be valid for all descendants.
On a second thought, superclass OpenablePack is responsible only for providing some sealed product. It should not care of parameters that will make sense only for Boosters. So, despite of having to write new overloads of equals and getHashCode, the first option looks like a better solution.
That is less code - one map instead of set of fields declared in their classes, but it's impossible to learn all the possible keys and the values each key may hold without digging through all the code that uses maps of one of these types.
As for OpenablePack - it would be better to remove the artIndex field from OpenablePack class, then add equals and getHashCode overloads to BoosterPack that will use results of superclass's methods as a starting point.
- Or - another option, if you like art indices that much, let OpenablePack's methods use getter for artindex field, meanwhile the very method in Openable pack always returns 0 and BoosterPack's overload returns an actual value. Your equals and getHashCode from OpenablePack will be valid for all descendants.
On a second thought, superclass OpenablePack is responsible only for providing some sealed product. It should not care of parameters that will make sense only for Boosters. So, despite of having to write new overloads of equals and getHashCode, the first option looks like a better solution.
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: Booster Pack Images
by moomarc » 02 Apr 2013, 09:55
Does everyone think it acceptable to upload 64mb worth of booster pack variations (about 4 times the size of the average LQ set) as the default booster image downloads? The main reason why it's so large is because they're in png format so would the package could be reduced to just under 13mb total by simply changing to jpeg (without dimension changes and without introducing visible compression artefacts). Is there any particular reason why the images are png format? There's no alpha in any of the files and I can't think of another good reason to use png in this instance (quality is probably marginally higher than a 100% quality jpeg, but even at 80% the average user won't notice the difference).
Edit: decompressed png files were actually only 41mb, but that's still reasonably large.
Edit: decompressed png files were actually only 41mb, but that's still reasonably large.
-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: Booster Pack Images
by Max mtg » 02 Apr 2013, 10:33
I think it'll be OK to convert them to JPG.
The first booster images were in png format, since they had been copied from magic online client
The first booster images were in png format, since they had been copied from magic online client
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: Booster Pack Images
by moomarc » 02 Apr 2013, 10:34
Thanks Max. It helps to know the source of the format choice.Max mtg wrote:I think it'll be OK to convert them to JPG.
The first booster images were png, since they were copied from magic online client
-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: Booster Pack Images
by myk » 02 Apr 2013, 16:11
I think jpg would be fine too. Ping me when they're uploaded and I'll change the URL list to match, test everything out one more time, and merge.
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
-
moomarc - Pixel Commander
- Posts: 2091
- Joined: 04 Jun 2010, 15:22
- Location: Johannesburg, South Africa
- Has thanked: 371 times
- Been thanked: 372 times
Re: Booster Pack Images
by myk » 04 Apr 2013, 15:48
Awesome! I'll get things merged asap -- I've been in a conference for the past few days, and I'll be out this weekend, but I'll do it as soon as I can
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
Re: Booster Pack Images
by myk » 04 Apr 2013, 18:56
Found a few minutes between presentations -- retested with latest trunk and merged : ) Thanks, Xitax and moomarc!
- myk
- Posts: 439
- Joined: 17 Jan 2013, 02:39
- Location: California
- Has thanked: 38 times
- Been thanked: 57 times
25 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 29 guests