GLBasic forum

Main forum => Bug Reports => Topic started by: PeeJay on 2009-Jul-29

Title: Bug in SAVEBMP?
Post by: PeeJay on 2009-Jul-29
There seems to be a bug in the SAVEBMP command which means that all pixels that are RGB(0,0,0) will be saved as RGB(255,0,128) in the resultant bitmap
Title: Re: Bug in SAVEBMP?
Post by: MrTAToad on 2009-Jul-29
Odd - all my blacks are, well, black...

Are you using a 16-bit screen ?
Title: Re: Bug in SAVEBMP?
Post by: PeeJay on 2009-Jul-29
Nope, 32 bit here.
Title: Re: Bug in SAVEBMP?
Post by: PeeJay on 2009-Jul-30
For those interested, this is the code and the resultant bitmap file.

The idea is that it loads speccy graphics at 4x resolution, applies a grid scanline effect, then saves the result as a bitmap. It also displays the file (which shows correctly, with black being black!) then waits for a mouse click before exiting.

Hope this helps in tracking down the bug .....

[attachment deleted by admin]
Title: Re: Bug in SAVEBMP?
Post by: Ian Price on 2009-Jul-30
Take out the "ALPHAMODE -0.5" command and see what that does ;)
Title: Re: Bug in SAVEBMP?
Post by: MrTAToad on 2009-Jul-30
I believe you've come across a valid bug here - it looks like SAVEBMP's is using the default transparency value of 255,0,128 - even if you try to override it with the SETTRANSPARENCY command set to 0,0,0
Title: Re: Bug in SAVEBMP?
Post by: PeeJay on 2009-Jul-30
Removing the ALPHAMODE -0.5 does stop the problem, but is not the desired effect. Adding ALPHAMODE 0 before the SAVEBMP does solve the problem, however. It's not surprising this bug hasnt been discovered before - I mean, who in their right mind would ever use SAVEBMP in this way?  =D
Title: Re: Bug in SAVEBMP?
Post by: MrTAToad on 2009-Jul-30
However, this does work :

Code (glbasic) Select
SETSCREEN 1024,768,1
LIMITFPS 60
SETTRANSPARENCY RGB(0,0,0)
LOADSPRITE "screen.png",0

LOCAL loop1,loop2

DRAWRECT 0,0,1024,768,RGB(0,0,0)
DRAWSPRITE 0,0,0
// SHOWSCREEN

SETTRANSPARENCY RGB(255,0,128)
SAVEBMP "convertedscreen.bmp"

SHOWSCREEN

WHILE MOUSEAXIS(3)=0
WEND

END


This also works :

Code (glbasic) Select
SETSCREEN 1024,768,1
LIMITFPS 60
SETTRANSPARENCY RGB(0,0,0)
LOADSPRITE "screen.png",0

LOCAL loop1,loop2

DRAWRECT 0,0,1024,768,RGB(0,0,0)
DRAWSPRITE 0,0,0

ALPHAMODE 0

FOR loop1=0 TO 1024 STEP 4
FOR loop2=0 TO 768 STEP 4
SETPIXEL loop1,loop2,RGB(0,0,0)
SETPIXEL loop1+3,loop2,RGB(0,0,0)
SETPIXEL loop1,loop2+3,RGB(0,0,0)
SETPIXEL loop1+3,loop2+3,RGB(0,0,0)
NEXT
NEXT

//ALPHAMODE -0.5

FOR loop1=0 TO 1024 STEP 4
FOR loop2=0 TO 768 STEP 4
SETPIXEL loop1+1,loop2,RGB(0,0,0)
SETPIXEL loop1+2,loop2,RGB(0,0,0)
SETPIXEL loop1+1,loop2+3,RGB(0,0,0)
SETPIXEL loop1+2,loop2+3,RGB(0,0,0)
SETPIXEL loop1,loop2+1,RGB(0,0,0)
SETPIXEL loop1,loop2+2,RGB(0,0,0)
SETPIXEL loop1+3,loop2+1,RGB(0,0,0)
SETPIXEL loop1+3,loop2+2,RGB(0,0,0)
NEXT
NEXT

SETTRANSPARENCY RGB(255,0,128)
SAVEBMP "convertedscreen.bmp"

SHOWSCREEN

WHILE MOUSEAXIS(3)=0
WEND


However, as soon as ALPHAMODE -0.5 is introduced, it goes wrong - it's possible ALPHAMODE affects SETTRANSPARENCY - which is needed just before the SAVEBMP, which is to be expected.  However the colour value is odd - using 255,0,128 the transparency comes out black...

Title: Re: Bug in SAVEBMP?
Post by: Minion on 2011-Jan-09
Did we ever get to the bottom of this ?

Im having a great problem with this now while trying to include a PrntScr button ;( Ive tried all the above suggestions to no avail.

The first image is how it looks (I did a manual PrntScr)
The sedond is if I save it as a BMP (saved as a PNG here just for upload purposes)
the third is saved as a PNG

I cant explain what is going off so any help or advice would be appreciated.

[attachment deleted by admin]
Title: Re: Bug in SAVEBMP?
Post by: Ian Price on 2011-Jan-09
I use SAVEBMP quite often and haven't noticed any oddities of late.

Those screenies would indicate that there's definitely a problem somewhere though.

I did have an occurence recently where an image wasn't displayed properly in one paint program, but did appear correctly in another, but that was just a one off (IIRC). The programs were Windows7 MSPaint and XP MSPaint - significant differences were apparent when I first opened up the image. Try using another paint program and see if the results are the same.
Title: Re: Bug in SAVEBMP?
Post by: Kitty Hello on 2011-Jan-10
Oh!!! Can you please try SETTRANSPARENCY -1 before you do SAVEASBMP again? It seems to take care of transparent bits, which is very bad.
Title: Re: Bug in SAVEBMP?
Post by: Minion on 2011-Jan-10
OK, tried that, and no effect on output files, but it does make my screen go nice ;)

[attachment deleted by admin]
Title: Re: Bug in SAVEBMP?
Post by: Kitty Hello on 2011-Jan-10
can you create a small snippet to reproduce it?