#Reading a .cso (shader bytecode) file into an ID3DBlob

46 messages · Page 1 of 1 (latest)

visual mason
#
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"
weak orioleBOT
#

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.

visual mason
#

_stream is an std::ifstream

#

file_size_ = std::filesystem::file_size(path)

snow stirrup
#

how do you open your stream?

#

what's the actual problem?

visual mason
#

line 61

snow stirrup
#

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

visual mason
#

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()?

viral stream
#

did you remember to open the stream in binary mode?

viral stream
#

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

visual mason
# viral stream also, if you think the problem is in your code reading the file -- compare the d...
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 :/

visual mason
#

Seems the problem was the ScopedFileLock class

#

Locking a file and reading from it causes corruption

snow stirrup
visual mason
#

Ohhh

#

That makes so much sense

#

Is there a way to make an ifstream with the locked handle?

snow stirrup
#

why do you need to lock it anyways?

viral stream
snow stirrup
#

just ReadFile instead of using streams when you're already using win32 anyways

#

or just don't lock the file ^^

viral stream
#

but streams are so nice :^)

snow stirrup
#

they're just calling read on it once xD

visual mason
# snow stirrup why do you need to lock it anyways?

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

snow stirrup
#

why do you need to prevent the user from modifying the file while it's in use?

#

you just read it once no?

visual mason
#

What if this file is really big

#

like gigabytes

snow stirrup
#

what about it?

visual mason
#

Do you think its a good idea to load gigabytes worth of assets into the ram when all of it isn't needed immediately?

snow stirrup
#

ofc not

#

i think that

  1. if the user modifies the file of your game while it's running, that's on them, and
  2. 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