Other I built a copy of Ship of Harkinian (Ocarina of Time PC Port) for OS X 10.9 Mavericks

[Wowfunhappy]

Ship of Harkinian is an unofficial PC/Mac port of The Legend of Zelda: Ocarina of Time, based on a decompilation of the game's code. https://www.shipofharkinian.com/

Official builds of Ship of Harkinian are compatible with OS X Catalina and newer. I had the urge to try getting this to run on Mavericks, and I figured I would share the results.

The good news is that it works! The bad news is that I'm disappointed in how it performs. My Mavericks computer is quite powerful, equipped with an Intel i7-4790K @ 4 Ghz, a GTX 780 with 6 GB of VRAM, and 32 GB of memory. Even so, I am not able to get a consistent 60 fps on the title screen of Ship of Harkinian. Given that this is a port of a game from 1998, and it's not running under emulation, I was really hoping for better.

I don't know whether the poor performance is my fault or not. It's also a bit frustrating because I can't seem to tell what the bottleneck is. CPU usage remains below 50%, and memory usage below 230 MB. I'm honestly not sure how to monitor GPU usage on OS X, but I find it kind of hard to believe that scenes designed for the N64 would overload a GTX 780...

My frustrations aside, the original Ocarina of Time only ran at 20 fps on the N64 (and at 240p), so I'm being more than a little picky. Feel free to download the attached and play around!

My build instructions are here: https://gist.github.com/Wowfunhappy/ab459b4bf7c070f31300894c42c427a4. I would have preferred to use git to track changes, but Ship of Harkenian uses a bunch of submodules which also needed edits, to the point where I found it less confusing to just document my changes in a single text file as I went.

 

[f54da]

>monitor GPU usage on OS X,
OpenGL profiler, from xcode graphics tools (download separately).

Do you have a reference for whether it's known to work OK on modern macos versions?

Edit: Looked at build instructions and saw that on newer macos it uses metal. I'm guessing it's using OpenGL backend for SDL then? I have no idea what type of messy abstractions that imposes, but I guess basic thing to check would be if you are CPU bound or GPU bound, using above profiling tools or a simple printf to log time taken in flushBuffers() vs game loop.

 

[Wowfunhappy]

Do you have a reference for whether it's known to work OK on modern macos versions?

Well, they advertise Mac support, I assume it's playable. But, no, and for all I know they mean at the original 20 fps framerate.

Edit: Looked at build instructions and saw that on newer macos it uses metal. I'm guessing it's using OpenGL backend for SDL then?

Yeah, but OpenGL/SDL is an officially supported backend (you're normally able to choose between Metal and OpenGL on macOS, obviously I ripped out Metal support). SDL usually performs well IME, lots of commercial games use it.

I'll see if I can do some profiling, but I'm not sure what I'd do with the information. I also just discovered the game runs perfectly on my much less powerful macbook air with integrated graphics, provided I keep the framerate locked to its native 20 fps. Apparently, anything above 20 fps uses frame interpolation, because all the physics and such is tied to the frame rate, so I think that may be what is killing performance, and then all of this is to be expected.

It's still disappointing to me, I just really dislike low framerates.

 

[f54da]

>frame interpolation

Frame interpolation should be fast though, if it's only blending already rendered-frames. But it probably doesn't look very good anyhow?

 

[Wowfunhappy]

>frame interpolation

Frame interpolation should be fast though, if it's only blending already rendered-frames. But it probably doesn't look very good anyhow?

It looks very good! I don't think it's using frame interpolation in the sense you're thinking of. I had the same confusion earlier and tried to Google this, but I didn't find a good explanation of what's going on.

 

[f54da]

Seems to be doing something they refer to as "matrix interpolation". Luckily there is a comment block

Matrix Interpolation

Is there a limitation in Dolphin's rendering that would prevent it from using matrix interpolation to increase framerates in games similar to how Ship of Harkinian (an OOT PC Port) implements it? Impl

forums.dolphin-emu.org

Shipwright/soh/soh/frame_interpolation.cpp at develop · HarbourMasters/Shipwright

Contribute to HarbourMasters/Shipwright development by creating an account on GitHub.

github.com

So it's not "interpolation" on the blended frames but rather interpolation the underling motion or something. I don't know what framerate it tries to interpolate to, maybe it's trying to do 60fps interpolation, whereas interpolating up to 30fps would probably be less intensive?

 

[Wowfunhappy]

I don't know what framerate it tries to interpolate to, maybe it's trying to do 60fps interpolation, whereas interpolating up to 30fps would probably be less intensive?

You can set it to any arbitrary value between 20 fps and your monitor's refresh rate. (There's a slider in-game.)

I made a discovery though. If the F1 enhancements menu is already open when I launch the app, and I leave the menu open, performance is noticeably better (I get 60 fps throughout the title screen cutscene). If at any point I close all overlays, I start getting frame rate drops until I restart the app, even if I bring up the enhancements menu again. So something is going on, but also for now there is an (admittedly slightly annoying) workaround.

Edit: Oh! And this bug doesn't exist on my Macbook Air, where the game runs at 60 fps even when the overlay menu is hidden, provided I disable antialasing (which is at least somewhat reasonable for a machine with Intel HD Graphics 5000). So YMMV.

 

[f54da]

Ah then this might be one of the cases where the opengl commands happen to hit some slow path for Nvidia drivers but not the intel ones. (Which as I understand is unfortunately common for the high-level api that is opengl). And maybe enabling the overlay menu is adding a synchronization point or somehow nudging things in a way that some presumable stall is avoided. (it might even be a driver bug, who knows)

I think with things like this the only real option is to have a flag or detect the gpu at runtime and use the different logic. Would be good if you can get a gpu profile and compare between the two. Could also look at the code to see what additional opengl commands are enqueued by having the overlay on.

 

[Wowfunhappy]

I think the first thing I'm going to try before even profiling is to see if just compiling with a different toolchain (e.g. different version of SDL and clang) fixes the problem. I'm also going to try adding support for Snow Leopard since I believe in theory everything should still work.

 

[f54da]

snow leopard doesn't support opengl 3.1 though? Or does this not use opengl3.