Sorry your browser is not supported!

So I have a quick question... while I know the Tier 2 SDK is included with AppGameKit Studio., something that seems incredibly fuzzy to me is what can actually be done with it that will interact with Tier 1 Programs as a Library?
Now personally I'm looking to work on a VR Plug-In that utilises OpenXR… something I know unlike OpenVR (which Steam VR uses) has much wider support for HMD and Motion Controllers.

This is primarily because for some reason the AppGameKit VR Plug-In doesn't work for me... it detects the HMD, it even supports the WMR Motion Controllers... the key problem is while it shows and reacts in the AppGameKit Preview Window., it NEVER dispatches to Steam VR; so it's Developer Preview Window is just black, as is the Image in the HMD.
It's also not exactly "Easy" to even start a new Project with the VR Plug-In as it takes a lot of effort just to get AppGameKit to recognise it., which when you also consider the Original Developer appears to have gone MIA and despite the branding TGC themselves don't officially support it... well it seems like a dead-end for anyone whose interested in using AppGameKit to Developer VR.
This said, I wasn't exactly enamoured by the reliance on SteamVR… as it really limits where you could even release your AppGameKit VR Project.

Now ideally speaking., as I recall back in the Dark BASIC Professional days... having to essentially hack a hook into the Direct3D Device in order to expand functionality that was never exposed.
I really don't either feel or frankly have the time to waste poking the Runtime Libraries and doing that.
Instead what I'd like to do is create something more integrated, which I know I can do with the Tier 2 SDK but I'm unsure if that allows it to be a Compatible Plug-In for Tier 1 or if that would simply result in 2 Instances of the Engine running side-by-side with a duct taped interaction.

And if it is possible, a quick and dirty example would be great.
Like, say... using https://gpuopen.com/gaming-product/tessellation-opengl/ (as that could work on the "Basic" Rendering but does require OpenGL Features that 2.0 doesn't have)

Here is the guide for creating a plugin for Tier1
The guides are always a good place to look if you want to explore AppGameKit functionality

Here is an example of an AppGameKit plugin

Blink has given all the info you would need really

The existing AppGameKit VR is built as a tier 1 plugin and just exposes the VR functions that you need to use for steam VR. Obviously changing over to another VR system should be possible if really wanted since that is how the existing implementation worked.

I've not had issues with AGK's steam VR implementation really but I tend to use it with Classic...not studio. Im doubtful it was ever tested with the vulcan renderer. I also use the Leap Motion plugin too to allow contact-less hand gesture controls.

The plugin architecture obviously allows you to integrate a VR library if wanted into teir 1. (thats how the original one works) However, a teir 1 plugin still wont give you low level access to the internals of AppGameKit or to the open GL interfaces. You would still have to manipulate 3d models with the object commands and memblocks. Teir 2 would be needed if you literally wanted low level or specific rendering functionality that isnt currently exposed.

The issue I have with the AppGameKit VR isn't with AppGameKit Studio, as I didn't see a point in trying it given others have mentioned issues that they've begun to have with it.
Rather the issue is present in AppGameKit v2 and it has NEVER Dispatched the Images to the HMD for me.

As such it has essentially been a waste of £35 - 40... w/e it cost at the time.
I'm also to my understanding not the ONLY person who has had some quite serious issues with said Plug-In.
Now how AppGameKit VR works exactly., I could only venture to guess.

Yes, it works on Tier 1... but keep in mind that the AppGameKit ("Classic") SDK on GitHub does provide complete access., while the Packaged SDK doesn't.
It's entirely possible the AppGameKit VR Plug-In was built on said "Full Access" SDK., and arguably I could do the same with my project, state that it ONLY supports OpenGL (#Renderer "Basic") and hope that AppGameKit Classic and Studio remain Engine Compatible.

…

While I appreciate the help, it seems quite clear to me that neither of you know the answer.
I mean at a most basic level... it would be good to know if Tier 1 and Tier 2 commands can even interact., or are they run as separate instances of the Engine?

Like I'm starting to see WHY there is a distinct lack of Plug-Ins for AGK., because unlike DBP there isn't even Pointer Support; so it's extremely limiting in what you can actually accomplish via Plug-Ins without access to the Source Code SDK.
Sure, that's available now for AppGameKit v2 … but is it Compatible with Studio? Are there Limitations to it's Compatibility? Will it remain Codebase Compatible?

Thats strange as my headset works ok but I must be the lucky one I guess?? Are you using a supported HMD? (do other steam VR apps work with it?)

There IS an issue with Studio at the moment with AppGameKit VR that is being fixed:
https://forum.thegamecreators.com/thread/225362

I know what you can do with Teir 1 plugins and what needs Teir 2 and ive used both, but I dont know is what your asking...tbh

Teir 1 commands ARE Teir 2 C++ functions...They map directly to C++ functions in the teir 2 code - Its the same core engine underneath. The players just take the teir 1 commands in the bytecode and call the relevant teir 2 library functions. Look in the wrapper.c file on github and all the teir 1 commands map directly to a function in there. Very simple really. Its why its easy to map AppGameKit to other languages (C# and Python wrappers for instance). Classic also shipped with the precompiled teir 2 SDK dll's so its nothing new that it comes with studio. The full source for teir 2 classic is on github as you know and allows you to add whatever you want really but means you would have to get to know the underlying engine in great detail to implement some functions.

What you dont get in Teir 1 plugins is any access to ALL the C++ objects other than the Csprite and Cimage classes - You can get pointers to those classes (and maybe a few more) and to memblock data but not to low level engine variables or other classes. So, you have VERY limited access to the core of AppGameKit from the plugin - but that is completely intentional. Plugins are to work with AGK....not replace the internal functions or rendering routines in AGK. You can call pretty much all of the Teir 1 commands from a plugin but you dont have direct access to the classes and member functions etc...

It would seem clear that if you do want to perform any custom rendering then a teir 2 version is the only way to go unless it is something you can do in teir 1 at present. Id be interested to know if the teir 2 source for studio (including the Vulcan renderer) will be made public. Doesnt look like it at present.

Take a look at the teir 2 source and its fairly apparent what you get access to vs what you can do purely in a plugin which is limited.

A fix for AGKVR working with AppGameKit Studio should be released soon. It did work prior to AppGameKit Studio updating to use the Vulkan rendering engine. It doesn't work when forcing AppGameKit Studio to use OpenGL (by using the #renderer "Basic" parameter) because AppGameKit Studio is no longer providing proper image handles to the render images. As soon as Paul fixes the problem in AppGameKit Studio, AGKVR will start working again with the OpenGL renderer. I am also going to update AGKVR to work with the Vulkan rendering engine, but I need AppGameKit Studio to provide some more information about the Vulkan device. That is a little more complicated to do, but should be no problem once access to the Vulkan device is made available.


I'm still here, Raven. I don't frequent the forum very often, but I've stayed available for support. TGC owns the code to the plugin. I developed it for them and they are free to do whatever they want with it. I've chosen to keep supporting it simply because I want to do so.


Using SteamVR was a no brainer at the time. SteamVR supports all of the PC HMD devices. All other choices would have required using individual API's for each device. Sure, there are some other options available now, but SteamVR was by far the best option at the time of development.


There is nothing special about the "access" that was used for AppGameKitVR. Everything was done with the standard install of AppGameKit Classic using the documented examples of creating plugins.


I'm not aware of anyone else having an issue with the HMD not receiving the render images in AppGameKit Classic. That problem does exist in Studio (for the reasons I mentioned above). I did read about one person having some issues, but it was related to their video drivers, but that is about it. I have both a Vive and WMR device that I use for testing. These days I primarily test with the WMR device because it is simpler to connect. I know someone else that tests with Oculus devices. So, your problem definitely shouldn't be a hardware compatibility issue. Are you trying it in Tier 1 or Tier 2?

Then there is clearly some conflicting feedback that is provided via the forums., as I did post for help with issues I was having with the plug-in on the AppGameKit Chat Forum back when I first purchased the Plug-In (back in June / July).
Ultimately after waiting for some form of response, I just gave up on the plug-In and decided to do prototyping in Unity instead.



While I do understand it from an "All-in-One" Solution., I would argue that there is a difference between creating a Middleware Tool / Library and an User-Centric End Product.
But note, I've been no less vocal about TGC themselves having quite heavy Steam Integration on Desktop Platforms... I won't delve into the litany of reasons why I'm not a fan of the platform (from a Developer / Publisher Standpoint... for Consumers; sure it's fine) but having such a limitation certainly is quite restrictive and also informs a lot about how you want / need to go about creating a (potentially) successful product which can actually see a return on investment.



As I saw it there were three possibilities.
1 • It was just an Interface that was basically behaving like an AFR Stereoscopic Rendering System that simply passed that on to OpenVR ... which sure is a way to do it, but would have issues in regards to Latency, Performance, Frame Stability and Motion Sickness.
(VR Chat uses a similar approach., and it's just plagued by said issues)
2 • It was using the AppGameKit SDK, and there was a way to gain access to the Render Device (or Context in OGL Terms) that I just wasn't seeing
3 • TGC had provided Special Access to the Render Pipeline to the Developer

If you notice I don't specifically assume any of them... merely had listed them within the possible approaches.
Now from my perspective Option 1 is a waste of time and effort., because you're essentially at the whim of both TGC and Valve who can (and have) accidentally broken support with Updates to their Engines / API.

In any case I do have my answer, and this will need some time to think about what / if approach to take next as there are some options but far less straight forward.



This is in Tier 1., as well I'm gonna be brutally honest ... Tier 2 literally makes no sense outside of Mobile Development, as there are just better options for Desktop.
I've had the issue since I purchased AppGameKit VR back in what June / July; as I just got the VR with it, figuring it'd be a quick and fun way to prototype VR Project ideas without having to deal with Unity...

I can't tell you why it doesn't output an image to Steam VR... just that it doesn't.
And that's both the Pre-Built Demos and any project Built with AppGameKit VR., which I've not exactly had much luck with Setting Up and Compiling Projects with AppGameKit VR ... as half the time it keeps telling me the Plug-In isn't Registered or Installed; something like that.
With the exception of copying across the runtime library., the Steam Version is "Supposed" to be Ready-to-Go; but yeah... I've had issues in respect to that as well, which again I got no bloody help about that either.

You know I miss the days of DBP where you'd just drop a Plug-In into the Compiler Folder and that was it... was good to go.
AGK so often feels like a few steps backwards.

Sorry. I just simply missed your post.


All of the feedback that I've received about AGKVR has been very positive. It can be argued that having one API actually makes it more user-centric, but hey, you can't always make everyone happy.


It is being done exactly how it would be done if using OpenVR directly with OpenGL, so option 2 is probably closest to your guess.



Yeah. Without a little more info, I can't really say either. If you ever want more help figuring it out, let me know. I'll see what I can do. Contact me by e-mail for a quicker response.

Wow......I had no idea that guide was there.

That's really useful.