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.
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!
I recently had a customer describe some very random crashes with my software. There didn’t seem to be a pattern or a way for me to reproduce the problems locally to debug them. So my first thought was to get him to install a version with some kind of crash reporting tooling so I could get a stack trace to help track down the issue.
I’d looked into implementing some form of crash reporting quite a while ago, but it was never a very high priority for me because I don’t get a lot of bug reports. In this case though it seemed like it would be easiest if I could produce a version of my software with some built-in stack tracing.
The first thing I did was to look at what libraries were available for this. My criteria were:
- simple to use/integrate with a Qt application
- works with the MinGW 32-bit compiler on Windows and the clang compiler on macOS
- inexpensive (or free!)
- usable in commercial software
The most promising were BreakPad (older) or CrashPad (newer) from Google. From what I understand, Breakpad no longer works on macOS which is why they switched to CrashPad. Unfortunately CrashPad doesn’t handle 32-bit MinGW builds. The reason I’m stuck with the 32-bit version is that Qt currently ships its MinGW builds of the libraries and toolchain using the 32-bit MinGW 4.9.2 compiler.
So after a lot of searching and piecing things together, I’ve created something that works and fits my criteria. It’s very simple – all it does is save the stack trace to a file that the user can send me – and requires some instructions to the user to work with it. If I wanted to get fancier I could have it automatically post the information to a web server, but for now this is simple and it works.
It might work on Linux too since the code path for macOS should be POSIX compliant, though I haven’t tried it. It could also be extended to handle MSVC compiles (or maybe it already does!), but I don’t use that compiler so I can’t test it.
I used many different sites in my search, but my primary sources were Catching Exceptions and Printing Stack Traces for C on Windows, Linux, & Mac by Job Vranish, Printing a Stack Trace with MinGW by Daniel Holden, and the C++ name mangling article on Wikipedia.