dxvk-native
buf
dxvk-native | buf | |
---|---|---|
23 | 41 | |
383 | 8,397 | |
- | 2.0% | |
3.0 | 9.6 | |
over 1 year ago | 6 days ago | |
C++ | Go | |
zlib License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dxvk-native
-
Left 4 Dead 2 has been updated to DXVK 2.0
DXVK 2.0 has upstreamed the dxvk-native code, meaning the game runs using native Linux libraries but uses DX11 with DXVK. This is mostly done because the ancient OpenGL linux-native renderer was rather bad.
-
Portal 2 and Half-Life 2 issue
what works best is games supporting dxvk-native: https://github.com/Joshua-Ashton/dxvk-native
- Some games play so well with Proton that it offends me they don't release a native build
-
Clip Control on the Apple GPU
There is DXVK native which doesn't require wine.
https://github.com/Joshua-Ashton/dxvk-native
-
DirectX is the reason we still need wine and proton?
There are also Dxvk native for porting game to Linux. Which is used by valve to port it's game to Linux.(replacing togl)
-
Very High VAR spikes on CSGO
I disagree, but I get the frustration. It's just that I've been playing CS:GO for almost a decade, and while I think the game is neglected by Valve in general, it's way a worse scenario on Linux. For instance, Vulkan support (via dxvk-native) was added back in December last year, and it's not been updated ever since, so you get way worse stuttering when compared to OpenGL (which is actually a DirectX 9 to OpenGL translation layer, called toGL, which has its own set of bugs and issues); Plus, you can't change screen resolution when using Vulkan. I get some occasional little stutters on Windows as well, but the whole CS:GO experience is honestly just way worse on Linux, unfortunately.
- What API or program would you like to see re-implemented on top of another platform?
-
OpenBSD Gaming Updates Q2 2022
DXVK-Native and the game Perimeter. Perimeter is the one game I know of that's opensource and that uses DXVK-Native. I got it to run, but there was no support for any audio, making this pretty unexciting. This is still being worked on upstream, so maybe a DXVK-native port later and a port of perimeter will happen then...
-
Is Proton now the all cure to PC Gaming On Linux or we not 99% there yet?
You never mentioned that requirement, but here you go: https://github.com/Joshua-Ashton/dxvk-native
-
which should I click?
DirectX isn't an option on linux/mac anyway, it's just launch or safe mode. (Note to any SCS developers if they're lurking around here... please implement the DX pipeline into the linux build so we can use DXVK-Native, it's much faster than OGL!)
buf
-
What happened to Captura? OSS maintainer burnout
> Open-sourcing protobuf was most likely not a big cost, and it had benefits for Google (otherwise it would not have been rational to open source it).
Nah honestly it was more like I said "Hey I want to open source this!" and other engineers said "Yeah that sounds awesome!" so I did. That was Google in ~2007, you could basically do whatever you wanted and as long as it was vaguely plausibly useful management said "sure".
I'm honestly not sure the company had any idea what they should do with OSS protobuf, at least for many years. Management never really gave me any credit for releasing it and gently pressured me to find a different project to work on that more directly aligned with company goals, which I eventually did.
Still not clear if they even know today. They seem more serious about it today but at the same time it's still clear that they mostly don't care about external users, so much so that startups like https://buf.build have to come in and build the actual products around Protobuf that Google never delivered publicly (but has internally). Of course, companies are not hive minds -- there are clearly people at Google who want to make Protobuf a great product, but I don't think management sees it as strategically interesting.
> If protobuf was not open source, something like Cap'n Proto may take its place, and that's not good for Google.
Honestly I don't know if Google cares. Cap'n Proto hasn't caught on much because frankly I don't care to make it a product, I maintain it for my own use (primarily in the Cloudflare Workers runtime, my day job). But if that changed and Cap'n Proto got really good and people ditched Protobuf for it, would it really affect Google? I kind of don't think it would. (Just like I'm not sure it would benefit me that much, which is why I don't make this my job.)
Certainly the strategy around open sourcing something like Protobuf vs. something like Chromium or Android is entirely different. Sundar probably doesn't even know what Protobuf is TBH.
(Disclosure: I wrote and open sourced proto2, created Cap'n Proto, and have a small investment in Buf.)
- Building a gRPC Server with NestJS and Buf: A Comprehensive Showcase
-
5 Open Source tools written in Golang that you should know about
The Buf CLI is a versatile tool designed for handling Protocol Buffers (Protobuf), a method of serializing structured data. It offers several key features, including managing Protobuf assets through the Buf Schema Registry (BSR), providing a linter to enforce optimal API design and structure, and a breaking change detector to maintain compatibility either in source code or at the wire level. Additionally, the Buf CLI includes a generator that activates plugins based on user-defined templates and a formatter to standardize the formatting of Protobuf files according to industry norms. It also integrates seamlessly with the Buf Schema Registry, supporting comprehensive dependency management.
-
Create Production-Ready SDKs With gRPC Gateway
We'll use the Buf CLI as an alternative to protoc so that we can save our generation configuration as YAML. Buf is compatible with protoc plugins.
-
gut: convert golang structs to typescript interfaces
Not so much anymore! Take a look at buf.build, it makes the whole thing notoriously easy :)
-
Flutter + gRPC for Desktop and Mobile App Development - Good choice?
In my opinion it's a good idea, it's the architecture we use at work, and it works well for us. The main limitation to be aware of is that many PaaS don't support gRPC traffic (because of the proxies used). For example, DigitalOcean App Platform or Heroku if I remember correctly. If the way you want to host your backend is OK with HTTP/2 and gRPC traffic, then it's not a limitation. One way around this limitation is to use the gRPC-Web protocol, or the Connect protocol (https://connect.build/). Unfortunately, Dart's gRPC client does not support the gRPC-Web protocol outside the web platform. So for a mobile application, it's not usable at the moment. (If this PR were accepted, it would solve the issue: https://github.com/grpc/grpc-dart/pull/557.) As for Connect, no client is currently offered by Buf for Dart. Don't hesitate if you want to know more. That said, I'd advise you to use the Connect implementation for Go to implement your backend. Connect will enable your server to speak all three protocols (gRPC, gRPC-Web and Connect), which is very useful in the long term. What's more, the code is cleaner, and you benefit from official support for observability with OpenTelemetry. If you don't know Buf (the creators of Connect),I suggest you visit their website: https://buf.build/. :-) Good luck!
-
Building a modern gRPC-powered microservice using Node.js, Typescript, and Connect
As mentioned in the intro, we are going to use Buf and Connect as our tools. We’ll start by installing the dependencies.
-
Building High-Performance Web Services with Golang gRPC
gRPC itself is quite nice, especially with buf which makes generating Go code much easier. The rest of the code was in a bad state. Unmaintained router packages, repository pattern without any actual benefit or a repository pattern.
-
gRPC vs REST: Comparing API Styles in Practice
The second big difference is that we now have auto-generated client and server stubs. For this task, I chose to use buf and the protobuf-ts plugin in order to generate idiomatic Typescript classes and objects. Not only do these classes describe the types we'll use in the server and client, but also includes the actual gRPC implementations used to serialize and send messages back and forth across the wire.
-
Show HN: ProtoCURL, a Curl for Protobuf
Our team has been using Buf (https://buf.build) recently, and they have a nice solution for schema dependency management.
What are some alternatives?
Dota-2-Vulkan - Tracker for issues specific to the Vulkan version of Dota 2 on Windows, Linux, and macOS
protoc-gen-validate - Protocol Buffer Validation - Being replaced by github.com/bufbuild/protovalidate
steam-runtime - A runtime environment for Steam applications
prototool - Your Swiss Army Knife for Protocol Buffers
d8vk - Direct3D 8 to Vulkan translation for DXVK!
grpc-web - gRPC for Web Clients
dxvk - Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine
goprotobuf - Go support for Google's protocol buffers
UnityPy - UnityPy is python module that makes it possible to extract/unpack and edit Unity assets
gRPC - The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)
OpenBSD-Games-Database - Database of games that run on OpenBSD
oapi-codegen - Generate Go client and server boilerplate from OpenAPI 3 specifications