Minotaur Arcade Vol1 supporting Looking Glass

I don’t know how to put this here anyway let’s say we created our first commercial product supporting Looking Glass.

It’s added in as “experimental” in the sense that things are not - yet - super optimised for it but it does work and it’s as “an extra” in our game engine.

Unfortunately as it’s part of an “upgrade” to our existing game ( apologizes for “shameless promotion” ) “Minotaur Arcade Volume 1” is present as BETA ( which means you had to have purchased a copy of the original to try it ) on Steam

STEAM - Minotaur Arcade Volume 1

It’s quite playable and it’s all OpenGL based, if it does happen you have that game you can try now the BETA and see how it works.

Overall we plan to continue to support Looking Glass for all our future games however “as soon as possible” I am planning another “technology migration” I have future plans to ditch OpenGL in favour of Vulkan and re-make a “totally new custom Vulkan driver” for our game engine with specific emphasis on VR and LG.

There was this short video we done some months ago

Small video

Overall we are still very happy about LG and we want to continue to support this technology.

So in case you have that game you can try the BETA in case you don’t well … it’s a really nice game :blush:



This looks fantastic! Just bought it and switched to the beta channel.
I’m having trouble getting it to run on my machine - selecting “Looking Glass” and setting the resolution to 2560x1600/ fullscreen doesn’t seem to do anything - I get the game in windowed mode and there’s no lenticular shader being applied.
Rest assured that I was very careful to ensure that the calibration + drivers were not the problem. :slight_smile: If it makes a difference, I’m running the “fast” Windows insider preview. Will try on another machine shortly…

I think there could be some problem IF your looking glass is NOT the “primary display device” or sorta, the code I used tries to basically looking for an ‘id string’ but look I am literally using this sort of stuff


	int count;

	count = 1;

	GLFWmonitor** monitors = glfwGetMonitors(&count);

	GLFWmonitor* the_monitor;

	// the default PRIMARY monitor
	the_monitor = NULL;

	bool foundLKG = false;

		const GLFWvidmode* vidMode = NULL;

		if (count > 1)

			// first search for a 2560 x 1600 monitor
			for (int i = 0; i < count; i++)
				vidMode = glfwGetVideoMode(monitors[i]);
				if (vidMode->width == 2560 &&
					vidMode->height == 1600)
					the_monitor = monitors[i];
					foundLKG = true;

			// now search by name, which seems to be unreliable
			for (int i = 0; i < count; i++)
				std::string lowerName = glfwGetMonitorName(monitors[i]);
				PRINTF("Found: %s\n", lowerName.c_str());
				std::transform(lowerName.begin(), lowerName.end(), lowerName.begin(), ::tolower);
				if (lowerName.find("looking") != std::string::npos ||
					lowerName.find("lkg") != std::string::npos ||
					lowerName.find("holoplay") != std::string::npos)
					the_monitor = monitors[i];
					foundLKG = true;

			//PRINTF("Monitor name : %s\n", glfwGetMonitorName(monitors[1]));
			//the_monitor = monitors[1];

		if (foundLKG == false)
			PRINTF("Looking glass monitor NOT found\n");
			*isWindowed = true;
			the_monitor = NULL;
			*isWindowed = false;
			// whatever it likes
			if (vidMode)
				glfwWindowHint(GLFW_REFRESH_RATE, vidMode->refreshRate);
				refresh_rate = (float)vidMode->refreshRate;


	} // if (flags == INIT_FLAGS_USE_LOOKING)


But I think i’ve seen a few times that unforuntately “that strings” never contains any of those info.

Try to mess up a bit with monitors, it’s still a beta and no should NOT go “full screen” I mean just leave it as “Looking Glass”, maybe try to remove the fullscren flag.

It’s BETA … but once it starts it should go ok, I’ll check a bit more later this afternoon.



Yep, the GLFW monitor name strings are, as far as I can tell, a bit of a lie. On macOS they return the values you expect (“LKGxxxxxxx”) but on Windows they return something like “\DISPLAY1” or some such; it has to do with the way the displays are enumerated in the registry.

FWIW, I could not get the window to go fullscreen, or the lenticular shader to appear, with any of the following configurations (all of them with resolution set to 2560x1600, websocket driver verified enabled, “Looking Glass” button used to launch game):

  • Looking Glass set to main display, fullscreen off
  • Looking Glass set to main display, fullscreen on
  • All other displays disabled, fullscreen off
  • All other displays disabled, fullscreen on

I’ve been working on a way to consolidate these kinds of issues basically ever since we last corresponded, and there are some new developer tools in the pipeline very soon that I hope will help to resolve a lot of these exact issues - hopefully ultimately we will be able to abstract away the headache of calibration and windowing (both of which have been irritating us ever since we released the first few versions of the SDK) as much as possible.

So, you can expect this project to be released shortly – it’s an RPC service through which you can request both calibration and window coordinates.
In the meantime I really want this game to work reliably, so I can share with you something I worked on as a potential stopgap measure: here’s a modified version of the calibration load executable that exposes window coordinates of the Looking Glass display; you can find them by launching the exe with -m flag from the command line.

you may be right, I suspect “something changed with some WIN10 update” I found out my code has a small problem I already corrected I’ll have soon to put up another beta.

I am finding like I have to re-install the driver any time to get it working, otherwise it’s really like the driver is NOT running and I get a “refused connection”.

Still, after I finished and got all the string and I perform


	// Gracefully close the connection.

	dwError = WinHttpWebSocketClose(hWebSocketHandle,
	if (dwError != ERROR_SUCCESS)
		PRINTF("WinHttpWebSocketClose returned error %d\n", dwError);
		goto quit;

I always obtain

WinHttpWebSocketClose returned error 12030


Despite correctly receiving the string such as

Received message from the server: ‘{“configVersion”:“1.0”,“serial”:“LKG-2K-01876”,“pitch”:{“value”:47.59394073486328},“slope”:{“value”:-5.403369426727295},“center”:{“value”:0.11983698606491089},“viewCone”:{“value”:40.0},“invView”:{“value”:1.0},“verticalAngle”:{“value”:0.0},“DPI”:{“value”:338.0},“screenW”:{“value”:2560.0},“screenH”:{“value”:1600.0},“flipImageX”:{“value”:0.0},“flipImageY”:{“value”:0.0},“flipSubp”:{“value”:0.0}}’

So I had to modify the code to ignore that error message, still it would appear that I need now any time to re-install that driver to have it working.

Also, how comes I CAN NOT see that thing in the “Services” ? I have to way to see if it’s running or not ?


Ivan Z.

Yup, well, the requirement for a websocket connection to access the USB devices is because browser-based applications can’t natively access the hardware (in theory, WebUSB will change that).

The structure of the websocket driver is as follows:

  • websocketd pipes the shell output of the calibration loader executable to a websocket running on localhost:11222.
  • As soon as an application opens a websocket connection at that address, websocketd is triggered to run the executable and forward the calibration from stdout over that pipe.
  • This system is really only designed for use with holoplay.js, due to the browser’s sandboxed access to USB devices, and it’s always been a bit of a hack. Native applications should use the native interfaces we provide through HoloplayAPI.dll / HoloplayAPI.dylib, which is how our Unity, Unreal, and Blender SDKs work.
  • The calibration loader doesn’t run persistently; only websocketd does. If you want to find the responsible process in the task manager, search for lkg-websocketd.exe.
  • If I were you, I would either use HoloplayAPI.dll (you have access to the C API libraries, right?) and call the load_calibration function to return a char[] with the calibration string. For a quick and dirty solution, you can also copy the calibration executable out of the driver directory and call it from your game, or use the slightly hacked-up version I uploaded in my previous post on this thread. (That one wraps GLFW functions to deliver the top-left window coordinate of the attached Looking Glass.)
  • We are well aware that all of this is annoying from a developer perspective, but cross-platform hardware access and windowing on a platform level are rather difficult problems to solve, prior to OS-level support for XR devices (recall the Oculus DK1 workflow). I am leading a product that will greatly simplify nearly all of these issues, that we will be rolling out over the next few weeks.

Here’s one more explainer of where the various calibration load executables are located and what they do.