Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Offline Last Active Today, 08:27 PM

#5255367 Vulkan is Next-Gen OpenGL

Posted by Promit on 03 October 2015 - 10:56 AM

Don't get me wrong - I am ALL ABOUT the new APis from a technical standpoint. But I'm not living in AAA world these days and practical reality is that writing a render pipeline for a market that maxes out at 22% is just a bit rough. Now it's very helpful that Win10 is free and everyone wants to get the hell out of Win8. But the real key point is that it's very difficult, outside of a few select high budget things, to really design around the new APIs. Oxide's been talking about this, where you really start leveraging the added capabilities in a way that is more extensive than simply writing multiple render pipelines, and those changes feed all the way up to your game design.


FWIW I am shipping a Metal pipeline game in a few weeks - which is more about the structure of Apple's platform than anything - and that's not designed around the new rendering API either. I still have to maintain GL ES paths for a wide swath of old devices and that means the rendering changes are low hanging fruit with a lot of old assumptions and limitations still preserved.

#5255297 HDR gamma correction

Posted by Promit on 02 October 2015 - 10:37 PM

HDR images are already linear, yes. The only images that need gamma correction are sRGB images (typically 8 bpc), which are your "normal" images in common image formats. Essentially you can just tell the API that the textures are sRGB and the GPU will handle the correction for you.

#5254606 Mac to buy for app development?

Posted by Promit on 29 September 2015 - 09:39 AM

The Macbook Pro Retina is easily a solid choice if you're also going to use it as a day-to-day laptop. I ran out of memory trying to do development on the older 8 GB model MBP, but I don't know how big or heavy your stuff is. (I didn't feel like ours was big, but...)

#5254049 What is more charged?

Posted by Promit on 25 September 2015 - 03:21 PM

I agree with the above. Buuuut if we're talking about the best paid game dev jobs, it's going to be highly capable system architects well versed primarily (but not exclusively) in C++ and various low level technologies like DirectX 12, GL/Vulkan, etc. People with deep and heavily mathematical knowledge of graphics and/or physics probably do best, as they're very difficult to replace. The web and engine-specific guys just don't merit the same levels of compensation.

#5252792 DirectX高级动画制作(Jim Adams)

Posted by Promit on 17 September 2015 - 07:29 PM

Google translate: I purchased this book (DirectX Advanced Animation) when I lost this book 's CD , give me a copy?

#5250653 High Quality Light Trails

Posted by Promit on 04 September 2015 - 10:36 PM

Some background info here: http://www.fxguide.com/featured/art-directing-effects-for-infamous-second-son/

GDC slideset here: http://www.gdcvault.com/play/1020158/The-Visual-Effects-of-inFAMOUS

#5245824 PI or not to PI ?

Posted by Promit on 11 August 2015 - 02:37 PM

The PI term comes from normalizing the light response to 1 - essentially it's the product of a surface area integration over the hemisphere. If you don't have it, your surface will reflect pi times the correct amount of lumens back out. If you want to make sure your lighting is properly energy conserving, you can do the divide by pi when submitting the diffuse color to the shader instead of in the shader itself.

#5245166 OpenGL vs DirectX

Posted by Promit on 08 August 2015 - 06:06 PM

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

#5245149 OpenGL vs DirectX

Posted by Promit 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 Promit on 17 July 2015 - 07:01 PM

You're Probably Storing Passwords Incorrectly

#5239834 Why Do People Use DirectX?

Posted by Promit 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 Promit 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 Promit 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 Promit 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 Promit 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.