At 7:10 AM +0100 on 11/25/99, M. Uli Kusterer wrote:
>>And then try and teach scripters about the format of pixmaps, handle
>>conversions between fromats, platforms, color sets, bit depths, check to
>>make sure pixmaps are valid before use, etc., all quickly and transparently
>>to the scripter & user.
>
>Anthony,
>
> why should users want to edit the pictureData?
Why do programmers play with pixel data in GWorlds, instead of using SetCPixel?
>It would be much easier to
>do this using drawing commands and paint tools under script control.
Not always. And it certainly won't make for any speed-demonism, either.
Lots of things can not easily be drawn with the built-in tools, unless you
consider using the pencil tool like this easy:
lock screen
put the pen color into oldcolor
put the tool into oldtool
set the tool to pencil
repeat with y = 0 to 342
repeat with x = 0 to 512
-- calculate pixel--
put sqrt(x^2+y^2) into b
-- plot pixel --
set the pen color to rgb 100x,100y,100b
click at x,y
if the color of pixel x,y � the pen color then
-- pencil tool inverted --
-- NOTE: can't just check against x,y,b,
-- because of color mapping.
click at x,y
end if
end repeat
end repeat
set the pen color to oldcolor
set the tool to oldtool
unlock screen
or, by pixel data -- this might even work cross platform!
-- get pixels. Maybe there is an xplatform way to do this.
put the picture of this card into pix
put 0 into offset
-- for whole card --
repeat with y = 0 to 342
repeat with x = 0 to 512
-- calculate & set --
put rgb 100x,100y,100sqrt(y^2+x^2) into�
pixel offset of pix
-- next pixel --
add 1 to offset
end repeat
end repeat
set the picture of this card to pix
(NOTE: I have no idea what this will look like...)
Even if you disagree which is easier, there is no doubt the later is
faster. And no, this is not a syntax proposal. Though there is quite a lot
of non-HT syntax in there.
>We
>won't take any features from them if we just say: The format of the
>pictureData is private, and may differ from platform to platform. It may be
>a filename of a temp file, it may be raw pixel data at screen resolution,
>it may be a pointer to the pixel data in RAM.
True -- and this way it is. So is the pixel offset format, though it does
not look that way.
> Domenu relies on the name of the menu item. What about localized versions
>of OpenCard?
Good point. Wonder if domenu should be able to work on a menuitem number basis?
