mellinoe

Is it really that hard to find them? I'm not that familiar with the current lineup of cards (still rocking a GTX 770 myself), but Amazon seems to have several 1050-1080 model cards in stock from various vendors. The prices do look a bit inflated, though.

It's very different in practice.

D3D11 contexts are explicit, real objects that you create, manipulate, and pass around. They can be properly and realistically handled in multi-threaded code. OpenGL contexts are opaque and global, and properly handling them in multiple threads is a nightmare. Multiple OpenGL contexts is also very different in functionality from multiple D3D11 device contexts.

> > Vulkan also requires a huge amount of code to do relatively simple things

IMO, this is a common misconception. Or, at least, the extrapolation of it is. Vulkan might require a lot of code to initialize, and has extra responsibilities related to memory management, synchronization, etc., but in my experience the end product doesn't require significantly more code than other graphics APIs. The up-front cost you pay doesn't translate to increased costs everywhere else, at least not to the same degree.

My library supports D3D11, Metal, Vulkan, and OpenGL, and Vulkan is the second-largest backend, but not by a lot (LOC: ~5k Vulkan, ~3.3k D3D11, ~2.5k Metal, 6k OpenGL). LOC is not the best indicator of complexity, to be fair. My OpenGL backend is definitely the most difficult to maintain and the largest, because the API is such a pain to deal with.

I guess I don't understand why this would be true:

> The imgui framework handles the previous frames events when drawing the current frame.

I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).

At least in dear imgui, the input information is provided every frame, so the system can track it over time. If you want to see if there was a double click, then you can call "IsMouseDoubleClicked", for example.

> Yet the draw button function returns true or false on whether it was clicked. But how can that be, this button has not yet been flush to the display?

A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both of which are usually provided to the system on a per-frame basis. I've not used Nuklear, but this is how dear imgui works. If the GUI system knows where you are clicking, and must know the position of the button it's drawing (in order to render it), then it should be able to tell if it's being pressed.

D3D, Vulkan, OpenGL (optionally) etc. do use a bytecode format, but that only covers shader modules, which are a small part of the overall API. I'm not that familiar with CUDA, but it looks like a large portion of it is delivered as a C API, judging by the bindings I see online.

It seems like a C API is a much better choice if you want your library to be callable from many different languages. What is a reasonable alternative without giving that up?

Very nice! I've always been fascinated by synth and sequencer programming.

Small nit: I'm used to being able to drag "upwards" to make a knob's value higher, but here it seems to do cause the value to decrease. Perhaps I'm just too used to how FL Studio behaves and others prefer this way.

There's a few projects working in this direction, one of the coolest being Avalonia (IMO, at least). It's still in "alpha", although I heard a beta was not far off.

https://github.com/AvaloniaUI/Avalonia

The technology will work with any kind of app. I know that some folks working on one of the bigger UI frameworks, Avalonia (https://github.com/AvaloniaUI/Avalonia) have toyed with it recently. One thing to keep in mind is that lots of these frameworks do dynamic, reflection-based data binding, which might be easily broken if the linker removes too much stuff. You can tinker with the settings of the linker to force it to preserve things that are actually necessary.

Just to clarify, we are actually calling the next version of .NET Core "2.0" so that the name aligns with .NET Standard 2.0, and so their relationship is more clear.

I don't know. From what I understand, this is still just a research project, and not something we have immediate plans to integrate into .NET Core. If we did that, though, I don't see why .NET Native wouldn't be considered as well.

I've written an amateur, hobby-level engine, described here: https://mellinoe.wordpress.com/2017/01/18/net-core-game-engi.... This was more of a personal exercise for learning and experimenting than a serious attempt at game design, so the engine isn't that advanced.

For something more professional and polished, there is Xenko, which runs on CoreCLR for some of its non-mobile targets. https://xenko.com/

Also, Unity itself doesn't really run on Mono -- it just has a scripting layer that hosts Mono on top of its C++ core. Perhaps not a useful distinction for you, but I thought I'd mention it.

(Note: I work on .NET Core at Microsoft)

I know it doesn't work with OpenGL ES, but RenderDoc works well on regular OpenGL apps, from my experience.

This is mentioned in the post, in case you missed it:

> Further, normally such testing is best done with a tool like BenchmarkDotNet; I’ve not done so for this post simply to make it easy for you to copy-and-paste the samples out into a console app and try them.

We love BenchmarkDotNet and use it (and other perf tools) quite a lot internally.

Yes, SharpDX does work on .NET Core. Although it's not "official", it is essentially the de-facto library for DirectX bindings.

I have a 2015 Razer Blade Pro and it worked very well under Ubuntu 16.04. The touchpad, touch screen, wifi, etc. all worked well, at least on newer Linux kernels (the trackpad had issues on older kernels). I did some 3D graphics work, and the Nvidia drivers were much better than other drivers I've used on Linux. There wasn't really any "sorcery" involved from my experience; I just installed from the official iso.

I followed this guy's blog for some further configuration: https://alexcabal.com/get-a-working-touchpad-on-a-14-razer-b...

My main problem was that battery life was pretty abysmal under Linux. With Windows, I would get 4-5 hours under light usage, but under Ubuntu I would pretty much only get ~2-2.5 hours, even without doing much on it. Stressing the CPU/GPU made it die even faster. But that thing isn't really known for its battery life anyways.

Unfortunately I don't have Ubuntu installed on it anymore because I couldn't get Windows and Ubuntu to happily coexist side-by-side. Windows (10) always gave me a boot failure when Ubuntu was installed next to it.

If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission.

https://github.com/dotnet/standard/blob/master/netstandard/r...

I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core?

Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available.

https://github.com/dotnet/standard/tree/master/netstandard/r...

For things like legacy synchronous or Begin/End async methods, we are more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal.

(I work on .NET at Microsoft).

It does not; it uses the same JIT and GC as the Windows version of .NET Core, and the code is also shared with the (full) .NET Framework that ships inside Windows.

Actually, this has always been the case for .NET Core, but you may be thinking of our older preview versions which gave you the option to run your app entirely on mono.

(I work on .NET at Microsoft)

Yes, you can specify a relative/absolute path in DllImport if you'd like. Generally it is easier to get consistent behavior if you either: 1) rely on the user to install the binary somewhere and place it on the path, or 2) deploy the native binary along with your application. We generally do 1) in .NET Core, or we rely on components of Windows, for example.

Most of the documentation/tutorials you find will be perfectly relevant, but they may be Windows-centric based on .NET's history.

At a really basic level, you simply declare a "static extern" method with a "DllImport" attribute attached to it. For example, you could call "printf" from libc like so:

  [DllImport("libc")]
  public static extern void printf(string message);

  static void Main()
  {
      printf("Hello World");
  }

Assuming you mean "foreign function interface", then yes, P/Invoke is supported on .NET Core just as it is in the .NET Framework (the Windows component). We use it extensively in the core libraries to access platform functionality.

(I work on the core libraries for .NET)