Booster Pack Images

[Xitax]

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

[myk]

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)

[Max mtg]

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]

implementation done in the varied_booster_pics branch. I'll merge to trunk when the new images are available on the server.

[Max mtg]

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

[myk]

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.

[Max mtg]

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.

[myk]

done

[moomarc]

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.

[Max mtg]

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

[moomarc]

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

Thanks Max. It helps to know the source of the format choice.

[myk]

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.

[moomarc]

Ping! Jpegs uploaded.

[myk]

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]

Found a few minutes between presentations -- retested with latest trunk and merged : ) Thanks, Xitax and moomarc!