DOOM 3 BFG - VR ( V0.021 Updated 3-12-2017)

Samson

Latest Release And Downloads:

Latest Version: V0.021

https://github.com/KozGit/DOOM-3-BFG-VR/releases

Updates from v0.20:

Edit: Many many thanks to 2EyeGuy for all his hard work on the .020 release, and for handling bugfixes and compiling this release while I was on vacation

Additions:

QuakeCon style teleport. ( jkchng )

Fixes from v 0.020

Fix issue #107: use other hand for movement.
Fix issue #97: Fix talking waking monsters.
Fix issues 100 & 106: Change language detection to use sound files. Issue #100 and Issue #106            
Fix issues #113 and #27: Fix timing issues.    
Improve issue #27:Disable ASW and make it a menu.
Improve issue #103:    Fix loading old savegames with different scripts.
Fix crash loading 020 save games, and allow old versions.
Loading RBDoom savegames works now.
"Fix" loading script objects of different sizes.   
Fix save and load menus.    
Adjust installer, Readme, and other docs for v 0.21 Alpha.
Work Around Movement Popping.

**EDIT:**
Known issue: After saving a game it might appear greyed out in the load game list and be unable to find it. To fix this issue, either use this console command before opening the load game menu, or exit the program and restart it:
testSavegameEnumerate
This issue is fixed in the next version.


Previous Release:

Doom 3 BFG VR: Fully Possessed V0.020 Alpha

This is sizeable update with many new features and improvements.

New features include:

Teleportation is now supported, including a parabolic aiming beam.

Voice commands are supported - say a weapon name to select it!

Flicksync mode based on Ready Player One.

Many aids to prevent motion sickness, including a new Third Person movement mode.

Many other improvements have been made, please see the readme.txt for a full feature list and documentation.
https://github.com/KozGit/DOOM-3-BFG-VR/blob/master/README.txt

Default Configuration
No single controller configuration or comfort setting is going to accommodate all users equally,
so Doom 3 BFGVR: Fully Possessed defaults to a comfort oriented mode. In the default mode, comfort ( or snap ) turning is enabled by default, and artificial movement uses the Third Person mode. These settings should provide a comfortable experience for almost all users. These settings may be easily changed or disabed in game if they do not suit your needs. From the System Menu ( say 'System', or press ≡ (menu) on the left Touch or Right Vive ), then select 'VR Options' then 'Comfort + Safety Protocols'. From this menu, use the 'Turning' options to change the turning mode (' smooth 'is standard analog turning - caution - smooth turning causes motion sickness in most people ). Use the 'Motion Sickness Aid' options to change the comfort settings. 'None' disables all motion aids, but this will induce motion sickness in the vast majority of people.

Default Controller Layout
The default controller layout can also easily be changed in game. Any controller button or Stick/Pad axis can be mapped to any in game action, to easily create a controller layout tailored to your liking. From the System Menu ( say 'System', or press ≡ (menu) on the left Touch or Right Vive ), Select 'Controls' then 'Key Bindings', Scroll through the list and highlight the action you would like to change the control for. Press the trigger to enter 'bind' mode, then simply press the controller button or stick/pad axis you would like to assign to that action. If the button or stick is already assigned to a different control, you will be asked if you are sure you want to re map, otherwise you are done! A button or joystick/pad axis can be unbound from an action the exact same way.

Installing Doom 3 BFG: Fully Possessed.

There are two options for installing the mod: A self-extracting installer, or a .zip file.
Due to the inclusion of new player AAS files needed to support teleportation, the size of the mod has
increased a fair amount. You will need about 1GB of free hard drive space to install the mod.

Installing with the self-extracting installer
Download the file 'Doom3BFGVR_Fully_Possessed_Alpha020_Installer.exe' from the release page at the top of this post and execute.

By default, the installer will look to install the mod in the default app directory in your Steam library on drive C. If your Steam library is in a different location, or you have installed doom 3 someplace else, browse to the location of your Doom 3 BFG installation. IMPORTANT If you browse to select a directory to install the mod, the installer will append 'Doom 3 BFG edition' to the install path. REMOVE THIS from the install path, so that only the full name of your Doom 3 BFG directory is displayed. Failure to do this will result in the mod files being installed in the wrong directory. Once installed, you should see a folder named 'Fully Possessed' inside your main Doom 3 directory along with some support files and the Doom3BFGVR.exe. Launch this .exe to play.

Installing with the .zip file
Download the 'Doom3BFGVR_Fully_Possessed_Alpha020.zip' file from the release page at the top of this post, and extract into your main Doom 3 BFG directory. You should see a folder named 'Fully Possessed' inside your main Doom 3 directory along with some support files and the Doom3BFGVR.exe. Launch this .exe to play.

Compatibility with existing Mods or Native Doom 3 BFG
Doom 3 BFG: Fully Possessed stores all changed assets and save games in their own directories. Installing the mod will not interfere with existing mods or the native game.

Compatibility with the Hi-Def texture pack
Doom 3 BFG:Fully Possessed is compatible with the hi-def texture pack. Please be aware that the 'generated' folder included in the hi-def texture pack is corrupt, and will crash the game if not deleted. This is not an issue with this mod, but with the texture pack itself. After installing the texture pack, delete the 'generated' folder inside the 'Base' directory.
NOTES

1. The texture pack also installs German language files. If you do not want the game menus to be in German, delete the 'german.lang' file in the 'Base/Strings' directory.
2. It does not matter if you install the mod first or the texture pack first, but be aware that games saved without the texture pack installed will not work once the pack is installed, and vice versa.

Reporting Bugs
Many bugs have been addressed in this relase, but if you do find one, please open an issue on our tracker. We can't fix it if we don't know its broken!
https://github.com/KozGit/DOOM-3-BFG-VR/issues

Enjoy!

OLD UPDATES:

--------------------

Update 12-10-2016

Fixed bug related to save game crashes. Archives updated

Additional Update 12-9:

I've updated the OpenVR version of the mod to address  issues some people were having, and added a few new features.

There are now versions of the mod that support OpenVR and the Rift/Touch natively via the Oculus SDK.

See  below for a link and additional info. 

Update 12-9

I've updated the mod and posted a test verison with native Oculus/Touch support.

This includes full motion controls and the ability to interact with in game guis and the PDA by using them as touch screens.

Release:

https://github.com/KozGit/DOOM3-BFG-RIFT/releases/tag/v0.11-alpha

Please make a clean copy of your doom 3 directory before installing, right now this mod will not co-exist with other mods as too many of the assets have been changed.

Take a look at the description on the release page, and the two readme files included in the archive.  I've also included a .pdf that lists most of the common cvars you can use to configure the mod.  Please remember all the controls ( all joystick axes and buttons) can be unbound or remapped to any other control. In the system menus go to  (Settings->Controls->Key Bindings)

There's still a little oddness during loading screens.  Let me know if you find any issues. This is the first test of this, so there may be issues I'm unaware of, please let me know if you find anything.

------------------------------------------------------------------------------------------------------------

Previous update:

I've been working on a mod for Doom 3 BFG edition for a while, and it might be ready for an alpha test. I'm looking for people to test and let me know what issues ( and I'm sure there will be some ) you have. ( Please note this is an entirely new mod, not a variant of an existing one.)

Anyway, here we go:

https://github.com/KozGit/DOOM3-BFG-RIFT/releases

New features:

Full motion control support for weapons, with support for right or left handed control.
Reload mechanics and motion controlled melee attacks are NOT finished yet, but in progress.
For now press the attack button to punch and reload to well, reload. Grenades are now
thrown via motion controls.

Flashlight modes
The flashlight can be held in the off hand, mounted to the weapon, mounted to the player helmet, or
mounted to the player body. If 'mount to weapon' mode is enabled, and a weapon without a barrel is
selected (e.g. grenade, fists, chainsaw) the flashlight is temporarily moved to the head.

Player body view modes:
You can chose to view the entire player body with ( very very basic ) IK for the arms, view the weapon and
hands, or view the weapons only.

Weapon sight modes:
Chose from a laser sight, laser dot, circle dot, or crosshair.

Optional heading indicator.
With independent head/body movement it's easy to forget which way the body ( and forward
movement) is pointing. The heading beam points in the direction the body is moving. Beam can be
solid, have arrows, or scrolling arrow. Temporary artwork.

Movement options:
The player body is locked to user position, so moving in the real world moves the player body.
Optional comfort turning, with user defined delta and repeat delay.
Walk speed adjustment from game default consistent over level changes
Option for forward movement to be in direction off hand controller is pointed
Headkick and knockback are disabled by default but can be toggled.
For non motion controls, you can lock the view and aim together, or use independent aiming with user
defined deadzones

Hud options:
Hud is translucent and projected into world.
Hud can be locked to the view or the body.
Hud position and size are configurable.
Hud can be toggled on or off, or faded in when user looks down past defined angle
If hidden, can be configured to reveal when health below defined level
Individual Hud elements can be turned on or off if desired

Stat Watch ( for the love of god someone come up with a better name )

Ammo stats are provided on a wrist worn armament inventory device if player has weapon equipped.
Soon to provide health stats as well.

Gui interaction modes.
Player can choose one of three ways to interact with in game guis
1) Look direction controls gui cursor
2) Weapon aim controls guis, in the event weapon has no barrel (grenade, fists, etc) default to look
direction
3) If motion controls are enabled, guis can be touch activated. When close enough to touch, look at gui
to activate then touch gui to control.

PDA is rendered as model in game.
PDA can be held in hand, or fixed in a position in front of the player body. If gui touch mode is enabled, the
PDA works as a touch screen device. Pressing escape during the game brings up the system menus in
game on the PDA.
PDA fixed position can be adjusted.

Cinematics
Cinematics are now from a fixed camera position. This is still being worked on, but is much better than the
free camera IMO. Some camera files still need to be tweaked for some of the cinematics. Pressing the PDA
button will exit the current cinematic

Pixel density can be adjusted.

ALL controller buttons and axes can be re-mapped to any control or action.

Weapon models have been fully fleshed out.

All of the options are currently controlled via cvars that start with vr_.  I'll add the options to the menus at some point.

The code has not been tested on any machines other than mine, so hopefully it will at least run for some of you

There are some issues I do know about. The loading and saving transitions are pretty glitchy, which is annoying.  I'll either smooth them out or just black them out.  I changed how the player hand animations work, so occasionally the hands don't play the correct firing animation.  I know how to address just need to implement.  The weapons also jump/blink for a frame when you change weapons, I know how to address I just need to get to it. Also, the source code is a mess, it's not actually on github at the moment, I'm working to clean it up and get it posted soon.

Anyway, let me know how it works for you!

Syndroid

It crashes on startup for me.  Here is the error message.

-----------------
0(108) : error C1008: undefined variable "rpShadowMatrices"
0(109) : error C1008: undefined variable "rpShadowMatrices"
0(110) : error C1008: undefined variable "rpShadowMatrices"
0(111) : error C1008: undefined variable "rpShadowMatrices"
0(138) : error C1008: undefined variable "rpJitterTexOffset"
0(139) : error C1008: undefined variable "PI"
0(143) : error C1008: undefined variable "rpJitterTexScale"

------- Game Map Shutdown ------------------------------------------------********************ERROR: While linking GLSL program 12 with vertexShader interactionSM and fragmentShader interactionSM

Samson

What gfx card are you using? Also, did you install on a completely clean BFG installation?  If you put this on top of the other mod, it will probably conflict.

Syndroid

gtx 970.
Just tried it again on another installation and now it seems to work. I'll be back with some impressions soon.

Maxxgold

Just an FYI; if you need a copy of Doom 3 BFG, you can get a Steam key for 5 or 6 dollars on eBay. 

Syndroid

I've just tested a bit and messed a little with the console commands. There are a lot of options to customize the playstyle, that's amazing! Performance is great as well.

Only real issue I had so far is the scale.
Is there a way to change the worldscale? With the default settting the world looks too big to me, though, the weapons feel right...

"vr_scale" does not seem to work. Only way I was able to change the scale was by using the IPD override and set it to a ridiciously high value. but that messes with the positional tracking and also makes the gun/hands too small. 
Would love to be able to change the worldscale and gunscale independently
For the guns I used "g_gunscale" in other versions, but that doesn't seem to work in this one

Samson

Gunscale and vrscale are disabled at the moment.  Just out of curiosity, what did you set the IPD to?

You may want try changing the player height (pm_normalviewheight)  and then reset the orientation to see if that makes a difference. Just out of curiosity, are you using a rift or vive?  Some of those cvars are old cruft, I need to clean them out sorry.  I can look into scaling options.

Syndroid

I'm using a Rift... With IPD set to ~75 the scale of the world looks right to me (except human npcs)
edit: 71 looks better
64 (default) feels off somehow. especially when I stand in front of things like desks or computers. same with smaller objects like cans etc. 

Thane_

Keep in mind that FOV, or the 2D size of things also plays a part the perceived size/distance of things. In 3D guns often look far too big while the world looks fine because they are given their own 2D size in the viewport. This is one area where Tridef succeeded over Nvidia 3D Vision, because it was able to specifically modify the guns 3D values independent of the world. I don't know if thats the issue as i can't try it, but i just wanted to throw that out there.

This mod looks great! Can't wait to try this when i eventually get a Rift.

Syndroid

Well, Doom 3 wasn't made with VR in mind. The size of some of the models ingame are not really accurate. Some are too big, some are too small. This becomes noticible in VR. But it isn't all that bad actually.
I still prefer a smaller worldscale than the current one for the world itself, though. Only downside is that human npc's (especially their heads) become a little too small then.

elboffor

I really want to try this out, but I also really want to wait till I get my touch controllers.
1st world problems right here!!!

RABID

just tried it on a clean install. its crashing on the intro cut-scenes. all 3 campaigns. using an Nvidia 980 with latest drivers

Leyland

The biggest problem with this release is this:
https://github.com/KozGit/DOOM3-BFG-RIFT/blob/master/COPYING.txt

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights.  Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received.  You must make sure that they, too, receive or can get the source code.  And you must show them these terms so they know their rights.

It looks like your source code is out of date with your binaries. Is this something we can just request from you and you email to us, or were you just not planning on releasing it?

AndyW1384

Leyland said:

[snip]

It looks like your source code is out of date with your binaries. Is this something we can just request from you and you email to us, or were you just not planning on releasing it?

Samson said:
[snip]

Also, the source code is a mess, it's not actually on github at the moment, I'm working to clean it up and get it posted soon. 

danknugz

this works with touch?

Leyland

AndyW1384 said:

[snip]

Also, the source code is a mess, it's not actually on github at the moment, I'm working to clean it up and get it posted soon. 

That's no excuse

My code is a tremendous mess, the code he has in his repo right now looks considerably better than what I have right now (he has things in actual files!)

The purpose of sharing code isn't so that people admire how beautiful your code looks (although they can), it's to help fix bugs and for people to learn how things work.

Besides, in my experience in open source, the worst criticisms I have gotten is not from other coders but from end users.

Samson

Leyland said:

The biggest problem with this release is this:
https://github.com/KozGit/DOOM3-BFG-RIFT/blob/master/COPYING.txt

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights.  Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received.  You must make sure that they, too, receive or can get the source code.  And you must show them these terms so they know their rights.

It looks like your source code is out of date with your binaries. Is this something we can just request from you and you email to us, or were you just not planning on releasing it?

When I put the video on youtube a year or so ago showing progress using the razer Hydras, I started getting spammed for requests on how to compile, how to play, feature requests etc.  The game was in a completely unplayable state, and I didn't have time to deal with all the requests, so I moved the code to a private repo to continue working on it.  As it's private,  I've stupidly been using it for lots unrelated things and generally made it a mess.   It has nothing to do with criticism, ( I freely admit I'm a terrible programmer, no amount of code clean up will hide it ) I can't just throw the code over without cleaning it up - at a minimum removing unrelated code and my coarse language from the comments.  The code will be released when its ready, and I wont apologize for that.

But still,  with all the posts here and on reddit about progress,  no one, including yourself, ever reached out to anyone here to ask if the code was available, or want to collaborate,  which would have been given or done gladly. To me, THAT's the biggest problem with this release. And yet you'll take the time to make vaguely condescending comments now?  There's no competition here man, we should just be having fun. 

( And for the record, there are far, far bigger problems with this test than the source isn't available yet. )

Leyland

Samson said:

When I put the video on youtube a year or so ago showing progress using the razer Hydras, I started getting spammed for requests on how to compile, how to play, feature requests etc.  The game was in a completely unplayable state, and I didn't have time to deal with all the requests, so I moved the code to a private repo to continue working on it.  As it's private,  I've stupidly been using it for lots unrelated things and generally made it a mess.   It has nothing to do with criticism, ( I freely admit I'm a terrible programmer, no amount of code clean up will hide it ) I can't just throw the code over without cleaning it up - at a minimum removing unrelated code and my coarse language from the comments.  The code will be released when its ready, and I wont apologize for that.

But still,  with all the posts here and on reddit about progress,  no one, including yourself, ever reached out to anyone here to ask if the code was available, or want to collaborate,  which would have been given or done gladly. To me, THAT's the biggest problem with this release. And yet you'll take the time to make vaguely condescending comments now?  There's no competition here man, we should just be having fun. 

( And for the record, there are far, far bigger problems with this test than the source isn't available yet. )

I'm not going to bother arguing with you, I don't consider this a competition either, rather I am actually interesting in seeing your changes, and the only reason I am not asking for it now is that I am still working on mine and wouldn't have as much time to look at it. What I am more worried about, and seems like a realistic scenario at this point, is that you disappear and never release the source code.

In my experience releasing binaries is a heck of a lot more trouble than releasing source code, maybe you've had a different experience, but as a recent example, I've had to buy a Vive this week (which I had planned to do much later on) in order to fix bugs because someone figured out they can run my binaries on Vive and shared the news on reddit.

Keep in mind also no one had to ask for source from these guys http://www.mtbs3d.com/phpBB/viewtopic.php?f=142&t=16703 and I even contributed a patch to them as a result (I'm LeeN), and your work here has benefited from them having shared their source.

Thane_

@Leyland: is this the version of Doom 3 VR that people are playing all over YouTube the last few days?

@Ayndroid: the size of the world is designed and made in 3D, everything should be exactly as the developers intended, in 2D or 3D. That's why I Nvidia 3D Vision work so well all you have to do is convert the game automatically to 3D and just a few things like Shadows or lighting needs to be fixed and you're good to go in general. 3D modelers, like myself, actually use digital rulers and units of measurement when building models. Unless something very strange is happening everything should be exactly the right size.

Syndroid

Thane_ said:

@Ayndroid: the size of the world is designed and made in 3D, everything should be exactly as the developers intended, in 2D or 3D. That's why I Nvidia 3D Vision work so well all you have to do is convert the game automatically to 3D and just a few things like Shadows or lighting needs to be fixed and you're good to go in general. 3D modelers, like myself, actually use digital rulers and units of measurement when building models. Unless something very strange is happening everything should be exactly the right size.

But that doesn't seem to be the case with Doom3. Either the model designers or the level designers didn't use any type of measurement system. My bet is on both.
I made a few models and designed a few maps myself for several mods on different engines since 15 years ago. I too haven't used any measurement system back in the day. But yeah, I'm not a professional and I never modded Id Tech engine 4, so I can't comment on that..
Anyway,  a can in Doom 3 has roughly the same size as a human head, And the level geometry itself isn't always 100% believable either. ^^
Stuff like this isn't as noticible on a 2D screen than it is in VR.

But again, it isn't gamebreaking bad in this case. It's just noticiable if you're looking for it.

Leyland

@Thane_

It's not but this mod is farther along than mine in a number of ways, I could learn a lot from it's source code and contribute to it (if nothing but knowledge of things I know in solving some things). I already kind of benefited from the binary release, it's OpenAL32.dll works better than the one that came with the original RBDOOM-3-BFG mod.

Samson

Yeah, the OpenAL thing was strange.  I had one machine where it would bomb every time starting marscity2, and one where it worked fine.  Always with the same audio issue. I finally nuked AL completely off the one machine and placed the current (at the time) OpenAL32.dll in the game directory and the problem cleared.  I'm a little torn, I hate the fact that some people are having the crashing issue, but am excited to try and implement HRTFs with OpenAL, its the reason I'm using that audio subsystem.  TBH not sure what the right call is here. Maybe just have binaries for both OpenAL and standard windows audio.

There is something I may be able to help with easily - I noticed some people playing your mod were complaining of 'flameout' rendering issues with transparent objects - maybe I misread but I experienced the same issues a while back.  Some times, and it seemed very dependent on view angle when looking off angle at or transparent objects, the post processing on tranparent objects became completely corrupted, and performance also tanked while this was happening ( if you haven't seen this issue you can ignore the rest of this). This was most prevalent on glass, and Imp fireballs using the heathaze shader.    It also only seemed to happen when MSAA was enabled. Anyway, this first happened for  me immediately after an Nvidia driver update. ( this was some time ago ).  If I rolled back, the issue disappeared, and reappeared with the new driver, so def a driver issue.   I was taking screenshots to post on Nvidias support website, and realized when I did a bit copy from the buffer to capture a screenshot, the corruption was not present in the screenshot, even though it was on the screen.  This narrowed it down to the blit operation when copying the framebuffer to a texture.   A little experimentation and I was able to work around the issue by disabling the scissor test before blitting the buffer, and restoring the scissor test after.  This cleared up the corruption and performance issue, which for me at least still exist in current Nvidia drivers.  Anyway, here's the code that I used to work around the issue: ( you may be resolving MSAA differently but you should get the idea)

( in image_load.cpp )

/*
====================
CopyFramebuffer
====================
*/
void idImage::CopyFramebuffer( int x, int y, int imageWidth, int imageHeight )
{
    glBindTexture( ( opts.textureType == TT_CUBIC ) ? GL_TEXTURE_CUBE_MAP : GL_TEXTURE_2D, texnum );
   
    // Koz begin
    if ( commonVr->useFBO )
    {
        if ( commonVr->VR_AAmode == VR_AA_MSAA ) // resolve the MSAA renderbuffer before copy.
        {
            glDisable( GL_SCISSOR_TEST ); // koz hack
            ResolveMSAA();
        }
        else
        {
            globalFramebuffers.primaryFBO->Bind();
        }
    }
    else
    {
        glReadBuffer( GL_BACK );
    }
    // Koz end

    opts.width = imageWidth;
    opts.height = imageHeight;
   
    glCopyTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA8, x, y, imageWidth, imageHeight, 0 );
   
    // koz begin
    if ( opts.genMipsOnCopy == true )
    {
        glGenerateMipmap( GL_TEXTURE_2D );
        glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR );
        glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );
    }
    else
    // koz end
    {
        // these shouldn't be necessary if the image was initialized properly
        glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR );
        glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );
    }

    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
   
    backEnd.pc.c_copyFrameBuffer++;

    if ( commonVr->useFBO )
    {
        globalFramebuffers.primaryFBO->Bind();
        if ( commonVr->VR_AAmode == VR_AA_MSAA ) glEnable( GL_SCISSOR_TEST);// koz hack - re-enable scissor test
       
    }
}
ResolveMSAA() is just a blit from the msaa buffer to a non-msaa buffer, this is where the issue occurred.
This is the kind of stuff I want to clean up, no one reading this would have any idea why the scissor enable/disable is there.   (The genMipsOnCopy stuff is only there so the new PDA gui on the rendermodel can be mipmapped )

Anyway, maybe this is helpful,  hope so.

RABID

Leyland said:

Samson said:

  There's no competition here man, we should just be having fun. 

( And for the record, there are far, far bigger problems with this test than the source isn't available yet. )

I'm not going to bother arguing with you, I don't consider this a competition either, rather I am actually interesting in seeing your changes,

you need to combine forces! become voltron! (if voltron could be made from 2 lions)

Leyland

@Samson  I am not aware of a 'flameout' issue but if I do come across it, I'll try out your suggestion, thanks!

Leyland

@Samson So I finally came across that 'flameout' issue, and someone helped me reproduce it (told me where to stand and look, provided a video). It turns out not to be a graphics driver bug (though a graphics driver may have exposed it), it is that glBlitFramebuffer respects glScissor, and prior to calling that to resolve an MSAA framebuffer some other drawn surface was setting the scissor to be too small. So I searched the code for all calls to glBlitFramebuffer and made sure they all disabled and re-enabled GL_SCISSOR_TEST, and the issue is fixed for me. It's possible that in your case previous graphics drivers were not doing glBlitFramebuffer correctly (ignoring glScissor) and a newer graphics driver fixed that but then exposed a bug in our code.

Here is something that may be useful to you. I notice in your main menu that the edges of the shell are not cropped, you can probably draw it to an FBO but a trick I'm using to crop them in 3d is to use the stencil buffer. SWFs support masking through the stencil buffer, so my trick utilizes its own masking to crop the edges. So in idSWF::Render when I detect I am render a shell, I add a fullscreen mask before the call to RenderSprite:

		renderState.activeMasks = STENCIL_INCR;
		gui->SetGLState( GLStateForRenderState( renderState ) );
		DrawStretchPic( 0.0f, 0.0f, sysWidth, sysHeight, 0, 0, 1, 1, white );
		renderState.activeMasks = 1;

And then before the end of idSWF::Render I remove the mask:

		renderState.activeMasks = STENCIL_DECR;
		gui->SetGLState( GLStateForRenderState( renderState ) );
		DrawStretchPic( 0.0f, 0.0f, sysWidth, sysHeight, 0, 0, 1, 1, white );
		renderState.activeMasks = 0;

You can see the change here. sysWidth and sysHeight in my case are the renderSystem->GetVirtualScreenWidth/Height but they might need to be renderSystem->GetWidth/Height, or frameWidth/Height.

Samson

My Shell rendering is actually a pretty big mess -  I've updated it since the last release to address scaling issues at different resolutions, but I should really go back and re-work most of it.  I did a lot of experimenting with changing the  SWF rendering scale for when the PDA or game shell is copied to a texture for the in game PDA model, and I havent gone back to clean any of it up.  I really need to take some time and  re-work everything related to pausing the game for rendering the shell on the PDA as well.  Thanks for the tip on the stencil mask, I'll think about that when i get around to re-working SWF handling.

I haven't looked at the scissor issue in a while, but I can tell you why at the time I leaned towards it being a driver bug, at least when I originally found a work around for the issue. 

1) It only happens when MSAA is enabled.  I did a test where I still performed the blit, just to a non-msaa framebuffer, and everything worked fine.

2)  I originally thought the same thing as you, that I had somehow corrupted the scissor settings, or an inappropriate scissor was left active, so I logged all  calls that set the scissor, and didn't find any irregularities.   Additionally, I tried manually setting the scissor to a known good value immediately prior to the blit, and the issue still occurred. Again, this was a while ago, but at the time it appeared to be all in the driver.  (Did you find a call that set the scissor too small -  If so, I must have missed it, that's really puzzling! )

I'm working on one more thing before I release an update - I want the player to be able to lean a little bit when the player model has collided with a surface and normal movement fails.  If that tests ok, i post an update and start cleaning up the code to release.

Syndroid

I hope at least one of you is going to implement proper Touch support  

Baz_uK

Syndroid said:

I hope at least one of you is going to implement proper Touch support  

THIS THIS THIS !!!!! I'm super Doom fan! I 'need' this lol 

Syndroid

Haven't tried it yet, but I assume it will work ok with Touch atm.
I'm just hoping for proper analog stick movement. finger gesture support (for touch screens) would be the icing of the cake  

Baz_uK

So when my Touch arrives I should be able download a small use this MOD as is.....or should I wait a tad longer for fixes / improvements. Not sure how good a state it's in right now? 

Syndroid

Baz_uK said:

So when my Touch arrives I should be able download a small use this MOD as is.....or should I wait a tad longer for fixes / improvements. Not sure how good a state it's in right now? 

There are two versions. The one from user Samson and the other one from Leyland.
I tried both with a gamepad only, but they both deliver one of the best vr experiences currently available.
They both run through Steamvr, but performance wise it's great.  Oculus SDK support would be better maybe, but I don't know if they are even considering it.