I missed that function the last time I went through the documentation. Since it takes a blob, however, we'd still need to perform much the same 'extra work' that causes FromStream to be inefficient.
We would have to call the native method, and then stream the data out of the blob and into the stream passed as a parameter to ToStream. I don't know how the native method is implemented, but chances are it does a lock and a read of all the suitable data -- so we'll end up reading and writing the entire texture twice, plus whatever overhead is involved in converting the texture data to the appropriate format.
I don't like the stream-related methods we have at all because of their hidden performance implications, but since there is a native mechanism to call which does provide extra functionality you can't easily get from manually locking, I could probably be convinced to implement it.
[SlimDX] Write textures to disk
Author
well, if you get around to do that, great, otherwise I fully understand and if needed I can work around on my side...
Again, thanks for the great support you guys are giving
Marcel
Again, thanks for the great support you guys are giving
Marcel
I'll take a look at it this evening. I am concerned there might be even more overhead involved in getting the native memory into the managed stream, but we'll see.
Author
Heya,
updated my code with the latest revision 653 and 32bit compiles ok, when I try to compile 64bit I get the following error:
Error 4 error LNK2020: unresolved token (0600081B) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 5 error LNK2020: unresolved token (0600081C) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 6 error LNK2020: unresolved token (0600081D) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 7 error LNK2020: unresolved token (0600081E) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 8 error LNK2020: unresolved token (0600081F) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 9 error LNK2020: unresolved token (06000822) SlimDX.Direct3D9.StateBlock::Apply Device.obj SlimDX
Error 10 error LNK2020: unresolved token (06000823) SlimDX.Direct3D9.StateBlock::Capture Device.obj SlimDX
Error 11 error LNK2020: unresolved token (06000824) SlimDX.Direct3D9.StateBlock::get_Device Device.obj SlimDX
updated my code with the latest revision 653 and 32bit compiles ok, when I try to compile 64bit I get the following error:
Error 4 error LNK2020: unresolved token (0600081B) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 5 error LNK2020: unresolved token (0600081C) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 6 error LNK2020: unresolved token (0600081D) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 7 error LNK2020: unresolved token (0600081E) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 8 error LNK2020: unresolved token (0600081F) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 9 error LNK2020: unresolved token (06000822) SlimDX.Direct3D9.StateBlock::Apply Device.obj SlimDX
Error 10 error LNK2020: unresolved token (06000823) SlimDX.Direct3D9.StateBlock::Capture Device.obj SlimDX
Error 11 error LNK2020: unresolved token (06000824) SlimDX.Direct3D9.StateBlock::get_Device Device.obj SlimDX
Clean your solution (entirely, manually, by removing all the build output directories by hand). A number of the configuration output directories (particularly for publish) ended up stepping on each other, causing nastiness if you tried to do a full SlimDX build from the command-line. So I moved them, and this caused similar errors until I manually blew away every bit of intermediate crud on the machine.
You also might want to right-click the Direct3D 10 Stateblock.cpp, select Properties, and under C++ -> Outputs make sure it has an overloaded intermediate file name (something like $(IntDir)/$(InputName)2.obj). VS can't do this automatically, which is exceedingly annoying.
EDIT: Poking in the .vcproj for 653 looks like the Release|x64 and Public|x64 configurations are not included in the handling for intermediate file renaming by the tool I wrote, so performing the above tweak should fix you.
Sometimes I wish I didn't volunteer to work on the build system. :\ I'll fix the generator tool when I get home tonight.
You also might want to right-click the Direct3D 10 Stateblock.cpp, select Properties, and under C++ -> Outputs make sure it has an overloaded intermediate file name (something like $(IntDir)/$(InputName)2.obj). VS can't do this automatically, which is exceedingly annoying.
EDIT: Poking in the .vcproj for 653 looks like the Release|x64 and Public|x64 configurations are not included in the handling for intermediate file renaming by the tool I wrote, so performing the above tweak should fix you.
Sometimes I wish I didn't volunteer to work on the build system. :\ I'll fix the generator tool when I get home tonight.
Author
kk, that worked, only getting one warning now, not sure that is important:
Warning 2 warning C4018: '<' : signed/unsigned mismatch c:\Program Files\SlimDX\Source\source\direct3d10\Texture.cpp 93 SlimDX
Warning 2 warning C4018: '<' : signed/unsigned mismatch c:\Program Files\SlimDX\Source\source\direct3d10\Texture.cpp 93 SlimDX
Author
ok, saw what this is refering to, doesn't seem to be a problem.
I did find a small spelling error though:
static bool ToStream( Texture^ teture, ImageFileFormat format, System::IO::Stream^ stream );
should be
static bool ToStream( Texture^ texture, ImageFileFormat format, System::IO::Stream^ stream );
texture instead of teture
I did find a small spelling error though:
static bool ToStream( Texture^ teture, ImageFileFormat format, System::IO::Stream^ stream );
should be
static bool ToStream( Texture^ texture, ImageFileFormat format, System::IO::Stream^ stream );
texture instead of teture
Quote:Original post by jpetrieYou also might want to right-click the Direct3D 10 Stateblock.cpp, select Properties, and under C++ -> Outputs make sure it has an overloaded intermediate file name (something like $(IntDir)/$(InputName)2.obj). VS can't do this automatically, which is exceedingly annoying.
VS can do this automatically, and usually does. For some reason it forgets to do this every once in a while, causing us headaches like this.
Quote:ok, saw what this is refering to, doesn't seem to be a problem.
Even though it may never be a problem, we make it a point to clear up every warning.
Quote:I did find a small spelling error though:
static bool ToStream( Texture^ teture, ImageFileFormat format, System::IO::Stream^ stream );
should be
static bool ToStream( Texture^ texture, ImageFileFormat format, System::IO::Stream^ stream );
texture instead of teture
OK, we'll be sure to fix that up. FxCop most likely would have caught that anyway.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
