Yay sneaky smart solutions!
Instead of refilling the combobox when the legal move list changes, wait
until the full list is required then repopulate the individual combobox
can't even notice the lag besides the individual tab load. yess
cache a hashset to determine if the legally allowed moves are the same.
reuse cache in paint method
previously, was noticeable if you load the Moves tab then check
legality; the legality message was delayed by a couple hundred
milliseconds due to repopulating 4 comboboxes (Combobox.NativeAdd
hotspot triggered by RefreshItems, which happens when we set the
datasource). By skipping unnecessary repopulations, gui lag is lessened.
would be preferred if I can just reorder the list inside, but noo.
Don't unlock/lock the GlowBase bitmap repeatedly; store the bytes
separately for frame generating. Fixes any memory access exceptions
(unlock->unlock due to program lag).
Do more preprocessing of egg glow sprites for cleaner appearance (now
glow inside sprite)
extract glow method for easier reuse
Sprite creation uses slot>=0 for determining if it's in a box or not;
kinda should redo the logic but there's no upside to passing 0-6 to the
sprite generator for these.
Closes#2069 thanks @iiippppk !
max IVs use flawless method directly with 6 IVs specified
move color blend/stat calc to ImageUtil
move potential string to commonedits
expose color properties for pkmeditor
don't constantly create/dispose brushes for drawing legal moves
reduce pk3/ck3/xk3 logic, share AbilityBit property within _K3, and when
loading, type check (favored over hardcoding individual load cases)
pull some non-gui code from PKMEditor to core/etc for general data
fetching
Rework box fetch in SaveFile to be a little more flexible, can now fetch
a single box
Hold control to... export all boxes :)
I wonder if there's a decorator that showdown skips when importing lines
that can help differentiate the boxes since there's the potential for
hundreds output (ie comments in a showdown set?) doubt it.
update handling that checked for this case to instead check for
equivalence to ability1 instead of 0
was generating a PGF with ability[1] = 0, which is not correct. Just fix
the binaries to behave and get rid of all the workarounds since future
tables don't have missing values.
