Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Doc Block: Apr 15, 2003; Fun Shoe

Yeah, that's kinda why I'm sticking with ObjC until Swift has settled down, has ABI stability, etc. One less thing to have to stay on top of as an independent developer.

If it helps, Metal by Example wrote their own OBJ file loader. There's also AssImp, which has a C API and can load a bunch of file formats. OBJ files are pretty simple, and writing a loader for them isn't very difficult, if you do wind up having to roll your own.

But I'm hoping it isn't a ModelIO or MetalKit bug. I'll test your sample app above on my iPhone 6 w/iOS 11 and let you know how it goes (sorry, I only looked at the source code before, and misread your earlier post; I thought you were asking me to test your actual app, not the test app you posted).

Doc Block fucked around with this message at 01:51 on Aug 9, 2017

# ? Aug 9, 2017 01:35

Adbot: ADBOT LOVES YOU

# ? May 29, 2024 03:44

Doc Block: Apr 15, 2003; Fun Shoe

I ran the test program on my iPhone 7 (iOS 10.3) and my iPhone 6 (iOS 11 beta 5) and got the same result for both, but they look correct to me:

I noticed that the project-wide deployment target is 10.2, is that what you're testing on? Maybe it's an iOS 10.2 bug that was fixed in 10.3?

edit: looking back at this:

lord funk posted:

Well a big problem with using Swift is that there is no way to get the C++ Metal structs visible on the Swift side. I've had some discussions about this and the honest best practice is: just hard-code-enter the stride of the struct.

I don't think you have to share them, in the sense that you don't have to write a header file or whatever that has your vertex attribute structs and is parsable by both Metal shader compiler and Objective-C or Swift or whatever. I've always made them match up out of paranoia and Just Because, but I could've sworn in one of the earlier WWDC Metal sessions they said that as long as your vertex attributes are properly marked in your Metal shaders, Metal will Do The Right Thing if the attribute types, sizes, etc. don't match up. Which makes sense: unlike OpenGL, Metal doesn't compile the shader to native GPU machine code until you create your render pipeline state object, and part of that object is telling it what the CPU-side vertex layout is (including the offset, stride, and data type).

Doc Block fucked around with this message at 02:50 on Aug 9, 2017

# ? Aug 9, 2017 02:16

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I missed that post. Is there really no way to define a struct in C that has the layout you want? It's unworkable to #if all the C++ goop out of the file or define it in a C++ type that wraps a C struct?

# ? Aug 9, 2017 03:43

Doc Block: Apr 15, 2003; Fun Shoe

Part of it is there doesn't seem to be an easy way to do the equivalent of offsetof() in Swift (according to a quick Google search; I don't know the language). What Lord Funk did, at least for his test project, was hardcode the byte offsets and sizes in his vertex attribute descriptor code (GameViewController.swift, in the testModelBufferContentsForModelNamed() function). My first thought when I saw the code was that maybe the size or byte alignment wasn't what the thought it was, but that doesn't seem to be the case.

IDK how easy it would be to write a header file that works in both Metal shading language and Swift that specifies a vertex attribute struct etc. It was Not Terrible^TM to make one that works in both Metal shaders and Objective-C, but it was kinda ugly because of all the #ifdef's needed to get Objective-C to ignore the Metal shading language stuff like [[attribute()]].

The problem Lord Funk is (possibly) having is that either ModelIO or MetalKit seem to be laying out his vertex attribute buffer in memory in a way other than the layout he was specifying in code. But his test app worked fine on both my test devices, running on different iOS versions.

edit: update:

Just to see, I created a new iOS Metal project in Xcode 9 b5 and the template creates a header file that's shared between Metal and Swift that contains various enums and structs that are shared between the Swift and Metal shader code.

Doc Block fucked around with this message at 06:18 on Aug 9, 2017

# ? Aug 9, 2017 05:39

lord funk: Feb 16, 2004

If you can show me how to get a Swift file to know about packed_float3, I'd love to see it. That data type is declared in the Metal stdlib, which you can't import because it's C++. I mentioned this a while ago on the Apple Dev Forums (can't find the post) and was told to just count the size of the struct manually.

Some updates:

Thanks Doc for the test runs! It very well could be a bug since your results aren't what I'm getting, and I'm on 10.2.1 on my device.

There does seem to be a correct way to access vertex data! Instead of querying the MTKMesh, there's MDLMesh's vertexAttributeData(forAttributeNamed:). It looks like it does what you'd expect by locking down the memory while you work with it. I've switched over and things are finally running.

# ? Aug 9, 2017 15:53

lord funk: Feb 16, 2004

Wait I just re-read your post, Doc. Xcode b9 actually has a shared header between them??? with Metal data types? I might just be spending the day updating this rig so I can run it if that's the case.

# ? Aug 9, 2017 15:55

Doc Block: Apr 15, 2003; Fun Shoe

Yes. Sort of. It uses <simd/simd.h> (both in the shared header and in the Metal shaders). But that isn't a recent thing.

And you don't have to use packed_float3, just use the data types in <simd/simd.h> (which Metal, ObjC, and Swift can all access; use "import simd" in Swift). Just be aware that vector_float3 might get padded out to 16 bytes for better alignment.

Like I said, though, Metal should Do The Right Thing if your CPU-side data types don't perfectly match your GPU side ones, so long as you've labeled your vertex attributes with [[layout()]] in your shader code and you specify the right offsets and sizes in your CPU code.

I saw on StackOverflow last night where somebody had created a C offset_of() function that they could use in Swift. In their Swift code they created an instance of their data struct with useless data, and passed the base address of the struct and address of whatever member in it to the C function, which computed and returned the byte offset for use in Metal/OpenGL/etc.

Doc Block fucked around with this message at 16:35 on Aug 9, 2017

# ? Aug 9, 2017 16:10

Doc Block: Apr 15, 2003; Fun Shoe

lord funk posted:

Thanks Doc for the test runs! It very well could be a bug since your results aren't what I'm getting, and I'm on 10.2.1 on my device.

Probably just an iOS 10.2 bug then. Upgrade to 10.3.

lord funk posted:

There does seem to be a correct way to access vertex data! Instead of querying the MTKMesh, there's MDLMesh's vertexAttributeData(forAttributeNamed:). It looks like it does what you'd expect by locking down the memory while you work with it. I've switched over and things are finally running.

This would have to mean that either the vertex attributes are stored in separate buffers, because if they're interleaved internally then it's creating a temp buffer and copying the attributes to it for you to modify, then copying them back when you're done. This sort of thing is part of the reason I don't use Model IO or MetalKit: the whole point of Metal is to avoid performance bottlenecks that can come from black box behavior, by letting your application explicitly specify how your data is laid out, but also how and when it's used, and to let your application control when (or if) it's copied.

One of the things that (for me) makes Metal on Apple's mobile devices so much nicer to use than OpenGL ES is that it doesn't pretend it has to copy your data to VRAM, and doesn't make shadow copies of it, so you don't have to map buffers before you change their contents. You can shoot yourself in the foot by altering something while the GPU is trying to read it, of course, but it's relatively easy to avoid that.

# ? Aug 9, 2017 16:47

lord funk: Feb 16, 2004

Man I was so excited that things were finally running on 10.2. Now 10.3 has me back at a blank screen and errors about sandbox access. Sigh.

Back to square one

# ? Aug 9, 2017 20:21

Doh004: Apr 22, 2007; Mmmmm Donuts...

Hey, I think I might be going crazy, but does calling layoutIfNeeded in an animation block on the parent view of a UICollectionView (to animate constraint changes), reset the contentOffset of the UICollectionView?

Basically, I'm animating some other constraints for my container view and it's resetting the scroll position for my UICollectionView. That doesn't seem right, but that's what I'm seeing? :iiam:

Doh004 fucked around with this message at 20:39 on Aug 10, 2017

# ? Aug 10, 2017 20:32

lord funk: Feb 16, 2004

lord funk posted:

... 10.3 has me back at a blank screen and errors about sandbox access...

Turns out mtkView(drawableSizeWillChange:) doesn't call at load in 10.3, but does in every other system version.

This is going to sound whiney, but are changes like that documented anywhere? I wouldn't be so terrified of future system updates if I had a clue how to react proactively.

# ? Aug 10, 2017 22:47

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The only solution is to be very proactive about installing betas, testing on them, and filing radars so that things get fixed before the actual release.

# ? Aug 10, 2017 23:26

jawbroken: Aug 13, 2007; messmate king

Doesn't look like it was noted in the API changes, but from the description of that method it was probably considered a straightforward bugfix.

# ? Aug 11, 2017 14:34

Doc Block: Apr 15, 2003; Fun Shoe

lord funk posted:

Turns out mtkView(drawableSizeWillChange:) doesn't call at load in 10.3, but does in every other system version.

This is going to sound whiney, but are changes like that documented anywhere? I wouldn't be so terrified of future system updates if I had a clue how to react proactively.

Check the release notes for new betas?

And yeah, test on new OS betas. Don't lag behind on testing on publicly released OS versions either

# ? Aug 11, 2017 16:39

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I'm having a... weird problem with the Swift compiler.

I want to attach a disk image to my emulated disk drive. The Apple II expansion slots are implemented as an array of 8 Peripheral? objects. backplane[6] contains a DiskII object initialized in AppleBase, the base class of AppleII and AppleIIPlus.

https://github.com/Luigi30/FruitMachine-Swift/blob/master/FruitMachine/AppleII/AppleIIBase.swift#L99

code:

        let slot6 = defaults.string(forKey: "a2_Peripherals_Slot6")
        if(slot6 == "Disk II") {
            backplane[6] = DiskII(slot: 6, romPath: "/Users/luigi/apple2/341-0027-a.p5")
        }

When I attach a disk image through the UI (by the ViewController creating an OpenPanel when a menu option is clicked), I call a method on the DiskII, accessing it through a global singleton corresponding to the emulator state. EmulatedSystemInstance! is an AppleIIPlus object.

https://github.com/Luigi30/FruitMachine-Swift/blob/master/FruitMachine/AppleIIViewController.swift#L102

code:

        if(picker.runModal() == .OK) {
            EmulatedSystemInstance!.attachImageToDiskDrive(drive: EmulatedSystemInstance!.backplane[6]!, image: picker.url!.path)
        }

When the app is compiled in Debug mode, the pointer to backplane[6] is the same in both functions and I can attach a disk image. When the app is compiled in Release mode, the pointers are different in each method and the disk image doesn't get attached to the original object. Optimization is disabled in both configurations. The schemes are identical. What's going on?

# ? Aug 13, 2017 01:26

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Whole module optimization, maybe? Despite the name, you can actually build unoptimized code with it; it's more like a different compiler configuration than a mere optimization setting. Maybe it's still enabled.

You're not supposed to see semantic differences even with optimized vs. non-optimized � well, other than deinit timings � so if this is reproducible, it's totally worth a bug.

# ? Aug 13, 2017 03:39

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I disabled whole-module optimization and it's still screwed up. In Release mode, it creates a new DiskII object every time I do (backplane[6] as! DiskII) while it always refers to the original object in Debug mode. I'll file a bug and see if I can figure out a workaround in the meantime.

# ? Aug 13, 2017 04:19

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I... I have no idea how that could possibly cause an allocation.

# ? Aug 13, 2017 19:29

Moogs: Jan 25, 2004; Proceeds the Weedian... Nazareth

I'm trying to randomize a horizontal point within the bounds of the user's Watch, whether 38mm or 42mm, and am using the code below to get the width of the screen in the GameScene.swift file -- what am I doing wrong?

code:

let screenWidth = self.size.width

E: if anybody else is an idiot like me, this is what worked:

code:

let screenWidth = self.frame.maxX

Moogs fucked around with this message at 05:00 on Aug 15, 2017

# ? Aug 15, 2017 00:06

lord funk: Feb 16, 2004

Xcode 9 beta is surprisingly all right. I mean, the entire Editor menu disappears occasionally, but I like the new Source Control stuff a lot.

# ? Aug 16, 2017 17:54

Doh004: Apr 22, 2007; Mmmmm Donuts...

lord funk posted:

Xcode 9 beta is surprisingly all right. I mean, the entire Editor menu disappears occasionally, but I like the new Source Control stuff a lot.

We've been working extensively in it and I'm very happy with it so far.

Building to devices does entire rebuilds every time, but I don't think that's new to XCode 9. :iiam:

# ? Aug 16, 2017 20:23

lord funk: Feb 16, 2004

Metal trip report: Model I/O is buggy. OBJ files don't always parse correctly, which makes it real hard when you're trying to figure out if your matrix math is right. STL files generally work better, but I feel like it's only a matter of time before that's going to break.

So I'm at a crossroads with two options:

1. Just use STL files and Model I/O, and deal with the inevitable app crushing bugs that happen with system updates.
2. Write my own OBJ parser, and re-write my graphics pipeline *again*.

Laziness says I'm going with option 1. When I come back to this thread in 13 months screaming feel free to quote this.

# ? Aug 18, 2017 20:31

Doc Block: Apr 15, 2003; Fun Shoe

Another thing to be aware of is that some programs output really lovely OBJ files. But it sounds like the Model IO bug you encountered was fixed in iOS 10.3 so why abandon it? I mean, you'll have to make sure to test your app on the beta releases to make sure Model IO doesn't break again, but you should be testing it on beta releases anyway.

# ? Aug 18, 2017 20:41

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

You've probably tried setting up a bunch of asserts that look for key values in the loaded obj?

# ? Aug 18, 2017 22:32

epswing: Nov 4, 2003; Soiled Meat

Xcode 6.4
MacMini OS X Yosemite 10.10.5
iPhone 5 SE iOS 10.3.2

The Deployment Target in Xcode is 8.4. When I try to target my iPhone with Xcode and run my project, I get:

"The Developer Disk Image could not be mounted. iPhone may be running a version of iOS that is not supported by this version of Xcode."

I suppose there's some mismatch between Xcode's SDK and my iPhone's iOS version. Any idea what my next steps should be?

# ? Aug 20, 2017 19:29

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I'm not surprised that an old version of the tools doesn't support debugging on a much newer iOS release; we try to keep that interface stable, but sometimes there are reasons we need to update things. Can I ask why you're still using Xcode 6.4? You can set an old deployment target in newer versions of Xcode � we even do deployment-target API checking in Objective-C now, although only in the 9 beta.

# ? Aug 20, 2017 19:58

epswing: Nov 4, 2003; Soiled Meat

Booted an old MacMini from a couple years ago, tried to update Xcode but App Store just spins, not sure if I should try manually installing Xcode 8, not sure if Xcode 8 will even run on Yosemite 10, not looking forward to upgrading my entire OS if I don't need to. I'm so lost

# ? Aug 20, 2017 20:24

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

epalm posted:

Booted an old MacMini from a couple years ago, tried to update Xcode but App Store just spins, not sure if I should try manually installing Xcode 8, not sure if Xcode 8 will even run on Yosemite 10, not looking forward to upgrading my entire OS if I don't need to. I'm so lost

Development support for iOS�the Developer Disk Image the error message mentioned�is included in the Xcode that comes out at the same time as that iOS, and later versions of course. So for iOS 10.3 development support, you need to use Xcode 8.3.

Xcode 8.3, in turn, requires macOS 10.12.

A general rule of thumb is that a spring Xcode (like Xcode 8.3) requires the previous fall's OS (like macOS 10.12). So Xcode 7.3 requires macOS 10.11, while Xcode 7.2.x will run on macOS 10.10. Unfortunately that doesn't really help you since Xcode 7.2.x doesn't support running code on iOS 10.3.

Earlier you mentioned that you set your app's iOS Deployment Target to 8.4; this ensures that the generated code for your app will weak-link APIs introduced after iOS 8.4, but it has no bearing on what iOS versions Xcode knows how to talk to for running and debugging code.

My strong suggestion is to just bite the bullet and do the OS upgrade if your Mac mini can run 10.12; Sierra should not feel substantially different on your system than 10.10, as operating system updates on the Mac have generally not been disasters and have not required a nuke-and-pave approach like other platforms have.

(On my personal Mac I'm using the same home directory I did when I first switched to Mac OS X 10.1 in 2001, and on my Mac at work I'm using the same home directory I've been since I started in early 2004. And I've run pretty much every release since those points, including prerelease versions, without major issues.)

# ? Aug 20, 2017 21:26

epswing: Nov 4, 2003; Soiled Meat

Thanks for the details, almost done downloading Sierra...

Edit: After the 5gb Sierra download, now starts the 5gb Xcode download! The size of software is unreal these days, I see Apple's is no exception

epswing fucked around with this message at 22:56 on Aug 20, 2017

# ? Aug 20, 2017 21:35

Doc Block: Apr 15, 2003; Fun Shoe

5GB is small for an OS, and 5GB for Xcode includes a ton of stuff.

# ? Aug 20, 2017 23:26

FAT32 SHAMER: Aug 16, 2012

Wasnt windows like 25-30gb lol

# ? Aug 20, 2017 23:48

epswing: Nov 4, 2003; Soiled Meat

FAT32 SHAMER posted:

Wasnt windows like 25-30gb lol

Doc Block posted:

5GB is small for an OS, and 5GB for Xcode includes a ton of stuff.

Aw I wasn't truly condemning Apple, it just seems that no matter the platform, everything is pretty heavy these days.

# ? Aug 21, 2017 00:45

Doh004: Apr 22, 2007; Mmmmm Donuts...

Also never download Xcode from the Mac AppStore, it never works. You can download the files directly from the Apple Developer portal.

# ? Aug 21, 2017 00:56

lord funk: Feb 16, 2004

Doc Block posted:

Another thing to be aware of is that some programs output really lovely OBJ files. But it sounds like the Model IO bug you encountered was fixed in iOS 10.3 so why abandon it? I mean, you'll have to make sure to test your app on the beta releases to make sure Model IO doesn't break again, but you should be testing it on beta releases anyway.

Different bugs than the 10.3 one. Just as apocalyptic, but not the same one.

One of the goals of this app is to allow users to load in their own models, so I'd rather go with the safer format than the one that might be buggy because it was exported from a dodgy app. I couldn't even pinpoint exactly what about the files was bad, but I'd re-export a bad OBJ using Blender and it would miraculously work.

Doh004 posted:

Also never download Xcode from the Mac AppStore, it never works. You can download the files directly from the Apple Developer portal.

Have a link? They've redone the dev portal site and I couldn't find it this time around.

# ? Aug 22, 2017 20:45

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

https://developer.apple.com/download/more/

# ? Aug 22, 2017 22:30

lord funk: Feb 16, 2004

Plorkyeran posted:

https://developer.apple.com/download/more/

Thanks I totally couldn't find that the other day.

# ? Aug 23, 2017 00:42

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

I'm a terrible person and still use this Stack Overflow question because it's easier for me to find (I just google "stackoverflow xcode dmg" and it's Safari's suggested website and Google's top search result).

# ? Aug 23, 2017 03:54

epswing: Nov 4, 2003; Soiled Meat

I'm building an http POST request in Swift 3 with a URLRequest. I have a dictionary of key/value pairs I want to send in the POST body. Do I have to manually concat a bunch of strings so it looks like year=2017&name=epalm&id=42 (i.e. do I have to write my own func dictToQueryString(_ dict: [String: String]) -> String)?

# ? Aug 23, 2017 04:55

Doh004: Apr 22, 2007; Mmmmm Donuts...

epalm posted:

I'm building an http POST request in Swift 3 with a URLRequest. I have a dictionary of key/value pairs I want to send in the POST body. Do I have to manually concat a bunch of strings so it looks like year=2017&name=epalm&id=42 (i.e. do I have to write my own func dictToQueryString(_ dict: [String: String]) -> String)?

You can serialize the dictionary to JSON and use the Data from that (assuming your endpoint accepts JSON request parameters).

# ? Aug 23, 2017 11:47

Adbot: ADBOT LOVES YOU

# ? May 29, 2024 03:44

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

epalm posted:

I'm building an http POST request in Swift 3 with a URLRequest. I have a dictionary of key/value pairs I want to send in the POST body. Do I have to manually concat a bunch of strings so it looks like year=2017&name=epalm&id=42 (i.e. do I have to write my own func dictToQueryString(_ dict: [String: String]) -> String)?

There�s a bunch of third-party libraries that will do that for you, but nothing built-in.

I�ve also written https://gist.github.com/nolanw/14b277903a2ba446f75202a6bfd55977 and https://gist.github.com/nolanw/dff7cc5d5570b030d6ba385698348b7c just for fun, which you�re welcome to use in any way you like.

# ? Aug 23, 2017 12:29

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »