Intel sponsors gamedev.net search:   
Promit's VentspaceBy Promit      

Welcome to Ventspace! Most posts here are delayed copies of posts from the real Ventspace.

Thursday, October 1, 2009
Let's look at a real, in the trenches SlimDX bug that results from a problematic subtlety in .NET. This one isn't even fixed in trunk yet. Here's our main function of interest:
generic<typename T> where T : value class
        Result BaseEffect::SetValue( EffectHandle^ parameter, T value )
        {
                HRESULT hr;
                D3DXHANDLE handle = parameter != nullptr ? parameter->InternalHandle : NULL;

                if( T::typeid == bool::typeid )
                {
                        BOOL newValue = Convert::ToInt32( value, CultureInfo::InvariantCulture );
                        hr = InternalPointer->SetBool( handle, newValue );
                }
                else if( T::typeid == float::typeid )
                {
                        hr = InternalPointer->SetFloat( handle, static_cast<FLOAT>( value ) );
                }
                else if( T::typeid == int::typeid )
                {
                        hr = InternalPointer->SetInt( handle, static_cast<INT>( value ) );
                }
                else if( T::typeid == Matrix::typeid )
                {
                        hr = InternalPointer->SetMatrix( handle, reinterpret_cast<D3DXMATRIX*>( &value ) );
                }
                else if( T::typeid == Vector4::typeid )
                {
                        hr = InternalPointer->SetVector( handle, reinterpret_cast<D3DXVECTOR4*>( &value ) );
                }
                else
                {
                        hr = InternalPointer->SetValue( handle, &value, static_cast<DWORD>( sizeof(T) ) );
                }

                return RECORD_D3D9( hr );
        }








This function will crash randomly on good input. Specifically, D3D will return a D3DERR_INVALIDCALL, which then gets translated to an exception. Again, that's on known-good input. The call to the function looks like this:
effect.SetValue<float>("alpha", 0.5f);

When this call is made, an EffectHandle is implicitly constructed that copies the string into native memory. Here's the relevant bits of EffectHandle:
        EffectHandle::EffectHandle( String^ name )
        {
                m_StringData = Marshal::StringToHGlobalAnsi( name );
                m_HasString = true;
                m_StringDataSize = name->Length;
                GC::AddMemoryPressure( m_StringDataSize );

                m_Handle = reinterpret_cast<D3DXHANDLE>( m_StringData.ToPointer() );
        }

//Called by both ~EffectHandle and !EffectHandle.
        void EffectHandle::Destruct()
        {
                if( m_HasString )
                {
                        Marshal::FreeHGlobal( m_StringData );
                        GC::RemoveMemoryPressure( m_StringDataSize );
                }
        }









So. Do you see where we screwed this up?

In case it's not clear:
* EffectHandle::InternalHandle returns EffectHandle::m_Handle
* D3DXHANDLE is a typedef for char*
* Although there's plenty of interop, the interop is NOT the root cause.

HINT: EffectHandle is finalizable. Answer is in comments.





















Comments: 12 - Leave a Comment

Link



Tuesday, September 29, 2009


Comments: 0 - Leave a Comment

Link



Thursday, September 24, 2009
I promised this a long time ago, and here it is. I prefer to let the video speak for itself. This is a demo from January, so it’s actually a much older iteration of what we’ve got now.
Link!

Comments: 2 - Leave a Comment

Link



Friday, September 18, 2009
Link

I'll concede it doesn't look like much, but honestly, the game is really addictive and fun. And it's a dollar.

One of the technologies in this is the binaural audio system that I discussed earlier. On the above page, there's a linked video -- put on headphones and watch it. You'll get the point very quickly. It's even better in-game than in the video, was my experience.

There's also the animation system, which is not really shown off that well here, but it's procedurally constructed, like NaturalMotion (but better, we believe). At no point were any animations build in a modeler. It's all done dynamically using relatively simple rules. The future games will leverage this tech more heavily, but at least as developers I think you can appreciate how awesome that is. The flying, the hits -- it's all physics based.

Did I mention it's a dollar? Try it out. And if you do try it out, please take the time to write an honest (and hopefully positive!) review. It'll go a long way for us if you do.



Comments: 3 - Leave a Comment

Link



Friday, August 21, 2009
This post is a late copy from Ventspace.

Just to be clear, I'm restricting my comments to the DirectX section of the codepack. I'll probably be integrating some of the other bits (jump list support etc) into SlimTune, so we'll see how that goes later. But around a week ago, they finally released 1.0. Same day as Windows 7 was out on MSDN actually -- I'm pretty sure that's not a coincidence. SlimDX's release with DX 11, Direct2D, and DirectWrite should come later this month, if all goes well. Now, the code pack does cover a few things we don't, like the Windows Imaging Component.

So it's not beta anymore. Now, I'm fairly sure that they haven't looked at our code for legal reasons, but I did make some harsh comments about their work. They've made some changes that seem to follow directly from those comments. I'm about to make some more. I've been perusing the release and frankly, it's just not any good. They seem to have spent most of their time implementing equally shoddy support for D3D 10 than fixing the actual problems. I'm going to run through all the reasons I see that this thing is not well done.

Okay, so they added a math library. I very pointedly slammed them for not having one in the 0.90 release, so let's start with the bread and butter of graphics -- Vector3F, as it's called in the Code Pack. It offers X, Y, Z, Normalize, NormalizeInPlace, static Dot, static Cross, operator +, operator -, and (in)equality comparisons. Yes, that's the entire class. No ref overloads, which are important for performance. No other helper methods of any kind. No PropertyGrid or System.ComponentModel compatibility. Matrix is even sadder -- it has operator * (by-value only) and Identity. That's it. Compare to ours, or XNA.

Functions that return object references still create brand new instances, which then not only have to be garbage collected, but if you don't remember to Dispose them, they'll be queued for finalization too. (These USED to be properties...it's an improvement, I guess.) This is a similar effect to the original MDX's event problems, just smeared out over time and difficult to track. There's certainly no leak tracking functionality like SlimDX has. (OTOH they will be released eventually, which SlimDX does not promise.) These are lots of small allocations, which the .NET GC is good at handling, but if you don't remember to Dispose them, or have a lot of them in general, this could really sour your day. It's a problem that just doesn't exist in SlimDX.

As for 64 bit support, it's simply not configured at all in the solution (remember, the code pack is source code only, no binaries). I set up and ran an x64 build that went off without a hitch, and there's no inherent reason for x64 to not work. I haven't tested it though, and neither has anyone else apparently.

Lastly, even though they've added D3D 10 support, there's no D3DX support in here at all. They basically invite you to go ahead and write what you need yourself, but none of it is done for you. For something that's intended to make your job easier by letting you use managed code, this is another odd omission.

The 1.0 of the code pack IS dramatically improved in several respects -- 0.90 had no math code at all, the memory situation was far worse, etc. Even so, this really doesn't inspire a lot of confidence. Although the core APIs are wrapped, the support code is basically non-existent. There's no binary distribution or redistributable, so you're on your own there. I know this is probably a small team at Microsoft with nowhere near the level of resources it needs, and I'm sorry that I'm continually trashing your work. But if this is what constitutes the successor to Managed DirectX, I don't think SlimDX is in any danger and I can't say I mind.

Comments: 1 - Leave a Comment

Link


All times are ET (US)

 
S
M
T
W
T
F
S
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

OPTIONS
Track this Journal

 RSS 

ARCHIVES
October, 2009
September, 2009
August, 2009
July, 2009
June, 2009
October, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
February, 2007