Posts

Post not yet marked as solved
12 Replies
0 Views
Ok, so not an answer, but writing here for the watching members to receive a notification: I've now found that, in my case, it happens when I use a build scheme for a universal app to run under Rosetta: I haven't had a chance to check if such a build, when running on an Intel machine, also kicks out so much guff. I'm hoping it's queit when on a non-Apple Silicon machine. If I switch to an Apple Silicon only build scheme then it all goes quiet. I'll log this as a bug.
Post not yet marked as solved
2 Replies
0 Views
There are a few ways to fix (apparently). Personally, I had to unpair the device in Xcode and restart the iPhone. Reconnecting it and leaving the 'Devices' window in Xcode to do it's thing fixed it for me. But there's also answers here: https://www.reddit.com/r/iOSBeta/comments/q1onth/ios_151_device_support_file_for_xcode/ https://stackoverflow.com/a/68378023/372347 Hope one of these works for someone!
Post not yet marked as solved
6 Replies
0 Views
I've used both Listing 2 and Listings 3&4. Most links I've found around the web seem to use Listing 2 which is certainly the 'cleaner' of the two.
Post not yet marked as solved
6 Replies
0 Views
Thanks for taking the time. It’s the same code as in the Q&A that I linked to in the original post.
Post not yet marked as solved
6 Replies
0 Views
Thanks, I’ve tried it on a MacBook Pro and a Mac Mini - same results.
Post marked as solved
1 Replies
0 Views
Found the answer:the MTLClearColor has to be set before the makeCommandBuffer() and makeRenderCommandEncoder(description:) is called.
Post marked as solved
2 Replies
0 Views
Sorry for a late response. Thanks for that I hope to give it a whirl later in the week. I did wonder about just dropping the projection part of the equation.
Post not yet marked as solved
2 Replies
0 Views
Hi Mike,It's being set with:storedPMatrix = matrix_float4x4(projectionFov: radians(fromDegrees: 65), aspect: viewWidth/viewHieght, nearZ: 0.1, farZ: 100)and this is declared in a library I got from the RW tutorials site:init(projectionFov fov: Float, aspect: Float, nearZ: Float, farZ: Float) { let y = 1 / tan(fov * 0.5) let x = y / aspect let z = farZ / (nearZ - farZ) columns = ( float4( x, 0, 0, 0), float4( 0, y, 0, 0), float4( 0, 0, z, -1), float4( 0, 0, z * nearZ, 0) ) }
Post marked as solved
8 Replies
0 Views
I think the short answer is no. I went back to my red bible and looked at the section in order-independent blending and it’s beyond me for the moment!
Post marked as solved
8 Replies
0 Views
Thanks Darkwing, it was a help! I used your better code but also had to render the primitives in reverse order to the way I had them. Is there not a way to do order-independent blending?
Post marked as solved
8 Replies
0 Views
Hi, Sorry to hijack your thread but I’m having huge problems getting blending working on Metal. I just want to half mix one texture on top of another and my pipeline setup matches yours but the half mixed texture cuts a hole in the background texture. I’ve posted a more compete explanation here: https://stackoverflow.com/q/48569436/372347 Don’t suppose you’d care to share your shader code for this would you? I’m wondering if I’m not doing the blending correctly there.
Post marked as solved
5 Replies
0 Views
I should have specifically mentioned: I did have the switch set to 'iPhone' target. The reviewer tested on an iPad anyway and sent a screenshot to me of the issue on an iPad Air. When I appealed the review board said:"We noticed that your app did not run at iPhone resolution when reviewed on iPad running iOS 11.0.3. Specifically, as we require all iPhone apps to be fully functional on iPad, we found that the last slider in the audio settings was covered by the bottom menu."From then on I had enormous troubles with Stack Views not working as I intended in all orientations on all devices and IB just being next to useless for prototyping. I found that hand-made positioning and sizing code which I wrote to be far more useful but I didn't like what it did in landscape mode on an iPad - there are numerous settings that I wanted the user to easily get to so it was proving too much of a task to re-arrange for all screens considering what a small utility app this is. Supporting only portrait has significantly improved matters!As I say, I've submitted with only portrait supported and hopefully it'll pass. It was good to hear from someone else that there shoudln't be an issue.Thanks.
Post marked as solved
5 Replies
0 Views
Thanks, so I'm not sure why another app was rejected for only operating in one orientation but I'll disable rotation and submit.Sorry: I'm not quite sure I understand the last two sentances. The reviewer wanted the app to run on an iPad even if it I had set the target device to iPhone and not Universal. Perhaps a small blip in the review process. Perhaps! 😉