Allow upto 512 images on a WPS

[kahuna_999]

Hi

My first patch for rockbox ,  http://www.rockbox.org/tracker/task/7289, is to up the available images allowed on a WPS from the default 52 to 512.  This is achieved using a new display tag %xp which has parameters to pick parts of a loaded bitmap.

There are two variations on the command. The first will use the x,y coordinates from the corresponding %xl tag, the second allows you to specify them.

%xp<bitmap load id>|srcx|srcy|w|h|
%xp<bitmap load id>|srcx|srcy|w|h|x|y|

The %xp tag can be used in conditions.

I hope the artists out there can use this to come up with some stunning new wps's

[Sambolina3]

Um not to be negative but why would you need more than 52 images? And what about those poor processors?  

[Llorean]

Basically, with the number of codecs Rockbox currently supports, plus the arbitrary length conditionals usable in the WPS it's very easy to come up against the limit for graphics. In fact, one of the official WPSes is pretty much up against it right now as it is (iCatcher). Used reasonably, bitmaps-by-parts should alleviate some of these problems. The total limit on WPS size (including graphics) will likely stay the same, or not increase much.

[NicolasP]

I like the idea. If used correctly it can be very useful for WPS creators.
I haven't had time to really check the patch out yes, but I sure will

[Yotto]

This sounds pretty cool.  If I read this correctly you're not allowing any more images to be loaded, but you're allowing us to specify an area of an existing loaded image to be displayed.  Very cool, and lots of potential.

[kahuna_999]

This sounds pretty cool.  If I read this correctly you're not allowing any more images to be loaded, but you're allowing us to specify an area of an existing loaded image to be displayed.  Very cool, and lots of potential.

Thats correct

I have not changed the existing 52 bitmap limit.   Just the way that they can be used.

[Flid]

In fact... wouldn't this potentially reduce the number of "loaded" bitmaps? Since the majority of bitmap usage tends to be battery & volume icons, this could allow scale enumeration of a single image, being slowly exposed (similar to progress bar bitmaps - or am I misinterpreting?).

How would this handle the clearing of images though? (ie. turning volume down)?

[Yotto]

Here's one idea.  Simple volume bar:

=========|||||||||||||

The = is the volume bar graphic, the | is the transparent color.

for 0% volume, you use all transparent.  For 100% volume, you use all graphic.  For each step along the way, you grab a portion between the two.

[Llorean]

I like it. Take an image 200 pixels long, the left side solid, the right side transparent, and slide your viewport from the rightmost 100 left until the leftmost 100 is displayed as you increase the volume.

[digerati1338]

Nice.  Very nice.  Hopefully we'll see a few new WPSs as a result of this.

[Mad Cow]

Here's one idea.  Simple volume bar:

=========|||||||||||||

The = is the volume bar graphic, the | is the transparent color.

for 0% volume, you use all transparent.  For 100% volume, you use all graphic.  For each step along the way, you grab a portion between the two.

I was thinking of something similar a while ago, except I was thinking of a progress bar. Make it work just like or similarly to the normal progress bar.

[Llorean]

Making it work similarly to the progress bar would break other solutions, like an icon that changes color from one color to another as you increase volume, or the circular volume indicator on iCatcher.

We should strive to not remove options we already have, and this does both (leaves existing options plus allows for some frugality in bitmap allocation).

[Mad Cow]

What if you make it a separate tag? %vb for bitmap and %vp for progressbar-like. Now I don't know if those tags are taken, or the feasibility of this, but I'm just suggesting.

[Llorean]

Why add that when the above solution solves the problem already, though?

[Mad Cow]

That's why I said I'm not sure of the feasibility of this. I was just suggesting.