Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I have the frame delta included in the calculation so even if framerate varies I think it should be fine, maybe some edge cases are unhandled.

I thought about the short-armed problem (or long-armed, could be awkward to see the flames produce too early in the movement). I wanted to include a distance-slider, and maybe measure it by asking to stretch your arm and press trigger. But yeah I want to rework the punch recognition method as a whole.

When I try your game in WebXR I get a pop-up “sorry your browser doesn’t support immersive VR”. Latest chrome on Windows.

Thanks for the specs, yeah loading shaders is an issue I think I used the Forward renderer for the PC export so they aren’t precompiled (IIRC it’s basically impossible for Vulkan-based renderers). Might be possible to compile as a loading step however, I think I saw something about it in Godot XR Tools gotta double check.

(+1)

Mmmm delta should help, but think of it as a pooling rate, at better fps, better data to work with

The Slider / Ask for calibration is a nice one, many games do that to calibrate arms length automatically

Oh my bad, try webXR with your headset, at least in quest 2 game is working fine.

Yeah Godot XR Tools have a common shader loader, in which you put all your materials and shaders, then put the commonn shader facing the camera (all the things you want to preload need to be in the frustrum of the camera and it need to be visible), is not like a precompile but like a work-around to load all things before starting the real game. I used that, so the game doesn't lag so much when doing the things the first time

(+1)

Instead of tracking the position of objects in game you could use the velocity as reported by the xr runtime, via get_pose(). This will be closer to using the raw accelerometer data from the controllers.

oooh I didn’t know about that! Thanks.