Open ChristophHaag opened 7 years ago
KozGit
commented
7 years ago Awesome! Do you want to put together a pull request so I can look at merging the changes?
Are you planning on integrating the controls? And thanks for taking the time to do this.
ChristophHaag
commented
7 years ago At the moment it needs more work, for example I think you're using the ovrFovPort struct in generic vr code, so I copied that one https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-784c3d4089599079122845d9b39480acR70 so I need to check this again. Also looking at the commit on github I think kdevelop reformatted two files (probably line endings changed) and stuff like https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-17339327116c66ae0bb568a98426356eR821 is just plain ugly. https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-a7c5ff9c3081c4188e1f9a8eafb7af94R48 was only in the windows input code so I randomly copied it into sdl_events that is enabled on other platforms but maybe there's a better place.
I think https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-0305d4ff097da14d06438c3d109d4d72R9832 is the place where it simulates pressing esc to open the menu when you press the menu button, but it does so in a windows specific way.
I'm not sure about the controller buttons but I commented out some handling code there that used keycodes from windows https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-2bf763fccca1cc36a8da19e7642571b3R1672 edit: Oh I did put a printf() there to see whether I broke it but when running it does not print that message so this is most likely not the problem.
It's also possible that it's still an issue in the openvr headers https://github.com/ValveSoftware/SteamVR-for-Linux/issues/35 but I haven't checked the new 1.0.10 release from yesterday.
KozGit
commented
7 years ago Yeah, unfortunately there is a fair amount of ugly in this code :( Sorry.
I don't have any Linux experience, so I probably haven't been doing things in a very platform neutral way - sorry you're having to clean it up. I'm happy to listen to any suggestions on making it more portable.
You're correct that https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b#diff-0305d4ff097da14d06438c3d109d4d72R9832 simulates pressing the escape key. Not knowing SDL very well, would calling SDL_PushEvent with type = SDL_KEYDOWN, key.state = SDL_PRESSED, and key.keysym.sym = SDLK_ESCAPE be an appropriate substitute?
Also, I'm not sure how OpenVR works w/ Linux, but in Windows, the OpenVR controllers are not handled as normal joysticks/gamepads, and the button/axis states are not polled through the OS like a standard joystick. They need to be polled explicitly via the OpenVR SDK. This is currently done in win_input.cpp PollInputEvents.
If there is anything I can do to help let me know!
( And I think you're the first person I know of who has seen the updated player hands )
ChristophHaag
commented
7 years ago Well, portability is what's in that commit / instead of \ and case sensitivity in include paths, and conditioning all the windows only stuff with #ifdef _WIN32. And of course plucking out all the oculus SDK calls because there's no oculus library to link to on linux.
OpenVR controllers work exactly the same on linux. If the code is portable usually the exact same code just works. I see the code in win_input.cpp. I think the entire win_input file is not used on linux, so the buttons states are never read. Probably need to copy this to the SDL input handling or try to do some common functions.
ChristophHaag
commented
7 years ago Okay so I played a bit with the input for linux. The problem is, there isn't a nice Sys_QueEvent( SE_KEY, key, value, 0, NULL, inputDeviceNum ) function to queue an event, instead the game event loop always calls Sys_GetEvent() which polls for events from SDL. Inserting an event into the SDL event queue didn't went so well, unless I want to write a whole extra version of the button handling translating it to SDL keycodes. Instead I tried a small hack and just return directly return a sysEvent_t from Sys_GetEvent() when a button on the controller was pressed. (It looks super racey, but I just want to see something work first before doing it properly and it shouldn't matter because you won't use the keyboard or mouse while using the motion controllers anyway).
The code: https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/62996b3da5c3ac1b8f9a1fe21d38c4d697bcf686
Now that seems to work so far. It prints stuff like
Button state 343 set to 1
returning vrevent 343 1
key 343 1and
Button state 294 set to 0
returning vrevent 294 0
key 294 0when pressing buttons, but ingame nothing happens. I think I'm missing something here...
ghost
commented
6 years ago I've compiled and run both @KozGit and @ChristophHaag versions of this and @ChristophHaag compiles and runs in the rift on linux. @KozGit 's code compiles too, but I don't seem to know or don't seem to be able to get the vive to react to it at all. In @ChristophHaag 's version, it starts up in the vive like it should. Asks you to look in your preferred forward direction and press a button. Then it gives you the doom version choice but as soon as you select doom3 it instantly exits. I'd love to figure out why..
ChristophHaag
commented
6 years ago I don't see how the unmodified KozGit version can compile on Linux. Perhaps with the old oculus headers it might be possible, but you'd still have to link it to an oculus library that doesn't exist, or maybe it works with the old one? Then, there are many issues with header includes using the wrong case, or \ in the filename...
The menu sucks a bit, I still don't really know what exactly it expects. I think the menu only really starts if the headset is tracking. And I think you need to have a controller in view before you can get past the start screen...
Like this: https://youtu.be/LvIdeN6X_Q0
On mesa at least there is some garbage rendered around the initial menu, but that never really was a problem.
Right now though, it really does crash every time you try to enter the game. I am about 90% sure it did not crash like that the last time I tried it.
Program terminated with signal SIGSEGV, Segmentation fault.
t#0 0x000055b0daba1b94 in idClipModel::~idClipModel() ()
[Current thread is 1 (Thread 0x7f2f0f7fe700 (LWP 18012))]
(gdb) bt
#0 0x000055b0daba1b94 in idClipModel::~idClipModel() ()
#1 0x000055b0da984a95 in idGameLocal::~idGameLocal() ()
#2 0x00007f2f90809448 in __run_exit_handlers () from /usr/lib/libc.so.6
#3 0x00007f2f9080949a in exit () from /usr/lib/libc.so.6
#4 0x000055b0dac6592b in Posix_Exit(int) ()
#5 0x000055b0dac674c5 in sig_handler(int, siginfo_t*, void*) ()
#6 <signal handler called>
#7 0x00007f2f90806860 in raise () from /usr/lib/libc.so.6
#8 0x00007f2f90807ec9 in abort () from /usr/lib/libc.so.6
#9 0x00007f2f90849437 in __libc_message () from /usr/lib/libc.so.6
#10 0x00007f2f9084fd34 in malloc_printerr () from /usr/lib/libc.so.6
#11 0x00007f2f90851439 in _int_free () from /usr/lib/libc.so.6
#12 0x000055b0daa97618 in idAnimator::FreeData() ()
#13 0x000055b0daa97659 in idAnimator::~idAnimator() ()
#14 0x000055b0da96028d in idAnimatedEntity::~idAnimatedEntity() ()
#15 0x000055b0daaabe3b in idClass::ProcessEventArgPtr(idEventDef const*, long*) ()
#16 0x000055b0daab7baf in idEvent::ServiceEvents() ()
#17 0x000055b0da980909 in idGameLocal::RunFrame(idUserCmdMgr&, gameReturn_t&) ()
#18 0x000055b0da627144 in idGameThread::Run() ()
#19 0x000055b0dacb7143 in idSysThread::ThreadProc(idSysThread*) ()
#20 0x00007f2f940b708a in start_thread () from /usr/lib/libpthread.so.0
#21 0x00007f2f908c842f in clone () from /usr/lib/libc.so.6I'm going to have to look for what's wrong there.
edit: Sorry to report that it does not crash when running with gdb. It's probably some weird race condition.
Let's see if I can work around that.
Another edit: the GL_EXT_semaphore patches I'm using are causing some bug in steamvr.. I've gotta sleep now, but I'll try later to get it running more reliably.
ghost
commented
6 years ago I'd love to just get past the game selection screen. I compile the client then copy out the elf file to a folder containing the doom3 base files as well as the "Fully Posessed" folder and run the elf file like it's mentioned in @ChristophHaag 's edited README.md file. Any suggestions to why the client exits on game version selection ?
ChristophHaag
commented
6 years ago No, no idea. And I don't think I have any extra steps that are not documented.
What does the game output on the console? Any hints that something might go wrong?
ghost
commented
6 years ago signal caught: Segmentation fault
si_code 1
Trying to exit gracefully..
session->GetSaveGameManager().CancelToTerminate();
soundSystem->StopAllSounds();
Stop();
--------- Game Map Shutdown ----------
--------------------------------------
CleanupShell();
delete loadGUI;
delete renderWorld;
delete soundWorld;
delete menuSoundWorld;
session->ShutdownSoundRelatedSystems();
session->Shutdown();
game->Leaderboards_Shutdown();
uiManager->Shutdown();
soundSystem->Shutdown();
usercmdGen->Shutdown();
eventLoop->Shutdown();
declManager->Shutdown();
renderSystem->Shutdown();
idRenderSystem::Shutdown()
Shutting down OpenGL subsystem
commonDialog.Shutdown();
UnloadGameDLL();
------------ Game Shutdown -----------
--------- Game Map Shutdown ----------
--------------------------------------
Shutdown event system
--------------------------------------
saveFile.Clear( true );
stringsFile.Clear( true );
CloseLogFile();
fileSystem->Shutdown( false );
Sys_Shutdown();
console->Shutdown();
idKeyInput::Shutdown();
cvarSystem->Shutdown();
cmdSystem->Shutdown();
ClearWarnings( GAME_NAME " shutdown" );
warningCaption.Clear();
errorList.Clear();
idLib::ShutDown();
shutdown terminal support
Tell me what to run for more precise output if needed
ghost
commented
6 years ago ran with gdb:
Thread 1 "Doom3BFGVR.elf" received signal SIGSEGV, Segmentation fault. 0x000055555588888d in idUsercmdGenLocal::CalcTorsoYawDelta() ()
ghost
commented
6 years ago then:
(gdb) step Single stepping until exit from function _ZN17idUsercmdGenLocal17CalcTorsoYawDeltaEv, which has no line number information. 0x0000555555ed64a0 in sig_handler(int, siginfo_t*, void*) ()
ChristophHaag
commented
6 years ago signal caught: Segmentation fault
Yea that's a crash. In gdb bt is the most interesting to see where it came from.
in idUsercmdGenLocal::CalcTorsoYawDelta()
That's a long function.. https://github.com/KozGit/DOOM-3-BFG-VR/blob/master/neo/framework/UsercmdGen.cpp#L1571
To get better debugging info like line numbers, make clean and compile again after cmake -DCMAKE_BUILD_TYPE=Debug ..
ghost
commented
6 years ago just when I select doom3: ` Thread 1 "Doom3BFGVR.elf" received signal SIGSEGV, Segmentation fault.
0x0000555555a81365 in idUsercmdGenLocal::CalcTorsoYawDelta (this=0x555556bb8c40
`
ChristophHaag
commented
6 years ago Hmm.. So gameLocal can't be null or invalid, that leaves gameLocal.GetLocalPlayer() returning null or GetLocalPlayer()->viewAngles being null (or invalid), but I think viewAngles is not a pointer here, so shouldn't be null. In gdb you can often check function calls with print gameLocal.GetLocalPlayer() and print GetLocalPlayer()->viewAngles. And if both of these are not 0x0, then it's an invalid pointer and you'd get an invalid memory access or something error when trying to dereference like print *(gameLocal.GetLocalPlayer()).
I would guess that it's GetLocalPlayer() returning null though, it seems like it would do that sometimes on startup https://github.com/KozGit/DOOM-3-BFG-VR/blob/master/neo/d3xp/Game_local.cpp#L2284
I've made a commit to my master branch, so with some luck it's just something that happens shortly during startup https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/4ca3886daf3ed4a1117f55b9161c33a2a69423ce
But since I haven't seen that crash, no idea.
ChristophHaag
commented
6 years ago And keep in mind that the controller buttons still don't work. You can walk around with mouse and keyboard though.
Edit: Also for actually playing you really want to compile with cmake -DCMAKE_BUILD_TYPE=Release. Performance with Debug really suffers a lot.
ghost
commented
6 years ago hm, this is what I got (before pulling and compiling your commit):
Thread 1 "Doom3BFGVR.elf" received signal SIGSEGV, Segmentation fault. 0x0000555555a81365 in idUsercmdGenLocal::CalcTorsoYawDelta (this=0x555556bb8c40 <localUsercmdGen>) at /home/source/git/DOOM-3-BFG-VR/neo/framework/UsercmdGen.cpp:1611 warning: Source file is more recent than executable. 1611 if (!gameLocal.GetLocalPlayer()) { (gdb) print gameLocal.GetLocalPlayer() $1 = (idPlayer *) 0x0 (gdb) print GetLocalPlayer()->viewAngles No symbol "GetLocalPlayer" in current context. (gdb) print *(gameLocal.GetLocalPlayer()) Cannot access memory at address 0x0
ghost
commented
6 years ago Okay, so the last commit got me past the initial selector and I got to start a new game.
I got the intro video and then I see a lot of
Writing generated/<images, rendermodels>
then it get's to Game Map Init where it segfaults:
Thread 1 "Doom3BFGVR.elf" received signal SIGSEGV, Segmentation fault.
0x00005555559e722e in idCollisionModelManagerLocal::AccumulateModelInfo (this=0x5555568d6e60
(gdb) bt
at /home/source/git/DOOM-3-BFG-VR/neo/d3xp/Game_local.cpp:1289No idea but that seems related to the map. Have you ever had texture packs or mods installed or have some weird old config file around?
ghost
commented
6 years ago it is possible, I can try cleaning it out
ghost
commented
6 years ago from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
ChristophHaag
commented
6 years ago And that finally is SteamVR breaking. Could be the engine doing something wrong with the shared textures, could be the graphics driver doing something wrong or, probably, SteamVR being buggy. In either case, a bug report at https://github.com/ValveSoftware/SteamVR-for-Linux/issues is not the worst idea, if it happens every time.
ghost
commented
6 years ago Okay, but in that case, how have you managed to get rendered images like posted at the beginning of this issue ?
ChristophHaag
commented
6 years ago It just works for me on my Radeon RX 480 with latest mesa git. It could be that it's broken only for some drivers. For example SteamVR's usage of the GL_EXT_semaphore may be broken, lostgoat (developer at Valve) is looking into that currently.
ghost
commented
6 years ago ah, great :smiley: thanks
KozGit
commented
6 years ago Looks like I forgot to check for a valid local player in idUsercmdGenLocal::CalcTorsoYawDelta. I'll add it to the main branch. Once I have the next version released, I'll look at moving the motion controller input out of the windows specific files.
ghost
commented
6 years ago There was a SteamVR update today, tried to run doom and this time it went properly, but, the framerate was pretty bad. I've got a FX8350 cpu (8core @ 4Ghz, no threads) and gtx 1070, so I'm finding the framerate problem pretty strange
KozGit
commented
6 years ago Were you running a debug build? Set com_showFPS to 1 in the console and post the timings.
ghost
commented
6 years ago Grrr... it worked ONCE, now it's back to segfaulting again: ` Thread 1 "Doom3BFGVR.elf" received signal SIGSEGV, Segmentation fault. 0x00007fffdedf19cd in CVRCompositorSharedTextures::SharedTextureDataGL_t::Release(CVRCompositorSharedTextures*) () from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
(gdb) bt
from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
from /home/source/.steam/steam/steamapps/common/SteamVR/bin/linux64/vrclient.so
leftCurrent=0x55555fec8520, rightCurrent=0x55555fecac40)
at /home/source/git/DOOM-3-BFG-VR/neo/vr/Vr_Gl.cpp:686allCmds=0x7fffc64df080)
at /home/source/git/DOOM-3-BFG-VR/neo/renderer/OpenGL/gl_backend.cpp:445at /home/source/git/DOOM-3-BFG-VR/neo/renderer/OpenGL/gl_backend.cpp:5580x555556cbce80 <tr>, cmdHead=0x7fffc64df080)
at /home/source/git/DOOM-3-BFG-VR/neo/renderer/RenderSystem.cpp:1370x5555568ee920 <commonLocal>)
at /home/source/git/DOOM-3-BFG-VR/neo/framework/common_frame.cpp:981at /home/source/git/DOOM-3-BFG-VR/neo/sys/posix/platform_linux.cpp:544`
johnr14
commented
6 years ago What OVR lib do I need to get and where is it ?
I get this when trying to compile :
../vr/Vr.h:42:10: fatal error: ../libs/OpenVR/headers/openvr.h: No such file or directory
ChristophHaag
commented
6 years ago It's Valve's openvr repository: https://github.com/ValveSoftware/openvr/
But you do not need to do anything manually, it's set up as a git submodule so you only need to do
git submodule update --init --recursivein the DOOM-3-BFG-VR directory and it will be set up automatically.
KozGit
commented
6 years ago I haven't had a chance to look at moving the input yet, but I was able to at least remove the calls to Sys_QueEvent - should be showing up in my next commit.
Replaced by defining
sysEvent_t ev
and then replacing the call to Sys_QueEvent with
ev.evType = SE_KEY; ev.evValue = K_ESCAPE; ev.evValue2 = 1; ev.evPtrLength = 0; ev.evPtr = NULL; ev.inputDevice = 0;
commonLocal.ProcessEvent( &ev );
ChristophHaag
commented
6 years ago No problem, I haven't looked at this for a long time either.
You just merged my stuff? I wouldn't have recommended that, because it's pretty much WIP and I hadn't even tested if the windows build still worked at all... But if it still works, good. :)
I strongly suggest going over the commits to see if it's all stuff you actually want and if there is still stuff to fix.
For example this commit is something that was a quick workaround so the game wouldn't crash on me, not a proper fix: https://github.com/KozGit/DOOM-3-BFG-VR/commit/9a5fb8cfae0b0eec155f8b45bba819c9130ca9ff
A few new windows only changes have come up btw: https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/dd8b44547f984648a7246528b9ad37fdc3402e2e. Don't take the commit message personally, I'll probably rebase it with a proper one after looking at the changes more closely. wglSwapIntervalEXT is a windows only thing, on Linux it doom uses SDL right, so I should add SDL_GL_SetSwapInterval(0) on Linux right?
I just tested it and it and it doesn't seem to be necessary. It runs but as expected and of course button input still doesn't work. I still have to look into it but yea, IIRC my theory was that the SDL key codes don't match what the engine expects.
CarlKenner
commented
6 years ago I merged it. I don't have Linux to test it on though. It will get tested on Windows a lot more now that it's merged. But you didn't change much.
I changed that commit to this when I merged it:
//TODO: this triggers an assert, but leaks data now
#ifdef _WIN32
eventDataAllocator.Free( data );
#endifSo it would work the same as before on Windows. I assume it was only crashing on Linux?
I haven't really looked at the Linux code, and I can't test, so you're a bit on your own there.
Since I don't want to demand stuff without putting in some work, here it is:
Code: https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9f5bc4d3eebc389209d82a8ff82d5fde43029a3b
What I did:
#ifdef OVRall code using the oculus SDK. Currently OVR is not defined anywhere.#ifdef _WIN32all code using the windows API. That is mostly some wgl sync code, all the voice code, and some input code. I suspect that's why the controller buttons don't work, also activating the menu somewhere. Some small fixes inside the engine taken straight from the current RBDoom3.Unfortunately not really playable with controller buttons not working but you can walk a bit with the keyboard, look around and wave your hands.
Performance is really good on my RX 480 with open source drivers, at least in the starting hangar.
Also some info how to make it do something on linux: https://github.com/ChristophHaag/DOOM-3-BFG-VR/commit/9b9c017a500e8128e4dee94d2e38b33c6ca537a2
tl;dr: Not fully functional, but works as an initial implementation on linux.