Quick Update…

Things are progressing on both the Mac port and the current Beta.

OSX

I did figure out the slowdown with OSX running at 1 FPS. Apparently there are certain functions in OpenGL 3.2 that are just unusable in the OSX driver because they cause a full GPU pipeline flush and the CPU just waits around doing nothing while it happens.

Really this just means that the OSX version of the OpenGL renderer now diverges from the PC (and possibly Linux) version, which is okay, it just means maintaining the renderer over time is slightly more annoying, and that my shader compiler now outputs different vertex and pixel shaders for OpenGL depending on the target platform. Gah!

I’ll probably write more on this later after testing a few more GPU/OS configurations to make sure the PC version doesn’t have to change.

Beta Version

As for the beta, there will most likely be an update soon to fix a few issues. There are two very common bugs that people are reporting.

The first is for mods that had custom materials built. In the developer build, those materials would just fail to draw anything, but in a release build the validity of the material was skipped (supposedly for performance reasons) and as soon as those materials ended up on screen, a crash would occur. That was an easy fix.

The other issue occurs when cutting down trees in an orchard. There’s a bug where the game tries to access the cut down tree after it’s removed, causing a potential crash. Also an easy fix.

Windows 10

What’s stopping me from updating the beta right now is there are bugs I have to dig into, but can’t. Unfortunately Windows 10 (I think) is causing me issues and I can’t currently use many of the crash dumps that people have sent.

What’s happening is that when the game detects the errors I added additional checking for, it forces an exception so that a proper debug crash dump can be output. The instruction on the top of the callstack happens to be in a system dll when this occurs. If the crash dump is generated on Windows 10, my Windows 7 machine doesn’t have debug information for (or even a copy of) the newer updated dll and therefore can’t generate a proper stack frame to begin walking the stack too see where the error occurred.

Basically this means I can’t read these crash dumps, and I just need to upgrade my development machines to Windows 10.

I’ve been avoiding this, because I hate doing OS reinstalls. This is mostly because there’s a lot of software to install to get up and compiling and developing, and I have a lot of computers to update. I end up half-working on other machines but mostly looking at progress bars. There’s also a big chunk of time spent making sure there’s nothing local to the harddrives that isn’t already on the server or NAS before they get wiped.

What I’ll probably end up with is my main desktop and new laptop with Windows 10, a desktop machine that dual boots Windows 7 and Linux, and my old development laptop will become a linux laptop.

Time to wait on HDD formats and progress bars…

Edit: Thanks for the tip of using the MS symbol server… works well. Goes to show there’s always something new you haven’t used or known about after 20-some years of programming. Windows 10 is still a good idea though as I’ve had a few Windows 10 specific bug reports…