From: BlueChip <cs_bluechip_at_webtribe.net>
Date: Fri, 14 May 2004 20:59:07 +0100

At 07:50 14/05/04, you wrote:
>On Thu, 13 May 2004, BlueChip wrote:
>
> > >Can you show me the patch that makes Rockbox use the last line in the WPS
> > >even though the font doesn't fit entirely on that row? I seem to have
> > >missed that.
> >
> > I think you misunderstood. Afaik, there is no specific patch for the WPS
> > screen. But, more generally, the graphics routines required to do it are
> > already written.
>
>OK. Can you show me the patch?
>
>I can't find any such patch in the tracker and I must've missed it when it was
>posted here.

I have not converted my code to a patch. But if you want to grab it from
my homepage and convert it to a patch - feel free to do so. All I ask in
return is that I be credited for my work.

Alternatively, the essence of the rework is:
If the bit you are drawing is pre-screen, do nothing and loop
If the bit you are drawing is post-screen, exit the draw routine

There is a time and code overhead, but.....

TIME: I doubt you would ever notice the overhead; alternatively you could
implement (as I have done) a "safe" and "unsafe" pair of routines ("safe"
meaning "Rockbox will not crash if you attempt to print off the screen")

CODE: If code space is becoming a problem, my random number routine will
recover some 5KB+ of RAM and produce indistinguishable results from the
Marseinne Twister ...You can check this visually by running the starfield
demo. This routine is also phenomenally faster than the Marseinne Twister
so things like games (etc) that use "safe" drawing could regain time by
using this random number generator (which, afiak, has no name other than
"X<-(aX+c)%m")

The random number generator is, as you may recall, the very first
optimisation I ever mentioned on this group. Someone at that time said
that it was not random enough. When I recently implemented this rnd() in
my own code, I immediately saw what was meant ...A bit of lateral thinking
led me to find that a >>8 on the final number resolved the "lack of
randomness" issue** ...this does mean that my routine will only produce a
24bit number, not a 32bit number, but I cannot imagine a time where I will
want a random number outside the range 0...16,777,215 ...but if ever you
did, it would be a trivial task to add a rnd32() but it would take three
lines of code to generate rather than one.

**It is very important to have a specific pattern in your random numbers - LOL

Hope that all makes sense, let me know if you need/want any clarification
on any of it.

Cheers,

BLuechIP

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-05-14