Exit, Scaling and IPD

[VRtinker]

Since now everything works perfectly on Quest+Touch Controller, I thought I'd point out as few things I noticed.

When clicking Exit in menu, you are presented with the Oculus Platform "Quit/Resume" panel, same as if you were to just click on the Oculus Home button on the Right Touch Controller. I think if the user takes the time to go into the menu and select Exit, the app should close immediately without any further confirmation.

I noticed that when scaling (I can scale up to a factor of 1.5 before the viewport becomes larger than my FOV) the image distortion doesn't proportionally increase as well, causing crosstalk/misalignment (headache potentially). Adjusting the IPD to a value of ~10 fixes that to some extent (at least for me). I'm not sure if all that is intended (maybe that's why the IPD adjustment is there in the first place?), but intuitively I would imagine that if the scaling increases/decreases the size of the left/right viewports exponentially from their centers, the "relationship" between the left and right image should be constant, so the 3D effect should stay the same at any scale.

The fact that IPD adjustments are not saved per-game, doesn't help, since a value that "fixes" one game, "breaks" another one (at least in my testing).
It would also be great, if we have to live with IPD adjustments to tailor the experience every time based on the game and chosen scale, if while adjusting the IPD the changes were to be applied/displayed in realtime. When pressing left/right on the controllers/gamepad to adjust the IPD values, the menu should get out of the way and show the effects (while just showing the IPD value at the bottom, like it happens on most TVs when adjusting Brightness/Contrast).
As it is, the user need to guess an adjustment, go back to the game, see the results, go back to the menu for more fine-tuning, back into the game, and so.....that's not fun :-)

It maybe just my OCD kicking in, but the buttons order in the "Emulator Button Mapping" drives me nuts :-P You got RStick-Up, RStick-Right, then all the four direction for the LStick, then Start and Select (named Enter and Back for the gamepad), and then the remaining RStick directions (Left/Down). I will rearrange that if it's not going to cause any issues as I know someone like me may lose it looking at that :-P

EDIT: I'm struggling trying to rearrange the mapping in the Emulator Button Mapping menu.

I'm able to rearrange the icons as shown in the picture, but that's about it. If I rearrange the actual buttons in Menu.cpp/Emulator.cpp/ButtonMapping.h, everything falls apart, buttons stop responding, it's a mess :-(
I'm clearly not doing it right and would love some guidance if possible

[CidVonHighwind]

So the exit button is mainly there for people using a xbox controller where it is not possible to access this menu (at least on the oculus go). I don't think that it is a good idea to just close the app without letting the user confirm that he really wants to close it. So I think the current implementation is better than just closing the app. But you are right that it does not make much sense with touch controllers.

Your points on the IPD setting are good. I will look into it and try to make the IPD settings work better with scaling. The other suggestions make a lot of sense but would also require a lot of work.

As you realized changing the button order is not that easy. The current order is the order the emulator is using internally. But that is a thing I wanted to fix and will probably do in the next few days.

[VRtinker]

Hey, thanks for getting back to me!
Regarding the Exit confirmation dialog, I figured it's there for GO gamepad users primarily (as a GearVR gamepad user, I still prefer to use the onboard touchpad to exit). As I mentioned, I consider going back into the menu, scrolling down and selecting exit, an implicit confirmation of your actions, otherwise what the hell are you doing going through all that to only back out at the very last click? :-p I reckon it saves trigger-happy users who inadvertently scroll the whole menu and click on exit by pure chance without any intention to do so but while unfortunate that's probably a rare case, I suspect.

At any rate, I think the world will go on with or without it, so no biggie :-)

Regarding the IPD, I was trying to point out that the scaling seems to not keep the viewports anchored to their respective centers when applied, requiring then IPD adjustments to compensate for that, as suddenly what was perfectly aligned to your eye balls it's not anymore. If the scaling could be applied while anchoring the viewports, I would think IPD adjustments would not be required at all, other than whatever a user might need to begin with at any scaling factor. I mean, after all, the user's IPD doesn't change when switching games or changing the scale, so once set no one should ever need to change it again really.

I would love to help out giving the Touch treatment to the GearboyVR project, so I was wondering if following the various changes you did to this repo, starting around commit 9 or 10, could be a viable way to get there.

Cheers

[CidVonHighwind]

So the main idea behind the IPD adjustment is to reduce eye strain and make it more comfortable. The thing is that the 3d effect from the virtual boy is far from perfect and depending on the game different IPD settings work better. Also the name IPD is not really correct. Currently it is something like a IPD offset as long as the scale is 1.

I was actually updating the GearboyVR project to use the common parts from the VirtualBoyGo Emulator. So that both emulators would use the FrontendGo part. I will try to push the current state in the next few days.

[VRtinker]

I get the IPD is to bring the viewports in front of your eyes, and that VB 3D is inherently funky, so you kinda need to adjust it even if only to improve the effect, but like you said, right now is more of an offset, but to compensate for the skewing of the viewports when scaling rather than for the eye balls of the user which on the other hand don't scale (thank god!) :-p
I admit, I haven't tried to turn off 3D and scale to see if my feeling of moving viewports is correct. I shall test and report back!

BTW I see now (thank you) where the buttons are declared in BeetleVBLibretroGo, so I'll start messing with that and see where it leads.

[CidVonHighwind]

I changed the button order and fixed the IPD (hopefully). If you want you can take a look and see if everything works correctly (especially the touch controller mapping). If it does I will release this version.

[VRtinker]

I tested the new changes, everything looks good! Cannot really tell if the IPD is fixed, or rather, what do you mean by that. The name has changed to IPD-Offset, but I still need to adjust it if I scale. I should mention this is the case at max distance 5.5 and scale 1.5 or above. If I reduce the distance to the min 0.5 I can leave the IPD untouched while even at scale 2.
At any rate, this is for sure release worthy!

On a side note, I was wondering why does it need to build with both arm64-v8a and armeabi-v7a libs? wouldn't armeabi-v7a libs alone suffice (and halve the app footprint)?

[CidVonHighwind]

Okay yes you are right my previous change could not have fixed the IPD problems. After looking closer into it I realized that I kind of have no idea how to fix this and what the actual behavior should be. The main problem is that I don't know how the IPD offset should change with changing scale. If you have any idea let me know.

For the arm64-v8a part. I build the app with armeabi-v7a. The arm64-v8a stuff is there since I updated the SDK. But as far as I can tell I am not using it I think.

[VRtinker]

Hey!
So I finally had a little time to update to the latest firmware and try the new commits. Not enough time to drill into the IPD issue though (when I can, I will take screenshots at different scale factors and overlap them to see if the L/R screens are keeping at the center at all times, before advancing any speculations on how to fix it :P)
I did "fix" the double-lib issue though. After a cursory online search, I saw that the ABI filters are what's responsible for what libs are included in the build process. Long story short, I got a working arm64-v8a-only to build (I decided to exclude armeabi-v7a libs since I believe Quest, GO and Samsung's GearVR ready phones all support arm64-v8a which should provide more performance).

To get that, I opened ALL gradle files and removed every mention of armeabi-v7a I could find. All the files but one have the following listed:
abiFilters 'armeabi-v7a', 'arm64-v8a'
which I changed to:
abiFilters 'arm64-v8a'

VrApp.gradle only has:
abiFilters 'armeabi-v7a'
which I changed (on two instances) to:
abiFilters 'arm64-v8a'

It's a bit weird that you need to change ALL the entries in the SDK, instead of just being able to select the type on your app, and have the SDK follow accordingly.

More bread for your readme, I guess, if you decide to go down this path.

Oh, the build shrinks by a whooping 30% as a result! it looks like it would go down 50% if you were to pick the armeabi-v7a route instead

On a side note, the first game I tried to test the arm64-v8a build was Jack Bros. It was funny cause I pressed the Select button and a prompt came up saying
Press select to adjust IPD
Press start to exit this screen
So I thought, damn, he implemented that whole custom IPD adjustment mode we briefly discussed about. When clicking Select, the Virtual Boy logo is shown, so it looked like a legit adjustment screen :P
Obviously, I realized soon after that that was something game specific that had nothing to do with the emulator :)

I found this two links that kinda talk about this:
https://www.planetvb.com/modules/newbb/viewtopic.php?post_id=26477
https://www.nintendo.com/consumer/systems/virtualboy/trouble_image.jsp

Now I'm also thinking, since the Quest has manual IPD adjustments available (like the actual Virtual Boy hardware, as it turns out - I didn't know it had one!), maybe the soft setting or the scaling factor are compounding with that somehow (i.e.: they operate on the assumption that the physical IPD is fixed, like on the GO, so the resulting image goes out of whack)

[CidVonHighwind]

I will try changing the app to arm64-v8a for the next release. Thank you!

I also just added a commit to adjust the screens to be centered for both eyes and use the IPD of the headset. Maybe you can look at it and tell me if it is working correctly this time. Before this the two screens where centered in between the eyes and now they should be centered in front of each eye.

[VRtinker]

So I tried the latest commit, I'm not completely sure what's going on.

It seems that the IPD adjustment now does the same thing as reducing/changing the screen distance

Maybe a little hard to tell, but the two screenshots above are with the screen distance at default (5.5) and scale at 1.5.
When in-menu, the screens are at the zoom level you'd expect at that distance/scale level. With ipd set at the minimum (-0.125) like in the shots, when in game, the viewports shift just like they used to when you were to select 0.5 as screen distance in previous commits.

The good news is that at -0.125 ipd, pretty much every game I tried is giving perfect 3D (you can even play 3D-Tetris without having your eyes departing from their eye sockets!), with this only drawback of a reduced perceived screen distance.

Somehow, I think the IPD setting is now crossing into the screen distance territory...

[CidVonHighwind]

Yes but I think this is something that should happen. Because if the IPD offset is set to -0.125 the two screens are moved to the left (for the right eye) and to the right (for the left eye). This essentially then makes it look smaller because the eyes are seeing images that are farther apart. Also this leads to the distance appearing smaller.
You are right that this is strange behavior. But I am not so sure if there is a way to fix this.

[Nicsky1]

This looks amazing in the quest 3, but it's way too dark and I don't see any options to adjust the brightness. Thanks if anyone can help! :)