"Bald Eagle" <cre### [at] netscapenet> wrote:

> But what you're essentially doing is exactly that.  Because there is no
> "function" - it's a look-up table - reading in the color values for each x,y
> pixel in the image.   It's simply the fact that it's done under the hood, via
> compiled source code, that makes it seem "different".
>
> [aource-code snippet]
>
> "If the x,y position is outside of the image area, return a clear value, else
> return the color of the image at that x,y value."
> No function.   Just an algorithm in a loop.

Fascinating! Thanks; that actually helps me to understand what's going on--
MUCH more than I knew previousy! The Black Magic mystery is slowly starting to
become clear...

>
> Now, what I have wanted, and suggested in the past, is for there to be a
> mechanism by which the compiled source code stores all the color data for an
> image file in an SDL-accessible 2D array.   Which would kinda give you what
> you want without all of the mucking around.

YES, that would be an interesting feature, and I '2nd' the vote.

> And I guess I should point out that _form_ follows _function_.
> What do you want to do with the function once you've got it, that you need to
> have it in function form?

That's a good question. My main answer would be, just to see if could be done.
And to try and better-understand the real power of function use in SDL. I've
used functions for years in POV-ray, but in relatively simplistic ways; I
haven't yet grasped the 'how-to's' of more complex combinations and usages.
(E.g., trying to turn a bunch of eval_pigment colors into a function, *via* pure
SDL equations. Etc.)

[Btw, my apologies to Robert M for going off-topic here]

Post a reply to this message