Re: [MiNT] Fwd: gradients,FreeMiNT 1.18

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

On Sat, Jul 30, 2011 at 9:12 AM, Helmut Karlowski
<helmut.karlowski@ish.de> wrote:
> Am 29.07.2011, 23:03 Uhr, schrieb Jo Even Skarstein <joska@online.no>:
>
>> On Fri, 29 Jul 2011 22:18:37 +0200, Helmut Karlowski
>> <helmut.karlowski@ish.de> wrote:
>>
>>>> Exactly. And the grd-file can be in the exact same binary format as the
>>>> gradient struct, which makes loading them very easy.
>>>
>>> That's currently the case!
>>
>> How? I thought it was an object file?
>
> It's an object-file, but all except the gradient-data is ignored (recognized
> by START and STOP-magic-patterns).
>
>>> I'd suggest to use the widely spread and well documented C-source-format
>>> ;-)
>>
>> Bad choice. Would you keep configuration files in C?
>
> Sure!
>
> --
> Helmut Karlowski
>
the real reason for keeping C source files, especially as user
modifiable gradient definition, is that XaAES is compiled with a
default one, so simply by swapping/renaming you can build XaAES with a
custom default gradient set.

I'm not debating wheather C source is better that any other file
format when describing gradients, I am more concerned with the amount
of coding required to get users to be able to add there own at (or
during) runtime, from the programmers point of view (workload)

the fact that at this very moment one has to use AHHC/Pur-C/GCC to
create object files from a C source, is kind of a moot point atm, As
we have already agreed that if a preview app where to be (properly)
user friendly, then it will have to output the same object file format
anyway..

even before that happens, an app can script out to a compiler to
simplify the creation process..

By including the GRD files at build time (release, daily builds, etc)
I meant the object files, created from any gradient source present..
not just the C sources (so you can create/edit your own with CVS
access)

Helmut:
As for binary forms of structs, it would be possible to load a new
block of binary over one currently in memory, but only if the maximum
length of each struct was created at compile time, an that means
creating a gradient set that uses the algorithm that requires an array
of 3 RGB color value, not the more widely use "array of 2 RGB color
values"

So I am say it would be possible to do a direct memory replacement of
those structs in the XaAES binary, but only under specific conditions
(as above - shorter is OK, it can be padded, longer is not), the other
requirement for this is the order in which the structs are defined in
source, and therefore compiled, as this affects the address used by C
(for a compiled binary)

Again, this is an idea, not a must have, or stipulation, and I can bet
there are some who would not allow this any of there own programming
methods, but that does not mean it would not work

As far as a preview option, this is a moot point, and does not even
make sense (hence the term: preview), but might be useful when
actually changing to new defaults.. (it is resource lite)

----------

btw I have plains for another algorithm, more when I have it on paper

Helmut:
can you add 0 border on all objects (currently only window), ie no box
outline definitions, at least for window widgets, slidebars, etc

Your work with gradients can be applied to image textures too
(especially if IMG folder can be defined in .cnf)

Cheers

Paul