VR: The Future?

I recently acquired a VIVE and after a day of oohing and awing about how cool it was, began to make games on it. The first of such games is located on my main site, along with a demo video in case you don’t have a VR headset. You should definitely check it out.

I discovered a couple of things on that day. First off, I’m totally sold on VR being the future. I don’t get motion sick, so I’m fine to whip my head around in Virtual Reality all I want. The experience is really cool. All I’ll say about it is when I first picked up a jetpack, I got butterflies in my stomach, because I felt like I was actually flying upwards. Obviously there’s a lot of room for improvement with the technology, but I can’t wait to see its advancements.

Something very interesting about VR is the need for a diegetic UI. A diegetic UI stands for a user interface that exists in the universe (in this case, a game) that we are experiencing. So, a non-diegetic UI would be your health floating at the bottom left of your screen on a normal computer game.

Now here’s the problem(?) with VR: your eyes can’t focus on something that close. Putting something on screen close to the face of the viewer works really well for normal games where you can focus on the screen at a specific part, but the way the VR goggles work is by projecting two separate images on each lens, and your brain combines it to achieve depth perception. Putting something close to the screen makes your eyes attempt to focus on it, which makes the viewer go cross-eyed and the whole immersion is broken. The solution? Use diegetic UI elements. What this means is attaching the UI to objects IN the game world. This looks really cool, and accomplishes the goal of not breaking immersion and looking terrible.

Notice the time, score, and health are all elements of the ship. It’s much easier to view in VR than here.

Likewise, the time left is stuck to the gun, making it easy to see at a glance.

And another ship one.

 

I wholeheartedly recommend that you pick up a VIVE if you have the money to spare and are looking for the next thing to boost your interest in games. Is VR the future? I don’t know for sure, but it sure as hell feels like it.


My Patreon | My Website

Apple strikes down another standard.

So, Apple is deprecating OpenGL support for macOS. OpenGL, for those unaware, is a

cross-language, cross-platform application programming interface for rendering 2D and 3D vector graphics. The API is typically used to interact with a graphics processing unit, to achieve hardware-accelerated rendering.

WIKIPEDIA LINK

This is an Apple-esque decision in every sense of the word. Whereas Windows supports backwards compatibility to a fault, Apple ditches anything that even remotely starts to become entrenched in our culture. You like physical function keys? No, Apple doesn’t. Use your headphone jack often? Not on the new iPhones, you don’t. Like normal keyboard keys? Ha! Welcome to the future, kid. Our keyboards break in less than two years. Ever replaced a Mac battery? Ever upgraded its RAM? Well, Apple is trying to make self-repairs impossible. Do you want to be on the cutting edge of technology? You’re out of luck. It used to be that Apple was a pioneer. You could count on them making the obvious choice. I used to be an Apple fan, but I’m not reluctant about shouting from the rooftops that they’ve been messing up for a while.

But I’ve digressed. Apple claims that OpenGL is legacy. That the newer standards differ too much, and Apple wants a clean break from the past. This has been their argument with virtually every single decision they’ve ever made. However, this can cause problems for anyone that uses applications, especially games. Gaming on macOS is terrible. I can personally attest to that. Weirdly enough, in tests, Fortnite (a super popular game at the present) performs worse on macOS than it does on the same exact computer running Windows via Bootcamp (built in macOS software that allows you to dual-boot Windows). Steam reports that 96.29% of people that use its massive platform to play games are Windows users. 0.78% use Linux, and a measly 2.93% use macOS. The numbers don’t lie, Macs just aren’t used for gaming.

You’d think that Apple would, therefore, want to keep one of the most popular libraries for creating games graphics alive on their platform, so at least the bare minimum of games that run on their ecosystem would still work. If they remove OpenGL, any game that uses it will cease to work. At the moment, they are simply deprecating it, but when they warned developers for iOS to upgrade to 64 bit versions of apps from 32 bit, they eventually removed support for 32 bit apps. They’ve done the same with their Donglebooks, and there’s no reason to think this will go any other way.

I’m sure this decision comes as a surprise to literally no one, and whether you make excuses for them or think it’s stupid, Apple is the first company to hit a trillion dollars market cap, so they must be doing something right.

If anyone figures out what that is, please let me know.


My Patreon | My Website

A word on Electron.

ElectronJS, also referred to as just Electron, is a really good idea.

Someone, at some point, thought to themselves, “Hey, web developers build websites all the time with HTML, CSS, and JavaScript. Why can’t we just render the same web pages people use as desktop applications?” Which is a brilliant idea. Put into practice though, I’m not sure that Electron should be your first choice when developing a Desktop application.

The implementation of it is what I have problems with. Now, there are a lot of better and smarter coders than me out there, but I feel as if I bring up some valid complaints. Here they are, in no particular order.

The size. A C# or C++ “Hello World” application (click for definition) is under a megabyte, and if memory serves, the C# one is less than 10KB. An Electron app published for the Mac is 115 MB in its “Hello World” application.  That’s insane. RuneTale *wink wink nudge nudge* is 36 MB. A full-on videogame is more than 3 times smaller than a basic program to display a string. This makes making small programs like the Searchifier, for instance, a no-go. If every program on your disk took up 115MB+, you wouldn’t be able to have very many applications. Plus, every time an Electron app starts up, it has to load its libraries into the RAM, which also weigh a ton. If you had a few Electron apps open, you could waste gigabytes of volatile memory.

The redundancy. Speaking of having to load all those libraries into RAM, let’s talk about that. Every single electron app comes with Node.js and Chromium. This is what is making the app so big in the first place. As stated above, bundling a complete browser rendering engine that has almost the same number of lines of code as the Windows OS doesn’t make for efficiency. This slows down newer and older computers alike. On terrible machines (Like this piece of garbage I had the displeasure of owning for a couple of years), running even ONE Electron app with a web browser like Firefox or even Edge slows the computer to a crawl, and literally increases loading times to above 20 seconds per click. Those were hard days.

The cluttered working environment. What’s Yarn? A year ago I would have told you it’s for knitting. Now? It’s a dependency manager for JavaScript. How do you get it? Through NPM. What’s NPM? A dependency manager for JavaScript. The first thing you do when you want to work on a project using React.js or Electron is “npm install” through the command line. Then, you wait as NPM installs the entire internet onto your local project. It gets ridiculous after a while when you have a couple projects on your hard drive all with their own “node_modules” folder that takes AGES to transfer all the tiny little files in it. Committing in git takes forever.

If I can add on to the other paragraph before you grind your teeth into dust, the fact that everything breaks at the slightest touch is a good one and goes hand in hand with the cluttered working environment. Every time you install the packages a project needs, you have to use the same version of those packages because one little change can break the whole thing. There are a couple of ways to denote what version you want, and it’s mostly taken care of for you. If you lock down your dependencies and specify that you only want specific versions of them, the dependencies themselves may not do the same. For example:

  • You want version 0.9.3 of dependency “a”.
  • “a” depends on package “b”, but allows versions 1.3.1 – 1.9.9, denoted by ^ (^1.3.1).
  • Package “b” depends on any path version of 3.4.1, denoted by ~ (~3.4.1) of packages “c” and “d”, both of which depend on any minor version of “e”, which is currently on 1.4.1.

So even if you lock down your dependency versions, package variations can exist across identical installs of the same project. This can lead to small bugs popping up out of seemingly nowhere as bugs are introduced in packages you don’t have any control over. What’s the fix? Often, it’s “turn it off and back on”, by way of

rm -rf node_modules && npm cache clean && npm install

What does this do? In plain English, “Remove the node_modules folder, clean the cache, and reinstall”.

Luckily, at some point someone realized this was an issue and dependency locking was added in Node 5.x+, but a mountain made up of tiny obstacles is still a mountain.

Electron produces some great looking results, however. Since anyone can use the power of CSS and JavaScript, applications can look very fancy and feel nice. Listed on Electron’s showcase page are a few applications that you might not have thought were built with this, including Discord, Skype, and Slack, and I can’t say I hate all Electron apps because I use Visual Studio Code almost religiously in my work and I love it.

Can’t help but wonder how much smaller and better performing Visual Studio Code would be as a native desktop application written in C++ though.


My Patreon | My Website