cancel
Showing results for 
Search instead for 
Did you mean: 

The image displayed on the screen of DK2 is large.

ttymsm
Honored Guest
I made a small program that runs on Windows 7(32bit) using OpenGL and SDK0.4.2.
It has been compiled using the MinGW (ghc) .

It will be drawn correctly on the screen of the PC when I run the program .
(Display Mode : Direct HMD Access, not support DK1 Legacy)

* captured PC Screen
https://drive.google.com/file/d/0BxywUl6rPiyHbUVQQy1RNGp2Qk0/edit?usp=sharing
(window size = 1920,1080)

However , intended does not appear on the screen of DK2.
Size of the image and DK2 screen size does not match .

* captured by the camera screen of DK2
https://drive.google.com/file/d/0BxywUl6rPiyHRWVJYWlTdzJCb3c/edit?usp=sharing

Where of a program do I need to check?
Please advise me.

### PC spec ###
CPU : core i7 860
Video Card : nVidia GeForce 760 (Driver Ver. 344.11)
4 REPLIES 4

jherico
Adventurer
Looks like you're specifying the wrong viewport for the textures you're using to pass into the SDK. You need to make sure that the texture viewport resolution is the size of the texture, not the size of the Rift resolution.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

skynet
Honored Guest
I experience exactly the same problem(GTX 660Ti, SDK 0.4.2, OpenGL, Win7 64bit). Its certainly not the viewport size since exactly the same code works fine in extended mode and debugging shows correct values.

Interestingly, the size and position of the mirror window on the desktop changes what is visible on the Rift?! I assume a big bad bug in the Oculus display driver or in the code that transfers/blits the image to the rift.
Another interesting point is that the Tuscano Demo works just fine in Direct Mode, even when switched to OpenGL. I could not find any difference between my code and what the demo is doing 😕

ttymsm
Honored Guest
Thank you reply.

I have been using ovrHmd_EndFrame.
And , the value of ovrGLTexture has set the following .


leftEyeTextureHeader = OvrTextureHeader
{ apiT = ovrRenderAPI_OpenGL
, textureSize = (2364 , 1401)
, renderViewport = (0,0) (1182,1401)
}
rightEyeTextureHeader = OvrTextureHeader
{ apiT = ovrRenderAPI_OpenGL
, textureSize = (2364 , 1401)
, renderViewport = (1182,0) (1182,1401)
}


* ( 2364 , 1401) = (1182 * 2, 1401)
(1182, 1401) the return value of ovrHmd_GetDefaultFovTextureSize.

This setting is correct?

> Its certainly not the viewport size since exactly the same code works fine in extended mode and debugging shows correct values.

It seems no problem in Extend mode is also my program .

>the size and position of the mirror window on the desktop changes what is visible on the Rift?!

The same problem occur.

skynet
Honored Guest
I think I found a hint an what's causing the problem:
There's a function in the SDK that gets called during the initialization of the SDK which seems to provide the rendering shim with the vital parameters:

bool DisplayShim::Update(Win32ShimInfo* shimInfo)
{
ChildUid = shimInfo->DeviceNumber;
ExpectedWidth = shimInfo->NativeWidth;
ExpectedHeight = shimInfo->NativeHeight;
Rotation = shimInfo->Rotation;
UseMirroring = shimInfo->UseMirroring != 0;
return true;
}

But it seems, when this is being called, its already too late. Instead, its going to use the default parameters which are DK1's:

DisplayShim::DisplayShim() :
ChildUid( 0 ),
ExpectedWidth( 1280 ),
ExpectedHeight( 700 ),
Rotation( 0 ),
hWindow( 0 ),
UseMirroring( TRUE )
{

}

Setting those to DK2 values, gets me the right output:

DisplayShim::DisplayShim() :
ChildUid( 0 ),
ExpectedWidth( 1080 ),
ExpectedHeight( 1920 ),
Rotation( 90 ),
hWindow( 0 ),
UseMirroring( TRUE )
{

}

So, despite the claim that a call to ovr_InitializeRenderingShim() at the beginning of the program is enough, it doesn't seem to work properly. There's still some other undocumented order-dependency that leads to failure.

Now that I have _some_ output, I note its much too dark and I can see color-banding as if the backbuffer was 16bit - weird!
Still need help?

Did this answer your question? If it didn’t, use our search to find other topics or create your own and other members of the community will help out.

If you need an agent to help with your Meta device, please contact our store support team here.

Having trouble with a Facebook or Instagram account? The best place to go for help with those accounts is the Facebook Help Center or the Instagram Help Center. This community can't help with those accounts.

Check out some popular posts here:

Getting Help from the Meta Quest Community

Tips and Tricks: Charging your Meta Quest Headset

Tips and Tricks: Help with Pairing your Meta Quest

Trouble With Facebook/Instagram Accounts?