Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Online Last Active Today, 05:06 PM

#5245166 OpenGL vs DirectX

Posted by on 08 August 2015 - 06:06 PM

And nobody is going to with your current behavior. Thread closed.

#5245149 OpenGL vs DirectX

Posted by on 08 August 2015 - 03:39 PM

If platforms outside than the Microsoft ecosystem are important to you, especially mobile, OpenGL.

If you're happy being limited to the Windows world, Direct3D.

#5241134 Md5 Password Hasher would you use this.

Posted by on 17 July 2015 - 07:01 PM

You're Probably Storing Passwords Incorrectly

#5239834 Why Do People Use DirectX?

Posted by on 11 July 2015 - 07:19 PM

I think we're done here. The responses you've gotten are on point.

#5239787 [SlimDX] Information on the history of SlimDX

Posted by on 11 July 2015 - 02:08 PM

I wrote about some of the technical issues we ran into on my old blog. One of the longer-reaching problems we had, in my opinion, was with object lifetime. We used IDisposable as a convenient way to wrap the COM reference counting semantics, but this ended up being a bad idea because the concepts did not map 1:1, even after we implemented an object table holding all the SlimDX object references to ensure we kept only a single reference count.

3) Interesting technical challenges

Lifetimes and object identity existed together as a vexing headache. We wanted the library to behave like a sane managed library would. Simple IDisposable interface, predictable object identities, etc. One of the big motivating problems was something that I think we called the Get == Get problem. Essentially it looks something like this:

var bb1 = device.GetBackBuffer();
var bb2 = device.GetBackBuffer();
Debug.Assert(bb1 == bb2);

There are two behavioral goals for this snippet. One, the assert should pass. Two, that Dispose call should destroy the underlying object. (And this should be true for all CLR languages.) Neither is true in the naive implementation of the library used early on. Each call gets a native pointer, wraps a new managed object around it, calls an AddRef on the underlying COM object, and returns it. The reference equality fails (the object identities are not the same) and both need to be Disposed separately. I ultimately solved the problem through the aforementioned object table, a tool that in retrospect I still have extremely mixed feelings about. In the vast majority of cases, it actually does its job quietly and magnificently, as well as enabling some very useful debugging techniques. But in the bad cases, it gets really problematic. As Josh noted, we had not planned on using that design again if we were going to take another crack at rearchitecting the whole library.


Building documentation was oddly a real pain. MS went to a lot of trouble to build this comment documentation stuff into VS, but apparently it never ever occurred to them that, gee, maybe somebody else would want to be able to publish miniature forms of MSDN for their work. Eventually Sandcastleappeared and I used that with many custom patches. In conjunction with SHFB, it works really well to make CHM documentation. It is (was?) however entirely useless for building websites. I eventually did some more custom patches and homebrewed a site with JQuery and that's what drives the current documentation.


4) Future plans

When SlimDX was built, we all had a lot more time on our hands. I want to simply hand implement (not auto gen) the SlimDX 2 design for D3D 12, roll the math library in, and call it a day. This is somewhat complicated by a few things. First, life. I have a lot of it nowadays and that's getting inconvenient. Second, at a personal level I have a lot of doubts about D3D 12's near-term viability and a lot of optimism about Vulkan, which is complicating things. I still want to do it, but I'm not in that big a hurry.

#5239668 [SlimDX] Information on the history of SlimDX

Posted by on 10 July 2015 - 09:46 PM

I don't have time right this minute but I'll give you a full rundown soon.


[Edit] And here it is. WIP to be expanded as I go.


1) Why was SlimDX started?

In 2006, I had a class which required us to do a sizable project in a 'pure OO' language. We wrote a game in C#, using the Managed DirectX 2.0 library. At this time, .NET 2.0 was still relatively recent having been introduced in VS 2005, and MDX 2.0 was still a 'beta' library with 1.1 being the stable branch. It worked well enough though. That spring/summer, it was announced that MDX 2.0 would never become a production library, and the first public previews of XNA were published. (Aside: I was working at Microsoft that summer, and managed to briefly visit with Tom Miller, who mysteriously had an Xbox 360 dev kit in his office. I was asked not to mention it.) 


I felt that XNA was technically deficient and filed a couple of early high profile bugs/feature requests. It became clear that I did not see eye to eye with the MS team on how a managed wrapper should look, and I went back to using MDX 2.0. Unfortunately the MS guys had neglected to mention that all of the MDX beta releases were time bombed: you could see in the decompiled source that it checked the current date against a hard coded value and generated an exception, but no one had noticed. So it wasn't just that the beta library was deprecated or not recommended, but that the whole thing literally stopped working overnight. MS refused to release a usable build of MDX, existing code didn't necessarily translate well, and the existing userbase was rightly pissed off. 


Remember I'd just written a game? I had a bunch of engine code which was relatively lean and simple in its DX API usage but had some sophisticated tricks that weren't XNA friendly. I figured that it might actually be easier to rewrite MDX than rework the engine. Maybe a week of learning C++/CLI and wrapping work later in December 2006, I had a library that was now source compatible with MDX 2.0, as far as my engine was concerned. I spent the next couple months refining both engine and wrapper to suit my own interests and thought nothing more of it.


Probably some time around March 07, I was discussing the work with a friend of mine, Josh Petrie, who convinced me that people other than me might be interested in seeing and using the library, and signed on to help me out. The name was chosen to sound similar to MDX, while conveying that it was meant to be a simplified minimalist replacement, not a total coverage DX wrapper. I initially published it right here:


That thread has a pretty good run down of what the library looked like at the time, and offers something of a window into my own mindset. It also highlights that I wasn't the first to do this, as Ralf Kormann was working on a (initially) D3D 10 wrapper, which ultimately fell by the wayside. I don't know why. The original source code continues to live on at the beginning of the SVN history:


Check out how many render states were implemented, and how much the Device class was capable of. That was slim. Anyway, Washu joined in to contribute some code within a couple days, and you can see Mike Popoloski's early interest. He eventually starts contributing code in early August, and that's been the core team ever since. You can also see that we start making breaking code changes from MDX almost immediately, and it's a torrent of activity in general.


Aside: In summer 2007 I was working at NVIDIA on the DX9 driver team, which gave me incredible visibility into how the core graphics subsystems actually worked. While not directly relevant to SlimDX work, it did make it clear that worrying about overhead from managed<->unmanaged transitions is pointless. Between working at both MS and NV, I think it helped me build something of a reputation as being uniquely suited to run such a project. That itself is something that still follows me in surprising ways.


2) How was the project organized and managed?

Things needed to get done, people went in and did them. The primary collaboration was and always has been via IRC. Broadly speaking we were working on different subsystems: I was heading up the D3D 9 work, Josh convinced me that D3D 10 should be included and was busy building it, Mike volunteered to deal with the DirectInput code. Washu wrote XInput and was also dealing with math library and architectural stuff, as he had the strongest understanding of the .NET Framework/runtime underpinnings. Later on we'd either use the bug tracker to manage tasks, or just discuss in IRC and do the work. 


Ultimately, Mike probably did the heaviest lifting in terms of overall code volume, and dealt with a lot of the really tedious stuff, D3DX in particular. He did a lot of the samples, too. Josh did D3D 10 and I think all of the 11 code. Washu wrote random bits and pieces and addressed a variety of architectural and performance problems. I did D3D 9, D3DX, core library design, developed the main wrapping techniques that we used, etc. I also did documentation, installer, releases, that sort of thing. There were a few other contributors over the years, usually for specific goals.


I would like to note at this point that the site was hosted for many years free of charge by Rim van Wersch, first as a subdomain of mdxinfo.com (which is amazingly still up) and later as its own site. We moved to our own hosting much, much later.

#5235611 Tiny Serialization Library

Posted by on 18 June 2015 - 10:10 PM


I dunno, I'm skimming through your code and it seems like serializing objects in yours is a crapload of work and code to write, plus you have to maintain matching read/write functions. Is that an accurate assessment?

A crapload of work, is of course subjective; you definitely have to maintain read/write functions; though out of ordering and matching is up to you by design.

I'd argue that having to maintain a parsable 'def' file of sorts for protobuf or the like is roughly as bad; but I am looking at adding some options which can allow for a single 'serialize' function for 90% of use cases where you wont care about having deliberate control over reads.


Well, this is what I did. It's kinda hard coded to JSON but it could be patched up for multiple backends easily enough.

#5235530 What is the future of the Game Dev. industry?

Posted by on 18 June 2015 - 11:13 AM

I'm interested in why you think games would run out of places to go after thirty years, when the film industry has been productive for over a century and the classic creative fields (literature, art, music) for ten times that or even longer.

#5235508 Tiny Serialization Library

Posted by on 18 June 2015 - 09:51 AM

I dunno, I'm skimming through your code and it seems like serializing objects in yours is a crapload of work and code to write, plus you have to maintain matching read/write functions. Is that an accurate assessment?

#5235167 Uses of curves in graphics?

Posted by on 16 June 2015 - 12:36 PM

Lighting response curves - http://graphicrants.blogspot.com/2013/08/specular-brdf-reference.html


#5235019 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by on 16 June 2015 - 12:08 AM

Oh - you still need the v part in the string. Try: "v %f %f %f". 

Also, your array declaration is incorrect, it should be value[3] as you have three values. 

#5235015 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by on 15 June 2015 - 11:00 PM

%d is integers, %f is floats. You probably just need "%f %f %f". Your values are also ints, which is obviously wrong.

#5234649 how much i can trust the shader compiler?

Posted by on 13 June 2015 - 02:35 PM

Depends on the API and platform, which already means that in the general case: no, you cannot trust "the compiler". The worst of the compilers are the mobile GLSL compilers, which may fail to make even trivial optimizations properly. HLSL is tricky because it's an intermediate compiler to a problematic format that is then finally compiled by the NV, AMD, Intel drivers. Overall I'd say HLSL on NV is probably the most reliable of all the platforms, with HLSL/AMD close behind. It also appears that Apple/Metal is very strong, as it's essentially running the clang/llvm stack.


And yeah, sometimes it's bad.

#5234488 Making a tool for the engine

Posted by on 12 June 2015 - 11:49 AM

That's a big topic, but I'm actually going to start by encouraging you to read the Bitsquid blog stuff. Of note is Our Tool Architecture.

#5233569 Game in pure C99

Posted by on 08 June 2015 - 11:45 AM

Without static linking, you have to manually decode a bunch of COM interface details and build function pointer tables. Honestly if you want to do a pure dynamic loader, it will be much easier to use OpenGL, as it is a pure C API.