Yeah, that E_FAIL is returned by BeginPass because it's catching the exception that is thrown in Device::VertexShader::set (device.cpp, line 534). Thanks for looking into it! If you need any info or something else, please let me know.
Any clue why this pointer->Release() is causing problems?
Cheers
Heiko
[SlimDX] Device.VertexShader setter fails...
Okay, well I found the cause of that crash (bit of a misunderstanding between us and D3D), but there's another crash, also in EffectStateManager, that I don't understand yet. I'm still working on fixing that.
Here's the thing though -- you guys aren't using the state manager. Your implementation is just a stub. All you really have to do is comment out line 415 in JEffect.cs and Jad will run. In fact, I'm fairly sure this is the first time Jad's ever run on SlimDX
[EDIT] To be perfectly honest, this isn't going well. I have no idea why the EffectStateManager crashes the way it does, and even when I put in hacks to prevent the crash, it still doesn't render correctly.
[Edited by - Promit on July 29, 2008 4:04:14 PM]
Here's the thing though -- you guys aren't using the state manager. Your implementation is just a stub. All you really have to do is comment out line 415 in JEffect.cs and Jad will run. In fact, I'm fairly sure this is the first time Jad's ever run on SlimDX
[EDIT] To be perfectly honest, this isn't going well. I have no idea why the EffectStateManager crashes the way it does, and even when I put in hacks to prevent the crash, it still doesn't render correctly.
[Edited by - Promit on July 29, 2008 4:04:14 PM]
Oh my goodness! Promit, I'll build you a shrine!!! :D
The pic you've posted looks like something is wrong with the texture coordinates, could be that I did a mistake while porting it from pointer arithmetic to the DataStream thing, I'll check that again.
Thanks a ton for dealing with that so far!
The pic you've posted looks like something is wrong with the texture coordinates, could be that I did a mistake while porting it from pointer arithmetic to the DataStream thing, I'll check that again.
Thanks a ton for dealing with that so far!
I saw a number of bugs or odd things just skimming through the code, you should definitely run through all the tutorials and make sure they run, and do it with D3D debugging turned on. For example, I noticed that you're creating your VBs wrong in some places. MDX took a vertex format and vertex count; SlimDX takes a byte count. That definitely failed at least one sample, which was trying to create a 4 byte VB. And in the shot above, it looks like it's using clamp for texture addressing mode instead of wrap.
Hey there,
I finally found out what is causing this strange artifact in Promits screenshot. Indeed the reason why the texture looks strange is that its texture address sampler states are set to clamp.
But this is only from the second frame on, the texture address states are set to Wrap in the first frame actually. I discovered that the engine's state manager is saving the sampler states it has set in a cache and if the state to be set equals to the state that was set last, it will do nothing.
The question is why that worked with MDX, and why it doesn't with SlimDX. What is SlimDX doing differently? Do the states get reset after a call to Present or something like that?
I turned the state manager caching completely off, and it worked as expected (the texture was repeated in U and V direction), but then DirectX threw a ton of Ignoring already set sampler state warnings on me.
Is there a "right" way with SlimDX to know when I should set the state and when I can skip it?
Any help is very much appreciated.
I finally found out what is causing this strange artifact in Promits screenshot. Indeed the reason why the texture looks strange is that its texture address sampler states are set to clamp.
But this is only from the second frame on, the texture address states are set to Wrap in the first frame actually. I discovered that the engine's state manager is saving the sampler states it has set in a cache and if the state to be set equals to the state that was set last, it will do nothing.
The question is why that worked with MDX, and why it doesn't with SlimDX. What is SlimDX doing differently? Do the states get reset after a call to Present or something like that?
I turned the state manager caching completely off, and it worked as expected (the texture was repeated in U and V direction), but then DirectX threw a ton of Ignoring already set sampler state warnings on me.
Is there a "right" way with SlimDX to know when I should set the state and when I can skip it?
Any help is very much appreciated.
We aren't doing anything special with render states to cache them, or indeed even mess with them at all. If anything, it's MDX that was doing something under the hood. I'm afraid we're going to need more information to figure this one out.
As a side note, anything that happens in DirectX should happen in SlimDX as well. Therefore, if you want to test whether a certain issue is a bug in SlimDX, the most bullet-proof way is to implement a test case in DirectX using C++, and see if it exhibits the same problem.
As a side note, anything that happens in DirectX should happen in SlimDX as well. Therefore, if you want to test whether a certain issue is a bug in SlimDX, the most bullet-proof way is to implement a test case in DirectX using C++, and see if it exhibits the same problem.
Well, I wouldn't entirely discount the object table caching from doing strange things in some circumstances. I'm not sure that's at all the case here, but I wouldn't bet my life on that code being bulletproof yet, either.
I localized the problem to be an effect that sets the address modes to clamp, and then I found this in the engine code:
Ok, this was fixed easily and I just thought it slipped in there somehow, but what then hit me really hard was the fact that this line was already in the 1.1 release of Jade and that it worked nonetheless ... maybe MDX was doing some "I don't care what you want" state resetting behind the scenes... never mind.
Thanks for your time guys!
DXResource.Begin(FX.DoNotSaveState)
Ok, this was fixed easily and I just thought it slipped in there somehow, but what then hit me really hard was the fact that this line was already in the 1.1 release of Jade and that it worked nonetheless ... maybe MDX was doing some "I don't care what you want" state resetting behind the scenes... never mind.
Thanks for your time guys!
I think maybe that the state manager you had was less clever than the D3DX one, so when combined with that flag, it worked okay. When you switched back to the D3DX default, it enabled the more complex logic which, combined with the DoNotSaveState flag, broke it.
Just a guess, though.
Just a guess, though.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement