Documentation #4
Comments
|
Hi, I've not done extensive testing regarding the garbage collector, but IMHO that has never been a real problem as when working with DirectX, it's more important to focus on DirectX itself (CPU <=>GPU comm, shaders, etc.) than to the language itself. Obviously, in this area, even with .NET 4, one shouldn't use byte[] buffers but instead use IntPtr coupled with interoped Windows technologies (WIC, DirectX, Direct2D, etc.). Many games can be written using C# for quite a time, but indeed it's even better with AOT. As for documenting DirectN AOT, I'm not sure what you mean. Currently 99% of the code in the DirectN project is automatically-generated, so these files cannot be modified "by hand". I think the most useful way of documenting it is probably to write samples. |
|
Hello Simon,
Thanks for taking the time to get back to me. I am aware that most of DirectN is auto-generated, but I did not know that this meant that the files could not be further edited. I was under the impression that once you have correct procedurally generated code, you could add documentation so that it is more intuitive in Visual Studio and relies less on you having a sound knowledge of DirectX natively. So, that's what I was willing to do. Since I cannot, I am happy to write samples in both C# and VB.NET and try and generate some activity over at gamedev.net and similar. . It's very messy in VB.NET, generating lots of compiler warnings (since you must "Dim myInterface As ISomething" without being able to immediately give it a value) and requiring heavy use of System.Runtime.InteropServices.Marshal but can be done if you're determined 😂
…________________________________
From: Simon Mourier ***@***.***>
Sent: Friday, October 4, 2024 9:18 PM
To: smourier/DirectNAot ***@***.***>
Cc: B. Eden ***@***.***>; Author ***@***.***>
Subject: Re: [smourier/DirectNAot] Documentation (Issue #4)
Hi,
I've not done extensive testing regarding the garbage collector, but IMHO that has never been a real problem as when working with DirectX, it's more important to focus on DirectX itself (CPU <=>GPU comm, shaders, etc.) than to the language itself. Obviously, in this area, even with .NET 4, one shouldn't use byte[] buffers but instead use IntPtr coupled with interoped Windows technologies (WIC, DirectX, Direct2D, etc.).
Many games can be written using C# for quite a time, but indeed it's even better with AOT.
As for documenting DirectN AOT, I'm not sure what you mean. Currently 99% of the code in the DirectN project is automatically-generated, so these files cannot be modified "by hand". I think the most useful way of documenting it is probably to write samples.
—
Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3APH4AOYKUFG24FLEP7NLZZZ57DAVCNFSM6AAAAABPLQZKKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJTGUZDCNRVGE>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Okay, so tell me if I've got this wrong or not. The vast majority of DirectNAoT is auto-generated and I note that some of the source files contain URLs to the relevant documentation regarding that particular structure or what not. Using DirectDraw and DirectX 9 as examples, these APIs will never change and so the code for these APIs (and others like them) should only need to be generated once. After this is done, what is stopping you from going in and adding inline documentation that can be seen from within the source editor? Can exclusions not be made to ensure they are not overwritten with subsequent code generations? On that note, I have a high-end workstation with 128Gb RAM and very fast SSD access times and yet navigating into DirectN's "Generated" folder caused VS2022 to hang for a minute or so. Opening source files just made it worst. Perhaps everything is just best left as is... |
|
DirectN AOT "runtime" (not talking about generation code) is composed of two projects/dlls:
You should read the readme here https://github.com/smourier/DirectNAot it explains most of this and also why it's so slow to open in Visual Studio (not my fault...). |
|
Thanks for the clarification, Simon, that all makes sense. I'm just wondering how AoT is facilitated since Windows.Forms/WPF is not compatible with AoT. Would that be handled by the Application/Window class you mentioned in Utilities?
My 9 to 5 involves the maintenance of an orthographic terrain mapping/markup tool which is used in the mining industry and in rural planning. It makes use of the NASA .FITS image format. When the project was handed to me, it was a terrible mess of Microsoft.DirectX.DirectDraw, System.Drawing and BitBlt running on .NET Framework 3.0. I moved it to .NET Framework 4 and Direct2D via SharpDX. Because the .FITS images are so large and are becoming larger as the years pass, performance is a major problem which needs to be addressed urgently. DirectN AoT and .NET Desktop are my intended solution, but I am not sure of where to go from Windows.Forms. If DirectN AoT can coexist with MAUI I might go that way, but the simpler the better.
…________________________________
From: Simon Mourier ***@***.***>
Sent: Saturday, October 5, 2024 3:22 AM
To: smourier/DirectNAot ***@***.***>
Cc: B. Eden ***@***.***>; Author ***@***.***>
Subject: Re: [smourier/DirectNAot] Documentation (Issue #4)
DirectN AOT "runtime" (not talking about generation code) is composed of two projects/dlls:
* DirectN is the AOT-friendly version of DirectN. It's 99% generated. Some partial classes complete generated classes and some utilities have been added because it makes sense to put them in there. The documentation you find in there comes from the Win32MetaData<https://github.com/microsoft/win32metadata> project from wich DirectN AOT generator takes its input. This documentation is more or less extracted from the Windows SDK header files when it's available.
* DirectN.Extensions is a set of manually coded utilities that are never mandatory, but very useful for programming with DirectN (and in fact interop / Windows in general). It contains two types of classes:
* Extension classes: static classes with extension methods that facility the most used classes (like D3D11 or D3D12). It's not 100% complete, anyone can create PR to add other extension, if they look the same as what's found in existing classes.
* Utilities: classes that ease Windows programming in relation with DirectX but not only. For example it contains an Application and a Window class that helps create a Win32 app from scratch with .NET.
You should read the readme here https://github.com/smourier/DirectNAot it explains most of this and also why it's so slow to open in Visual Studio (not my fault...).
—
Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3APHZRP6SIMXAASIBSVUDZZ3IUDAVCNFSM6AAAAABPLQZKKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJUGI3TKMBRGY>.
You are receiving this because you authored the thread.
|
|
Winforms and WPF will be AOT-compatible (maybe only partially but there has been a big push) with .NET 9. As for MAUI, this is using WinUI3 on Windows targets and this is also moving toward AOT-compability. DirectN AOT's Application & Window are really small bloat-free classes that don't compete with everything you have in those big techs. You can also have a look at this project which uses DirectN and/or DirectN AOT (I have updated it recently) https://github.com/aelyo-softworks/Wice |
My name is Brett, I am a .NET developer based in Australia.
I would like to, should you permit it, integrate complete inline (quick info, parameter info etc.) documentation into DirectN.
Historically (SharpDX) this was done using a tool, but the results were incomplete, incorrect, outdated, poorly formatted or a combination thereof. I understand that this is a substantial undertaking, but it is time I am fully committed to investing. Let me explain why.
Although not yet fully realized by the status quo, DirectN represents a whole new paradigm for managed DirectX development. All attempts up until now (Microsoft.DirectX.*, XNA, SlimDX, SharpDX) have been lacking in some way, largely due to the fact that they were held back by .NET itself.
.NET 5+ (.NET Desktop) has made enormous strides in so many areas -- some of which made serious DirectX development all but impossible in a managed environment, garbage collection being one of the largest hurdles, which has been completely overhauled.
The introduction of AoT is another one of these huge steps and .NET Desktop 10 will bring even more improvements to garbage collection and memory performance.
In summary, the time for DirectX on .NET is NOW and DirectN should lead by example. By doing away with all of the syntactical sugar and exposing the raw COM interfaces, DirectN coupled with the power of .NET Desktop 9 and beyond, makes the development of games and applications without the likes of Unity and MonoGame a true reality.
Have you observed the difference in GC behaviour betwween .NET 4.8.1 and .NET Desktop 9? I wrote a simple sprite demo (fixed and variable timestep, buffered Hermite-spline interpolation, basic Verlet integration) targeting both and on .NET Desktop, frequent 11-18ms GCs have -zero- impact. No frame-skip. At all. Ever.
This is the dawn of a new era.
Please let me know if I can be of assistance.
The text was updated successfully, but these errors were encountered: