ComPtr<ID3DBlob> ReadToBlob()
{
ComPtr<ID3DBlob> blob;
D3DCreateBlob(file_size_, blob.GetAddressOf());
stream_.read(reinterpret_cast<char*>(blob->GetBufferPointer()), blob->GetBufferSize());
return blob;
}
```Is there anything wrong with this?
I'm trying to read a shader bytecode (`.cso`) file into a blob to pass to the pso, but it complains that "Encoded Vertex Shader size doesn't match specified size"
#Reading a .cso (shader bytecode) file into an ID3DBlob
46 messages · Page 1 of 1 (latest)
When your question is answered use !solved to mark the question as resolved.
Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.
you wanna check whether reading actuality succeeds
then you'll notice that it doesn't
because you opened the file with ate mode and didn't rewind it
https://pastebin.com/ANqFV3fb
same error again
This loads the vertex shader correctly:cpp D3DReadFileToBlob(L"Default_vs.cso", vertex_shader_.GetAddressOf()); This doesn't :/```cpp
{
ScopedFileReader vs_reader("Default_vs.cso");
vertex_shader_ = vs_reader.ReadToBlob();
}
"Encoded vertex shader size doesn't match specified size"
What is the "specified size"? vertex_shader_->GetBufferSize()?
did you remember to open the stream in binary mode?
ah you posted the whole code, and you did
@visual mason can we see the CreateVertexShader calls etc. that fail?
also, if you think the problem is in your code reading the file -- compare the data in the blob you read and the one D3DReadFileToBlob read
bool comp_blobs(ID3DBlob* blob1, ID3DBlob* blob2)
{
void* data1 = blob1->GetBufferPointer();
void* data2 = blob2->GetBufferPointer();
size_t size1 = blob1->GetBufferSize();
size_t size2 = blob2->GetBufferSize();
if (size1 != size2) { return false; }
auto bytes1 = static_cast<unsigned char const*>(data1);
auto bytes2 = static_cast<unsigned char const*>(data2);
for (size_t i = 0; i < size1; ++i) {
if (bytes1[i] != bytes2[i]) {
return false;
}
}
return true;
}
```This returned false
The problem's with the reader :/
Seems the problem was the ScopedFileLock class
Locking a file and reading from it causes corruption
no, it just locks the file. you're not accessing the file through the handle you locked, you're not gonna be able to access the file through any other handle until you unlock it. that's what locking a file does ^^
Ohhh
That makes so much sense
Is there a way to make an ifstream with the locked handle?
why do you need to lock it anyways?
Apparently MS' fstream has non-standard constructors, so you can construct one from a FILE*, and there are more MS specific functions you can use to get a FILE* for a HANDLE 😛
https://stackoverflow.com/a/476014
Stack Overflow
Is there any way to take advantage of the file creation flags in the Win32 API such as FILE_FLAG_DELETE_ON_CLOSE or FILE_FLAG_WRITE_THROUGH as described here http://msdn.microsoft.com/en-us/library/
just ReadFile instead of using streams when you're already using win32 anyways
or just don't lock the file ^^
but streams are so nice :^)
they're just calling read on it once xD
For safety
This might be dumb, im not sure, but I was thinking of doing something like this:```cpp
struct Asset {
static void Init() {
// initialize the stream and lock the handle
}
static void Destroy() {
// destroy the stream object and release the handle
}
static Asset& get(int id) {
// read the file to get the asset at this id
}
private:
static std::ifstream stream_;
static HANDLE handle_;
}
I want to be sure that I get the same result from Asset::get(21923) for every call
why do you need to prevent the user from modifying the file while it's in use?
you just read it once no?
what about it?
Do you think its a good idea to load gigabytes worth of assets into the ram when all of it isn't needed immediately?
ofc not
i think that
- if the user modifies the file of your game while it's running, that's on them, and
- you're already opening the file with read sharing only, so no one else can write to the file while you've got it open anyways
so locking the file in addition to the rest is already kinda redundant
as i said, just use your already opened file handle to just ReadFile the contents
you're already using the win32 api there
no point in mixing that with iostream