what's going on? - porting
I thought that even if I don't have anything particular to share, I will be still doing a short "what's going on?" posts. Here's the first one.
A week ago I started to port Tea For God to Oculus Quest. While it's not going to be released there for a while, I think that it should be possible to experience its current state on Oculus Quest. Wireless, without a powerful PC.
How is it going? Well, it's quite an interesting experience, to say least. Although I expected it to look a bit different. I thought that I will spend a day on adjusting code to run a bit differently on 3 cores (that are available on Quest), then a day setting up the development environment, testing examples, running them on Quest, then a few things related to code organisation and finally, it thought that it will be a few days of making it compile with Clang + replacing all code that depends on Windows or third-party libraries with what's available for Quest. Then it should run and probably run slow, maybe even horrible.
It went a bit differently.
The first thing on the list went all good. I introduced changes, I allowed rendering thread to do gameplay tasks while waiting for GPU to finish. I also changed when background tasks start. As most of them require synchronisation with the game very close to their start and they were starting before gameplay loop advancement, they all were waiting for gameplay code to finish. Moving them after gameplay loop should help a little.
But then comes the development environment. Android Studio + examples went quite quickly. Getting Visual Studio on my computer to compile Oculus Mobile examples was mostly waiting for stuff to download (I have a pretty slow Internet connection, the fastest I can get where I currently live) but I couldn't get VS2017 to do it. I tried various suggestions, even reinstalling VS2017 (that was the last resort to stay with VS2017 and it was one of the suggestions found on the official support page). And finally I installed VS2019 and first thing was to get the game running on PC.
And then the best part started. While I expected that Clang (a compiler used to compile code for ARM64) was going to point warnings and errors in my code, I didn't expect that there will be so many. Visual Studio's compiler, by default, makes lots of stuff easier and doesn't care about some of the stuff. It's not according to the C++ standard. Some of the stuff are almost bugs. But there are also some peculiar things that Clang catches, that are required by the standard, even though they do not make much sense and even Clang just provides a proper solution right in the message - you just have to modify the code and recompile.
I thought that at least after I deal with the core functionality which is low level, I get rid of errors and warnings and I replace PC stuff with Oculus/Android counterparts, it should be much quicker to deal with the framework and the game. Well. No. I'm almost finished with the framework and now I expect that it will be still a day or two left for the game. And then instead of just trying to run the game, I will be testing specific functionalities that had to be modified to get them compile on Clang.
I will take a break from porting to fix the bugs and add a new zone variation to provide a new build this week (think "this weekend").
Get Tea For God
Tea For God
vr roguelite using impossible spaces / euclidean orbifold
Status | In development |
Author | void room |
Genre | Shooter |
Tags | euclidean-orbifold, impossible-spaces, Oculus Quest, Oculus Rift, Procedural Generation, Roguelite, Virtual Reality (VR) |
Languages | English |
More posts
- performance of a custom engine on a standalone vr headsetMar 27, 2023
- "Beneath", health system and AI changesFeb 16, 2023
- vr anchors and elevatorsJan 16, 2023
- v 0.8.0 new difficulty setup, experience mode, new font, performance updateDec 15, 2022
- performanceDec 02, 2022
- getting ready for demo udpate, scourer improvementsNov 15, 2022
- new difficulty + insight upgradeOct 31, 2022
- release delayOct 20, 2022
- loading times and early optimisationOct 17, 2022
Comments
Log in with itch.io to leave a comment.
Great to hear that, especially because I'm a Quest user :)
But I'm not sure if using the Render Thread for other purpose than rendering is a good idea. Why not using another additional Thread for that? Shouldn't the system be able to distribute the threads by itself?
It's the way I have threads, there is just one thread per core and "Render Thread" should be treated as the core on which rendering happens (more info you can find in a devlog post). It is a bit different to what people do, but as I already have it, I will be giving it a go. If it works, I'll keep it. If it causes problems, I can always change the multithreading system :)