SDL style event handling would be quite nice. i always thought glfw's event processing was terrible

SDL style event handling would be quite nice. i always thought glfw's event processing was terrible
i just like to do

SDL_Event event;
while (SDL_PollEvent(&event)) {
  switch (event.type) { .... }
}

SDL_Event event;
while (SDL_PollEvent(&event)) {
  switch (event.type) { .... }
}

SDL_Event event;
while (SDL_PollEvent(&event)) {
  switch (event.type) { .... }
}

SDL_Event event;
while (SDL_PollEvent(&event)) {
  switch (event.type) { .... }
}

khitiara•10/17/23, 5:31 PM

that ill agree with

Kai•10/17/23, 5:32 PM

perksey having fun with CI

AAqua SDL style event handling would be quite nice. i always thought glfw's event proc...

Perksey•10/17/23, 5:32 PM

this will probably still be heavily abstracted away

Perksey•10/17/23, 5:32 PM

e.g. you'd still have to call RunRun the "root" surface and that'll pump the events to the relevant windows

AquaOP•10/17/23, 5:33 PM

ah 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

AquaOP•10/17/23, 5:33 PM

since the days of when I was using opentk i've been ignoring the built in windowing systems and just rolling my own

Perksey•10/17/23, 5:34 PM

yeah, essentially libsilklibsilk is just going to be a native counterpart to the HLU that basically implements an almost identical API, but in C (+COM?)

Perksey•10/17/23, 5:34 PM

@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 SinSin on a bytebyte).

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.

Perksey•10/17/23, 5:35 PM

oh i didn't reply to the message, this is the relevant link team-talk

AquaOP•10/17/23, 5:35 PM

currently .net generic math requires you to specifically implement ITrigonometricFunctionsITrigonometricFunctions etc to get the sin and cos functions

AquaOP•10/17/23, 5:35 PM

so you can't use those on integers for example

Kai•10/17/23, 5:35 PM

I think with the new generic API you can solve this with extension types no?

AquaOP•10/17/23, 5:35 PM

as only float + double support it

AquaOP•10/17/23, 5:35 PM

and yeah you can use extensions to fix some issues

Kai•10/17/23, 5:35 PM

I mean we hardly ever want to support VectorN<T> : any_of_the_interfaces

AquaOP•10/17/23, 5:35 PM

as they will only show up on types that support it

Kai•10/17/23, 5:36 PM

so Vector2<T>.Sin can just be defined as an extension method on Vector2<T> where T : ITrigonometricFunctions

AquaOP•10/17/23, 5:36 PM

https://github.com/piegfx/Warp/tree/main/src/Warp.Math here's my current generic math implementations if its of any use

Kai•10/17/23, 5:36 PM

(not mentioning the horrible IDE support for this pattern but...)

khitiara•10/17/23, 5:36 PM

yeah that works just means things like Length cant be properties

Perksey•10/17/23, 5:36 PM

yeah 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>Sin<byte>

AAqua <https://github.com/piegfx/Warp/tree/main/src/Warp.Math> here's my current gener...

AquaOP•10/17/23, 5:36 PM

note the use of extension methods for things like Length()Length()

Kkhitiara yeah that works just means things like Length cant be properties

Kai•10/17/23, 5:37 PM

no reason length isn't well defined on integers?

Kkhitiara yeah that works just means things like Length cant be properties

Perksey•10/17/23, 5:37 PM

I can live with that, we already have static functions like Vector2.LengthVector2.Length in a lot of places anyway

KKai no reason length isn't well defined on integers?

khitiara•10/17/23, 5:37 PM

sqrt

Kai•10/17/23, 5:37 PM

how is that not well defined on integers?

Kai•10/17/23, 5:37 PM

sqrt(4) = 2?

AquaOP•10/17/23, 5:37 PM

the square root of 2 is like 1.4whatever

AAqua <https://github.com/piegfx/Warp/tree/main/src/Warp.Math> here's my current gener...

Perksey•10/17/23, 5:37 PM

this 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.

AquaOP•10/17/23, 5:37 PM

it only works for some integers

PPerksey this is a bad suggestion, we can't have silk contributors looking at this due to...

AquaOP•10/17/23, 5:38 PM

while this code is technically gpl license its so generic (haha im unfunny) that i don't care if it gets copied verbatim

AquaOP•10/17/23, 5:38 PM

given that i just copied stuff from other people anyway

khitiara•10/17/23, 5:38 PM

and choosing a floating type to coerce to for sqrt-ing ints is always a choice being made

AquaOP•10/17/23, 5:38 PM

(system.numerics mainly)

Perksey•10/17/23, 5:38 PM

that's irrelevant, we have to respect the license. DNF can't accept that liability.

Kai•10/17/23, 5:38 PM

sqrt(2) won't be precise on floating point either

Kai•10/17/23, 5:39 PM

just like sqrt(2) won't be precise* on integers. Sure one is more precise, but either one will be inaccurate

Kai•10/17/23, 5:39 PM

^ 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

Perksey•10/17/23, 5:39 PM

see that's the thing, Scalar.Sqrt<byte>(64)Scalar.Sqrt<byte>(64) would do the correct thing

Perksey•10/17/23, 5:39 PM

(i think)

Kai•10/17/23, 5:40 PM

yes, it will. Otherwise that's a big bug but ye

khitiara•10/17/23, 5:40 PM

either way the issue is implementation here; cant use generic maths with supporting that

Perksey•10/17/23, 5:41 PM

i think go with what generic maths is using, the BCL team (tanner) have made these decisions for a reason

khitiara•10/17/23, 5:41 PM

because eg IRootFunctions is only implemented by floats for this case

Perksey•10/17/23, 5:41 PM

as 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)

Kai•10/17/23, 5:41 PM

return (T) (object) (sbyte) (float) Math.Sqrt((float) (sbyte) (object) x);return (T) (object) (sbyte) (float) Math.Sqrt((float) (sbyte) (object) x); its not optimized - but should work fine

PPerksey i think go with what generic maths is using, the BCL team (tanner) have made the...

AquaOP•10/17/23, 5:42 PM

i 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

Kai•10/17/23, 5:42 PM

It will even do this beauty return (T)(object)(sbyte)(float)Sse.SqrtScalar(Vector128.CreateScalarUnsafe((float)(sbyte)(object)x)).ToScalar();return (T)(object)(sbyte)(float)Sse.SqrtScalar(Vector128.CreateScalarUnsafe((float)(sbyte)(object)x)).ToScalar();

Perksey•10/17/23, 5:42 PM

yeah i've just seen this as well.

Perksey•10/17/23, 5:42 PM

not every function is implemented to automatically upcast though, iirc Length is weird

SDL style event handling would be quite nice. i always thought glfw's event processing was terrible

Similar Threads