Cool. Another approach. Never thought of using assumingMemoryBound.
Need to read up on that. I wonder how both versions compare from a
safety/security/performance stand point.
Behold the spinning cubes… ;-)
P
>
> On Sep 3, 2016, at 9:03 PM, Gerard Iglesias via swift-users
> wrote:
>
> Thi
Ok, I see.
But withMemoryRebound requires a return value. Don’t think there’s any way
around that…compiler error
And mainPtr (now typed correctly/safely) needs to access the appropriate data
structure mainPassFrameData.
Hence the external mainPtr.pointee assignment (since I can’t do so safely
I was referring to this:
let mainPtr : UnsafeMutablePointer = shadowPtr.advanced
(by: 1).withMemoryRebound(to: MainPass.self, capacity: 1) {$0}
mainPtr.pointee = mainPassFrameData
The result of $0 is being returned from the block and used later.
cc'ing Andrew Trick on this conver
This is my funny version… I succeeded and I didn’t come back to find an other
way…
// Grab a pointer to the constant buffer's data store
// Since we are using Swift, it is easier to cast the pointer to the ShadowPass
type to fill the constant buffer
// We need to make a copy of these so the bloc
Not sure what you mean?
The positional arg $0 is never used outside the closure whatever the version...
No attempt is ever made to save and reuse after withMemoryRebound?
Why would I use a separate function?
Are we looking at the same code? 🤓
rédigé sur mon iPhone.
> On Sep 3, 2016, at 4:16 PM
Yikes! That's unsafe! When using withMemoryRebound, I think you're only
supposed to use the argument $0 inside the block. Saving it and using it
after withMemoryRebound is probably undefined behavior. But maybe you can
move your ".pointee = x" into a separate function rather than using a
closure?
Finally Success! I’m seeing my pretty little 3D twirling Metal Renderer cubes
again… Here’s how
Snippet of old sample code which no longer compiles in Xcode 8 beta 6 with
stricter Swift3 unsafe type casting restrictions
(in MetalView.swift from # Adopting Metal II: Designing and Implementing
Gerard-
Excellent! Looking forward to seeing your fix (hoping you get your book back
soon ;-) )
I think Xcode/Swift gags on the last ptr advance to objectData. I recently
tried another variant using withUnsafeMutablePointer like this:
var ptr : UnsafeMutablePointer =
withUnsafeMut
Ok
For the record I succeeded this transformation phase last week
I remember the tedious stuff to advance pointer from one struct to the other
kind of struct... it worked
But I don't have my MacBook with me, only the phone, the six :)
Gérard
> Le 3 sept. 2016 à 18:22, Patrice Kouame a écrit
Indeed. There is a difference between stride and size, but I interpreted
capacity incorrectly for my purposes. It should indicate the number of
elements (not their size - right?) and the snippets below should work.
Still, compiler crashes and Xcode IDE is left in inconsistent state. So I
fil
Hi guys,
I’m either missing a subtlety in regards to closures or I found a bug with the
type inference system in Xcode 8 Beta 6. Thought I’d run it by you.
I’m trying to use Data’s method withUnsafeBytes(_:). It’s declared as:
func withUnsafeBytes(_ body:
(UnsafePointer) throws -> ResultType
Hello,
I think that it is more secure to use stride in place of size, sometimes it is
not the same value.
I use it in my own use of raw bindings
Regards
Gérard
> Le 3 sept. 2016 à 10:03, Patrice Kouame via swift-users
> a écrit :
>
> Hi Jacob -
>
> I think you’re right. “capacity” shou
Hi Jacob -
I think you’re right. “capacity” should be the count of type T elements in my
buffer. So in my case that line should read
let shadowPtr = constantBufferForFrame.contents().bindMemory(to:
ShadowPass.self, capacity: shadowPassData.count)
The withMemoryRebound calls need simi
13 matches
Mail list logo
