dx11 backend won't compile, missing parameter

[bvanevery]

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>

[kvark]

That's unexpected. We have AppVeyor CI going, and the last build was successful. Perhaps, some of the winapi libraries have changed in the meantime, breaking semver? cc @retep998

[retep998]

According to MSDN, that function does take two arguments. This was a bug that was fixed (you even commented on the bug!). So, just update gfx to use the correct parameters. I follow semver about as strictly as Rust does, breaking code whenever necessary to ensure soundness.

[retep998]

cc https://github.com/gfx-rs/gfx/issues/923

[kvark]

@bvanevery please submit a PR if you can. RestoreContextState should be TRUE. Don't forget to bump the backend crate version as well.

[bvanevery]

@kvark, I'm confused. You want me to do a PR for a trivial bug that you understand and have the solution for? You have commit rights to gfx, yes? Can't you just add TRUE yourself and be done with it? I'm still rather a noob about Github PRs, and I'm only just learning Rust.

[kvark]

@bvanevery well, I don't have a windows box nearby to test it and see that the examples are behaving normally. Also, it's an opportunity for you to get involved with the project, starting with something trivial but much needed.

[bvanevery]

Heh! As I do have Windows machines, and this should be easy if delaying, I'll figure out how to do as you ask.

But I would also say, I don't think it's a good idea to seek to recruit people to work on gfx, as opposed to just fixing what is easily fixed. I'm not a Rust or gfx contributor at this point. I'm only someone evaluating things for whether it's even worth messing with. Bugs per capita, and the likelyhood of them staying that way unless I personally fix them, are part of that evaluation. Let's put it this way: if I find a lot of such things that simply haven't been fixed, I'm not going to spend time polishing gfx up. I'd run for the hills. I'm not sure if you have any personal sense of ownership of the bug, whether you see it as being within "your area" or not. But if it were my codebase, I'd be ashamed of not fixing such a trivial thing immediately. Barring life pressures of course.

Hopefully this is just "the one that got through." We'll see.

[kvark]

@bvanevery I understand your position.

Bugs per capita, and the likelyhood of them staying that way unless I personally fix them, are part of that evaluation.

This is not an issue that's going to be staying for any longer. You are welcome to fix it. If not, we'll do it without hesitation.

Let's put it this way: if I find a lot of such things that simply haven't been fixed, I'm not going to spend time polishing gfx up. I'd run for the hills.

You mean, things that are covered by CI but got broken just because one of the dependencies failed semver? I don't recall that happening ever before.

But if it were my codebase, I'd be ashamed of not fixing such a trivial thing immediately.

To be honest, I'm long past the point where I would be ashamed that gfx is missing something. It's a project in development for almost 2 years. It's still rough, and the nearest future doesn't show signs of stabilization for the API. There is, however, lots of exciting stuff on the horizon, like Metal and Vulkan.

People came and went, including some of the core developers. Today, we need contributors much more than we need users. We need people who realize the potential of the project and ready to move it forward together with their own games/engines on top of it.

[bvanevery]

@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.

[bvssvni]

@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.

[retep998]

For the record, winapi 0.2.7 came out May 10, so it took about 9 days for someone (you) to notice this, which isn't too bad considering how the majority of the Rust community doesn't use Windows, and even those that do typically use OpenGL.

[bvanevery]

I think my biggest fear is I haven't yet found anything "3d compelling" in the Rust ecosystem at all. Like, something that renders piles and piles of triangles for some purpose, and either looks sorta good, or is sort of impressive in the amount of data it's visualizing. All I've seen so far from perusing rust-gamedev are toys. Toys are a good start for something, but they are only toys, and not proof of concept that Rust or gfx can do what I want. It looks suspiciously like I'd have to come up with that "pile of triangles" myself, and then hope the performance doesn't suck.

I'm not inclined to single out gfx as being somehow responsible for this. I remember looking at Rust maybe 2 years ago, and there was no story that I remember being worth telling back then. It was just some new language with high hopes and not much proof of efficacy. Jonathan Blow notably didn't think much of it, and subsequently went off to write his own language. Which isn't publicly available for me to make any use of. I appreciate, however, that he truly gets how stagnant language evolution has been in the game industry, and seeks to do something about it. I haven't run into anyone else in industry who does get it, or is doing anything about it.

So far, the part of the Rust story that is actually working for me, is Cargo. I've got umpteen years of painful CMake experience, and Cargo is clearly better. I hope there's something to the idea of Rust trying to take over the "systems programming" space from C++. That is still under investigation and my jury is out on that.

I have no idea how Rust might specifically help the conceptual modeling and simulation of a 3D game. My jury is out on that. Frankly I've only barely cracked the programming manual.

[bvanevery]

I figured out how to fork. Still going up a semvar learning curve as to which dep version numbers should be minimally required. After some false starts, I deduced that the missing parameter needed is actually winapi::TRUE, not just TRUE. Adding it, the original error goes away. I get a brand new warning, which may or may not be a bug:

C:\Users\bvanevery\devel\fork\gfx\src\backend\dx11>cargo build Compiling gfx_device_dx11 v0.2.0 (file:///C:/Users/bvanevery/devel/fork/gfx/src/backend/dx11) src\command.rs:19:14: 19:33 warning: unused import, #[warn(unused_imports)] on by default src\command.rs:19 DXGI_FORMAT_R8_UINT, DXGI_FORMAT_R16_UINT, DXGI_FORMAT_R32_UINT, ^~~~~~~

C:\Users\bvanevery\devel\fork\gfx\src\backend\dx11>

I'm not seeing any kind of test binary generated, only target\debug\libgfx_device_dx11.rlib. So I figure "cargo build" in dx11 backend directory is probably not sufficient to make a test. More small learning curves. "cargo build" from toplevel gfx directory still contains the warning. Which I guess is a good thing, that warning behavior is the same. Still don't see a test though. Ran "cargo test" from toplevel gfx directory. Things compiled, tests ran, didn't see anything specific about dx11. So, not sure how I'd verify anything other than "I got it to compile."

[kvark]

@bvanevery you seem to be a lovely dev, seeking your own happiness with the tools to build stuff, like most of us. I appreciate the story, it's nice to see the background you are coming from. :+1:

Except then the actual systems end up not working cross-platform in the real world.

There is nothing specific to gfx here. Most of the stuff that gets developed, in general, is not working correctly in all the situations of the real world.

3D APIs are just conceptually replicated at a higher level of abstraction, which by itself is not valuable.

Incorrect. The value is portability. Higher level abstraction is the means to get there. It's not even strongly "higher". Comparing to GL, there are concepts that can actually be considered lower level, like command buffers.

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.

The burnout can be accelerated if the code developers rush in to fix every issue encountered by the users instead of delegating it or guiding the users themselves to a solution ;)

Why DX11? Because deployment with that is sane right now

I'd like to add that it's simply a very beautiful and concise API. It was so much ahead of its time when it was released, and still much nicer to use than GL. Only frustrating things about it are COM interfaces and the runtime.

Vulkan will try to supplant it, but given Valve's bad deployment story, I'm not certain Vulkan has any actual future.

Regardless of Valve's actions, Vulkan will live. I've got to admit that, again, DX12 is way simpler and more beautiful, but there is no real contender for Vulkan on mobile.

I do the basic QA of filing bugs because open source can't function at all if people won't do that.

You did a good job filing this issue. Thanks!

I think my biggest fear is I haven't yet found anything "3d compelling" in the Rust ecosystem at all. Like, something that renders piles and piles of triangles for some purpose, and either looks sorta good, or is sort of impressive in the amount of data it's visualizing. All I've seen so far from perusing rust-gamedev are toys. Toys are a good start for something, but they are only toys, and not proof of concept that Rust or gfx can do what I want. It looks suspiciously like I'd have to come up with that "pile of triangles" myself, and then hope the performance doesn't suck.

Sounds like you are looking for an engine/framework. Yes, rust gamedev doesn't have much to offer yet. There is kiss3d, but I don't know anything impressive built with it. There was a couple of older engines, like claymore or snowmew, but they perished.

The most promising thing right now, it seems, is Amethyst. @csherratt is involved there (and happens to be one of the gfx core devs), plus lots of other good folks. I've also made a little table for engine comparison that you may find interesting.

I get a brand new warning, which may or may not be a bug

That's harmless and trivial, although I don't recall seeing it before.

I'm not seeing any kind of test binary generated, only target\debug\libgfx_device_dx11.rlib.

Right. I'd advise you to do it like this:

git clone https://github.com/gfx-rs/gfx && cd gfx
cargo test
cargo run --example cube # or any other in `/examples`

[bvanevery]

I learned git clean -f -x to get rid of stale Cargo.lock files. Cargo seems to suck in winapi 0.2.7. I'm not sure what the minimum version of winapi should be specified as, if anything, so I think I will give up on that.

Ok got a cube. Need to verify why it would be a DX11 cube. Ok, the cube example does have DX11 code in it, and might be configured as the compile time default on Windows. But I don't know for sure. It would require more understanding of Rust than I have, and maybe ability to trace what's going on in a debugger. I'm still just plunking with a text editor. I think I've done what I can for making a well-formed fork. Now to figure out how to do a PR.

Git has default vim configuration. Ridiculous. Freakin' stone ages. Got SciTE working.

I'll look at the 3d game / engine links you provided.

Portability is only valuable if something substantial is ported. I've wasted years of my life, multiple times, on "premature cross-platformization". I've ended up with things like an extremely portable software rendering 3D API that barely renders 1 polygon, or an icosahedral planetary topology that doesn't have a game with it, or a Windows build for a Scheme that I don't actually end up using for anything. Nowadays I rate things based on what people have actually gotten done with them, not their theoretical potentials. The reality is (especially young) open source developers burn out and move on, in a timeframe of a few years. Things like oh gosh, is this keeping a roof over my head, is it sustainable? Nevermind people just getting bored, a severe project threat even if survival resources (food, shelter, mates) are assured. I actually have a strange "career" that I've even tried cross-platformization as many times as I have, but that's a story for another time.

Ok PR completed. It'll be interesting to see how many "delegation" exercises are tolerable.

[kvark]

Fixed by #975

[kvark]

@bvanevery thanks! FYI, all the examples (besides performance and triangle) are using gfx_app, which is defaulting to DX11 on windows. So the cube does serve as a test. A guaranteed way of verifying that is taking a capture with PIX or RenderDoc.

As for the portability... on the other side of the spectrum are the applications that turned out to be successful but then facing the scalability limits. Think TotalCommander for example. When the app grew, it's much harder to change the low level that would expand to different platforms/graphics APIs. That's why thinking about this early on is reasonable, in my view.

[bvanevery]

No prob. Thanks for responding quickly to my filed Issue and closing it quickly on submission. Good sign.

I don't think scalability is even basically applicable to indie game development. 1st job is to make an actual title that actually makes money. So that one can survive and expand it. You can hire all sorts of people to port things if you actually have a revenue stream, or even luxuriate in it yourself if one is so inclined. Front loading portability is the wrong problem to solve. Should front load making a good game on a commercially viable platform for a worthy target audience.

Perhaps you're not especially interested in commercial Windows games. My observation is open source $0 GPLed game development basically doesn't scale. Freeciv and The Battle for Wesnoth are pretty much the historical best of breed. They were quite limited in ongoing developer energy, and especially in the latter, in developer maturity for entertaining new directions or visions.

Apple has been a terrible steward of games. I hope Metal changes that, but I don't like their corporate philosophies in any event. They aren't that different from the Microsoft of old, they just have somewhat better design taste.

Valve hasn't fixed Linux.

Android is a ghetto.

My bias is I pretty much hate mobile. Especially the small screens. Real 3d games have real triangle counts and decent sized screens. Keyboard optional but tends to be highly useful for the complexity of games I actually want to play.

[kvark]

@bvanevery I do buy your argument about the need for scalability for games. So, if you are making one, you may not give gfx's portability too much credit. But if you are making a higher layer, like a game engine... that is much different. An engine locked to one platform/API is not appealing.

Then, if there are engines available, people would surely consider them for making games and apps. Not just for the portability, but mostly for the convenience. The former comes as a nice bonus.

As for the mobile, it's power and screen size (both physical and resolution) are growing quickly. These are just going to be different kinds of games there, that we (older folks) are not very used to. But I do see how some of these new games may be graphics demanding too.

[bvanevery]

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.

[sectopod]

As much as I enjoy reading this discussion, I'd like to kindly suggest it to transition into our gitter room.

Oh, and I've just published gfx_device_dx11 v0.2.1 for your convenience ;)