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

Re: [MiNT] gradients,FreeMiNT 1.18



On Fri, Jul 29, 2011 at 11:47 PM, Jo Even Skarstein <joska@online.no> wrote:
> On Fri, 29 Jul 2011 13:28:25 +0200, Helmut Karlowski
> <helmut.karlowski@ish.de> wrote:
>
>> 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 tbl-files can be created with KeyEdit. I doubt it's easier to to modify
> C source ;)
>
dude (and others) have a look at the gradients, ALL of them, then have
a look at the gradient algorithms
we are NOT talking about a SIMPLE A=B, it is much more complex than that

this MIGHT be a different agrument if gradients were just being
introduced, bu they are not, they are already present, and they are
already about as simple as you can get.

ALSO, no matter how gradients are load, at compile time they must be
present as C structs, end of story, so why go to the trouble of
inventing a second wheel

>> The grd-files only contain data, they could be produced by any other
>> program as well.
>
> Aren't they object-files?
>
>>> 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).
>
> Most people don't have a C compiler at all.
>
see end for answers to these

>>> 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.
>
> Yes, I'm interested. I believe the gradients can be represented in a much
> simpler but still structured and readable text format. It might even be
> possible to write a GEM-program to edit and pre-view them.
>
> Jo Even
you are wrong here Joe, they are already about as simple as you can
get, in that they support compact and clean definition, while being
clean and simple (read: fast & res lite) to execute

I believe the real answer to ANY arguments here, is a preview app that
generates an equivalent "binariy object", as well as load and save
gradient config files (which just happen to also be c source files)

and to top it off, the is no reason why a bunch of .GRD files can not
be part of the build process (and therefore, the archive)

Paul