this was what DangerousCreate did, and was removed as soon as humanly possible
this was what DangerousCreate did, and was removed as soon as humanly possible
Kmy point was more you cant use the sneaky way to circumvent this ref field to ref struct issue
Pyeah sure
Mwhat if
PI also don’t know any way that doesn’t involve fixed, refs, or sentinels to track a heap pointer
Mweak table?
Pthat would be the sentinel
Pand you’d have to have a secondary object to act as the sentinel
Pbecause if you create a single CWT (aka DependentHandle) with a sentinel freeing the GCHandle upon collection and you use the GCHandle target as the sentinel itself, it’ll never get collected
Pyou can’t have an object manage its own lifetime in a managed to native transition without fixed or refs
Ptechnically we could make it so the user can opt into manually managing their heap memory, but that sucks
Mcall into internal coreclr methods
Mthere must be one of them
CHere's a question, currently the SilkX code uses Unsafe.AsPointer to cast a ref variable to a related pointer. What happens if the GC moves the value between us getting the pointer and using it in native code?
Does Unsafe.AsPointer fix the object so the GC can't move it?
Does Unsafe.AsPointer fix the object so the GC can't move it?
Pnope, that’s why I wanted to make sure that you made the operators that use Unsafe.AsPointer explicit instead of implicit
Pbecause it’s basically only safe for stack refs
Por struct this refs
Palthough even that can be unsafe
Pbasically only use it if you know it ain’t moving
Cso in practice is this usable to take my vertex array or descriptor table data and pass it into commandlists? Data most likely put on the heap.
Pthe current implementation is yeah as you won’t have Unsafe.AsPointer in the loop
Pthe ref will remain tracked until it’s fixed by the generated code
CIs the plan for users to use these objects in place of an array or object all the time or just to be silently converted to when you pass in an object into a Silk function?
Pit’s only intended to be an interchange type
Pso when you need to pass something to native or read something from native
Pbasically what’s in Playground
Tdid I get pinged?
discord said there was one here, but nothing in the inbox or that I can find
discord said there was one here, but nothing in the inbox or that I can find
Pyeah, I pinged you a while ago wrt porting silk.net.maths to generic maths. One sec
Vperksey#0000
@266043404398493696 i don't suppose over the years you've come up with some smart ideas for Vector2<T>? we're looking into moving to generic maths, and obviously there's loads of cases that Silk.NET supports today that would be silly in a generic maths world (e.g. you can do
we can go with use case parity with 2.X, even if it doesn't make sense, but i figured given you'll have to be tackling this problem eventually maybe you have some loose thoughts knocking about in that noggin.
Sin on a bytewe can go with use case parity with 2.X, even if it doesn't make sense, but i figured given you'll have to be tackling this problem eventually maybe you have some loose thoughts knocking about in that noggin.
Original Message
Quoted by perksey#0000
TI see, I see. I wonder why it only showed me the ping today 
TVector2<T> supporting only floating-point vs supporting integers in general is something I've struggled with finding the right balance for/aroundTWhen you consider some of the most core APIs that a "euclidean vector" needs to provide
then, in general, there are a lot of concepts that simply don't work with integer types
for example, you really can't even do something as basic as normalize the vector or get a valid length
but you can still do some things that somewhat make sense, such as get a rounded distance
then, in general, there are a lot of concepts that simply don't work with integer types
for example, you really can't even do something as basic as normalize the vector or get a valid length
but you can still do some things that somewhat make sense, such as get a rounded distance
Tnow, you could argue that at the most basic level, it is fine for
which is to say, it does the computation and rounds it to the nearest representable result using some specified rounding direction
but, this gets problematic when needing to consider the algorithm generically and version it over time
because while you could give an approximation of
you can't do the same with integers and things trend towards 0 or 1 for all answers
Sin(x) for an integer to work much as x / y doeswhich is to say, it does the computation and rounds it to the nearest representable result using some specified rounding direction
but, this gets problematic when needing to consider the algorithm generically and version it over time
because while you could give an approximation of
Sin(x) for floating-point, as you can say that Pi can be loosely representedyou can't do the same with integers and things trend towards 0 or 1 for all answers
T----------------
so, the closest thing I've determined to "correct" here is that
and that the concepts where you want to support integers as well are more limited and should be a separate type
so, the closest thing I've determined to "correct" here is that
Vector2<T> should only be where T : IFloatingPoint<T> (or IFloatingPointIeee754<T>)and that the concepts where you want to support integers as well are more limited and should be a separate type
Point2<T>Tthat way you can still do basic arithmetic operations and concepts like
(distance can be represented, not as straight line distance, but rather as a pair representing the lengths of the two sides, rather than hypotenuse; for example)
distance between two points where-as that can be made to makes sense(distance can be represented, not as straight line distance, but rather as a pair representing the lengths of the two sides, rather than hypotenuse; for example)
Twithout having to pessimize the type in general for the core concepts that do need to be supported when you have floating-point types
PHuh yeah makes sense, I hadn’t considered making a basic type
Tit's not necessarily "ideal", and in many ways
vector and point are "the same thing"Tbut, it ends up being just enough of a theoretical difference that it ends up kinda working, at least in my head
Pyeah. I think the other thing we were considering was just having everything as static/extension methods and discriminate that way
Pother than core operators of course
Pthat way the struct is basically just a storage type
Poh but then I suppose you can’t implement the generic maths interfaces on the vectors themselves
Tyeah, I had considered that as well. But it had broken down when considering things like
and those are such core concepts to vectors, that it made me think again
Length or Normalizationand those are such core concepts to vectors, that it made me think again
P.Length and .Length() isn’t too much of a compromise but get your point
Tright, just it wasn't about whether you do
but rather the fact that
.Length or need an extension called .Length()but rather the fact that
Length was not universally availableTit not being available for a
Vector2<int> almost means that what you have isn't a vectorTand the conceptual difference between point and vector is that point is a location in space
where-as vector is a length and direction instead
thus for a point
just the point represents an exact location and a vector represents a delta
thus the point is the same as a vector from
where-as vector is a length and direction instead
thus for a point
(1, 3) and a vector (1, 3). You have conceptually the "same thing", but also notjust the point represents an exact location and a vector represents a delta
thus the point is the same as a vector from
(0, 0)Tso it's almost like
DateTimeTimeSpan (vector) in that regardPhmmm, I suppose we could just pretend that the struct is in fact a point and put the name down to “unfortunate historical reasons”
