new images not completly black
Displaying 1-13 of 13 total.
1
gannon
|
when you create a new image it isn't completly black (there are a couple non black pixels). the doc for the newImage says it should be blank.
Posted on 2005-07-04 20:58:14
|
Omni
|
Maybe it's like doing Malloc(). You're never quite sure what the state of the memory was prior to Verge grabbing it for you. That's not such a huge deal, of course, since you can easily fill the new image with whatever color you want (I have a custom Image generating function that does this by default) but I guess it should be fixed.
...Erm, yeah, just sharing my thoughts here.
Posted on 2005-07-04 22:02:18
|
RageCage
|
I think omni is right all except for the 'it should be fixed'. I'd rather have an extra line of code than extra overhead for the function as not everyone always wants the new image to be black.
Posted on 2005-07-06 10:37:27
|
Kildorf
|
It probably should be either fixed, or the documentation should be amended to say that you can't rely on it being blank.
For my part, I think I agree with Rage. It'd be best to let the coder handle clearing the image... if for no other reason than we wouldn't have to clear it to black, and then to death-magenta or whatever. On top of that though, it'd probably be a good idea to have a NewBlankImage() or something in the sully code libraries. It'll probably be a bit confusing to new programmers to get the weird garblish stuff that you usually get in a new image.
Posted on 2005-07-06 20:08:09
|
rpgking
|
If anything the blank image should be magenta. But like Rage said, this should be up to the coder. Especially since this is hicolor we're working with and there's really no standard for a default color.
Posted on 2005-07-06 20:15:53
|
Omni
|
Well then, I'd say let the NewImage() function take a color argument for the starting color of the image.
Posted on 2005-07-06 22:58:58
|
Overkill
|
Quote:Originally posted by Omni
Well then, I'd say let the NewImage() function take a color argument for the starting color of the image.
But that'd break compatability with any code that uses NewImage() as it is currently. Unless, the developers implemented optional arguments for at least the builtin functions. NewImage(width, height[, color]).
Posted on 2005-07-07 11:42:15
|
anonymous
|
Fix NewImage() to be black (or magenta, whichever) and give us a NewImage2(int width, int height, int color) or something.
Posted on 2005-07-11 07:49:49
|
anonymous
|
Hrm. That was me. --Omni
Posted on 2005-07-11 07:50:18
|
mcgrue
|
int im = NewImage( x, y );
RectFill( 0,0, x,y, my_color, im );
Not something particularly deserving of it's own function, is it?
Posted on 2005-07-11 21:51:06
|
Omni
|
The idea was to appeal both to RageCage's desire to prevent additional overhead (thus by having NewImage clear the image itself so we don't have to do it) and allow this image clearing to be of any color possible (also so we don't have to RectFill it ourself, saving more overhead).
Not deserving of its own function for any benefit of obfuscation, but maybe for the slight speed increase (especially if you must deal with a _ton_ of RectFill), though admittedly NewImage() is tons slower than, for example, ImageShell() or even RotScale() [though perhaps this might be another reason to reduce overhead]. Anyway, just more thoughts.
Posted on 2005-07-11 22:46:48
|
vecna
|
Its intended that NewImage does not initialize the memory. If the docs say otherwise, they're wrong.
It is a speed thing obviously, MOST images that are allocated are going to be loaded with something rather than just drawn to arbitrarily.
I guess a ClearImage(img, color) might be nice.
Posted on 2005-07-21 22:12:50
|
Kildorf
|
A decisive voice; that's just what we need. Go vecna!
I've changed the docs to reflect what newImage() actually does.
Posted on 2005-07-22 04:58:00
|
