WiteWulf wrote:Any progress on Llamasoft games for Oculus Quest 2? I know Giles was pretty critical of the hardware capabilities, but the price/performance balance makes it very attractive for those of us without a high-spec PC.
".. I underestimated the power of your Vindaloo .."
But in this case "I underestimate the time it would have took me for a port", given that the PC version of Moose Life is all OpenGL I had the feeling that "should have been quite a snap".
.. I .. haven't realised "how much ELSE other than graphic" there's in our Neon engine, QUITE A LOT, that deals with "OS stuff" like loading, saving, handing controllers, this, that, etc. the audio ! ..
Those things where "yes the code is quite portable" but "It needs some include there, a define there, a modification there, a complete rewrite there, another thing here, etc. etc." in essence "at the state it is", which is quite advanced, it NEVER before ever been ported or made it run an Android.
So .. it's been a heck of a work.
Got to the point it runs .. it runs but the frame rate is abysmal
Fact is "a core part" been made over a "particular thing that the PS4 does wonderfully", fundamentally the fact you can have areas of shared CPU/GPU mem where the CPU can write "at a low cost" and the GPU can read "at an even lower cost" also the "interface" to that mem is much simpler/direct.
Now on the PC "someway it appears to quite go okeish as well" by use of certain functions, for whatever reason the same code on Quest runs pants.
But there's another huge spanner in the thing, we also used an OpengL draw function that I absolutely had NO IDEA that "does not exist on OpenGLES 3.0" which is GlDrawArraysInstancedBaseInstance(),which allows you to 'offset' both the per-vertex data and the per-instance data the same time "avoiding a fuckload of shit".
Still this works assuming the GL driver does not need to map/unmap/copy buffers because if for whatever reason it does all goes to shit.
So I am finishing a "phase" of COMPLETE REWRITING of the "core draw code" in order to :
- use FP textures as "data buffers"
- use specialised VS that can fetch data "adding that missing offeset"
- use even more specialised buffering mechanism to "pack the data" into non-sparse/smaller chunks
- reduce the number of instructions-per-call in certain functions
Actually I've done almost ( and tested up to a point ) all this but it's still a bit of a work to get there.
If that doesn't work, I'll need to spend quite some time with some GPU/CPU capture thing to figure out "where all the time is gone" and what can be slimmed down to speed up.
Overall, the quest has nor that much of a CPU power, nor that much GPU power and "seems to struggle a bit" when Alpha blending is in use.
Plus being VR "all this gets multiplied by a factor of 2".
But yeah is challenging, the Quest overall is nice but "not so powerful like a PC", also keep in mind a lot of game don't go 70 fps or such but that's our aim.
[edit] - I'd like to add that "I studied various things, I read various articles, I tried a few things myself, I watched some videos of some clever people" .. "those that take out those things like 1M polygons/particles per frame" you DO NOT take that kind of performance EASILY at all, that's the result of months of study sometime even years of research and often "quite some weird and extremely clever optimisations/tricks".
Also "work for some cases" but it's always result of MUCH study/tests, it's not the kind of stuff "you take out in a snap", performance is always very tricky business.
