PUT erases the screen

[Stevo]

Hello all! I'm having a problem with PUT.
I'm using the basic method where you use Data statements to make a 16 x 16 Bitmap. Then I PSET that to the screen, GET it into an array, and PUT it back on the screen, and that all works fine

The problem comes in when I try to PUT that array on the screen a second time. The reason I'm trying to do this is to have it re-PUT the array each time the player hits a key (it's a map, and the player will be able to move a person around the map). But when the graphic has already been PUT to the screen, using PUT a second time blanks the screen out. Another PUT puts the graphic back up, and it just alternates endlessly like that.
I'm wondering, how can I keep using PUT to update the screen without blanking it out every other time?

Btw, I've had this happen both in Screen 13, and Screen 7 using pages. Thanks very much,

Stevo

[Ralph]

Sounds strange. Could you post a part of your "successful" code, plus all the "unsuccessful" code, explaining what is supposed to be going on, perhaps with comments in the code? Thanks

[Ralph]

Stevo:

After clicking F1 on the graphics PUT statement, I see that the form

PUT (X,Y), arrayName, actionVerb

defaults to actionVerb = XOR. Now, that statement, with XOR, is the best way to erase the image, so, you are, in effect, PUTting the image, then erasing it, then, PUTting the image again, and then erasing it, and so on.

So, if you MUST use the PUT sttement to PUT the image on the screen, then you want to first chech it the image is not there first. Here's one way

'PUT the image on the screen the first time
PUT(X1,Y1),SPRITE(1)
code

'if you use PUT (X1,Y1),SPRITE(1) and the previous image is still there, you will erase it! So, test to see if the color is not just the screen color in, say, X1,Y1, by using the SCREEN function, thus
IF SCREEN(X1,Y1) <> 0 THEN
PUT(X1,Y1),SPRITE(1) 'now, the image should be visible again
END IF
'and so on.

The above assumes that the value in X1,Y1 in the SPRITE(1) image is not
'zero. If it is, then use another non-zero point in SPRITE(1), say, X5,Y5.

Give it another spin, and let us know if this does it for you.

[RyanKelly]

The format of the PUT graphical statement is

PUT (x,y), arrayname, actionverb

The actionverb, which defaults to XOR, is basically a logical operation to perform on the memory contents of the screen.

PSET - Simply copies your array over the screen. This is the one you want.

PRESET - Copies the logical inverse of you array onto the screen.

OR
AND - These should explain themselves.
XOR

[Ralph]

RyanKelly:

After trying many different combinations of the PUT statement to copy an image, and then to erase it, then copy the image to a new location, then to erase it, and so on, to produce movement, usingthe PSET and the XOR (default) actionVerbs, the movement was fine as long as the background color was black (0).

When I tried the above with the background different than black, I kept on getting a sort of trail that, no matter what I did, I could not get rid of. Finally, I created a new sprite, which I called "spritebg", which I created by GETting an empty part of the background early on. Then, to erase the image that I was moving, I PUTted spritebg on top of the image. This works fine. Is this the usual way of doing this?

[RyanKelly]

Sometimes thats the best solution, but maybe I should explain why XOR is the default method. If you already understand bit wise operators, then you won't get much out of this, but maybe this will help you make sense of what the PUT statement is doing.

Bit wise operators take two individual bits as arguments and "return" another based upon them. Here I refer to the bits as being either 1 or 0, but elsewhere you might see them called TRUE or FALSE, ON or OFF

AND returns 1 with boths bits are 1.
1 AND 1 = 1
1 AND 0 = 0
0 AND 1 = 0
0 AND 0 = 0

OR returns 1 if either of the arguments are 1.

1 OR 1 = 1
1 OR 0 = 1
0 OR 1 = 1
0 OR 0 = 0

XOR returns 1 if one and only 1 of the arguments is 1.

1 XOR 1 = 0
1 XOR 0 = 1
0 XOR 1 = 1
0 XOR 0 = 0


Now the thing about XOR is that (A XOR B) XOR B = A
For instance. 0 XOR 1 = 1, and 1 XOR 1 = 0
1 XOR 1 = 0, and 0 XOR 1 = 1

When you use the XOR operator on bit fields, each bit in the first argument is matched up with the corresponding bit in the other argument.
1000
XOR 0110
EQUALS 1110
XOR 0110
EQUALS 1000

When you use the PUT statement with the default action XOR, your program takes each pixel in your array and performs the bit wise operator on the pixels on the screen and sets the screen pixels to the result, so if you put an image on the screen, and then put the same image on the screen in the EXACT same place, you wind up with what you started.
This works well when the back ground is black because the color value used for black is ZERO. In screen mode 13, you have eight bits per pixel so a black pixel is set to 00000000. With the standard palette, color value 4 is high intensity red, and in binary 4 = 00000100. When you use the XOR operation with 4 and 0, you get 4. When you use XOR with 4 and 4, you get 0. In fact A xor A = 0 and 0 XOR A = A, always.
00000000
XOR 00000100
EQUALS 00000100
XOR 00000100
EQUALS 00000000
When your background is not black, trying to use XOR doesn't usually give you what you're after. If your blackground was blue,1= 00000001, and you XORed that with green, 2=000000010, you'd get 00000011 =3 , which is cyan (light blueish green).

PSET is simpler. PSET simply overwrites the contents of the screen with the contents or your array, but then your background is destroyed and can't be restored with simple logical operations, and so that the solution you've worked out is your best bet.

[Ralph]

RyanKelly:

Thank you for your thorough explanation of the varios logical operators and their effect on the bits and resulting pixel colors. I followed it very well, and now feel secure in that knowledge.

Germantown, MD, hmmm. We lived in Rockville, MD, for three years, and passed that way on a few occasions. It's a small world!

[RyanKelly]

If you haven't been in the area for a while, you might not even recognize it. Change is the name of the game here.

[Ralph]

Stevo:

You, as the original poster, haven't shown us if you have solved your problem or not. It would be nice if you let us know if we can now abandon this thread with peace of mind, knowing that you are now more knowledeable and are going forward in QuickBASIC.


RyanKelly:

We lived in Rockville, and I worked in Gaithersburg for Bechtel Corp. from 1986 to 1989. I remember the beautiful, mountain-and-farmland area. I'm sure that the nearness of the D.C. has inspired "civilization and progress" to have been hard at work since then, changing all that to nice homes, shopping centers and gas stations! But, I'm sure a lot of the beauty still lingers.