gfx: dx11 backend won't compile, missing parameter
My system is Windows 10, msvc x64 version of Rust, Visual Studio Community 2015. I tried to duplicate the reddit post announcing a DX11 backend. https://www.reddit.com/r/rust_gamedev/comments/47j2z2/first_render_of_dx11_backend_for_gfx/ Went to the backend directory, tried “cargo build” on it.
C:\Users\bvanevery\devel\gfx\src\backend\dx11>cargo build
Updating registry https://github.com/rust-lang/crates.io-index
Downloading d3dcompiler-sys v0.2.0
Downloading d3d11-sys v0.2.0
Downloading dxguid-sys v0.2.0
Compiling winapi-build v0.1.1
Compiling log v0.3.6
Compiling d3dcompiler-sys v0.2.0
Compiling d3d11-sys v0.2.0
Compiling bitflags v0.6.0
Compiling winapi v0.2.7
Compiling draw_state v0.6.0
Compiling gfx_core v0.3.1 (file:///C:/Users/bvanevery/devel/gfx/src/backend/dx11)
Compiling dxguid-sys v0.2.0
Compiling gfx_device_dx11 v0.2.0 (file:///C:/Users/bvanevery/devel/gfx/src/backend/dx11)
src\lib.rs:419:31: 419:49 error: this function takes 2 parameters but 1 parameter was supplied [E0061]
src\lib.rs:419 (*self.0.context).ExecuteCommandList(cl)
^~~~~~~~~~~~~~~~~~
src\lib.rs:419:31: 419:49 help: run rustc --explain E0061
to see a detailed explanation
error: aborting due to previous error
Could not compile gfx_device_dx11
.
To learn more, run the command again with --verbose.
C:\Users\bvanevery\devel\gfx\src\backend\dx11>
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 21 (18 by maintainers)
I think game developers can be pretty mixed up about what’s appealing. If they think their job is to just bang out a widget, and throw it on a big pile with everyone else’s widgets, well then yeah. They may only be capable of seeing the world as a numbers game, and they think the more devices they run on, the more numbers they will have. It’s a false hope because it doesn’t pay attention to market saturation, the lack of value compared to competing widgets, and the crappiness of certain kinds of customers. Suffice it to say I’m trying to take a qualitative approach to game development, not quantitative. But of course I’m not rich and famous yet, so nobody has any need to listen to me.
Commodity “cover everything” vs. vertical integration is an ongoing tension in the computer industry. Apple proved that vertical integration works, that retaining the most profitable customers is an excellent strategy. Market share and quantity is not really a great thing to be obsessing about. That’s why the PC industry is in a downturn and Intel just laid off a bunch of employees for instance.
The historical thinking about “cover everything, port to everything, get the market share” is misguided. Same goes for what API features and value adds you implement in a 3d engine. You can try to be everything to everyone on all platforms, or you can actually focus on something that makes your 3d engine more “worth it” compared to someone else’s.
Urho3D is pretty much a “best of breed” C++ / OpenGL / DirectX / Lua / AngelScript / Bullet / various open source libraries / CMake integration job. But it is only an integration job, following in the footsteps of an industry that mostly uses Unity. That’s not an automatic sinker, but it’s pretty hard to maintain a developer ecology that way. I’ll admit, I had trouble staying interested in its internals, which is pretty necessary if you’re talking about a tiny core dev team. And it happened to run like butt on these crappy old laptops I’m using. I think it’s targeted at much more aggressive shader HW.
I hope Rust has some magic tricks that make this better. Unfortunately there are critiques out there that the mission is more safety than performance. We’ll see.
@bvanevery I want to give some input here: Gfx has been through several redesigns in this 2 year period, on top of a compiler with bugs and an unstable ecosystem. The specs on Vulkan was not released until recently. The way I see it, Gfx has been staying ahead where others thought it this would be impossible. It has gotten very far, and all it needs is some tweaking, cleanup and stabilization. Definitely worth considering if you are in for the long run.
@kvark, I understand energy, burnout, and priorities all too well. For instance, I gave up on Linux after 3 years. After that, I spent almost 1 year doing small amounts of QA with the Urho3D developers, beating their stuff into shape on Windows. Recently I had to concede that it wasn’t actually helping me get anything done. Urho3D may be a cleaner house on Windows for someone else due to my efforts though.
When you say you are not ashamed if gfx is missing something, that “something” seems to be a DX11 backend. Right now it doesn’t work due to something trivial, and that indicates it probably has zero users. Sure it only showed up 2 months ago, so that might be expected, but it’s indicative of a pattern I’ve seen in Linux-driven open source in general. For instance Urho3D was using Travis as their continuous build and test server. Travis doesn’t support Windows, so from such a project, there’s typically never-ending cleanup work on Windows. At least I see you’re using Appveyor which supports Windows.
I begin to wonder, what is the point of cross-platform development? Core devs tend to have a preferred platform and leave others rough, to the point of not actually working, not having any users, or any sustainable ecology. “Paving over” 3D APIs to make them cross-platform seems like a compelling idea, doing all those neato abstractions and such. Except then the actual systems end up not working cross-platform in the real world. The actual value adds (i.e. games, 3d apps) don’t get written. 3D APIs are just conceptually replicated at a higher level of abstraction, which by itself is not valuable. Those pave-overs tend to use up a lot of an open source developer’s time, like over the 2 years you mentioned, leading to burnout. End of ecology.
What do I need, currently? “DX11 with a language that isn’t C++ that doesn’t suck.” I’ve tried everything and Rust is pretty much the last port of call. If it isn’t suitable, then I’ll write my own.
Why DX11? Because deployment with that is sane right now. Because Valve hasn’t turned Linux / SteamOS into a credible game platform. Whenever I try to find out about Steam Machines sales or consumer uptake, I hear crickets chirping all over the internet. Meanwhile, OpenGL will be dead Real Soon Now. Vulkan will try to supplant it, but given Valve’s bad deployment story, I’m not certain Vulkan has any actual future. Apple doesn’t want it, they’re doing Metal. Microsoft already deployed DX12 and Vulkan has no hope of displacing it there, any more than it displaced DX5…11 with OpenGL.
I suppose this is all tangential, but I like to probe a project’s real development commitments, aspirations, and energy level before volunteering much work for it. I do the basic QA of filing bugs because open source can’t function at all if people won’t do that. But sometimes I question whether even that minimal level of involvement, is worthless. The most important idea may be to focus on the 1 problem that actually matters, and forget about contributing to “open source”.
I could do Rust and gfx. I could do Rust and DX11 only. I could roll my own language with DX11 only.
I hope this is food for thought, about what you actually want to do.