[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] gradients,FreeMiNT 1.18



Jo Even Skarstein wrote:

> > To me the c-files for gradients are a lot easier to edit than the
> > keyboard-source-files, so that would not help much apart of the
> > additional work/error-source.
>
> Sorry, but this sounds absurd to me... You are using gcc to compile a
> C-file into an object, and then add code to XaAES to load this object file
> at run-time. To me this is almost like if mint.cnf was mint.c because
> it's easier. Yes, it's easier to leave the text parsing to gcc and just
> load a binary, but only for the developer.

Sure - that's true, but for the user it's not difficult to make changes
to a gradient-file once there's a c-compiler around. It's easier than to
create tbl-files because it all has names and more structure.

The grd-files only contain data, they could be produced by any other
program as well.

> What is a gradient? It's very simple: A start colour, a end colour and a
> direction. The colours inbetween are calculated. If a user wants to edit a
> gradient, he would probably just want to edit the start- and end-colours.

I don't know much myself about this, but in XaAES there are two possible
directions for gradients (h/v simultaneously), and you can set
"middle"-values not only start/end.

> Most people won't even have gcc on their Ataris (I don't). I'm quite sure

pure-c works also (didn't test ahcc, but it should do as well).

> that there must be an easier way to create and load those grd-files. I can
> maybe do this if you can explain to me in more detail how gradients are
> defined in XaAES.

Sorry - I can't. I created some by trial/error.

But if you're really interested, I'll have a closer look.

Also I plan to extend the object-types to which gradients may be
applied, and maybe use two different gradients for boxes (small/big) and
so on, so this is still under development and should not be seen as
final at all.

-Helmut