Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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;
}
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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;
Post not yet marked as solved
It's exactly what I mentioned. Smaller images may have some page sub-allocation strategy. Small buffers in Metal are sub-allocated from a larger 128K buffer, but that's harder with texture data. Not that on macOS Intel, the page size is higher so the need to atlas is even more true there.
256x256, mips 8, Astc: 21872, Metal: 32768 <- mips add up to 16K x 4/3 approx = 21845, but due to align and 16K page size, padded out to 32K
256x256, mips 1, Astc: 16384, Metal: 16384 <- this is the exact fit 32x32x16B = 16K