[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PyGame / PyOpenGL Example



On Thu, Feb 14, 2008 at 5:42 AM, David <dvkeeney@xxxxxxxxx> wrote:
>  Do you have an algorithm as to how to automatically divide an
>  arbitrary rectangle into a near-optimal set of smaller power-of-two
>  rectangles?
>
I've never written one myself - I've seen somebody else's code (I
think it might have been the popcap framework) that split stuff into
at most 4 textures only did a split only if the image was > .5 and >=
.75 of the next higher power-of-2 - so like 800 would stick with 1024
cause 512 + 256 < 800, but 600 would become 512 + 128 cause 512 + 256
> 600. In that case it would save like 30% of the memory usage of the
alternative (1024x1024 texture), and it also puts an upper bound on
the waste per image to be like 69%, as opposed to 400%.

I suppose it would be very simple to write a nice recursively defined
algo - basically where the function can be asked to decide how to
split some quad (either vertical horizontal or both) and when it does
split it would call itself on the leftovers as appropriate. I would
guess that you just put in some practical limit as the decision to
split in terms of pixel or percentage waste (to have 0 waste in the
crazy bad case of a 511x127 image you would have 9x7=63 textures for
that one image, while 1 texture would only be 1% waste - and you may
start getting occasional seams on some cards cause of floating point
issues on coords)


>  I am the author of Lamina, and just have never worried about
>  optimizing the texture usage.  Now that it has my attention, the
>  mapping of multiple subtextures into one continuous panel seems
>  straightforward, but choosing the subtexture sizes to start with is
>  not obvious.  I suppose I could just premap all the common full-screen
>  window sizes by hand, and then nearest-fit any other window sizes.
>
It's probably not important if you haven't found a case where it's
important. Compared to the weirdness that happens when you don't
address the power-of-2 problems at all (stuff like large white
textures or invisible content or slow performance on some machines,
like Richard mentioned)  it's small beans.