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.

Bumping this thread!

Hi there,
FIRST of all “I want to make it clear we/I did NOT abandon Looking Glass”, quite the contrary BUT we been literally “overloaded with other work”.

To make it short ( you can have more details of our day-to-day doing by following Jeff’s twitter @llamasoft_ox ) I’ve been finishing another game that was supposed to come out on PS4 but will come out on PC/Steam first called “Moose Life”.

This, for “compatibility issues” is based on OpenGL/OpenVR it performs “quite so well” I was thinking in a future to add support of LG but a first quick test … “eh rendering 43 frames are quite bit” wasn’t super promising … however it’s another of those things “set aside for the future”.

The other thing is, no mystert that much so far, we are working on a totally NEW engine/synth for VLM 4.0 ( Llamasoft Lightsynths ) which is "a complete new evolution of all that in VR ) and is totally Vulkan-based.

I became “a Vulkan adepth” I am now “all Vulkan” I wear a Vulkan t-shirt, I am “obsessed” in “getting the max frame rate/performance I can ever get” … so far working on/for Oculus Rift / Quest but “I do have plans” for “further investgations/applications into LG”.

Problem is as a “small indie developer” ( we are still and only in 2 people ) you are often between the “what I’d be nice to do” and “something to pay the bills at least a bit” so it’s a juggling of times and resources act.

Say that I’ll keep saying that “I LOVE Looking Glass”, I wish I could afford the higher res version but maybe one day, I’d be also curious at some point to try our newest VLM 4.0 thing on it becuase “I have absolutely NO IDEA how it could look like” :slight_smile:

So yeah “all BUT abandoned”, the LG is always here on my desk and I am thinking “yeah can’t wait to try this/that now that I know more about Vulkan”.

Also “another of those thing that just came out” … looks like “finally” some people decided to start usign OpenXR, the new “standard” by Khronos … which means I will have to have a look into it as well … so “even more time that goes”.

Yeah also that SW “has a bit of bugs and things” that I am probably going to fix soon as well as I fixed them for “Moose Life” ( the new game soon to come out on Steam ).

Anyway I’ll try my best to put a bit of “more love” for the LG the fact is “now that I know a bit of something about Vulkan” LG “deserves a special treatment by its own” and a bit of experimentation.

My only advice to LG people would be “always keep things as simple as you can and DOCUMENT all as much as you can” … “leave us do the weird things in Vulkan” don’t make APIs/ui “too complex” “let the low level to me” :smiley:

Seeyou :slight_smile:

Hi @GilesGoat - we’ve been trying to alter our approach to our dev tools along these lines, your experience working with our original (now deprecated) C API was a big part of that. We have a new version of this that is meant to be much more minimal and transparent, you can check out the documentation for that here. I’d be interested to hear what you think!