QinL / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

getbackuppixel() returns nonsense after a picture resize #530

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
This bug was originally found through use of DawnBringer's DB-Toolbox 'Image-> 
Set Image Size' script, available through the 'Resources and Support' subforum 
of PixelJoint. The attached script is a minimal test case which reproduces the 
behaviour.

What steps will reproduce the problem?
1. Put the script file in an accessible location
2. (optional) Set the image size to something small, for easy overview; eg. 
16x16
3. Do not draw anything on the image; Leave it blank.
4. Open the Brush Factory and activate the script

With the offending line commented (this is the state of the attached file), the 
picture is filled with color #255. That is a correct result.

now 5. open the script file and uncomment the line starting "-- c = get"

With the offending line uncommented, the result is random 2-pixel-wide noise, 
but a correct result would be an image where X dimension is scaled to 200% of 
original size (IOW, since the input is completely blank color-#0-filled image, 
so should the output be). Further testing indicates that putpicturepixel() is 
behaving normally and getbackuppixel() is returning random values.

I can attach an image example if needed.

I'm Using GrafX2 2.4 (SVN r2062) on Arch Linux x86_64, with Lua 5.2.2. 
DawnBringer indicated he did not experience the bug on the version he was using 
(r2035, running on some flavor of Windows IIRC)

(btw, this is the same person as 00ai99 -- this is my new account.)

Original issue reported on code.google.com by fintic...@gmail.com on 25 Apr 2013 at 5:27

Attachments:

GoogleCodeExporter commented 8 years ago
Inserting finalizepicture() after the setpicturesize() line will produce a 
correct result (scaled picture content, rather than scaled random-pixels)

However this doesn't make sense in terms of the action IMO: Shouldn't the 
backup buffer already be filled at that point? Does it really make sense to 
require scripts that have to read from the image to first make an undo step, 
instead of grouping the entire script action into one undo-step?

Original comment by fintic...@gmail.com on 25 Apr 2013 at 7:15

GoogleCodeExporter commented 8 years ago
This bug appeared in r2052, what I tried to do doesn't really work :(

Original comment by yrizoud on 25 Apr 2013 at 9:56