HL2Mode3 directly in perception?

[Lilwolf]

Could the perception drivers try and support 'mode 3' type interface where the mouse is used to move the cursor around the screen (a bit), but the visible area is based on the head?

The calculations seem easy, but I'm not sure how much of the scene you can look in most of the games, when the game is focused on one spot.

<yes, this part could be hard>I thought if you increased the fov in the game to 155 degrees, the game engine would have to keep that much 'in view', then downsize the display area to 110... this would give you 45+45 (I believe) degrees that the mouse could away from your eyes... Ok really, this would allow the drivers to move the mouse a bit, then un move the visible, displayed area back...

What I don't know is if you can really tell the game engine its 155 degrees fov, but then only render in the rift 110. Or if that's even necessary.

Thanks

[cybereality]

I guess in theory it's possible, but it's not an easy thing. The main problem is that just by hooking into DirectX, you not actually modifying the game. You're just modifying the rendering. So doing the stereo render is fine. Moving the gun independent of the view would be difficult.

One way to accomplish this would be to render a higher FOV in the in-game settings, but that hook into DirectX and set the FOV lower. This would mean more geometry on the sides would exist in the frustum, but not visible on the screen. This would allow you to move your head and just shift the image to the side, revealing more geometry but leaving the gun aiming where it originally was. Similarly, when the gun moves, you could set a "dead-zone" where the shifting would compensate for the mouse movement and effectively keep the background static while the gun moved.

I believe this could work, with enough effort.

[Lilwolf]

the second paragraph is what I was talking about.

Perception is already moving the camera (left and then right pointing in a bit, and allowing for twisting). But if you move too far off, you start getting unrenderable parts because the engine.

So you keep the gun in center always (for the game), you increase the fov (if needed), but instead of moving they eyes left/right and point to center, you move them left/forward, right/back and point the the right by a bit. Then reduce the fov. The fov reduction is what I'm not sure if feasible / realistic, everything else should be just simple geometry (as much as an of the other calculations)

As a java programmer, it's not super easy for me to play with this. I haven't played with c++ in years. What IDE is used to compile the project? (and is it free?)

[cybereality]

I used MS Visual C++ 2010 Express as the IDE, it is 100% free.

[Lilwolf]

One last question

Is it possible (without HUGE changes) to reduce the fov displayed? I'm curious if something like this is already in the application. I don't know if there is a layer that allows this type of manipulation.

Thanks

[cybereality]

What do you mean by FOV? Like the FOV of the game camera? Why would you want to reduce this?

[Lilwolf]

Step one will be move the the screen around.

Step two will probably have to be increasing the FOV in game, then reducing it after. So the game doesn't try an optimize the models out of the display.

[cybereality]

Yes, I originally had the feature in the driver, but I took it out since it wasn't very useful without other work done.

Basically what you have to do is somehow extract the projection matrix, and then replace it with a new one.

You can create a projection matrix like this:

Code: Select all

D3DXMATRIX matProjection;
D3DXMatrixPerspectiveFovLH(&matProjection, D3DXToRadian(45), (FLOAT)SCREEN_WIDTH / (FLOAT)SCREEN_HEIGHT, 1.0f, 100.0f);

Extracting the matrix from (most likely) the combined world/view/projection matrix is a little more difficult. There may actually be code to do this in there, I haven't looked at the code in a while.