Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Juanjogomez on September 24, 2020, 03:01:18 am

Title: Problem whith PCOPY
Post by: Juanjogomez on September 24, 2020, 03:01:18 am
Hi.
I have a problem copying the above screen using PCOPY.
I have always worked with Screen 0 and the PCOPY command has been used regularly to copy the current screen with the data, paint a second screen over it to introduce other data, and then restore the previous screen with another PCOPY; but when I have tried it defining a new screen and loading an image, trying to restore the previous screen with PCOPY does not. It comes out in black.
What am I doing wrong?
Thank you

This is then program:
Code: QB64: [Select]
  2. LOCATE 10, 10: PRINT "This is the first screen"
  3. LOCATE 12, 20: PRINT "Press a key to load image"
  4.  
  5. x$ = INPUT$(1)
  6.  
  7. PCOPY 0, 1
  8.  
  9. SCREEN _NEWIMAGE(2100, 1900, 32)
  10. WIDTH 150, 40
  11.  
  12. i& = _LOADIMAGE("image.jpg", 32)
  16. PageScale = 10
  17. PageHeight = 190 * PageScale
  18. PageWidth = 210 * PageScale
  19.  
  20. PointSize = 10
  21. FontHeight10 = INT(PointSize * 0.3527 * PageScale)
  22. Fuente10 = _LOADFONT("c:\windows\fonts\times.ttf", FontHeight10)
  23.  
  24. LOCATE 14, 20: PRINT "press a key to go to the previous screen"
  25.  
  26. x$ = INPUT$(1)
  27.  
  32. _FREEFONT Fuente10
  33.  
  34. PCOPY 1, 0
  35.  
  36. LOCATE 20, 10: PRINT "press a key to end": x$ = INPUT$(1)
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 24, 2020, 03:20:50 am
You’re making a copy of a SCREEN 0 screen, and then tossing that text screen out and swapping over to a graphic screen with: SCREEN _NEWIMAGE(2100, 1900, 32)
Title: Re: Problem whith PCOPY
Post by: Pete on September 24, 2020, 03:31:06 am
Can't go between text and graphics screens with PCOPY, but you could make a hack...

Code: QB64: [Select]
  2. LOCATE 10, 10: PRINT "This is the first screen"
  3. LOCATE 12, 20: PRINT "Press a key to load image"
  4.  
  5. x$ = INPUT$(1)
  6.  
  7. FOR i = 1 TO _HEIGHT
  8.     FOR j = 1 TO _WIDTH
  9.         pcopy_string$ = pcopy_string$ + CHR$(SCREEN(i, j))
  10. NEXT j, i
  11.  
  12. SCREEN _NEWIMAGE(2100, 1900, 32)
  13. WIDTH 150, 40
  14.  
  15. i& = _LOADIMAGE("image.jpg", 32)
  19. PageScale = 10
  20. PageHeight = 190 * PageScale
  21. PageWidth = 210 * PageScale
  22.  
  23. PointSize = 10
  24. FontHeight10 = INT(PointSize * 0.3527 * PageScale)
  25. Fuente10 = _LOADFONT("c:\windows\fonts\times.ttf", FontHeight10)
  26.  
  27. LOCATE 14, 20: PRINT "press a key to go to the previous screen"
  28.  
  29. x$ = INPUT$(1)
  30.  
  34. LOCATE 1, 1
  35. PRINT pcopy_string$;
  37. _FREEFONT Fuente10
  38.  
  39. LOCATE 20, 10: PRINT "press a key to end": x$ = INPUT$(1)
  40.  
Title: Re: Problem whith PCOPY
Post by: Juanjogomez on September 24, 2020, 03:53:35 am
Thank you.
Although I do not understand if I make a copy of screen 0, load a new screen and then return to screen 0, why is the previous screen not copied with PCOPY, if it was saved in memory.
Title: Re: Problem whith PCOPY
Post by: Juanjogomez on September 24, 2020, 03:56:19 am
Pete's option is very good, but there are different colors of text on the screen and it would have to be rewritten entirely
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 24, 2020, 04:08:58 am
Use _COPYIMAGE to make a backup copy.

The problem with PCOPY is that there’s no set PFREE command.  QB64 allows us to make a limitless number of screen pages, but how would you ever free those pages from memory??

You can’t, manually, so QB64 does it automatically for you, if you switch SCREENs.  PCOPY is just for quick, temporary coping of one screen, while you’re staying in that screen.  Insert another SCREEN statement, and that temporary data cache is freed, reducing resource requirements.

What you want is to use _COPYIMAGE to make a backup of your screen, which you can restore later.  Only important thing to note here:  you need to manually _FREEIMAGE when finished with the copy.  QB64 won’t clean it up automatically for you.
Title: Re: Problem whith PCOPY
Post by: Pete on September 24, 2020, 05:17:28 am
_COPYIMAGE??? No dammit, do it the hard way!!!

Code: QB64: [Select]
  2. LOCATE 7, 10
  3. FOR i = 1 TO 9
  4.     COLOR i, 9 - i
  5.     PRINT i;
  7. COLOR 7, 0
  8.  
  9. FOR i = 1 TO _HEIGHT
  10.     FOR j = 1 TO _WIDTH
  11.         pcopy_string$ = pcopy_string$ + CHR$(SCREEN(i, j))
  12.         pcopy_color$ = pcopy_color$ + CHR$(SCREEN(i, j, 1))
  13. NEXT j, i
  14.  
  15. x$ = INPUT$(1)
  16.  
  17. SCREEN _NEWIMAGE(2100, 1900, 32)
  18.  
  19. x$ = INPUT$(1)
  20.  
  22.  
  23. FOR i = 1 TO _HEIGHT
  24.     FOR j = 1 TO _WIDTH
  25.         x = ASC(MID$(pcopy_color$, _WIDTH * (i - 1) + j, 1))
  26.         COLOR x MOD 16, x \ 16
  27.         PRINT MID$(pcopy_string$, _WIDTH * (i - 1) + j, 1);
  28. NEXT j, i
  29.  

Pete
Title: Re: Problem whith PCOPY
Post by: Pete on September 24, 2020, 05:21:51 am
Oh, and so Steve doesn't have a barf-a-thon over the repetitive COLOR call, do this...

Code: QB64: [Select]
  2. oldx = -1
  3. LOCATE 7, 10
  4. FOR i = 1 TO 9
  5.     COLOR i, 9 - i
  6.     PRINT i;
  8. COLOR 7, 0
  9.  
  10. FOR i = 1 TO _HEIGHT
  11.     FOR j = 1 TO _WIDTH
  12.         pcopy_string$ = pcopy_string$ + CHR$(SCREEN(i, j))
  13.         pcopy_color$ = pcopy_color$ + CHR$(SCREEN(i, j, 1))
  14. NEXT j, i
  15.  
  16. x$ = INPUT$(1)
  17.  
  18. SCREEN _NEWIMAGE(2100, 1900, 32)
  19.  
  20. x$ = INPUT$(1)
  21.  
  23.  
  24. FOR i = 1 TO _HEIGHT
  25.     FOR j = 1 TO _WIDTH
  26.         x = ASC(MID$(pcopy_color$, _WIDTH * (i - 1) + j, 1))
  27.         IF x <> oldx THEN
  28.             COLOR x MOD 16, x \ 16
  29.             oldx = x
  30.         END IF
  31.         PRINT MID$(pcopy_string$, _WIDTH * (i - 1) + j, 1);
  32. NEXT j, i
  33.  

Now if you will excuse me, that deer isn't going to tear itself apart with my bare hands...

Pete
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 24, 2020, 08:10:59 am
Even simpler:

_CONTROLCHR OFF
oldx = -1
LOCATE 7, 10
FOR i = 1 TO 9
    COLOR i, 9 - i
    PRINT i;
NEXT
COLOR 7, 0
 
BackUp =  _COPYIMAGE(0)
 
x$ = INPUT$(1)
 
SCREEN _NEWIMAGE(2100, 1900, 32)
 
x$ = INPUT$(1)
 
SCREEN BackUp
 
Title: Re: Problem whith PCOPY
Post by: Pete on September 24, 2020, 10:15:13 am
When will we be getting that _justdowhatiwant keyword? Even better...

DO until _igetwhatiwant
LOOP

How's that for simple? Well, I'm torn. I miss the good ol' days of having to figure this stuff out, but I appreciate the new tools in the box, too. Somewhere on my old backups, I have a 1990's something color screen saver routine. QBasic had no _CONTROLCHR OFF, so I think I just added past the control characters and subtracted that amount when calculating the colors. +31 and -31, maybe +8 and -8, or maybe I just swapped out chr$(7) with 255, using a select case. The only downside was loss of some possible highlighted color combos, but really only important if PALLET was being used. I sure wish the QBasic developers would have made _CONTROLCHR OFF back in the day.

I haven't used _COPYIMAGE in QB64, but yes, if I was making a graphics to text screen app, I would... STILL DO IT THE HARD WAY! Brooohahaha!!!!

Pete
Title: Re: Problem whith PCOPY
Post by: Juanjogomez on September 24, 2020, 02:32:40 pm
Thank you. It has been very helpful
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 24, 2020, 03:50:03 pm
Quote from: Pete on September 24, 2020, 03:31:06 am
Can't go between text and graphics screens with PCOPY, but you could make a hack...

Thats right you old hack... :P

Quote from: Pete on September 24, 2020, 05:17:28 am
_COPYIMAGE??? No dammit, do it the hard way!!!

Pete

whats so hard about PCOPY?
Antiquated maybe, but 'hard'. Nay says I.
Title: Re: Problem whith PCOPY
Post by: Pete on September 24, 2020, 09:12:35 pm
Lay off the weed and learn to read!

Pete :D
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 25, 2020, 12:47:53 pm
Quote from: Pete on September 24, 2020, 09:12:35 pm
Lay off the weed and learn to read!

Pete :D

Really.... REALLY?
Is that it? Oh come on where is the snappy witticism I have come to expect from you Pete?
The fun, the pun, the wit! What happened? Dont tell me you have gotten too old?!

Seriously,
Being Screen 0  you could use DEFSEG, and PEEK to save both the character data and color data to a string. But not sure how to get the colors from screen 0 to translate back in a 32 bit screen mode. Save the brute force method of predefining them ie:
Code: QB64: [Select]
  1. CONST WHITE = _RGB32(255,255,255)
  2. IF C% = 15 THEN COLOR WHITE
and doing that for each color. But then you get the blinking colors. Besides some trickery how would you copy those to a 32bit screen?

Ah screw it.. come on lets just stick with SCREEN 0! Who needs more?
Title: Re: Problem whith PCOPY
Post by: bplus on September 25, 2020, 01:22:16 pm
Quote
Who needs more?

I do! :) and any one who likes color graphics.

Hey just look at our avatar choices! ;-))

Title: Re: Problem whith PCOPY
Post by: Cobalt on September 25, 2020, 01:36:19 pm
Quote from: bplus on September 25, 2020, 01:22:16 pm
Hey just look at our avatar choices! ;-))

*counts colors in Bplus avatar*
1... 2... 3... 4... .... ....?

Yep need those 16m colors!
Title: Re: Problem whith PCOPY
Post by: bplus on September 25, 2020, 02:04:17 pm
Quote from: Cobalt on September 25, 2020, 01:36:19 pm
*counts colors in Bplus avatar*
1... 2... 3... 4... .... ....?

Yep need those 16m colors!

Yep need those shades! QB4.5 red and blue and that god awful green wouldn't do!

And don't let Pete get you with "Lay off the weed and learn to read!"

That's a Trump trick to cast dispersion's on others so people don't see how severely handicapped he is with Screen 0.

BTW I tried to count colors in your avatar, ha! Ha!
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 25, 2020, 02:40:40 pm
Quote
But not sure how to get the colors from screen 0 to translate back in a 32 bit screen mode.

Look in the SaveImage library.  It shows how to convert a text screen to a graphical screen.  (And then it saves it to a picture, which you can just LOADIMAGE and use, if you want to change resolutions, or not.)

Quick run down of the process:
USE SCREEN(), POINT (), or _MEMIMAGE to get the color and character of each block on the text screen.
Create a graphic screen of WIDTH * _FONTWIDTH, HEIGHT * _FONTHEIGHT size
Now just set foreground, background color and PRINT each character, in place, on your graphical screen.
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 25, 2020, 04:01:28 pm
Quote from: SMcNeill on September 25, 2020, 02:40:40 pm
Quick run down of the process:
USE SCREEN(), POINT (), or _MEMIMAGE to get the color and character of each block on the text screen.
Create a graphic screen of WIDTH * _FONTWIDTH, HEIGHT * _FONTHEIGHT size
Now just set foreground, background color and PRINT each character, in place, on your graphical screen.

I kind of meant with the PEEK method where it just returns 0-255 for the color value. And even simpler, Screen 0 having a base of 0-15 colors.
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 25, 2020, 04:39:19 pm
Quote from: Cobalt on September 25, 2020, 04:01:28 pm
I kind of meant with the PEEK method where it just returns 0-255 for the color value. And even simpler, Screen 0 having a base of 0-15 colors.

It still returns a value from 0 to 255.  4 bits are foreground color, 3 bits are background, and the last bit toggles blinking on and off.  You’ll need to MOD and \ your return value to get the colors used.  ;)
Title: Re: Problem whith PCOPY
Post by: Pete on September 25, 2020, 05:05:43 pm
Hey everybody, cover your eyes. Pete's FLASHING again!

Code: QB64: [Select]
  2. SCREEN 0, 0, 0, 0
  4.     COLOR 7, 0: CLS
  5.     x0$ = "": x1$ = ""
  6.     f = f + 1: IF f > 30 THEN b = b + 1: f = 0
  7.     IF b > 15 THEN IF f = 30 THEN EXIT DO ELSE b = 0
  8.     COLOR 7, 0: PRINT "f ="; f, "b ="; b;
  9.     COLOR f, b
  10.     LOCATE 1, 40: PRINT "Pete..."
  11.     FOR i = 1 TO 47
  12.         x0$ = x0$ + CHR$(SCREEN(1, i))
  13.         x1$ = x1$ + CHR$(SCREEN(1, i, 1))
  14.     NEXT
  15.     PCOPY 0, 1
  16.     SLEEP
  17.     COLOR 7, 0: CLS
  18.     SLEEP
  19.     PCOPY 1, 0
  20.     LOCATE 2, 1
  21.     FOR i = 1 TO 47
  22.         IF ASC(MID$(x1$, i, 1)) \ 16 >= 8 THEN
  23.             ' Flashing
  24.             'PRINT ASC(MID$(x1$, i, 1)) MOD 16 + 16, ASC(MID$(x1$, i, 1)) \ 16 - 8
  25.             COLOR ASC(MID$(x1$, i, 1)) MOD 16 + 16, ASC(MID$(x1$, i, 1)) \ 16 - 8
  26.         ELSE
  27.             ' Non-Flashing
  28.             COLOR ASC(MID$(x1$, i, 1)) MOD 16, ASC(MID$(x1$, i, 1)) \ 16
  29.         END IF
  30.         PRINT MID$(x0$, i, 1);
  31.     NEXT
  32.     COLOR 7, 0
  33.     SLEEP
  35.  

Just to prove there is a way in SCREEN 0 to differentiate flashing from non-flashing characters. I apologize in advance if I'm off on any of the color parameters. I didn't want to spend much time on this, so I didn't check it for accuracy. It's just to demonstrate the method I'd use to detect flashing colors on the screen, and preserve them, which PCOPY will not do on its own.

Just hold a key down to "flash" through all the color combos. When f > 15 "Pete..." will flash. The second line "Pete..." will flash as well, which is possible only because of the conditional color algorithm. Let me know if it needs any tweaking or if anything was missed. I may have actually made something like this 20+ years ago for a screen saver routine.

Pete
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 25, 2020, 05:15:53 pm
Quote from: SMcNeill on September 25, 2020, 04:39:19 pm
It still returns a value from 0 to 255.  4 bits are foreground color, 3 bits are background, and the last bit toggles blinking on and off.  You’ll need to MOD and \ your return value to get the colors used.  ;)

But no way to directly translate the base(foreground) color to 32bit mode.
which seems odd since we can ,sort of, use 32bit colors in screen 0
COLOR _RGB(255,0,0)

least I believe _RGB() finds the nearest color in the available palette. But we cant reverse the process, presumably cause 32bit modes have no palette to compare from. However QB45 did have a base palette to work with, so maybe we could add that under the hood and pull the RGB values off of that internal palette?

It would make it easier to translate old QB45 code to QB64 if someone wanted to make use of a larger screen but didn't want to have to rewrite everything. Just change the SCREEN line but not have to worry about going through the code and changing all the COLOR statements. Yes probably a nitch scenario.
An augmentation of the COLOR statement, if used in 32bit mode to automatically choose from the palette if a value 0-255 is used?
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 25, 2020, 05:35:39 pm
Quote from: Cobalt on September 25, 2020, 05:15:53 pm
But no way to directly translate the base(foreground) color to 32bit mode.
which seems odd since we can ,sort of, use 32bit colors in screen 0
COLOR _RGB(255,0,0)

least I believe _RGB() finds the nearest color in the available palette. But we cant reverse the process, presumably cause 32bit modes have no palette to compare from. However QB45 did have a base palette to work with, so maybe we could add that under the hood and pull the RGB values off of that internal palette?

It would make it easier to translate old QB45 code to QB64 if someone wanted to make use of a larger screen but didn't want to have to rewrite everything. Just change the SCREEN line but not have to worry about going through the code and changing all the COLOR statements. Yes probably a nitch scenario.
An augmentation of the COLOR statement, if used in 32bit mode to automatically choose from the palette if a value 0-255 is used?

Use _RED, _GREEN, _BLUE.

For example, SCREEN 0 High Intensity Blue might be 125, 125, 255.  (I don’t remember the exact values, but you can get them with the command.)

Then use _RGB32() with those values to convert to a 32-bit color . 
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 25, 2020, 05:39:04 pm
Quick demo:

SCREEN 0
FOR i = 0 TO 15
    PRINT I, _RED(I), _GREEN(I), _BLUE(I)
NEXT
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 26, 2020, 01:43:17 am
Quote from: Pete on September 25, 2020, 05:05:43 pm
Hey everybody, cover your eyes. Pete's FLASHING again!

Code: QB64: [Select]
  2. SCREEN 0, 0, 0, 0
  4.     COLOR 7, 0: CLS
  5.     x0$ = "": x1$ = ""
  6.     f = f + 1: IF f > 30 THEN b = b + 1: f = 0
  7.     IF b > 15 THEN IF f = 30 THEN EXIT DO ELSE b = 0
  8.     COLOR 7, 0: PRINT "f ="; f, "b ="; b;
  9.     COLOR f, b
  10.     LOCATE 1, 40: PRINT "Pete..."
  11.     FOR i = 1 TO 47
  12.         x0$ = x0$ + CHR$(SCREEN(1, i))
  13.         x1$ = x1$ + CHR$(SCREEN(1, i, 1))
  14.     NEXT
  15.     PCOPY 0, 1
  16.     SLEEP
  17.     COLOR 7, 0: CLS
  18.     SLEEP
  19.     PCOPY 1, 0
  20.     LOCATE 2, 1
  21.     FOR i = 1 TO 47
  22.         IF ASC(MID$(x1$, i, 1)) \ 16 >= 8 THEN
  23.             ' Flashing
  24.             'PRINT ASC(MID$(x1$, i, 1)) MOD 16 + 16, ASC(MID$(x1$, i, 1)) \ 16 - 8
  25.             COLOR ASC(MID$(x1$, i, 1)) MOD 16 + 16, ASC(MID$(x1$, i, 1)) \ 16 - 8
  26.         ELSE
  27.             ' Non-Flashing
  28.             COLOR ASC(MID$(x1$, i, 1)) MOD 16, ASC(MID$(x1$, i, 1)) \ 16
  29.         END IF
  30.         PRINT MID$(x0$, i, 1);
  31.     NEXT
  32.     COLOR 7, 0
  33.     SLEEP
  35.  

Just to prove there is a way in SCREEN 0 to differentiate flashing from non-flashing characters. I apologize in advance if I'm off on any of the color parameters. I didn't want to spend much time on this, so I didn't check it for accuracy. It's just to demonstrate the method I'd use to detect flashing colors on the screen, and preserve them, which PCOPY will not do on its own.

Just hold a key down to "flash" through all the color combos. When f > 15 "Pete..." will flash. The second line "Pete..." will flash as well, which is possible only because of the conditional color algorithm. Let me know if it needs any tweaking or if anything was missed. I may have actually made something like this 20+ years ago for a screen saver routine.

Pete

Now Modify your program to make use of a Dark Grey in the background. Surely with your mighty Screen 0 knowledge you can.
Title: Re: Problem whith PCOPY
Post by: Pete on September 26, 2020, 02:25:25 am
Code: QB64: [Select]
  1. OUT &H3C8, 0
  2. OUT &H3C9, 10
  3. OUT &H3C9, 10
  4. OUT &H3C9, 10
  5. msg$ = "Cobalt's Sofa Kingdom :D"
  6. COLOR 15, 0: PRINT msg$

Pete
Title: Re: Problem whith PCOPY
Post by: SMcNeill on September 26, 2020, 02:39:59 am
When Pete says he likes to do things the hard way, he’s not kidding.

Why use something slow and hard to decipher, like: ASC(MID$(x1$, i, 1))

You know, you can just use ASC(x1$, i), and accomplish the exact same thing...

If there’s ever a need for an obsolete, overly-complicated solution to a simple problem, Pete’s the guy to go to, to ask for advice on it!
Title: Re: Problem whith PCOPY
Post by: Cobalt on September 26, 2020, 01:23:40 pm
Quote from: Pete on September 26, 2020, 02:25:25 am
Code: QB64: [Select]
  1. OUT &H3C8, 0
  2. OUT &H3C9, 10
  3. OUT &H3C9, 10
  4. OUT &H3C9, 10
  5. msg$ = "Cobalt's Sofa Kingdom :D"
  6. COLOR 15, 0: PRINT msg$

Pete

Something tells me your method there wont produce these results.
Title: Re: Problem whith PCOPY
Post by: Pete on September 26, 2020, 02:54:38 pm
Code: QB64: [Select]
  1. PALETTE 7, 56
  2. msg$ = "Bright white text on a dark grey background, on a black screen..."
  3. COLOR 15, 7: PRINT msg$
Text Only | Text with Attachments