Drawing different screens on different monitors from 1 program? (Multi Monitor)

[madscijr]

Hi all,

I saw the "Multi Monitor" thread from July

• https://www.qb64.org/forum/index.php?topic=4082.0

which discussed the _SCREENMOVE command.

What if you want to simultaneously display different output on 2 or 3 different displays from one program?

For example if you wanted to make a flight or driving simulator where the middle monitor shows the front view, and the side view is displayed on the right/left monitors, or perhaps a simple game of Battleship where each player's view is in a different display. Or a game where screen 1 is the map and screen 2 is statistics. Etc.

With _SCREENMOVE it sounds like there is still just one screen per program. I suppose you could have a main program which drives display #1, and separate child programs running concurrently which control the other displays based on data sent from the main program (is there an efficient way to get 2 QB64 programs running concurrently on the same computer to talk to each other, besides reading & writing to a file?)

Anyway, has anyone done a simultaneous multi-display program in QB64?

Any information or advice appreciated...

[Petr]

Hi. I don't have two monitors to try. I think it could work something like this, in this case the default monitor is on the left, it will make a blue screen and the one on the right will make a red screen with the same resolution.

It's just a suggestion that may work, but only if you have your desktop set up as an extended, not as a copy of desktop. It is also a question of whether _DESKTOPWIDTH and _DESKTOPHEIGHT are then counted only for a specific monitor, or whether it contains the overall resolution. And this implies the need for a new function that could switch between individual monitors (to get their resolution), I do not know if you can use the _DEVICES function to this (I do not even have how to try it).

Code: QB64: [Select]

1. 'let say, you have two monitors, both with resolution 1920 x 1080. Windows desktop is set as one screen with resolution 2x 1920 x 1080:
2.  
3. ScreenA = _NewImage(1920, 1080, 32)
4. ScreenB = _NewImage(1920, 1080, 32)
5.  
6. Screen _NewImage(1920, 1080, 32)
7. _FullScreen
8.  
9. $Color:32
10. _Dest ScreenA
11. Cls , Blue
12.  
13. _Dest ScreenB
14. Cls , Red
15.  
16. _PutImage (0, 0), ScreenA, 0
17. _PutImage (1921, 0), ScreenB, 0
18.  

[Petr]

So I found a way to try it but I have bad news. 1) after connecting two monitors (specifically, I found a VGA cable and connected a laptop to the second input of the monitor), the resolution of both monitors in windows 7 is set the same, accordingly with a lower resolution (extended desktop mode). QB64 coordinates can only be seen on the first monitor, the example above does not work (of course when using the correct resolution). So I tried the mouse. The mouse that moves to monitor number two in the system gets out of focus (probably that's the problem) and _MOUSEX stops responding and stays at the maximum level _DESKTOPWIDTH even if it moves on the right monitor, QB64 can't see it.

I tried it in QB 1.4 because on a laptop, I don't have a newer version of the IDE. So - it probably won't work.

[bplus]

Got 2 AI programs playing each other, they shared a data file that tracked the moves of each player. When the other player finished, the next player up had it's turn to play and add to data file it's move. Worked OK. The first player's duty at startup was to start a new data file. Probably had to start the 2nd AI after 1st player made it's move.

If you need several screens I would say developing them on the side and _putimage to screen when and where needed. Although QB64 is one screen PL you can program as if a Windows OS is controlling what and where things go. I've seen Keybone and _vince (maybe Petr or TempodiBasic too) start these and Rho Sigma has multiple-screens in his projects resume.

[Petr]

I made another attempt. So yes, two monitors can be used. If you have two monitors with the same resolution, you will do so in _DESKTOPWIDTH * 2, _DESKTOPHEIGHT. The program window is then drawn over both monitors, so if you want to solve it separately, you have to take this into account in the program. The program window simply splits between the two monitors. I took a picture of the result (the red area is the area of the program window), this time my monitors uses different resolution.


This code:

Code: QB64: [Select]

1. Screen _NewImage(_DesktopWidth, _DesktopHeight, 32)
2. $Color:32
3. scr = _NewImage(_DesktopWidth * 2, _DesktopHeight, 32)
4.  
5.  
6. Screen scr
7. Cls , Red
8. _ScreenMove 0, 0
9.  

do this output:

  [ You are not allowed to view this attachment ]  

[SMcNeill]

I don't think the OP is talking about writing one program that spans two screens; what he's wanting is to produce two screens which can be positioned independently on each monitor.  Unfortunately, QB64 doesn't have "child windows", so I think the closest he can get to his desired results is with the main window and a separate console window.  That's all the "multi-screen" support we offer intrinsically.

[Petr]

Well, maybe I misunderstood. But if not, then now is verified, that if @madscijr has two monitors with a resolution of 1980x1050 and makes the main program SCREEN in 3960x1050 resolution, then it will be able to use _PUTIMAGE on this screen and place the graphic outputs anywhere in this area of the two monitors. So in my first case it would work, I only initiated one monitor with the SCREEN command, but for it to work on both, the called SCREEN must be large across both monitors.

[Petr]

And if @madscijr really wants more windows with graphic outputs on one monitor, then it can be done as well. Although they will not be classic windows as we perceive them, you can use _DEST, _SOURCE, _PUTIMAGE to make windows with graphic outputs, you can redirect any graphic or text output to them. Just use virtual screens...

[Petr]

@bplus i think, you talk about COMMON SHARED between two programs. Then is really possible runing more EXE files (windows), and run it with shared variables between this two or more programs. It is somewhere in forum...

[OldMoses]

My space flight project is one that I've thought about modifying to do something similar. Mind you, I've only thought about it, and have not tried any implementation. I really haven't used multiple monitor setups enough to fool with it.

It being a RPG utility, I could run a setup where the gamemaster would have one screen showing all the action and another monitor which would have only what the players would have access to.

I assumed that since only one screen could be drawn, one would just make a double width screen, draw the desired details on each half and _SCREENMOVE _DESKTOPWIDTH - _WIDTH(0)/2, 0 {or whatever ratio desired} to split between the two as a work around for not having two separate screens.

Alternatively, upon a certain condition being true one could move the screen at will with a _SCREENMOVE that alternates between 0 and _DESKTOPWIDTH +1

...well anyway, nothing would beat a try, but a failure...

[bplus]

@bplus i think, you talk about COMMON SHARED between two programs. Then is really possible runing more EXE files (windows), and run it with shared variables between this two or more programs. It is somewhere in forum...

No, the 2 programs access the same Data file. The programs can both be running on my computer or one on your computer and one on mine, as long as we can get the data file updates from both programs. We could just pass the data file back and forth between us at this forum. Would not be practical for real time action though. The program, Connect 4 AI, was tried at Steves old forum before he closed it to new members.

[madscijr]

@bplus i think, you talk about COMMON SHARED between two programs. Then is really possible runing more EXE files (windows), and run it with shared variables between this two or more programs. It is somewhere in forum...

Thanks everyone for your replies.

I would really prefer each screen be discretely seperate, and not treated as one big window where you plot each "screen" to a portion of the window, or dependent on both displays having the same resolution.

It sounds as though having seperately running programs that communicate to each other is the way.

Using a file to share data is probably fine for something like Battleship, or a D&D type game where the dungeonmaster sees their view on one screen and the players get a different view on screen #2, where screen updating doesn't have to be done in realtime.

But for realtime action games like a flight or driving sim (where you want to continuously update 3 displays with the front / left / right views), I think some more direct and faster method of communication between processes would be necessary.

So the shared variables you mention might be the answer. Do you recall what subject line to search the forums for?

Thanks again!

[SMcNeill]

In that case, I'd use OPENHOST and OPENCLIENT to form a TCP/IP connection between the two programs, ofwhich there are several examples already here on the forums via chat hosts and clients.

[Petr]

I'm glad we finally came to a solution. I have to laugh at my English. This is not the first time I have answered something other than what the author of the topic asks. I apologize for that, but on the other hand, at least it's fun here, isn't it?

:)

[FellippeHeitor]

(...) but on the other hand, at least it's fun here, isn't it?


:)

🤗