ASDL style event handling would be quite nice. i always thought glfw's event processing was terrible
i just like to do
i just like to do
Kthat ill agree with
Kperksey having fun with CI
Pthis will probably still be heavily abstracted away
Pe.g. you'd still have to call
Run the "root" surface and that'll pump the events to the relevant windowsAah you're talking about high level silk windowing? i've only used it a handful of times so I don't have too much input on it
Asince the days of when I was using opentk i've been ignoring the built in windowing systems and just rolling my own
Pyeah, essentially
libsilk is just going to be a native counterpart to the HLU that basically implements an almost identical API, but in C (+COM?)P@tannergooding 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 byte).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.
Acurrently .net generic math requires you to specifically implement
ITrigonometricFunctions etc to get the sin and cos functionsAso you can't use those on integers for example
KI think with the new generic API you can solve this with extension types no?
Aas only float + double support it
Aand yeah you can use extensions to fix some issues
KI mean we hardly ever want to support VectorN<T> : any_of_the_interfaces
Aas they will only show up on types that support it
Kso Vector2<T>.Sin can just be defined as an extension method on Vector2<T> where T : ITrigonometricFunctions
Ahttps://github.com/piegfx/Warp/tree/main/src/Warp.Math here's my current generic math implementations if its of any use
K(not mentioning the horrible IDE support for this pattern but...)
Kyeah that works just means things like Length cant be properties
Pyeah I think maybe we should just have a bunch of generic static methods that conditionally enable. a weird consequence of Silk.NET.Maths implementing a proxy over the base ops itself is that all ops were defined in terms of that proxy, allowing strange things like
Sin<byte>Anote the use of extension methods for things like
Length()
Kno reason length isn't well defined on integers?
PI can live with that, we already have static functions like
Vector2.Length in a lot of places anyway
Ksqrt
Khow is that not well defined on integers?
Ksqrt(4) = 2?
Athe square root of 2 is like 1.4whatever
Pthis is a bad suggestion, we can't have silk contributors looking at this due to the license. they'd become radioactive and we won't be able to take any of their contributions for legal reasons.
Ait only works for some integers
Awhile this code is technically gpl license its so generic (haha im unfunny) that i don't care if it gets copied verbatim
Agiven that i just copied stuff from other people anyway
Kand choosing a floating type to coerce to for sqrt-ing ints is always a choice being made
A(system.numerics mainly)
Pthat's irrelevant, we have to respect the license. DNF can't accept that liability.
Ksqrt(2) won't be precise on floating point either
Kjust like sqrt(2) won't be precise* on integers. Sure one is more precise, but either one will be inaccurate
K^ this has essentially been the stance on 2.X. I still stand by that a lot, as I think without this VectorN<int> is just utterly useless
Psee that's the thing,
Scalar.Sqrt<byte>(64) would do the correct thingP(i think)
Kyes, it will. Otherwise that's a big bug but ye
Keither way the issue is implementation here; cant use generic maths with supporting that
Pi think go with what generic maths is using, the BCL team (tanner) have made these decisions for a reason
Kbecause eg IRootFunctions is only implemented by floats for this case
Pas much as you could do more whacky things with Maths 2.X, doesn't mean that you should in every use case (but mostly the respecting BCL team's decision, that's the most pertinent reason)
Kreturn (T) (object) (sbyte) (float) Math.Sqrt((float) (sbyte) (object) x); its not optimized - but should work fineAi almost made mine support all these functions by all types by converting to double under the hood and then doing the calculations, before casting back to int etc
but i thought
there's a reason why it is like this
so best to do it how its been designed
but i thought
there's a reason why it is like this
so best to do it how its been designed
KIt will even do this beauty
return (T)(object)(sbyte)(float)Sse.SqrtScalar(Vector128.CreateScalarUnsafe((float)(sbyte)(object)x)).ToScalar();Pyeah i've just seen this as well.
