At the beginning of 2021, ArenaNet announced that they would no longer be supporting the macOS client for Guild Wars 2. As a longtime player, I found this… unfortunate.
There are several ways to run the Windows client on a Mac including dual-booting Windows with Bootcamp, but that’s not an option for me. Running in a virtual machine like VMWare or Parallels is too slow, so that leaves some form of Wine which is a Windows compatibility layer. The old macOS 32-bit Guild Wars 2 client actually used a version of Wine to run. It wasn’t as good as when they released a 64-bit native client, but it worked for a time.
I tried several ways to run Guild Wars 2 using Wine before finding one that works for me. In this post I’ll explain how to set it up.
One of the fantastic things about game development is that there are a lot of resources available online. Video tutorials, blog posts, forum posts, etc.. Unfortunately the quality varies dramatically and they can end up out-of-date quickly as the game engine changes.
So it can be difficult to figure out how to do simple things because either what you find online uses APIs or techniques that no longer exist, or they don’t use an up-to-date technique that may be simpler. Often they don’t even include what version of the engine they used, so that adds an extra challenge.
There was a simple idea I wanted to play with in Godot that led me here…
Some old-school arcade games such as Raiden and 1942, are top-down, vertical scrollers. In these games, the player is generally restricted to moving left and right (possibly forward and back a little) and the background scrolls past them giving the illusion the player is moving forward. To recreate that style I needed to create a vertical, infinitely scrolling, parallax background.
Googling led to some video tutorials on side-scrolling parallax backgrounds (close!), some short answers in some forums (must be for an older version – didn’t work), and some things that were clearly hacks. After a fair amount of time looking around and watching videos, it turns out that it’s incredibly simple.
The following is a short tutorial will step through setting up a project with a simple player and an infinitely scrolling, parallax background. The complete project may be found on GitHub.
Over the past couple of months I have been porting an existing Unity game to macOS. It is a shoot-em-up called Blue Rider developed by Ravegan from Córdoba, Argentina. It was originally released on PC (Steam), XBox, Playstation 4, and Switch.
I spent quite a lot of time getting it ported and running smoothly only to find that I couldn’t get past Apple’s notarization procedure because of the version of Unity I am using (5.6.7f1).
The binary uses an SDK older than the 10.9 SDK.
Notarization is required as of macOS 10.15 to distribute games in the Apple Store and it may become necessary on Steam. It may also be useful to notarize games for standalone distribution to avoid confusing warnings when users try to run your game.
(I am going to hold off a whole rant about Apple and their BS requirement to do this code signing/notarization at all. And I will try not to rant too much about their incredibly complicated process, documentation, and implementation.)
In this post I’ll describe the main problem I ran into and how I solved it. Hopefully it will help someone else.
Recently I have been working on porting an existing Unity game to macOS. It is a shoot-em-up called Blue Rider developed by Ravegan from Córdoba, Argentina. It was originally released on PC (Steam), XBox, Playstation 4, and Switch.
The main things I needed to work on to bring Blue Rider to macOS were the menu system, the resolution handling, the input handling, and some optimizations to achieve a smooth framerate.
(Note: I’m using Unity 5.6.7f1 since Blue Rider was written using a 5.x version. I’m not 100% sure, but based on the current documentation, I think what I’m doing here still applies with recent versions.)
One such optimization had to do with shaders. The game was hitching sometimes when an enemy appeared and when it exploded. It only seemed to happen some times and with some enemies.
I’ll explain what I found when I broke out the profiler and then I’ll provide one possible solution using ShaderVariantCollection.
CloudCompare is open source software for viewing and manipulating 3D point clouds and meshes. I started participating in the project several years ago to build and package it for macOS and have continued to contribute to it since then.
(The source code for CloudCompare is available on GitHub.)
Last year (2018) I initiated a user survey to get a better idea who is using CloudCompare and to solicit feedback from our users. I set it up using Google Forms and we received 330 responses over the course of about 10 months.
I recently had a case come up related to OpenGL where I needed to know programmatically if my application was running within VMWare Fusion.
It took me a while to understand and piece together a solution, but here is one based on the half-psuedo-code from VMWare’s site.
// Determine if we are running on VMWare or not.
// This is based on code from here:
__cpuid( cpuInfo, 0x1 );
if ( cpuInfo & (1<<31) )
__cpuid( cpuInfo, 0x40000000 );
memcpy( hyperVendorID + 0, &cpuInfo, 4 );
memcpy( hyperVendorID + 4, &cpuInfo, 4 );
memcpy( hyperVendorID + 8, &cpuInfo, 4 );
hyperVendorID = '\0';
return !strcmp( hyperVendorID, "VMwareVMware" );
I didn’t need the extra checks for testing the virtual BIOS DMI information and hypervisor port outlined in that VMWare page, so I didn’t try to implement them.
Hope this helps someone!