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.


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

Treat finishing like a skill.

When working as a game developer, I’ve noticed something that sticks out at me quite often, and that’s actually finishing a project. Whatever you’re trying to build, if you’re a creative person, guaranteed you have a stack of unfinished projects or grand ideas that you’re too lazy to finish. Or maybe you just don’t have time. Either way, finishing something, especially a game, is hard. I heard this a long time ago, but it was “treat finishing like a skill”, not just a verb. It’s great advice. Grinding through to the very end of any project is hard, hard work. Sometimes, it’s just not fun. And that’s okay! A lot of creative projects are work sometimes, which is why it’s hilarious to me whenever anyone puts playing video games and making video games even close to the same realm. Yeah, because sitting here trying to convert a Quaternion (which is a mathematical formula representing something in 3d space), to Euler angles is the same thing as scoring a goal in Rocket League. Speaking of Quaternions, there’s a cool simulation here that gives you an idea of what they look like.

Recently, I saw a reddit post on /r/gamedev where someone asked when they know they’re done with their game. The short answer? You don’t. You’ll never be done. There’s always stuff to tweak, and there’s always more to add. But here’s the thing: You need to give up. Yeah, weird, huh? You need to know when to quit. It’s very important. A little ironic, considering many people tell you never to give up, but it’s actually also a very important skill. Listen, if we all had unlimited time to make video games, guess what they would all be? CoD mixed with Overwatch mixed with World of Warcraft mixed with… you get the idea. Because we have a shortage of time, we’re forced to make cuts. You have to decide what really fits in the game and what doesn’t. It makes you create a concise experience that ultimately would be better than a meandering mess of a game with no real theme anyway. You just have to get things finished enough and then quit. Release and move on to the next project. You can always go back and update it if you have a great addition or the like, but you do need to be done with it so you can work on other creative endeavors at some point.

So, how about it? Got a project lying around that you’re thinking about taking a crack at again? Why not give it a shot and work towards finishing it?

My Patreon | My Website