QB64 REPORT S01E02: "SCREEN modes"

[FellippeHeitor]

Here's the second episode of QB64 Report, our podcast on all things QB64. In this episode, "SCREEN modes".

Catch it on all major podcast providers or listen straight from https://www.buzzsprout.com/1147208/4174160

[bplus]

Ah so Alt+ something gets us 4 different screen modes without a single line of additional code.

That's pretty good tip, thanks!

[FellippeHeitor]

That's alt+enter. The behavior of the key combo can also be customized (and even disabled) with:

Code: QB64: [Select]

1. _ALLOWFULLSCREEN

[bplus]

Thanks again

Like the idea of layering when I was thinking how difficult to update screen over and over again for mouse over on buttons, it's on redo whole screen, no it's off, redo whole screen... yikes! But draw an overlapping layer, and you only have to make the image once! Layer on, layer off, layer on, layer off... that should work well!

[Ashish]

Squirrels for sale, fried on sticks. - @Richard Frost

[Dav]

Another great episode!  Ya'll sure do a podcast good together.  Everyone puts in their valuable input, and nobody gets in the way of each other.  It's to the point stuff, and you keep it interesting too.  The episode flows good.  Maybe add some intro + outro music!

- Dav

[_vince]

There is the WINDOW statement, QB original, that fixes the coordinate system to whatever you want but no one ever uses it and rightfully so, it's too confusing, but why not?

Code: QB64: [Select]

1. screen 12
2.  
3. window (-_pi,1)-(_pi,-1)
4.  
5. pset (-_pi,0)
6.  
7. for x= -_pi to _pi step 0.1
8.  
9. 'wow is this mathematica?
10.  
11.         y = sin (x)
12.  
13.         line -(x, y)
14. next
15.  
16.  
17. sleep
18. system
19.  

[bplus]

There is the WINDOW statement, QB original, that fixes the coordinate system to whatever you want but no one ever uses it and rightfully so, it's too confusing, but why not?

Code: QB64: [Select]

1. screen 12
2.  
3. window screen (-_pi,-1)-(_pi,1)
4.  
5. pset (-_pi,0)
6.  
7. for x= -_pi to _pi step 0.1
8.  
9. 'wow is this mathematica?
10.  
11.         y = sin (x)
12.  
13.         line -(x, y)
14. next
15.  
16.  
17. sleep
18. system
19.  

Hey _vince I was showing STx this, since he is always wanting a central origin and y-axis pointed up. Be careful with graphics commands they don't all work and there is a special command to get correct mouse location, probably can find it in Wiki under Window or related keywords.

Maybe I can dig up the demo I made.

Code: QB64: [Select]

1. OPTION _EXPLICIT
2. _TITLE "Test Using Window for Cartesian Coordinate System x = -100 to 100, y = -100 to 100"
3. 'It seems all graphics commands convert x, y to window system BUT...
4. 'Mouse and _PrintString do not convert! BUT...
5. 'Somebody setup a PMAP system that will do these conversions both to grapghics coordinate system and back
6. ' convert mouse qbx, qby to graphics x, y use
7. ' PMAP(qbx, 2), PMAP(qby, 3)
8. ' And to print something at the graphics location use
9. ' PMAP(graphicsX, 0), PMAP(graphicsY, 1) to _PRINTSTRING to a graphics location
10.  
11. CONST xmax = 700, ymax = 700, red = &HFFFF0000, grn = &HFF009900, blu = &HFF0000AA
12. CONST tlx = -100, tly = 100, brx = 100, bry = -100 ' Cartesian Coordinate System corners for WINDOW command
13. SCREEN _NEWIMAGE(xmax, ymax, 32)
14. _SCREENMOVE 300, 40
15.  
16. DIM mx, my, a, r, s$
17.  
18. WINDOW (tlx, tly)-(brx, bry) ' converts QB csreen to Cartesian Coodianate System
19. WHILE _KEYDOWN(27) = 0
20.     CLS
21.     WHILE _MOUSEINPUT: WEND
22.     mx = INT(PMAP(_MOUSEX, 2)): my = INT(PMAP(_MOUSEY, 3)) 'covert mouse to Cart Cood using PMAP
23.     a = atan360(my, mx) 'mouse angle to origin
24.     r = INT((mx * mx + my * my) ^ .5)
25.     LINE (0, 0)-(mx, my), grn 'hypotenuse = radius
26.     LINE (0, 0)-(mx, 0), blu ' r*cos
27.     LINE (mx, 0)-(mx, my), red ' r*sin
28.     arc 0, 0, 10, 0, _R2D(a), &HFFFFFF00 'yellow arc
29.     s$ = "Mouse (" + _TRIM$(STR$(mx)) + ", " + _TRIM$(STR$(my)) + "), Radius: "
30.     s$ = s$ + _TRIM$(STR$(r)) + ", Degrees: " + _TRIM$(STR$(_R2D(a) \ 1))
31.     _PRINTSTRING (PMAP(0, 0), PMAP(-1, 1)), s$
32.     _PRINTSTRING (PMAP(-95, 0), PMAP(95, 1)), "COS = x/r = " + _TRIM$(STR$(mx / r))
33.     _PRINTSTRING (PMAP(-95, 0), PMAP(89, 1)), "SIN = y/r = " + _TRIM$(STR$(my / r))
34.     IF mx <> 0 THEN _PRINTSTRING (PMAP(-95, 0), PMAP(83, 1)), "TAN = y/x = " + _TRIM$(STR$(my / mx)) 'EDIT
35.     _DISPLAY
36.     _LIMIT 60
37. WEND
38.  
39. ' A regular graphic draw still works correctly in a Cartesian Window System!
40. 'note: degrees start due East = 0 and go clockwise: South = 90, West = 180, North = 270
41. SUB arc (x, y, r, degStart, degStop, c~&)
42.  
43.     DIM rs, re, a, ax, ay, lastx, lasty
44.     'x, y origin, r = radius, c = color
45.  
46.     'degStart is first angle clockwise from due East = 0 degrees
47.     ' arc will start drawing there and clockwise until degStop angle reached, unless in Cartesain Window
48.  
49.     IF degStop < degStart THEN
50.         arc x, y, r, degStart, 360, c~&
51.         arc x, y, r, 0, degStop, c~&
52.     ELSE
53.         rs = _D2R(degStart): re = _D2R(degStop)
54.         FOR a = rs TO re STEP 1 / (7 * r)
55.             ax = x + r * COS(a)
56.             ay = y + r * SIN(a)
57.             IF a <> rs THEN LINE (lastx, lasty)-(ax, ay), c~&
58.             lastx = ax: lasty = ay
59.         NEXT
60.     END IF
61. END SUB
62.  
63. 'need to match degrees going around clockwise up to full circle
64. FUNCTION atan360 (y, x)
65.     DIM test
66.     test = _ATAN2(y, x)
67.     IF test < 0 THEN atan360 = _PI(2) + test ELSE atan360 = test
68. END FUNCTION
69.  
70.  

See the PMAP for the mouse?

[OldMoses]

I frequently use the WINDOW statement to redefine the coordinate system. I just prefer not having to flip the mathematics around. I've sometimes wondered if it had any particular effect on execution speeds, but QB64 hasn't let me down in that respect yet.

Example is a quickie graphing routine that I wrote to help me with my math function studies. It redefines the screen for x left to right ascending and y bottom to top ascending. That's how I remember it from school. I just comment in or out what I need to look at.

Code: QB64: [Select]

1. A& = _NEWIMAGE(650, 650, 32)
2. SCREEN A&
3. DO: LOOP UNTIL _SCREENEXISTS
4. _TITLE "Graph"
5. _SCREENMOVE 5, 5
6.  
7. WINDOW (-15, 15)-(15, -15)
8. g = -16
9. DO
10.     g = g + 1
11.     LINE (-15, g)-(15, g), &H7F7F7F7F '                         horizontal grid lines
12.     LINE (g, -15)-(g, 15), &H7F7F7F7F '
13. LOOP UNTIL g = 15
14. LINE (0, -15)-(0, 15), &HFF0000FF, BF
15. LINE (-15, 0)-(15, 0), &HFF0000FF, BF
16. FOR x = -15 TO 15 STEP .01
17.  
18.     'FORMULAS
19.     'y = ABS(x) ^ .5
20.     'y = ABS(x)
21.     'y = -1 * (x * x)
22.     'y = -3 * x ^ 2 + 6 * x + 72
23.     'y = x ^ 2 + 7 * x + 6
24.     'y = 4 * x ^ 2 - (12 * x) + 9
25.     'y = (x + 2) / 6 ^ 2
26.     'y = 2 * (x * x) + 2
27.     'y = 2 * x - 4
28.     'y = (x * x) - 2 * x
29.     'y = 7 * x ^ 3 - 63 * x
30.     'y = -.05 * x * x + 6 'parabola
31.     'y = (.5 * x) ^ 3
32.     y = SIN(x) 'sine wave
33.     'y = COS(x)
34.     'y = TAN(x)
35.     'y = TAN(x) ^ 2
36.     'y = _ATAN2(x, 1)
37.     'y = _CSC(x)
38.     'y = 3 / (x - 2) + 1
39.     'y = (x ^ 2 * -_PI) / 6
40.     'y = -.33333 * (x + 1) ^ 3 - 1
41.     'y = (x + 2) / (x - 6)
42.     'y = (x - 6) ^ 2
43.     'y = 2 * (x * x)
44.     'y = x / (x * x) - 4
45.     'y = (x * x) / 2 * (x * x)
46.     'IF x < 0 THEN
47.     '    y = 3 * x + 4
48.     'ELSE
49.     '    y = -x + 2
50.     'END IF
51.  
52.     'y = (x + 2) ^ 2 - 1
53.     'y1 = x * x
54.     'y2 = -(x - 3) ^ 2 + 2
55.  
56.     'DISPLAY CODE
57.     PSET (x, y)
58.     'PSET (x, y1), &HFFFF0000
59.     'PSET (x, y2), &HFF00FF00
60.     'LINE (x, y)-(x, -15), &HFF0000FF
61.     'LINE (x, y)-(x, 15), &HFF000000
62. NEXT x
63.  

[_vince]

I just noticed that WINDOW SCREEN doesn't seem to allow you to have y go up from bottom to top but WINDOW does.  I corrected my code above accordingly - the sine wave is now the correct phase with the origin being the center of the screen.

[bplus]

I just noticed that WINDOW SCREEN doesn't seem to allow you to have y go up from bottom to top but WINDOW does.  I corrected my code above accordingly - the sine wave is now the correct phase with the origin being the center of the screen.

Oops sorry I missed WINDOW SCREEN in your code _vince.

WINDOW does seem to me to maintain consistent and correct trig function for the angle going counter-clockwise as it increases. There is trouble (as I recall) trying to draw arcs with CIRCLE using the start and stop angles which is why I use a separate arc routine that works fine without any change to the trig functions, eg using - sign with SIN. The demo is supposed to demo that, the trig math remains consistently correct, using the WINDOW command that sends increasing radian angles counter-clockwise which is all the math enthusiasts want ie for the graphics to remain consistent with their schooling.

This is why I showed it to STx as he is jumping through hoops to correct BASIC graphic direction of y increasing as you go down the screen. WINDOW does it with some caveats I mentioned (probably more). Well STx confuses the issue with 3D before getting the WINDOW under his belt, of course I don't know ship about GL which might be goofed 3D wise when coding 3D WITH _GL commands, I don't know, but STx does not use that either I am pretty sure.

Oh I notice another discovery I made, use PMAP to correct mouse locations in WINDOW and also _PRINTSCREEN locations are fixed with PMAP :) Ha! but it is a challenge to think in text locations with a Cartesian Coordinate System.

I suppose more WINDOW examples and practice would help clear things up.

[STxAxTIC]

The behavior of the y coordinate is still backwards by default. Whether you use WINDOW or custom LINE and PSET is a matter of taste.

And what's this shit about me being confused about 3D? Spell that out for me, cause these sounds like the ramblings of someone who learned trig upside down...

Window is cute but redundant, and so are you bplus :) just kidding

[bplus]

The behavior of the y coordinate is still backwards by default. Whether you use WINDOW or custom LINE and PSET is a matter of taste.

And what's this shit about me being confused about 3D? Spell that out for me, cause these sounds like the ramblings of someone who learned trig upside down...

Window is cute but redundant, and so are you bplus :) just kidding

The behavior of the y coordinate is still backwards by default. Whether you use WINDOW or custom LINE and PSET is a matter of taste.

Nope! add something to a y coordinate and it goes up the screen not down with proper WINDOW setup.

Code: QB64: [Select]

1.  
2. _TITLE "Test Using Window for Cartesian Coordinate System x = -100 to 100, y = -100 to 100"
3. 'It seems all graphics commands convert x, y to window system BUT...
4. 'Mouse and _PrintString do not convert! BUT...
5. 'Somebody setup a PMAP system that will do these conversions both to grapghics coordinate system and back
6. ' convert mouse qbx, qby to graphics x, y use
7. ' PMAP(qbx, 2), PMAP(qby, 3)
8. ' And to print something at the graphics location use
9. ' PMAP(graphicsX, 0), PMAP(graphicsY, 1) to _PRINTSTRING to a graphics location
10.  
11. CONST xmax = 700, ymax = 700, red = &HFFFF0000, grn = &HFF009900, blu = &HFF0000AA
12. CONST tlx = -100, tly = 100, brx = 100, bry = -100 ' Cartesian Coordinate System corners for WINDOW command
13. SCREEN _NEWIMAGE(xmax, ymax, 32)
14. _SCREENMOVE 300, 40
15.  
16. DIM mx, my, a, r, s$
17.  
18. WINDOW (tlx, tly)-(brx, bry) ' converts QB csreen to Cartesian Coodianate System
19.  
20. x = -100: y = -100
21. PRINT "From bottom left to top right increasing x and y by 1"
22. FOR i = 1 TO 201
23.     x = x + 1
24.     y = y + 1
25.     PSET (x, y)
26.     _LIMIT 10
27. NEXT
28.  
29.  
30.  

and if you don't get this there is no point in arguing and name calling.

And I am saying you, STx, confuse the issue when bringing 3D into the discussion about y going up or down.
ie How the right hand rule is there or not depends on how you set up the z axis with or without WINDOW.

If _GL commands for 3D preserve right hand rule is beyond my scope of experience to comment.

[STxAxTIC]

You are respondng to the wrong concern bplus, did you notice the lack of resistance whilst making your windmill slam dunks against no opponent?

If you think the WINDOW statement occurs in a program by default, as I was saying it does not, then I think you don't have qb64 v 1.4 installed. When I go to file new, the default behavior is as if window is not called. I just got a blank blue screen with a backwards y direction.

Or is window just jumping through hoops? Anyway it's a redundant statement if you've solved this another way and who cares. And wth are you saying about me and 3d again? I missed it twice. People might actually believe you, which is why I need to call you out each time you mention it.

[STxAxTIC]

Oh wait I get what you're saying

No, the right hand rule has a 3d implication even when all coordinates are in 2d strictly, it does not confuse the issue to need the right hand rule to be correct in a strictly 2d system. I see what you want to mean though, honest.