.Net Foundation Silk.NET, 7 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Silk.NET Community Meeting & API Review

Description

EDIT: Delayed to Jan 7 at the same time.

Join the Silk.NET team on 7 Jan 19:00 UTC for a community meeting as they discuss & review designs for a complete rewrite! Have you used Silk .NET or a similar library, or interested in .NET graphics/compute? Tune into this stream and give the team your thoughts!

Timestamps to be added

Proposals/Discussions:
https://github.com/dotnet/Silk.NET/pull/1145
https://github.com/dotnet/Silk.NET/pull/748
https://github.com/dotnet/Silk.NET/issues/1169

GitHub: https://github.com/dotnet/Silk.NET
Discord: https://discord.gg/DTHHXRt

A

A

A

A

A

A

B

Hello, everyone um so welcome to the community meeting. uh For those who don't know, we have two streams on the.net Foundation um channel. uh There's this one, which we do well fairly, rarely to be honest uh where we review uh Community API, uh Community, API proposals, um as well as uh just general uh project discussions that are more like a big picture so like setting the standards setting what we decided, we're essentially deciding on best prank. This is and the future development of salt.net.

B

So um last time we did a community meeting, it was focused entirely on the complete rewrite. um I think the description might still say that we're not focusing on that today. So um apologies, that's probably for from the previous stream, um but today we'll be uh discussing some improvements. That's slated for the next update of silk.net, um so it it will be a shorter meeting than the last one. The last one did go on for quite a bit um so yeah.

B

This is also your opportunity to ask us anything about the project, not necessarily just about the um apis we're reviewing today or the proposals that we're reviewing. um Please ask us anything in the YouTube channel. The Discord chat um I have both up and the other maintainers do as well.

B

um So yeah, uh hello, everyone, my fellow peers. How are you all doing.

C

I'm doing good.

B

C

Yeah so I'm also doing very good um yeah.

B

Okay, no small talk love, it.

D

A

C

A

C

Thought is there, is there something I'm missing.

D

uh I, don't we have something on the project tracker for we're, gonna be reviewing.

C

D

Yeah um I have uh working group tasks so I'm assuming that's it.

B

So I've been shoving everything into the Milestone, but obviously that doesn't include things that are on the project tracker. uh Let me just switch screen.

B

Where do they live in the um project from uh right, so we got two. We got an action on us. um I have no idea what that is, as it's got. No details on it. uh Just remembered: I need to zoom in and reword a proposal which I think is still sitting with a Kai from the last one, um but obviously maintain your effort permitted.

C

B

um So yeah I I think the ones what we're going to be reviewing today are the ones that uh in the next working group, meeting milestone um on the GitHub repo, um which is just the well just the three. um So there's the proposal, the project templates.

B

um We want to discuss some best practices around that uh we've got one. That's come from the community about um chain polymorphism.

B

um So that's a Vulcan specific um referring to the Vulcan structure, chainings that a community contributor added in previous updates and expanded that to be a bit easier to use um and then finally, this one's primarily for Kai is the um math struck, struck representing an angle uh to try and make uh angle, conversions and um black Jazz uh easier with, except on that maths, um so well, yeah, I! Guess: let's go in a chronological order, um so starting with the project template so Thomas.

B

Do you want to kick us off of where we landed last time.

E

So we're going to be talking about the opengl templates and windowing templates right.

E

B

E

I'm not sure if, if I'm seeing something old on the stream or if you're do you have it open right now, uh yeah I.

B

Do I just didn't scroll down.

D

E

All right so when.

E

Sorry so the project templates, we basically have two primary things that we need to talk about. Let me just quickly pull them out of my, so there are two things that we left to discuss after the VR was reviewed and they're, not very big, so we're going to go over them fairly quickly. The first one is whether the window has to the window should come with the preferred depth and stencil bits set on the window.

E

So we decided that it would be better if it did come with predefined values, because sometimes the otherwise the the driver will choose some values and it can be inconsistent Behavior between different machines, and that might also mean that a sometimes it might straight up just like not work with some machines. If you don't set those values like it has happiness list to me with some crappy drivers, what we did not agree was what should those values be?

E

So basically, we are between setting them both to zero or setting the depth in extensive to 24 and 8 base 3 respectively, which is a very common.

E

The other issue we have to discuss is whether we're going to use like pure opengl handles or, if we're going to use the strong type of traction classes like buffer object and vertex array object. If you go to the tutorials on basic docs that we have on the repo and on the examples you're going to see that 1.3 shows abstractions the up tutorial number three: has these classes, which you can use if you like them, to make a opengl a bit easier to use?

E

Well, the discussion is whether the templates for, for example, a basic opengl triangle should come with these obstructions or if they just should just be playing opengl.

B

Yeah um I mean I do want to encourage the um use of the strongly typed handles as much as possible. However, I know there are some usability issues with it at the moment, um like I I thought that was originally an implicit cast from a strongly typed handle to a uint. There apparently isn't so um that that sort of stands in the way of people integrating that into their applications.

D

D

It's a bit odd how you have to manually get the value out instead of just implicitly casting down.

B

A

D

E

B

I think we want to add that.

E

To me personally, I've never used these types of abstractions I, just never liked them very much. When I started making creepy GL at first, it was really just making a set of abstractions like that, but as I developed, more and more of the library I realized that they just weren't as much value to me. On the other hand, I think we should not consider as much a how much value the abstractions themselves provide as much as what are people expecting from a template.

E

That brings them a basic opengl Triumph like do they want something more, do they just want to see that opengl is actually working and you that it's actually rendering and trying on the screen like? Why would you want a template? That brings you an opengl triangle, instead of just the pure openglm, with blank window.

D

Yes, that makes sense um instead running a template for that.

D

This kind of this can go both ways. This is basically entire preference. We can maybe have two templates one for with the handles one for not, but that may be confusing.

D

um It depends who want the templates to be whether it should be just general for anyone who has never used opengl or for someone who has used opengl before and wants a good and wants to get kick started with silk, specifically I guess that would depend I, guess that would change what make more sense here.

E

So that's another solution. We can also just ship both like we can have windowing with opengl and another one as we know we're going to opengl abstractions. So if you want just pure opengl, you can have, uh you can have the pure opengl one you just normally use handles, and if you want the abstractions, you can also get those.

D

Yeah but it may be confusing to users to see two different tutorials or two different yeah.

B

That's what I was going to say yeah like really, we want to be able to do a net new opengl um and that's the example. If you have to switch between two examples that couldn't quickly overwhelm someone new to all this.

E

All right, then, I think we should go back to discussing what I just said about what are people expecting from a template of this type 18 that they did do they want something more like something to start building on, because if you just get the basic free basic triangle like that, that's not much you're, probably going to delete that and start adding something else. So why would you want a triangle other than the just see that it's working and I think that this is a good moment for other people?

E

Maybe people who use the library to talked maybe say what they would want from template like this like see, here's some opinions.

B

Yeah I mean from a high level C sharp perspective. I will naturally um prefer the abstractions but yeah it does come back to what we're expecting um these. These strongly typed handles are very new um and they there aren't a lot of Bindings that expose them. In fact, I think the only other ones are uh well I.

B

Don't know um like this, including us, there's three Bindings that um expose these strongly typed handles because they are just so new, um uh so so it would be less akin to C, but then again, I I thought um thought: silk done it, something that has always tried to go above.

B

What see like we're, not trying to be an exact um one-to-one wow we're trying to be one-to-one with Native, but not necessarily when it comes to all the uh intricacies of how you pass data around, and all of that um we do try to make our bindings um smooth and silky, um as well as being uh comparatively and relatively easy to understand when paired with their native counterparts.

B

So um it does what sort of make me lean towards the um it towards the strong attack handle, probably because they are strongly typed and we're using a strongly type of language. um You know you might as well it's it's a silkier element of our bindings. However, you are absolutely right in that. It's it's something different and I think even some of our overloads, um like the uh the create buffer function, for example, I, think that will return a uint and not a strongly typed handle, so it it yeah.

B

It does make it clunkier to use um I, don't know. I can I can lean either way, I feel like if we. If, if we as a working group, decide we uh we completely hate them, then we should just well uh not remove them, because obviously that will be breaking but deprecate them and call it a day.

B

um But we I think in this meeting. We do need to decide how we feel about them and whether to whether I use would expect that or want that. In an example.

D

Opengl tutorial, um you should look at open till tutorials, 1.3 abstractions. You can see that it creates its own abstractions wrapping around the you end with more functions like set uniform and such um and that's generally, how a lot of people write opengl code in a more strongly typed language. Is they have things wrapping on top of the units to add functions, to class like um set like a set data or set sub data on a buffer?

D

That's generally, how people will abstract over um isn't C, sharp and I believe last time, I used these strongly typed handles I, don't think there is actually functions on the handles.

E

D

Right so this was.

E

Just what they was about to race like? Are we talking about adding abstractions sort of like what the tutorials have or are we talking about like a seal.net? That opengl currently has some a sort of I want to call an abstractions because I'm looking like at the compilation of the buffer extract and it's basically just struct buffer public wind handle and it's just yeah.

D

I didn't strongly typed handles um well I.

E

Think if he doesn't have any any um any methods or anything, it's just a rubber around an interview.

C

Yeah, so it's like I I think it's similar to what Vulcan does and so I think we should keep them in general, because I think uh what do you know like handles.

A

C

Work extremely well with how Pokemon works I really like that, because, like I, have a project where I use both and so I think it's still useful, so I, don't really think removing your duplicating makes much sense. uh Adding functions to them is very difficult. uh It's part of what is slash, must plan for 3.0, so I, don't think that'll happen like soonish, if no one like wants to put in a bunch of time so but I don't think deprecating them is either.

C

Regarding the actual question about the tutorial, I think we should just make it like minimal. So, just like a triangle should be fine. I agree that most people will just delete whatever's in there, but this kind of follows the same style that the rest of the templates worked like so for winiforms you get like a basic window with like one component in it.

C

I think you get like Hello World printed right overall Library you get like class one and like all of those, everyone deletes immediately, but it just shows that okay, so the most basic use case works and you can build on top of it. So I think that is still very useful.

C

I think many um workloads are around built like around using like.net watch, for example, which will automatically rebuild the product, so I I think that's that's very nice and works very well, so I think just put in a triangle: you do you like do.net new opengl, you dot net watch. It opens a window with a triangle. You start modifying the code and everything is just happening as you type I think that's very nice.

C

So, yes there's a will of like unnecessary code that you will delete, but I think it's still like worth the oh, so yeah, that's like what I think we should just do.

E

Sorry I got a bit mixed up in there. So I agree with the part that we should at least keep um the abstractions like. If we already have them, I, don't see everything like to remove them or deprecate them like they're, not something that we need to maintain they're, just dummy codes in there that at least for if multiple people are using silk, then they can easily more easily make their code interoperate without having to convert between different types that are just rubbers around the integers, so at least leaving them.

E

There is I, don't see any harm. I lost you a bit on what you meant with the other thing.

C

So, regarding the tutorial uh or like the template, sorry uh I think we should just make like a very basic like triangle, so I'm not sure what what else you'd want to do, but I think having the bit of like boilerplating code in there. That like draws a triangle that you will likely delete as a user is still good just to show that it works. Yeah.

B

Yeah, so we do, we do have that it's just whether that code should use the strongly typed handles or not um because yeah, the the exact the template at the moment is the silk. It is AGL triangle, that's all. It is.

E

Okay, it's basically a minimal triangle.

C

Yeah right so I think that's good and I I don't have a preference on on stronger type versus you in the template. It's like it's not that much code um from what I've seen so like. If you want to change it, you can just change it. uh Yeah I, don't really mind I, don't have a preference, so yeah.

D

I think the main thing is whether we want to expose it to the user uh when they first because, like with the templates, it's likely that a lot of people are going to be using the templates as their first experience with silk at all.

D

um So it's whether we want to expose them to the strongly typed handle system or to working directly with the non-type units.

E

um So in that case, maybe we should keep it units because, uh at least in my experience when people are looking for opengl wrappers to c-sharp and they're I mean they're expecting opengl.

E

So if we start modifying it a lot or if we start making look like it's something else like we had the abstractions on top of it, maybe they will think? Oh, so these guys they like they bought the opengl or something, but they made it made the API different or they might not realize that yeah I know it's just some extra things that we had on top of it. You can also not use them. So if people are expecting pure opengl, maybe that's what we should give them by default.

D

Yeah, it just really depends on what we want to expose. The first time uses the library whether it be um a bit more of a abstracted experience for the raw open Geo. It just depends on what we really want to advertise as the starting point for jumping off um I. Think at the very least, if we do make a decision for the templates, it should be followed in the tutorials um to keep consistently just to keep consistency. uh Perhaps with a note in the tutorial stating also use units here or something.

E

So the tutorials start with using a pure integer handles and then they switch to the abstractions. So yeah.

D

They have their own abstractions and then they start.

E

Building more on top and I, don't think that's wrong like using the attractions there. It simplifies people slightly, but because they're not using just the the other uh strongly typed handles. They are using abstractions yeah.

D

Although when it comes to abstractions, that is a bit less on the simple template side, as the template is mostly just to show here's how you run basic opengl commands create a window and how to clear the screen just simple stuff to get you started, which may be confusing to a new user like um the fact that we swap buffers automatically for you or stuff like that.

D

That can be confusing for new users who may expect to have to swap buffers on their own or they expect to have to manually load the function pointers. They come from some.

E

Other languages I would leave. The I will do the template, as they are using just integer handles, because we don't want to add additional code if all people are going to use. Those four is basically check that it's working and see how to use things like well. As you said, oh look, I have to swap buffers it does that automatically so.

A

E

Ask like, if you store the template and see some extra classes, and all you wanted to know, is how to make minimal window opening it. It might be a bit more overwhelming or feel like. You have you're using load query in your project. Yeah.

D

Perhaps the template can link to the tutorials or it can link to some page explaining the handles um like at the bottom or the top, or something just to give a basic overview just from the template like um actually here to have a tutorial uh for how to do more with opengl as the basic template should just get you started and have something on screen at the very least, but I I think I think it's best not to expose um the abstractions.

D

Just as a first thing, someone sees with the interface as it may cause confusion if, for example, someone's coming from C and wants to write some C sharp code, they're, probably going to be used to using the just raw units or, if someone's, just being exposed to opengl and is recommended a tutorial like learnopengel.com for stuff like instancing, it may be confusing to them to come. Look at silk and see the template has non-uint types as they may not. It may not be clear that you can use units alone.

E

Yeah I agree: although we have a new opengl tutorials, which really has been working on them and they are pretty good, so yeah we could link to them once the website is working properly.

D

Yeah, it would be good to think personally. At least the best option is to have the uint handle or have the non-strong type Handles in the template at the top link to uh page of the tutorial, and maybe a page explaining strongly type handles what they are. They use them.

D

I feel like having to be on a separate page, not in the main example would be good for newcomers, because if someone is wanting to learn more they're, probably going to look at The Links at the top and see and they'll be able to actually judge whether they personally want to use the strong emails, because it's a very, very polarizing thing. I personally, don't mind them, but since I have my own abstractions over opengl anyway, I don't need them. They get a little bit in the way in their current state.

D

They don't implicitly cast down into.

D

um I think just for uh just a general first first view of silk I think it should use units and just something explaining the handles and the tutorials I feel like that's just the best option. It prevents people getting confused at the start and make people look aware of the idea if they go looking for it.

E

All right, anyways.

E

The depth style field issue.

D

E

You'll be moved to the depth stencil buffer bits issue alright. So this is a relatively simple one. So I, as I said before we decided we should set the we should set the preferred depth and stencil bits for the default frame buffer on the window, so I think currently they're set to zero zero respectively. However, we should discuss whether we should actually turn them to 24 and 8 for definition respectively, which I think is actually a good idea.

E

um I mean having them at zero series, not bad. It's preferable to not setting them at all, like I said before it can cause a inconsistent behavior and different machines, and especially different drivers can handle that situation differently and setting them to zero. Zero, however, has an issue that, if you try to do 3D, it might not work since you don't have a depth buffer, so you will get friends not render it properly.

E

So if we set them to 2480, you can just basically start doing 3D and stuff without any issues.

E

Of course, that would also mean that we are asking for a location of additional buffer which yeah it's it's not much. I think it most people will use it. Anyways.

D

Yeah I, don't think the allocation leadership buffers really matters I, don't think it'll cause problems for anyone. If they do exist, um yeah they aren't needed for every case. Like 2D, you don't really need a depth buffer.

D

um Perhaps it I think by default it should probably be 24 8., because someone coming to opengl, especially new to Silk and opengl may have may have trouble understanding like.

D

Why won't my things render because maybe they're using learn opengl.com, which I believe uh just uses Raw glfw, and so they may be confused, trying to replicate the same thing with silk as it's unclear just from a newcomer uh how to set.

E

Properties to have a looking at, why is it not rendering what the hell is Step buffer and why do I have to set it to 24, just set it, and if you can, we can we set it to 24 and it will work for them and they can learn that later when they are more accustomed to what they're doing yeah.

D

I think just I think. Ideally, these templates should be just for beginners to Silk and, if someone's, to do with silk they're, very likely to struggle with things like um windowing system parameters like window options as I struggle all the window options when I was first landing silk, uh it's a very, very different way of handling an API to how a lot of people are used to it um and C sharp, um especially if you come from something like XNA or model game.

D

It's a very different way of saying the parameters as in mono game, you have this Graphics device thing which you can set properties on and such I, don't think you even can change the buffer bits correctly if I'm wrong, um I think just by default. It should be 24 comments. Eight then, maybe a comment saying this may not be required for 2D or perhaps just a comment linking to a page explaining good F, buffer and stencil buffer.

D

E

uh I didn't know if we should add a link like on the template, because if we just start adding links all over the template, then people are going to create a new project. And if you already know what you want to do, then you're just going to have to delete those links, because all you just want the last equal to open the window, uh but yeah I think we can all agree that 24 8 is better questions.

E

It starts in 2022 when this PR was first made saying that he also thinks he should be said to uh 24 8 I think his opinion has not changed.

B

Yeah yeah I agree, I'm, still, team, 24, right, um I, think the point on the on the links um yeah. It is one more thing they need to remove, but you know what's what's one comment among what is probably a 100 100 line, tutorial they're going to be deleting it and they're going to be deleting it anyway.

D

A bunch of code you're going to be deleting in book. Oh so yeah, but.

E

Templates are pretty clean, I mean if you just get the silk empty window. It doesn't have a lot of code. If you're just looking for that the windows initialize for the code to initialize the window, then you don't really need to delete anything like it's very rare bones. Yeah.

B

E

A lot of comments if people are going to have to start removing them.

B

E

um It's worth noting, originally, we were.

B

Going to have like three sections on the uh website, we're gonna have a uh opengl tutorial um section. We're gonna have a a deep dive into uh windowing and input section like well I'd, say we're doing an input all of our high level, libraries that are in addition to our binding. So that would include maths as well, uh and then we were going to have a um miscellaneous section called tips and tricks where it will be literally anything else.

B

um For example, that's where our experimental feed documentation lives are not frequently asked questions um again. The website is very Bare Bones. This can change, but um I I think it would be just two links like one to the opengl tutorial to find out more and then uh for some of the advanced stuff it would be.

B

um It will be a link so I, don't know the the windowing exception, a page in the windowing section, so I'm not I'm, honestly, not fussed in adding a comment or two um because there's enough code in there anyway, that they'll be removing in bulk. So um you know: there's no difference between a control, a with uh with 61 lines under control, a with 63 lines.

D

Yeah I think there is a point where it does get a little bit excessive, but I think most four or five comments isn't going to cause problems um and it does help remove confusion for those who are looking to use these. uh These templates, as a jumping off point, aren't just going to delete it.

B

I think the default templates even have a comments at the top. That says, learn more about the templates at the Microsoft documentation.

C

All right did any of you check about uh like machine support about uh like depths and stencil, because, like what I like being like online, is that there's usually support for 24 bits or at least 16 bits. But then, when you mix and stencil, it gets worse with compatibility that really rather not add things to the template that make it unusable on some machines.

D

Maybe it should default to a lower value like the Intel buffer, isn't used by a lot of things. Although.

D

Yeah, maybe it should be 16 8 instead of 24 bits, 16.

C

The problem is, if you set it to eight I, think I'm, not sure how, uh whenever I can handle this but I, it might also error and then also, then the user has a preset and they don't know that it's very option. Wow.

D

Is there even a way to like catch these kinds of errors and put a good message? I, don't think either GLW nor sdl really expose for invalid yeah.

B

It will throw away um API.

D

A

For sdl it will throw an.

D

Estate section.

B

And glfw will throw glfw exception.

D

Yeah I, don't think I, don't think I've had problems with this before, where it just dies with the wrong settings. I, don't think all platforms throw a pretty message when that happens, I think it just throws unable to create window or something along those lines. Yeah.

B

It is best effort we do have that functionality. For example, there's a throw error function in our sdl bindings and likewise dlfw the glfw provider automatically binds and error callback that will throw an exception, but um that well I believe that uh blows up uh on anything on other than Windows. So it's best effort, but we try.

D

E

Think a lot of it I'm, looking at the template right at the templates right now, uh only the triangle: one has the preferred depth and still buffer, which said I think we should set them on all of them right, yeah. Let's.

B

Make sure if we, if we decide something it should be applied.

C

Fw just defaults to 24 um steps and eight stands for which is I, think what proxy suggested so I'd I'd probably just follow what they do, because they are widely supported and yeah.

D

I can't find any better information.

D

I believe, actually, some platforms do have their own like preferred bits for defaults. Yes,.

B

Yeah I think we've we've had this problem before, where our our examples originally didn't work on AMD um or they say they. The cubes were horribly.

C

C

W will by default, do 24, but we always said don't care which G of w will assume to mean. You want the driver to decide and not gfw to decide. That's just a bug that.

B

um No I, don't I, don't I, don't think so. I think. If you don't provide a value, then it it defaulting to whatever the driver decides and it sort of makes sense. You.

C

B

Haven't indicated a preference, so it's.

C

The Wild West, it's like a fine way to do it, but that's why we had the incompatibilities, so I think change it like at least now doing like the template doing what dlw would do. Anyways is I think very cynical, because many people that follow tutorials the tutorials would also use glfw. They would also have these defaults, so I think that makes sense.

D

What does open what does learn opengl do because that seems to be a good source of this stuff. So if we look at the creating window tutorial.

D

Yeah, because if if they specify 24 bits eight bits well, they don't specify at all I'm not seeing.

C

Yeah they just use real of w and JFW will do 24.. Oh.

D

C

Glw will always request 24 from the driver, regardless of what you.

D

But I think we should probably just do what um W does that, because um If there really was a big compatibility issue caused by learn: opengl not specifying. It probably would be noted on the page, but I'm not actually seeing anything on the page. Regarding uh I.

C

Think I think gfw is so widely supported that it really doesn't matter.

D

Yeah I think I think we should just do what G of w does, um and maybe maybe on the page that explains the windowing stuff and the sections specifically connected to the uh depth and stencil buffer. It should elaborate about why it doesn't work um if you do get an error or something along those lines. um Maybe there's some specific way to tell like some like just grabbing the error details or something cursed like that to tell specifically about which is causing the problem, um but I think 24.

D

8 is going to be a good default that won't cause problems for a majority of devices um also won't not cause problems or no won't cause problems, yeah. Well those problems relating to window creation on just a majority of devices. If your drivers don't support 24 8, it probably doesn't run just standard glfw apps anyway,.

C

um It doesn't happen honestly, yeah.

D

I think it is just safe to do it because um other large windowing things assume 24 8 is supported. um So I think it's safe for us to do that too. Just so uh stencil or stencil and depth both work and.

D

E

All right just to make sure um there is a template that is just a variables Windows like we know that, like it doesn't even have opengl, Vulcan or anything doesn't even select an API, it's just a window with a title and we add the preferred them stencil buffers to these two like, even if it's just the most Bare Bones things. We also add this option. This defaults do.

D

You agree, I think I think they all should match personally uh for consistency, because someone may already know a little bit about opengl and so may feel they don't need.

D

um They don't need the opengl example directly and they may they may try to work off of the example or the template for just blank and they get confused.

D

So maybe it is a good idea that we should unify the definition bits of all the tutorials and all the templates just so if someone does use the simpler one and start off, they.

C

Don't I don't think, there's a harm I, don't think, there's a harm in specific I guess, uh but it's also kind of unnecessary. It's like the the raw one, because.

D

Maybe unnecessary, but it doesn't cause shouldn't cause problems. If your device doesn't support 24 8, it probably doesn't run a majority of games anyway. So.

C

I mean I mean on if you set it on the raw one. You'll also have DirectX or woken people using it and I. Don't know what happens then. I.

D

Don't think it does anything.

C

I think it'll uh do nothing I hope at least.

D

Deal because um I I believe uh basically all settings willing to depth buffers stencil buffers is all done. I believe everything's done to dxgi I, don't believe glfw nor sdl speak with dxgi at all for creating, um although doesn't still have like some extension for for talking with creating a DX, Drive factor. I think I saw something about that about still creating the extract, Factory I'm, not sure. If silk attempts to create a swap chain on DX.

B

Joey bro, you really you're, really scraping the bottom of the brain barrel uh now um I. Remember adding something uh I remember there being some sort of extension, I think in in dxgi. uh That will create a swap chain for you, but it's never been implicit. Windowing doesn't do it for you ever.

B

It will um there's a create DX dry swap chain um method which will well okay, on win32 use the create swap chain for H wind um method on the factory you give it um and on winrt, which we don't support yet, but we've got a supporting code for it anyway, uh it will do the create swap chain for call window.

D

Oh, in that case, uh we need to add support. We need to switch to using the DX handle uh on a native Windows Source or what it's called so that so that this function, Works under Linux.

C

D

Yeah, that's what I need to do so remind myself. Do that later.

E

All right so in summary, the the templates basically with the handle thing they remain as they are, then we don't change them currently tax hand to strongly typed hand and story I'm getting a break for it, strongly typed handles and in regards to the default depth and cell buffers. We set them to 24 and 8 Bits respectively, and we can also see a once. We have the website up and running. We can also see about adding maybe a link on the template.

E

If you want more information about this template to add additional things like if you want to know about depth things why we shouldn't do that, make another link.

B

Yes, yeah um I shall copy in some notes uh in just a second, uh so yeah just double checking um oh yeah, the actual names of the templates.

B

um Actually, no, that wasn't for the working group, so we don't necessarily have to oh wait. No, no I did marketers.

E

The tumbling names.

B

Yeah, so removing the silk prefix from the template name. So you can just dot net new opengl.net new Vulcan and it will um automatically use something.

E

Like that I don't know, how do you feel I'm happy to go either way? I mean it could be, I mean doing naming a templates like that could be prone to having. If you have the multiple packages with templates installed, it could have name clashes. Oh.

B

Yeah sure, if you're using opengl use, silk foreign.

D

I think just the name window is a bit too vague template. There's a lot of templates and I tend to accrue templates on my machine. Maybe not everyone does, but I I accrue a lot of templates on my machine, so it's possible just window alone.

B

Oh yeah, I, agree, I, agree: silk window should still have the silk prefix but I'm more specifically like um talking about um the silk gel triangles. That's that's a lot to type.

E

I feel like that would be inconsistent if we're going to have one name: silk window, but the other ones don't have the silk prefix like I think we should either have them all with the prefix or not.

D

Yeah I think um triangle or silk gel or just maybe, silk GL will just Implement just a a.

E

Blank that's uh so the naming right now is: silk window. Silk GL window like everything like I'll, just go.

B

uh Can you put it in the meetings chat? Please.

B

B

One way it pops up on stream as well.

D

There they are okay,.

D

So book gel window- it's just okay, um I I, think, silk GL window is I, think I think that's a bit misleading. uh It doesn't specify opengl version, um it's silk gel window because it just doesn't initialize a jail to null and it just creates opengl. But in the window options we don't specify Joe version I'm, not sure what the default gel version is for window options.default.

D

It's a 3.3.

E

Oh yeah, it's not specifying a opengl version.

D

I think for a opengl window default, it should specify a version, as that is probably something most people are going to be doing. I think a good default is that's.

E

Not a bad idea.

D

Yeah I think I think by default, silk GL window should specify three to match with uh yeah.

E

So the triangle and game templates do specify they use a 3.3 core context, so I could just copy the setting on the window options from that template into the others.

D

Yeah I think that's a good idea having it having everything specified.

D

Having making sure everything is specifying the window, the the GL version is uh good for consistency and prevents.

E

And it also shows people that are using template how to easily change it, which is also important.

D

Because having it on window, options is a bit weird: it's a bit Arcane to a lot of people, so it makes sense to have it be there exposed in the blank template, I, think I think just silk GL should go to silkgl window, then silk GL triangle or just like you'll try. If you could do aliases, just silk, GL Tri.

E

If we know we can name it silk, instead of silk gel, we know we could just go: silk, GL and then seal the GL triangle and silica GL game. They can just stay as they are.

B

E

B

Mean I put this on the pull request originally, but I I personally feel like combining gel window and Geo game, primarily because well, as far as I can tell, the difference is like basically two lines and it's the GL game creates an input context, whereas jail window doesn't create an input context. I feel like it'd.

A

Be pretty common that, if you use.

D

Window I feel like oh wait. That's weird! uh There's a disparity between game and window uh games; that's jail, viewport on load for some reason, I'll.

B

No, it doesn't I'm sure that I'm sure that's not intentional. um Okay, I.

E

Think the the reason why we initially made them separate is basically because one of them includes input and the other one does not sorry. What were you talking about? That might be intentional.

D

It doesn't line up with uh Jill window which doesn't have viewport and load I'm, not sure why that is there, maybe there's some oh I know that makes sense to be there. Does it I, don't know, I'm, not actually sure what the initial behavior of an opengl buffer is like.

B

Everything probably undefined.

E

So maybe it's still window one should also have the buprof thing, although it does set it on a frame buffer for resize, but it should also set it on loud you're right, yeah, yeah, probably.

D

Yeah that's the frame, but for size, and then yeah I feel like by default in the basic template. We should include input and create a book context. um There's just not really too much. You can do without input context and I. Think the general use case for silk is going to be for trying to build games or interactive applications and generally um you're not going to be interacting with it through a console window or something.

D

So it is probably best to include when to include input all of them and just combine silk gel game and silk GL window and also put inputs. We could do silkdale triangle.

E

Gl window and we're just going to leave a GL game, yeah, basically I.

C

Mean we couldn't, we can just have options, you know, but you can just accept. You can actually just have like a like interactive or like plane or whatever as an option, and it just has the imported it. Doesn't it's not that difficult.

D

I feel like I feel like for basic templates. More options is not necessarily better.

C

um No I mean foreign.

C

D

Mean what are the real use cases for a non-interactive window, specifically that.

C

You can think of any rendering tests stuff like that.

D

Yes, but generally just when someone is trying out silk, it's probably going to be because someone recommended it for making a game engine or making a game. Specifically, um it's not too much of a game if you can't interact with it, um I think we're just through the General Normal use case. Creating input context, makes sense um and more options to the users is more opportunities for them to choose the wrong one and mess up um when you're. First learning, C, sharp or um silk uh templates and input and everything can be very confusing.

D

I struggled with it for a long time trying to differentiate windowing from input um as it's not a very clear separation, because they're like intertwined but uh like they depend on each other, but they're, separate I. Think by default, having input contacts there and just the default window for the general use case. I think is a good idea because someone, it lessens the likelihood of someone clicking the wrong template, then coming into the Discord to ask for help.

D

How do I get input or spending more time trying to research how to get input working um it's very hard for someone to read uh and every especially when you're overwhelmed.

E

And it's also very easy to just take the input out so yeah.

D

I think I think we should just uh remove silk gel window and then rename silk gel game. Just silk gel.

D

A

That would be a fair.

E

E

Triangle we should add the input because still kill triangle is basically a silk gel window, but we with the triangle. So we should basically also add the input things to silicial triangles, so it's basically the game but with a trial. Yes,.

D

I think as much should be matching as possible like uh buffer and stencil bits should match between all the templates and API and input. All that should match between all of them. Just for consistency should be like silk: silk. Gl is an extension of silk window and silk steel triangle is an extension of silk yellow.

D

This is different stages of the same project.

E

We like that, but we're changing the order a little bit because we change we removed a cell TL window yeah.

D

I think it should just be silk: window is the most basic, doesn't specify opengl and then silk GL uh specifies the API version.

E

Right, so silicone is the one that doesn't have GL yeah.

A

E

Are we going to uh we're going to rename them.

D

E

D

That's a good question: should we.

D

Actually, good question: I, don't I'm, not sure doc, window stock, GL, also triangle yeah,.

D

um Namesock window makes sense, I, don't think we should just have a blank silk one or Clarity. What.

B

Would we put in what we, what would we put in that template and.

E

It's basically empty, it's just adding the filamness, so you can. You already have the window. Events.

B

E

B

Api yeah, but that's that's so window. It's a I, I, don't know what a template just called Silk would look like because it will be as well yeah.

C

B

Has to make an opinion, otherwise it's just an empty project like it needs to pull in something and if it's opengl well, that becomes silk gel, not just silk yeah.

D

I think I think it's probably best if it stays silk window for clarity, so.

A

Someone might see a generalized.

B

D

Someone might see a generalized silk template and think, oh, that probably has everything I need to start working on a game, uh but it may not. Maybe they need help with opengl, so they may want to choose the silk GL instead, I think it's best if it's just called Silk window yeah I.

B

Agree: uh yeah I I am happy with what you've put in uh the meetings chat, Thomas a short copy and paste that into the notes. Current.

B

E

We can move into other issues if you want, if you want to I, think we're.

D

Done is that everything with the projects.

B

I'm, just looking through.

B

Yeah, so we're using 24 8 so leave that open um right, I've copied and pasted some notes into the um in well into the GitHub, um a polar Crest. So if you have any objections to any of those do, let me know um so yeah I guess we can move on to chain polymorphism then uh so this is. uh This is a very, very small proposal.

B

It's an expansion of the uh Vulcan uh structure, chaining um abstraction, which uh thorogy added in the um the bindings Library, um and it essentially just allows um chain uh structure chains to be downcasted and upcasted, and so that um your code can be still written in terms of these chains, but not necessarily need to know about the whole chain and just know that oh I don't know the the first. Two structures in the chain are a instance create info and a application info or whatever I know. That's not how that works.

B

But again, I was really struggling for an example off the top of my head um or for in fact, yeah I can't think of a better example.

B

um So yeah again it's very it's very simple: it's essentially just adding interfaces to the um chain uh classes and also, um uh in fact, yeah. That's pretty much all there is to it um yeah, defining the interfaces and then uh implementing the interfaces on the types. So this will be purely generated.

B

um I, don't think, there's anything breaking about this, but uh I don't know. Is there any any issues with the API that anyone can think of.

C

D

I'm not seeing anything I dislike um it looks relatively clean to use.

D

um Yeah I, don't see anything wrong with it, although my experience with Vulcan is not too great, so I can't really give too much specifics here.

B

Oh yeah I think you're our resident Vulcan expert, Kai.

C

I mean I use this whole convention and I think it looks very good. I, don't have any issue with it. I mean I I, don't use the training that much but I, don't know how necessary it is, but I mean it looks really good. It's a small extension. So why not.

D

Yeah it looks like it, it will just slightly improve experience there.

D

uh This Vulcan can be a little bit weird to bind to sometimes uh like just for my limited experience with using the silk bindings um or just vocal minings in general, with C sharp. It can be kind of weird to bind to and a bit weird to wrap your head around I think this seems to improve it. A decent amount.

C

It's pretty good.

B

B

So the next one is a issue: it's not a formal proposal, um but it sort of makes sense to review it now. This one is on the um silk.net maths library, on adding a structure that represents an angle with some helpful, um with some helpful apis on it that help with converting and doing calculations with angles or um well degrees or radians um sort of abstracting that away um I. Don't this really isn't my area?

B

So um I don't know if anyone has any comments or if anyone wants to jump in and take us through this proposal.

C

D

C

So I think it's it's like a decent idea. I'm not like a huge fan, because angles are simple. Usually most like engines will have like one way to do it, not that many use uh a lot of menus like degrees, but I do definitely see it for like some areas, especially when you have the interface uh with the user. Bunch people generally prefer degrees, so I can see it. uh I I think we should generalize it over a scalar. Yes, it doesn't make that much sense for integers, but so does quaternion.

C

It's basically the same thing.

C

It makes sense, but we still do it right. So it doesn't matter um and then I think there's like two things we decide. One is whether we want to do it similar to what type span worked like I. Think someone commented that uh until it pulls up uh yeah, someone commented the just like someone similar to what time works like where it's like. uh We could do like total, where it's like unborn it and it would just do like, if you add to it or if you initialize it with like 1 million degrees.

C

It will just tell you that and then there's the normalized version, and then we need to decide what normal list means for us, so either zeros or two Pi or minus pi to Pi personally I think doing. Minus pi to Pi is a bit better for a floating point, but it is uh a bit of words for integers I. Don't think caring about integers makes sense, so I I personally prefer minus pi to Pi similar to degrees, I. Think for consistency, which we should then do -180 to 180, but I don't know so yeah.

C

That's basically one one way. We could do the API and the other one is basically to simplify it a bit and never reconsider uh any unnormalized uh representation, always normalized, given how cheap normalization is. I think this is valuable. Also because I mean doing like one uh mod operation is like extremely cheap. We don't really care. We could do it on demand on red, if you, if you think but I, think it's so cheap, but you can just also do that so yeah, uh it's basically a matter of.

C

Do we care to keep track of how often you went around in the circle? uh I, don't think so, but uh yeah.

D

I feel like there is some case for that, but it's not a generalized enough case for it to really matter and need to be kept track of here. I think for float accuracy, it's probably best. If we keep everything from a minus pi to Pi um representation, as floats are more accurate, the closer you are to zero right, it's probably best if it's minus amount of Pi rather than zero to two pi um yeah.

D

It's my thoughts.

C

Do you agree that we should then be consistent and do like minus pi to Pi yeah, then minus 182, 180.

C

Minus pi to Pi and then we normalize up to zero to 360.

D

Generally, in most cases,.

D

You're not going to be storing degrees very much in float form uh generally. All your math is going to be done in radians and you're going to be converting to degrees only from user input and generally pure integers uh degree values. Don't really get hit with inaccuracies, um I think for degrees. It should be zero 360. just from a pure user's point of view, because it makes more sense to an end user, seeing a value from 0 to 360 for rotation rather than a value of negative 180 to 180.

D

um For for the internal representation and radians, it does make sense, because a developer is probably going to be the only one seeing radians wow. The end user is probably going to be seeing the degrees representation of the angle.

D

Also normalizing them different ways is bit inconsistent. It depends on what in degrees is going to be for, because, if it's just for display to the user, then it makes sense to have it being normalized to 0-60. If it's going to be used for math, specifically I like like someone's going to be turning into degrees specifically to do math on it, and it makes sense to do negative. 100 to 180.

D

just depends on it.

C

D

Depends on what the user is going to be using the degree orientation.

C

It's very, like I, think it's just very simple to convert between the two, so we should do whatever is the common case, because all of these operations are extremely cheap. All of these operations are very easy to employ yourself.

C

Yes, I think we should just do what's like simple and like the obvious thing, you would do and then also I think. Basically, all these like Ops would be in line by JT so like, even if we internally go up to zero to 360. If you then immediately go back down to 982 and ready I, don't think there would be performance penalty either. It will only be a minor inconvenience and so I think just doing the like common case. For all these things makes sense.

D

A

D

Common case for converted language degrees is going to be for printing it to the user or receiving input from the user, because no user wants to type out eight digits of pi to get an accurate angle in um because the average is going to want to type 180, 270, 360. and I. Think that should be how the degrees works.

D

That's just the most common way to work with degrees.

D

Well, it's very really much of a standard, at least to my knowledge for radians, um since it's not really a thing to like display radians to the user, so I don't I'm. Unless there's some math construct, I, don't know, there's something: there's not really much of a reason to for one.

C

Yeah, so, regarding the API, uh obviously perfectly you already pasted this little snippet. uh The person that opened the issue provided a small uh uh use in their project thing uh I. Think it's the last message in the issue, so you can just click on that and maybe zoom in a bit. So we can see uh yeah. Thank you.

C

They provide like a bunch more things. A couple of these are redundant because we already have a little before so I can scale, um but I. Think most of these are good apis. uh Yeah I mean we can go through them. If you want uh otherwise I just make a proposal, and then we can like I, don't know like I, don't know what the what the next steps are here.

C

I think we can like all agree that I think this is a good idea and I think we just like the complicated bits which is about Radiance and uh degrees. To summarize, we will use Radiance internally and then 0 to 360 externally, yes, like, as in like, if you called in duties, it'll, be zero to 360.

C

um and yeah. What else uh I guess we didn't really decide on whether it should be knowledge or not? um um What.

D

Do you think I think just for a majority of use cases normalizing it to normalizing it to a set range, makes sense.

C

Yeah I mean the the if I would have like the if I you'd expect, with like dot, radians and Dot degrees. Those will definitely do uh mobilize, but then the question is: do we also have total Radiance and total degrees, which would do the.

C

So I I don't think this is a good idea. I, don't think it's needed and I I don't like. If you really need this just make yourself like your own yeah.

D

C

D

I think it should cover the general use case and if you do need it, then you can either extend it or just create your own I feel like that's a okay, so we.

C

Just we've only degrees in radians, those are normalized to, uh respectively minus pi to Pi and 0 to 360.

C

And we don't expose any other apis like for conversion um yeah and then like there's a bunch of apis, that we should probably add.

C

I mean I can quickly go through them. If you want- and you can write it down to actually.

C

What do you think.

B

Yeah I'm happy with that um yeah I think to get it in a get a firm, a formal um proposal and that will give us give us a clearer idea but I think yeah. It generally we're all happy with this. It seems.

B

Cool uh any objections to the notes: they're not as big as the um as the other. Well another issue, there's a the other one passed with flying. Colors.

C

D

Don't think so looks good.

B

We think that is it unless anyone has any questions or any concerns, they want to bring up while we're all in this, for any updates or literally anything at all,.

A

E

Not necessarily related to.

B

What we've discussed today, it could be anything to do with sold on that.

E

C

E

Just talk about.

D

What what is the current main blocker with uh pushing an update.

B

uh So we're still waiting on the dotnet foundation to uh give us the um Azure resources. um They have said.

A

B

We're fine with it on paper, but uh we need the actual um VM created I. Think I'm going to chase up um Chris about that. um Well on Monday. Hopefully, if I remember um yeah, but.

C

B

Mean when I say stuff like that, never never trust that I'll actually do it. So please, someone remind me on Monday and I'll, send an email um as it currently stands. We've got access to the resource Group, so we couldn't Theory, make it ourselves, but I, don't I, don't want to just jump the gun and I. So I do want to double check that hey.

B

Can we create this, um but yeah we've got we've got it agreed in principle, so we'll set up the CI Runner I think there might be some issues with the um with the sign service on the radar, so that might also be broken, um or at least I've heard other other um projects I've been reporting that has broken so that could be another Blocker on our um on our radar. But we'll see what happens when we try to release.

D

uh Also, the um the the native the the native Library CI front still seems to be broken. I was assuming it was a temporary like run out of storage with a CI Runner, but it seems to be a larger issue. Just the past week or two just um the native Runner has just died.

A

B

Did that scale that, as um pull request ever ever get through because I I think it's breaking mono at the moment, yeah.

D

I think we're still hitting the mono bug uh you can try running. You can try running CI, um so you can get that seeing if it's fixed in some update um but yeah I'm fairly, certain we're still killing mono here.

C

uh uh So do we still use the.

C

I forget what it's called the open.

C

Imagination, so we still use one so I guess: I'm gonna foreign.

C

Okay, so I hope it's better. Now does.

A

This sound good.

C

Okay, so um I want to ask about the funding thing that we used to use the I forget what it's called.

B

Collective yeah, we did start on that um I think. Well, we well. We need to figure out what to actually populate that with and um start pushing it because we created it. um So we just need to put goals on there. Put projects on there that we want funding for and then start um stop pushing it.

C

It's like I've, been collecting I've still been collecting some sponsors money like a couple months, so I'd be happy with you like, give it to uh I, guess: Bailey who's been working with a tolerant or like donating into the like open the funding thing like whatever you, whatever you prefer honestly I just know they take like 10, so I didn't want to jump the gun on it because you know it's just it's just gone, then uh yeah. So I just wanted to ask what what what's this at us there in.

B

Someone's actually contributed something to our open, Collective I. Don't remember that happening. Oh.

C

It's the striker, oh.

D

Thank you straight guys.

B

I guess this is more wait. What wait? What happened never mind? No, so there's two silk.nets on open, Collective, there's a um there's, obviously our open, Collective and then there's a subsection of open Collective on uh strides Collective.

B

um Oh, that is called silk.net. um That is I'll have to ask what that's about. uh Oh, we want to start supporting.

D

C

B

With salt.net Okay.

C

B

Let me pull up ours, real quick, um open, Collective.

B

Oh I know the guy ever pasted the link and that's.

A

B

D

B

Silk Matt: oh.

B

There there's ours there there we go so yeah, I've already been Collective, is pretty damn empty. At the moment, um I mean we can sort of ask whether we want to merge with them, but yeah. The only thing we've got on there is the silk.net 3.0, um a pot of money.

B

um Really we kind of need to um yeah figure out what our open Collective strategy is going forwards and hopefully start pushing it out and uh collecting some money for well Bailey, as is the only one only maintainer at the moment. Now.

D

I, don't even know what I do with the money I got on the I got all the development. I guess actually I actually don't know what I could do with the money. I guess, yeah I, don't know I I, don't I, don't actually need it right now. I guess I mean honestly.

C

Like like honestly, I I, like I, could like a couple hundred bucks, probably from your sponsors and I, mean I, just always used it just for myself, because I feel like it's just compensation for all the work you're doing it's like yeah. If you like, open like.

A

If you either give me some.

C

Bank details, or just your or if you open, like GitHub sponsors like I'd, be happy to just forward you the money that, like I'm, still getting from sector net. It's like you have a Bunch right. It.

D

May be useful to get a secondhand Mac for testing, because currently I have every single platform to test on, except for Mac, okay, yeah I'll.

B

Probably move that Collective.

D

I furball is getting a Mac, so I I may be able to use theirs, but they're, probably going to use as a normal computer too I don't want to bog them down. So I think it may be helpful for me to get like a just secondhand, M1 Mac for just making sure silk was running gun map uh because arm support on silk. uh My knowledge isn't very well tested um arm.

D

Windows just doesn't work right now without some hacks um and our Mac I, don't think we have CI tests for that or really much usage to my knowledge. I, don't know how many users are using a silk with M1 Mac, so I I do want to get some proper testing done with Mac.

D

um I also want to try to get some CI running uh just just for some basic stuff on um Windows arm. 64.2 um I want to get arm support better with silk, which is one thing which I the money would be helpful for is getting a Mac, so I can have the full development Suite.

C

Yeah I mean uh first of all, we can probably uh invite you to the open character, so you can just like put on whatever you want, but also I guess we can put either like RM support or um specifically Mac support uh in it all up there for like Nations and then yeah.

D

Our Sports going to come no matter what, because my main Windows development machine is the harmful Terror dev kit, but for Mac OS, specifically yeah uh I think we should have just a general Mac OS uh silvernet one, because currently uh web GPU was broken on Mac OS, due to a lack of a lack of being able to test, um and just no testing for I haven't seen anybody really pretty much testing the molten VK, given the fact that it's kind of been broken for a while, and only recently, the pr someone sent in for fixing it for fixing the Vulcan example on Mac uh I think we do need some proper testing done.

D

So I'm going to be doing that uh I want to get silk running on just running good I want it 2.x, smooth enough to coast along until 3.0 as it currently stands. 2.X does have some problems.

C

I mean I just had a look at my guitar sponsors. I, don't know about the Dolan I, don't know if you're still listed there but, for example, the person that asked about getting a new version released. uh You I, probably you probably remember that this year, yes.

D

C

Two days ago, so, for example, they have recently started donating uh to this project. I, guess and so yeah I mean, for example, you could just like if signing is broken or you need, like the machine, give a hold of this use it to pay for that uh yeah. But I can I can just I'll just DM you later and we can.

D

Yeah we can talk.

C

D

Later the specifics.

C

Yeah, what's the plan and I guess there's no like current uh open, Collective I mean we get to go again, I don't know yet, but then.

D

I will with them going.

B

uh The funds that came from the Oculus uh microgram uh should that probably should that go on the open, Collective as well.

D

Probably I think we should put as much as possible Collective to be clear about.

C

D

C

I'm happy to like put anything on a book and Collective uh I just want to point out again. They like take like 10 cuts, so I'd, rather not transfer in, like 200 bucks. To just really take note. 180.

D

In that case, yeah we'll we'll get something worked out in DMS. For that.

B

Yeah well I think the.net Foundation was originally going to come up with something because they do have their own fiscal host and open Collective. But when I spoke to um well the former executive director, they said they were trying to move away from it because well, obviously, projects being able to make their own payments in the.net. Foundation's name is Rife with fraud um and they want comfortable um with it going forward. So that's why we had to do this complicated. They did say that um they were looking into a new platform.

B

However, all expenditure would need to be approved by the.net Foundation, which, if the um Azure resources or anything to go by, is not a good thing um but yeah the host fee is a 10 percent.

C

D

So we'll probably have to work out to get the money, then without the ultimate Collective. So we don't have to deal with a fair amount of money being lost.

B

I believe that balance- that's hilarious.

D

Really, no transparency! Oh my God.

D

Oh dear um Graphics program experience, yeah.

B

Yeah, the graphics program is not graphics, artists, um yeah, so I am um I'm happy with that, of course, the open Collective stuff we can carry on discussing offline, but I'm happy with the the um reviews that we've done today, um uh yeah they're the Civil 3.0 progress, um the what most of the proposal got approved, May some with caveats um last meeting. uh However, the ones that didn't have an um haven't been updated. There's not a lot for full transparency.

B

There's not a lot of effort in 3.0 at the moment, probably because um the maintainers have lives um that are unfortunate.

D

B

D

B

D

Sense because we.

B

Need we need that and we need to keep that um smooth, smoother silk. uh While we wait for um 3.0 to kick off.

C

Yeah I mean, if you care about like an update over 2.0. It's basically like I got a job like several months ago. I'm pretty settled in now, so I might just start working on it again on, like the weekends uh I think we're pretty far into.

D

Yeah and let's look at the code, you uh you get decently far in the generation, so it shouldn't be too much time to get a basic like just getting glfw to generate something. So we can actually have a little windowing and get stuff kicked off.

C

Yeah exactly and like I'm I was looking into um uh like making proper issues about. What's only to be done and then I was also looking into like how we can like get like. Hopefully, you can get like some Community engagement there to like help out with like making that happen, uh because it's still a bunch of work, uh even though it's much more organized but yeah, we'll see we'll see, I'll probably start working on it on weekends, soonish.

B

Yeah handle I mean obviously I'm, not a maintainer anymore, so, um probably won't. It won't be from me.

A

B

There's definitely some things that here and there, where I get an idea and Phil I need to share it with the group um that I'd make small prototypes here and there, but in terms of actually uh driving it over the line. um I think you're all doing a very good job um and uh yeah, hopefully um well, hopefully, Bailey's work on uh 2.2.x, um we'll uh tie the community over until um 3.0, um properly kicks off and uh arrives yeah.

D

There's gonna be there's gonna be a lot in 2.17 once it.

B

Gone, it's gonna, be a massive update, absolutely.

D

Update yeah four new bindings.

B

D

Warnings, yes, fair amount.

B

So the changes.

A

D

Been done for the Improvement of the usage like, for example, a lot of units which were just rules are now changed to our bull 32 type, but that was a big problem on the DirectX bindings we had to where we had to like put comments in to specify that yes, this one means true, it was very annoying I fixed that uh it should implicitly convert still. So all your coaches still compile.

D

um But now you have the option of just using a normal Boolean there, which is a lot better. That's but I think that's the biggest like user-facing change, aside from maybe some opengl stuff being shuffled around due to restructuring on chronos's side. Yes, yeah.

B

Upstream breaking changes um so yeah what we've got. We've got d311 on 12 uh we've got oh God, all the comp pointer stuff. That's.

D

Just gigantic stuff, uh via web GPU, uh with both Don and wgp extensions.

B

um Wgl bindings as well that I originally intended to use for WF but WPF support.

A

B

Then I have direct 2D now oh yeah yeah. That.

D

Was completely contributed.

B

D

Finally, some working samples and example, not samples but there's finally, some working prototypes for wasm support, which is currently blocked, Upstream but I'm working on getting that unblocked. uh But finally, progress is being made with silk on the web and hopefully should be able to be done with almost zero user user-facing changes to code, hopefully.

D

um I already have almost unchanged examples: some of the some some of the programs from mix from the experiments page uh I have some of those compiled and actually running perfectly fine, with almost zero changes aside from the stuff required to make aot work um yeah so hopefully, maybe two to eighteen, maybe throughout 19 depends on if I can get this unblocked, but it currently seems like I'm, adding multiple mono runtime bugs.

D

That seems to be a pattern with silk.

A

D

Otto is not not very fun to work with, but yeah. There's progress being made a lot of stuff with 2.0 2.x.

D

um Hopefully, it'll tie the community over until 3.x is in a usable state or has any sort of anything um yeah uh stay tuned for 2.x. We're, hopefully going to get it at 2.17 out within three months, because we actually have to go ahead to create the Azure VM, but we just gotta make sure it's okay to do so.

D

um So hopefully it shouldn't take too long to get that out and then once we get the Azor Runner we'll be able to get the update out within a month of that.

D

Since the since the experimental uh tab has been tested a lot, it should just be ready to push that's you're able to.

B

I agree um yeah, so thank you for your time. I haven't seen any uh questions pop through on the chat or in the Discord, so um yeah. Thank you for your time. Everyone and uh yeah go project.

E

A

B