Tales of a developer

I've been doing some performance analysis of EVE running under Wine on OS X. My main test cases are a series of scenes run with the EVE Probe - our internal benchmarking tool. This is far more convenient than running the full EVE client, as it focuses purely on the graphics performance and does not require any user input. Wine Staging One thing I tried was to build Wine Staging . On its own, that did not really change anything. Turning on CSMT, on the other hand, made quite a difference, taking the average frame time down by 30% for the test scene I used. While the performance boost was significant there were also significant glitches in the rendering, with parts of the scene flickering in and out. Too bad - it means I can't consider this yet for EVE, but I will monitor the progress of this. OpenGL Profiler Apple has the very useful OpenGL profiler available for download . I tried running one of the simpler scenes under the profiler to capture statistics on the...

In a previous blog I wrote about the perils of auto-updating the EVE launcher on Windows when it is installed in Program Files - a protected folder - as it would elevate the process. Due to a bug (that's now been fixed) the launcher would then also start elevated after the update. Any files it would write in that elevated sessions would be owned by the administrator - subsequent launcher sessions where the launcher was started regularly would not be able to overwrite those files. To further complicate matters we were occasionally getting reports of the client reporting damaged files even when the launcher seemed to be downloading and staging files successfully. Protecting system files This turned out be due to a very helpful feature of Windows, actually going back to Vista, when the UAC was introduced. When a legacy application wants to create a file in a protected location where it does not have write permissions, Windows will open a file in the Virtual Store folder, rath...

Writing the C++ code for the EVE launcher is but the first step in getting the launcher to run on EVE players machines. The code is then compiled, the resulting executable and all its dependencies staged in a folder. This folder is then used to create an installer as well as packaged for downloads for the launcher auto-update mechanism. We use TeamCity  to run these builds of the launcher from the source, triggered by checkins. Build agents The machine used to build the launcher has to have the correct software set up - the correct version of Qt , the compiler and the installer framework. For Windows, this meant manually setting up a virtual machine by running the Visual Studio installer, followed by the Qt installer and so forth. The Mac was similar, except it wasn't a VM but a Mac Mini sitting on my desk. The EVE launcher is a small project and the build process is about 6 minutes (including unit tests, compilation of launcher and updater, installer and upload to Amazon) so...

The EVE launcher has an auto update feature - when it detects that a newer version has been deployed, it downloads any changed files and updates itself. The launcher executable can't overwrite the itself or the DLLs loaded so it uses a separate updater. After downloading, the launcher starts the updater and shuts itself down, then the updater replaces the launcher files and restarts the launcher. If the launcher is installed in Program Files, a protected folder, the launcher has to run the updater as an elevated process. Otherwise the updater will not able to overwrite any changed files in the launcher. Going up? At EVE Fanfest we had a roundtable where my team met with players to discuss the things we're working on - the launcher and Wine support. One player mentioned that he had noticed that the launcher would sometimes run in elevated mode, and asked me if it was possible that the update process was the reason. This got me thinking, and I looked over the code in the ...

The EVE launcher downloads a version of Wine that is built from CCP's own fork of Wine. This fork lives on GitHub at https://github.com/ccpgames/wine.git. If you want to build this version yourself, here are some instructions to get you started. Wine has quite a few dependencies we have to fulfil before attempting to build. The first one is Xcode - if you don't have that already installed, get it from the App Store. Note that after installing Xcode you need to run it once to accept the license agreement before being able to use it in the build scripts later. The other dependencies are easiest to get via brew - get it from brew.sh if you haven't already. Wine already exists as a brew recipe, and we can use that to pull down the dependencies. First, though, we need to get XQuartz: brew install Caskroom/cask/xquartz Then to get Wine and its dependencies: brew install --devel wine This takes an hour or so, just so you know. Now everything should be ready to g...

EVE Online has an ingame browser, and under Wine that browser has issues with opening some websites using https. Those sites work in the game under Windows, so I knew it wasn't a browser issue per se. It wasn't an issue with all sites using https, either, so it wasn't a matter of SSL not working at all, either. With the help of CCP's security expert, we noticed that the sites that were failing had certificate chains up to a root certificate with a very strong signature algorithm, ecdsa-with-SHA384, and chances were that Wine did not support that particular algorithm. Now what? Personally I'm no expert in security algorithms, SSL or TSL or anything like that, so I wasn't sure where to even begin looking at Wine source code to see if this algorithm was supported. After some digging around I decided to look at the output of the secur32 channel: export WINEDEBUG=+secur32 Then I started up the EVE client and opened up the browser, entering https://zkillboar...

One issue with the EVE client running under Wine is that when starting in windowed mode, the window would grow by a few pixels every time. I spent some time trying to figure this out and wanted to document my findings here before forgetting all the details. Rather than digging directly into Wine source code I started by looking at how the window is created in our code. That code is a bit convoluted, to say the least, and largely hasn't been touched in years. But hey, it works, right, and if it ain't broken don't fix it. There are two parts to the story when creating the window - there is the window itself, and the Direct3D backbuffer that is drawn in the window. When the window is resized, the backbuffer is recreated to fit the window. The Python code calls trinity.app.ChangeDevice, which internally creates the window if it doesn't already exist, then creates a backbuffer of the appropriate size. The window proc for the window handles the WM_ENTERSIZEMOVE and WM_...

A few months ago I started experimenting with Wine support in the launcher for EVE Online on Mac. We announced this on the EVE forums and players have slowly started migrating over to using the Wine wrapper. I want to use this blog to share my experience with using Wine, and describe my process of finding and fixing issues with running EVE under Wine on the Mac. Who am I? If you follow the EVE forums you may know me as CCP Snorlax - I have worked at CCP since 2007, doing all sorts of stuff, mostly low-level graphics and other systems. Lately I've been working on the launcher for EVE - redoing it from scratch with proper support for multiple accounts and logging in to test servers, as well as rethinking the patching mechanism used for updating the EVE client. As I mentioned above, the last few months I've been working on Wine support on Mac. Before joining CCP I lived in the San Francisco Bay Area - I worked for Electronic Arts (Maxis) on various Sims titles, and even...