Fool me, this is real good shit ! [the VR thread]

[gilesgoat]

Yeah, that's a big contribution. However, I get it standing outside, on concrete, too .

MA DIO (*$#@()$*)@#( wtf is doing this "EnumerateDisplayDevices()" returning something like \\.\DISPLAY1 .. and NOT giving me also something like :
\\.\DISPLAY1\Monitor1 .. where do I get that "Monitorx" out ??

[edit] -- MI ME LANCIO DA UNA FINESTRA !!

WTF is the difference between EnumDisplayDevices(),EnumDisplayDevicesW() and EnumDisplayDevicesA().

I tough the one without W/A was choosing depending on WideChar or Not .. it seems that EnumDisplayDevicesA() returns ONLY .\\.DISPLAY1 while
EnumDisplayDevices() returns .\\.DISPLAY1\Monitorx ...

To me that sounds some "weird strncat problem somewhere" .. wtf .. wtf ???

[pogo]

This is fun: a HD drone which works with you iOS / Android device and optionally a Rift

http://www.bbc.co.uk/news/technology-27403761

He has it on for only a few seconds though and finds it 'slightly nausea inducing', which you don't really want when controlling an expensive aircraft, even an unmanned one. Must be expensive too: the drone, an iPad, a Rift and a dedicated controller which connects them together and provides a range-boosting antenna.

[DeanoC]

To me that sounds some "weird strncat problem somewhere" .. wtf .. wtf ???

I suspect you are right, the blahblahA are on the legacy line now I think, so probably not entirely tested that well these days. After all in reality only useful for Win9x, as NT has always been unicode, you can probably wrap your own version of that blablahA function just using

Code: Select all

	std::string wstring_to_utf8(const std::wstring& str)
	{
		std::wstring_convert<std::codecvt_utf8<wchar_t>> myconv;
		return myconv.to_bytes(str);
	}

around the strings, will convert the unicode 16 bit code points into UTF8 so can be handled by good old char code. IIRC requires VisStudio 2012 as before there was a bug in codecvt_utf8.

[gilesgoat]

To me that sounds some "weird strncat problem somewhere" .. wtf .. wtf ???

I suspect you are right, the blahblahA are on the legacy line now I think, so probably not entirely tested that well these days. After all in reality only useful for Win9x, as NT has always been unicode, you can probably wrap your own version of that blablahA function just using

Code: Select all

	std::string wstring_to_utf8(const std::wstring& str)
	{
		std::wstring_convert<std::codecvt_utf8<wchar_t>> myconv;
		return myconv.to_bytes(str);
	}

around the strings, will convert the unicode 16 bit code points into UTF8 so can be handled by good old char code. IIRC requires VisStudio 2012 as before there was a bug in codecvt_utf8.

No ... no no no no .. it's le chalisse ...

One of the biggest mistakes in my life been "fuck all this shit, let's go all unicode full stop".

UTF-8 .. UTF-8 is what you want .. and NOTHING ELSE ..

1 byte per thing use extra bytes IF necessary ...

Anything else I tried with "unicode" or "other standards" always seems to miserably fail in some HW or another or one OS or another hopelessly.

Anyway back to this I was JUST telling Yak "it is true something CPP can create code that ONLY the one that made it, maybe ... I'd like to see this 6 months later .. can understand it".

I tried to debug/hack the OVR lib to understand "how the heck they enumerate those devices" .. well .. "you kinda get the idea about what the code kinda does" .. "kinda" .. but you don't really get PRECISELY how .. after getting lost in "too many templates" and not sure at this point what's calling what and where ( let alone where are the parameters going ) it's like .. "ok, the heck knows how they get something that I can't get in any way" .

Anyway turns out the problem I belived was there wasn't there, there was nothing wrong with my previous enumeration way and nor with the second I've done, in fact they were equivalent/almost identical.

"Almost" because anyway they were getting something like "Display1/Monitor1" in a CLONE mode, while I was getting a "Display1/Monitor0" and "Display2/Monitor0" as - according to MSDN - should be correct when you are in clone, you'd get
that 'Monitor1' only if your monitor is "extended".

So at that point is like "the fuck I know how they get that/who is more correct in this case and why".

But you really don't have to look at that "monitor" you really have to look and need only at that "DisplayX".

Anyway the problem wasn't there.

The problem was someone was working in clone mode with a display that was not supporting the OR "higher res".

I.E. the OR has a native res of 1200x800 BUT the display supports a couple of more modes higher than that, now many people found out that - keeping proportions and all the rest correct - as the PHYSICAL dimensions of the device don't change ( that ratio does but that gets corrected ), if you set a higher res the downsampling does a much better AA than what you'd do 'at cost 0' because it's done inside the OR HW and does not impact latency.

Try to believe it, it's *MUCH* better if you set 1920x1200 and you draw like that.

Of course if you are in clone mode and your display does not go over 1080 ....

[DeanoC]

Code: Select all

	std::string wstring_to_utf8(const std::wstring& str)
	{
		std::wstring_convert<std::codecvt_utf8<wchar_t>> myconv;
		return myconv.to_bytes(str);
	}

No ... no no no no .. it's le chalisse ...

One of the biggest mistakes in my life been "fuck all this shit, let's go all unicode full stop".

UTF-8 .. UTF-8 is what you want .. and NOTHING ELSE ..

1 byte per thing use extra bytes IF necessary ...

Anything else I tried with "unicode" or "other standards" always seems to miserably fail in some HW or another or one OS or another hopelessly.

Yep, which is why that five line bit of code is awesome, it converts any OS wstring to UTF-8 in a portable way. The OS can choose to use shift-JS if it wants and this code will give UTF-8 and then we can stop worrying.
This is a good drop in library for C++ utf8 stuff for anything more fancy http://www.codeproject.com/Articles/146 ... rtable-Way

[MegaZoid.]

https://www.kickstarter.com/projects/80 ... ref=banner
Interesting.

[Darkflame]

I like that controller concept.

[Misfit]

Although I have a DK2 on order this may be worth keeping an eye on. Reasonable price considering you get controllers and I like the way it's being made to work with existing systems/games.

Of course it could also go horribly wrong....

[MegaZoid.]

Could definitely go wrong , just look at the agent smart watch I funded last year , no physical evidence it even exist yet.
That hasn't stopped me slapping the money down for this though, Doh.

[axel000]

So a Chinese rip-off of Occulus ? Since when has any good gaming hardware been designed in China ? Its good to see the field expanding but I have doubts about this one.

[gumboot]

What is there about Occulus specifically to rip off? Isn't it exactly the technology that people have been trying to make work for a couple of decades?

[Whiteball]

But it isn't going to give you the 'proper' VR experience is it? You know, presence and all that?

They say it will work with ANY game, so is it just like having a large screen in a dark room or being at the cinema when the lights go down?
While that could/would still be good, it doesn't sound like what the other VR people are promising.

[Misfit]

But it isn't going to give you the 'proper' VR experience is it? You know, presence and all that?

They say it will work with ANY game, so is it just like having a large screen in a dark room or being at the cinema when the lights go down?
While that could/would still be good, it doesn't sound like what the other VR people are promising.

The way I read it is that it will do both.

[Yak]

You can't just automagically make it work with any game. The rendering sequence is different for a VR game and a "normal" game. A normal game renders one view from the in-game "camera", projecting it on a plane that is what is displayed on your monitor. A VR game has to render the scene twice slightly offset - this is what makes the view stereoscopic, one slightly different view for each eye. There is usually a further pass with a shader that corrects for the distortion of the optics and optionally for any chromatic aberration introduced by the optics.

The double-rendering pass *must* be done in the internal game logic. It can't be grafted on to any game afterwards. You can't just magically make any existing game work properly in VR - you can hook up the headset orientation to work like mouselook or whatever, but without generating the stereo view the game will not look like proper VR.

By far the greater problem though is that even if you do the correct rendering, just taking an existing game and replacing mouse/joystick input with head tracking control does not work well at all. You can bolt on the correct rendering but what people are overwhelmingly finding with VR is that the actual underlying game has to be made with VR in mind or else you will end up with something that is very likely to sicken users and make them never want to play in VR ever again.

There simply is no "one size fits all" solution that will allow anyone to retrofit VR onto older games and systems. Not going to happen.

[gilesgoat]

In short : get any traditional 3D game, do two projections and put it "into VR" == quite possibly you created a vomit machine and a very disgraceful experience.

It HAS to be designed for VR, tested as VR, changed and even completely redesigned for VR.

"VR is NOT cheap" is going to take considerable investment of research and work to support it, if you are not ready / can't put that into it then you won't.

Also it has to be "quite snappy" this is the place where "60 fps or death" anything below that is going to make all feel pretty clunky and again nausea inducing.

This is probably dawn of a new era, many will fall, some will go on, once "the tricks and methods to do things right" will become more common knowledge loads will jump on it and then 'everyone will be doing it'.

Probably .. but quite possibly that's the pattern of things.