This is the workaround is to set the containing scrollView hidden instead of the tableView itself. // doesn't work, scrollbar responds to pan gestures and displays empty scroll region // _tableView.hidden = YES; // fix broken NSTableView, keeps showing scroll and responding to pan   // so set scroll to hidden instead of tables   NSScrollView* scrollView = [_tableView enclosingScrollView];   scrollView.hidden = YES;

Actually, that's not a complete fix. The area the table occupies invisibly for the scrollView is still consuming pan events. There's just no visual of the slider moving, but that whole area is a panning dead zone now.

I had a second NSTableView in the storyboard that I needed to remove. The fix above is still needed to have the tableView hide itself.

Where is an Apple code example that sets all this up? Having a single post about this on the forums is not enough. The link above is not informative. We don't want multiple windows, we just want a single resizable window of an iOS title. Other posts state that you must be iPad Multitasking aware, and that requires several settings.

This seemed to work. I still don't see why the storyboard settings don't apply to control this. - (void)awakeFromNib {   [super awakeFromNib];   // vertical offset of table down so hud can display info   NSScrollView* scrollView = [_tableView enclosingScrollView];   CGRect rect = scrollView.frame;   rect.origin.y += 50;   scrollView.frame = rect; }

USDZ is a dcc format that's not optimized for GPU use. It's a dcc transfer format that Pixar designed for maintaining high-quality assets for their films. Unlike GLTF, the data is completely stored as uncompressed floats. You can use ModelIO to compress all the vertices. Then write that out as a GLTF or usable asset format of your own design. Then the image data is jpg/png. Jpg should never be used with 3d models, unless you like normals to ring. And png can't represent the 7 image types that most gpus need. So then you need to turn those png textures into ktx or ktx2 files, and then BC compress for desktop or ASTC/ETC compress them for mobile.

Not quite correct to lump M1 in with A14. It has BC support not reflected in that table. Now I wish the iPhone/iPad did too.

This is all fine, but C++20 modules don't apply to Objective-C and C++ libraries. Would be nice to just have this work, so interop continues to work. I had to go through and replace all @import usages with #import.

Also seems like one of the main reasons to switch to C++20 isn't implemented either - C++20 modules. So I can't seem to still use clang modules, and can't switch to C++20 modules.

Fastest method is to use Neon vcvt_f32_f16 and vcvt_f16_f32. Intel also has ops for f16c extension, but note that Rosetta2 doesn't support emulated AVX for f16c.

There are no armv9 parts from Apple yet. it's all arm64e/arm64 which are variants of ARMv8 I think. What's nice is fp16 conversions and other features often missing from Android are present.

Sorry, you'll have to buy a Mac. Then you can install Windows on Bootcamp if it's Intel based, but not if it's M1 based. We dev games on all platforms using Parallels VM.

Apple's OpenGL 4.1 lacks BC6/7, compute, validation layers, and glClipControl, and much more. So if you're still using OpenGL, then good luck.

Also the microscopic single color super-thin display of the signposts in Instruments is really not that helpful. This should be displayed as a real flame chart. We'll keep using Perfetto for now.

I don't see anything in the build output that indicates that the pch was compiled and used. And the build timings aren't any faster. -ftime-trace shows the same header file being parsed as used again and again, adding up to a large overall time.