on Windows 10 remote desktop not work.

[aviscaerulea]

I use Ebiten v1.9.3 and Golang 1.12 on Windows 10 Pro 1809.
The following error occurred when trying to display the Ebiten window on the remote desktop PC.

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x4f1262]

goroutine 1 [running, locked to thread]:
github.com/hajimehoshi/ebiten/internal/glfw.(*Window).GetMonitor(0x0, 0x0)
	D:/sample/vendor/github.com/hajimehoshi/ebiten/internal/glfw/glfw_windows.go:135 +0x42
github.com/hajimehoshi/ebiten/internal/ui.(*userInterface).currentMonitor(0xa5f180, 0x15decd4)
	D:/sample/vendor/github.com/hajimehoshi/ebiten/internal/ui/ui_glfw.go:955 +0x36
github.com/hajimehoshi/ebiten/internal/ui.glfwScale(0xc00005c2a8)
	D:/sample/vendor/github.com/hajimehoshi/ebiten/internal/ui/ui_windows.go:105 +0x34
github.com/hajimehoshi/ebiten/internal/ui.initialize(0xf, 0xc00009d140)
	D:/sample/vendor/github.com/hajimehoshi/ebiten/internal/ui/ui_glfw.go:116 +0x122
github.com/hajimehoshi/ebiten/internal/ui.init.0()
	D:/sample/vendor/github.com/hajimehoshi/ebiten/internal/ui/ui_glfw.go:89 +0x2e

[hajimehoshi]

Thank you for reporting! I'll take a look...

[hajimehoshi]

Looks like glfw.CreateWindow returns nil without errors. I'm not sure the reason 🤔

[hajimehoshi]

It seems hard to fix this issue, maybe...

glfw/glfw#1245

[glycerine]

Windows virtual machines also might not support OpenGL/GLFW. Is there a way to force a different graphics driver, @hajimehoshi , or none at all? Output is going eventually to the web page for display, so let the browser worry about how to render the images.

[glycerine]

mechanics of the problem, and a really lame workaround are here:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS

quoting that forum thread:

When you start the OpenGL apps on the office PC using the 
physically attached monitor and keyboard, the graphics card 
may be checked by OpenGL - there are some OpenGL apps 
that require physical hardware support and other OenGL apps 
that are happy with rendering OpenGL in software. Both checks
 are successful in this scenario and both flavors of OpenGL run 
properly. Now you go to your home PC and establish a remote 
connection to this user session. During the connection process, 
the capabilities of the home PC's graphics card is sent to the host 
PC in order to optimize the graphics output. This is required to
 do some rendering on the receiver side rather than on the 
sender side. This is done for GDI graphics primitives, but not 
for openGL primitives. In your "remoting into existing user 
session" scenario the OpenGL output on the host is sent to 
the client pixel by pixel.

When you establish a new connection from a home PC to an
 office PC, the home PC's graphics capabilities are relevant for 
the user session. Such a remote session does not support 
OpenGL in hardware - in other words, there is no 3D hardware 
graphics support. This is why only the software OpenGL app 
starts, but not the hardware OpenGL app. So your system 
works as designed even if it sounds weird.

Note: In both scenarios all applications run on the office 
PC. In the second scenario the graphics options are a little 
bit different due to the OpenGL app already launched in 
the existing user session. Actually, I'm surprised that it 
works at all. I would have expected that the hardware 
OpenGL app throws an error when remoting into the existing session.

I'm afraid that there's not much can do about this behaviour 
if you don't want to invest into Citrix (HDX Pro) or VMware/Teradici 
(PCoIP in HW) which supports 3D graphics acceleration in 
hardware from workstation to workstation. Another option 
is to run your OpenGL apps in Win7 virtual desktops hosted 
on Windows Server 2008 R2 SP1 Hyper-V and use the 
RemoteFX extension of the RDP protocol. This option also 
supports OpenGL in hardware if the appropriate graphics 
adapter is installed on the Hyper-V server.

Benny

latest workaround script

@echo off
echo.
echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
echo.
pause
@echo on
REM The active session has an arrow as the first character
setlocal EnableDelayedExpansion
FOR /F %%A in ('qwinsta') do (
	set tempSessionName=%%A
	if "!tempSessionName:~0,1!"==">"  ( 
		@echo on
		tscon.exe !tempSessionName:~1! /v /dest:console 
		@echo off
	)	
)
@echo off
echo.
echo Starting MyProgram.exe . . .
@echo on
start MyProgram.exe
@echo off
echo.
pause

[glycerine]

looks like Chrome solves this problem by using ANGLE:

https://opensource.google/projects/angle

"How Google uses ANGLE: ANGLE is used by Chromium and Google Chrome to enable WebGL functionality without having to rely on OpenGL drivers."

[glycerine]

A simpler solution than ANGLE: the library https://github.com/gonutz/d3d9 offers DirectX bindings for Golang.

I confirmed they work by trying this client game (by the same author) and it ran fine over RDP on windows 2016 virtual machine: https://github.com/gonutz/ld36 (whereas ebiten always crashes on the same setup with the "panic: ui: glfw.CreateWindow must not return nil" at github.com/hajimehoshi/ebiten/internal/uidriver/glfw/ui.go:122

[glycerine]

Apparently Allegro uses the directX when available too. https://github.com/dradtke/go-allegro

[hajimehoshi]

Windows virtual machines also might not support OpenGL/GLFW. Is there a way to force a different graphics driver, @hajimehoshi , or none at all?

I confirmed OpenGL (and Ebiten) worked on Parallels. I'm not sure the others.

A simpler solution than ANGLE: the library https://github.com/gonutz/d3d9 offers DirectX bindings for Golang.

Using Angle, or directly DirectX 10 sounds the way to go. (I'd want to avoid 9 since 9 can cause device lost)

[hajimehoshi]

I understand using DirectX in some forms is the way to go, but the cost is too large compared to the benefit: the benefit is only for remote desktops so far?

[glycerine]

the benefit is only for remote desktops so far?

Yes.

I thought though, that there might be some way to avoid needing a driver at all...

If a driver is required, I agree it hardly seems worth making ebiten portable to remote windows.