[MiNT] Fwd: gradients,FreeMiNT 1.18

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Paul Wratt wrote:

> I misread your post, and I guess gradient screenshots are not helpful
> until you have some nonstandard ones.. unless the ones you have are

I have - but it's not finished yet.

> >
> > Should textures precede gradients - i.e. no gradient if a texture is
> > given for an object?
> >
> If you just extended gradients, then it should use gradients if
> non-zero values is given (as it originally did), irrelevant of the
> presence of IMG folder (or future setting)

Currently it happens that gradient and texture are both applied if I'm
not wrong - at least textured objects look different with or without gradients.

> I see there are 2 files. what is the difference between g_blue.c and
> n_blue.c (slist and window-title exchanged?)

Of course everything is in one file - the n_*-gradients are variations
by me where slist and window-title-gradient is exchanged.

> the gradient struct is very clean, with the primary difference being
> a gradient algorithm (one of 5 I think), look at attachment (from my
> 1.16.3 build) is easiest, but basically just an array of RGB groups
> (in VDI format), depending on algorithm requirements

When you only care for the rgb-values it's really easy! But who knows
what the 5 methods do?

> same, which is why I thought of using a C parser in XaAES, and or an
> interpreter in the preview app.. why create a new INI stule format
> that will have to then me converted or require a loader, especially
> when you realise just how clean the gradient structs are in C form.

For a GEM-config-app there is no need to use any human-readable format
(like c or keyboard-source). It would read and write the grd-file
similar to keyedit.

> but deciphering the struct output will be time consuming (but not
> impossible), I think there were about 148 structs needed (maybe less),
> and about 5 different struct layouts (1 per algorithm), so atm it is
> just easier to use compiler.. but probably a good idea for a final app

They all have numbers, and it's not necessary to write all of them into
a file, the missing ones remain unchanged in XaAES.

> one final thing here regarding loading the structs (I forgot to
> mention before), because some algorithms have different sizes (require
> more than 2 sets of RGB values, ie used in window widgets), this
> complicates loading changes from raw binary. It may be be possible to
> pre-define the area with the algorithm that uses the most memory, but
> that would also mean changing the default gradient used, and may give
> bad rendering results too, so some experimentation is required

Don't know what you mean: there allways 16 rgb-triplets, and all
gradients have the same size.

> anyway, in the meantime, at least people can start playing, and (more)
> easily get results

I've added a quick hack to load a gradient-file at runtime:

$echo -n "#\$#0<filename>" >/pipe/alert

Works, but only newly created windows are affected, and old memory is
not freed. Don't know if this is useful.

$echo -n "#$" re-reads the xaaes.cnf, but of course gradients are not
affected by this.

-Helmut