Re: [MiNT] XaAES Gradients

[Paul Wratt <paul.wratt@gmail.com>]

On Fri, Aug 6, 2010 at 7:17 AM, Peter Persson <pep.fishmoose@gmail.com> wrote:
> 5 aug 2010 kl. 22.35 skrev Helmut Karlowski:
>
>> Am 05.08.2010, 19:06 Uhr, schrieb Paul Wratt <paul.wratt@gmail.com>:
>>
>>> I know that there is a hold on new additions to MiNT/XaAES, but could
>
> ---- snip ----
>
>>> I also propose a change to the default gradients for this release
>>> dedicated to Frank, I think the G_YELLOW.C would produce the best
>>> result.
>>
>> I do not understand anything on this topic.
>>
>> I think it's better to do this when there's more time.
>
> Shouldn't this be solved by providing an external API to it all? My impression
> is that XaAES has fairly sophisticated theme handling internally, but right
> now all we have is hardcoded coder-colours. Extended texture patches and
> new patches for new hard coded themes doesn't really feel like the answer
> to it all. Feels like a waste of resources for something that in the end is a
> matter of taste for each user.

"matter of taste" - Yes, which is why I suggested a yellow set for
this point release, as apart front the yellow/gold window title bar,
it is hard to tell that they are not the original, unlike the other
color sets.

On top of that, including the use of an API, that is one reason
(choices) why I believe it would ideal to include this files in the
CVS, as I have already done the work of creating different gradient
color sets. You can use them as a reference to create a new or custom
gradient, or you can cut and paste them directly into the 2 files
where they are used.

As for the patch, and the use of USE_GRADIENT=filename.c as a Makefile
option, it works well with 1.16.3. You do a full compile, then use the
"recolor.sh" to change the gradient file. This is EXACTLY as GCC/Make
does it, so it takes only a few seconds because only WIN_DRAW.C and
RENDER_OBJ.C have change since last compile/build

Regarding the theme code, you are right, it is very sophisticated, but
it is also beautifully layed out, and the gradient constructions
themselves are very simple to understand (my hat goes off to Ozk, or
who ever came up with that part or XaAES, it really is well layed out
and implemented)

By including the gradient files (even without changing the current
default one), it would allow other to investigate the 3 or 4 gradient
render methods, as there is no documentation of these, or what they
do.

By API, I presume you mean "in XaAES" as opposed to "in the build
process". This is the next step after the patch, to somehow allow
gradients to be dynamically loaded, an extends into allowing XaAES to
reload all interface texture objects (which is what the gradients are
rendered to).

That last step/process is obviously a bit more involved that the
patch, and would therefore take time. I believe it should be possible
to add GEMScript support, to allow config programs or the desktop (VA
server) to change settings in XaAES. So here definitely there would be
a need for something API related.

The single file containing the gradient is beneficial, especially if
you have seen the code, as it allows people to play around with
gradients, without the concern of breaking XaAES's building process.
It also allows a gradient tool to be created fairly easily (which is
also on my todo list).

I provided the link to the files for 1.16.3, simply because it does
not change, therefore the "recolor.sh" works without a hitch (check
its contents to see what I mean). Note that the texture and gradient
code did NOT change between 1.16.3 & 1.17.x, so the gradient files
attached above can be used in either version.

I would like to do a G_GENTOO.C gradient color set specifically for
use with Alans GentooMiNT release, with black gradients, and green
tinges or trimings (along with a new extended texture set). This is
easier to do if there is more info and examples on gradients (and
textures) in the CVS (there is none atm, except the code itself)

Paul