huh, are your drivers up to date?
#Fwog and co.
long robin
robust bough
huh, are your drivers up to date?
yeah
i literally just updated them
(hoping it would fix this)
long robin
did you set glDebugMessageCallback to make sure you didn't do an oopsie
robust bough
did you set glDebugMessageCallback to make sure you didn't do an oopsie
Yes
long robin
I'm on windows 10 with AMD
strange that it works on mine though. usually it's the other way around
robust bough
lel
golden schooner
i was on lunix (nvidia 560.35) replaying this, i would get a black screen
robust bough
I've never experienced something like this in my life 
golden schooner
John is telling you to switch to Vulkan
golden schooner
alternatively, John Vuk has a product to sell too
btw
did you make use of the buffer?
robust bough
but seriously, i dont understand this problem lel
golden schooner
other than just accessing .length?
golden schooner
how did you init glfw?
robust bough
very carefully
golden schooner
wrong answer
robust bough
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
handle = glfwCreateWindow(width, height, title.data(), nullptr, nullptr);```like this?
glEnable(GL_DEBUG_OUTPUT);
glDebugMessageCallback(OpenglErrorCallback, nullptr);
glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS);
glDebugMessageControl(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, nullptr, GL_TRUE);```there is a glfw hint
golden schooner
what did you do
robust bough
we're so back
golden schooner
did you just reboot?
robust bough
no i literally just used it again
golden schooner
make sure you didnt leave the > 0 or == 0 in the .fs 😛
robust bough
void main()
{
vec4 zero = planet_transforms[0][0];
if (planet_transforms.length() > 0) {
o_colour = vec4(vec3(zero.x, 1.0f, 1.0f), 1.0f);
} else {
o_colour = vec4(vec3(0.0f), 1.0f);
}
}```this works
golden schooner
ah
robust bough
void main()
{
vec4 zero = planet_transforms[0][0];
if (planet_transforms.length() > 0) {
o_colour = vec4(vec3(1.0f, 1.0f, 1.0f), 1.0f);
} else {
o_colour = vec4(vec3(0.0f), 1.0f);
}
}```this doesn't
golden schooner
so you are acessing the buffer now
golden schooner
thats surely John Fucked
golden schooner
yeah the 2nd doesnt work
robust bough
works if i access it inside the if as well
golden schooner
because zero is not contributing to anything
robust bough
except it's a length check
which is reasonable
smh
thank you deccer
without your help it would've been jover
back to planet rendering
(i have some ideas)
||they're all bad||
golden schooner
better not be a dead project like the minecraft clone thing 😛
robust bough
I prefer "Discountinued until further notice"
dire badge
What was .length() in GLSL? Array length?
dire badge
Ah, it was glm::vec3 v; v.length() which returned 3 / dimension
robust bough
I can't find much documentation on doing 2d texture arrays
Is it possible to create a 2d sampler array with textures that are different sizes?
robust bough
no
is this because of opengl?
I'm searching around and I'm finding different answers
long robin
is this because of opengl?
yes, and it's how the hardware works
robust bough
fair enough
long robin
You can use bindless textures if you need different sizes, but make sure you use nonuniformEXT if you do
robust bough
You can use bindless textures if you need different sizes, but make sure you use...
eh, im not sure i "need" it
just that now I have to figure out a way to go about doing this
but, now this is no longer a fwog problem 
thanks for the response @long robin
robust bough
I think I might be doing something wrong here, but I'm not sure
const auto vertex_position_descriptor = Fwog::VertexInputBindingDescription{
.location = 0,
.binding = 0,
.format = Fwog::Format::R32G32B32_FLOAT,
.offset = 0,
};
const auto vertex_uv_descriptor = Fwog::VertexInputBindingDescription {
.location = 1,
.binding = 0,
.format = Fwog::Format::R32G32_FLOAT,
.offset = 12
};
const auto vertex_descriptors = {vertex_position_descriptor, vertex_uv_descriptor};
return Fwog::GraphicsPipeline{{
.name = "Planet Render Pipeline",
.vertexShader = &vertexShader,
.fragmentShader = &fragmentShader,
.inputAssemblyState = {.topology = Fwog::PrimitiveTopology::TRIANGLE_LIST},
.vertexInputState = {vertex_descriptors},
.rasterizationState = {
.polygonMode = Fwog::PolygonMode::LINE,
.cullMode = Fwog::CullMode::NONE,
},
.depthState = {
.depthTestEnable = true,
.depthWriteEnable = true,
.depthCompareOp = Fwog::CompareOp::LESS_OR_EQUAL,
}
}};```
I'm getting a relative offset of 0
is this expected behaviour?
long robin
I think I might be doing something wrong here, but I'm not sure
```cpp
const...
Can you show the Cmd::BindVertexBuffer call
fiery sorrel
imagine reverse fwog
A vulkan wrapper that uses ogl style global state
is fwog still alive thats awesome
long robin
is fwog still alive thats awesome
it's in maintenance mode
the last time I added a feature it was experimental vcc support lol
long robin
I implemented all the features I want it to have
I mean there is still one "kinda" major bug but so far it hasn't affected anyone yet 
robust bough
@long robin I was looking at some raw opengl code, and I would just like to say thank you for making fwog 
fiery sorrel
fwog made me appreciate vulkan more too its nice. I wanna try vuk
robust bough
Is there someway I can copy a texture array to another texture array?
I'm trying to do cpp Fwog::Texture heightmaps = Fwog::Texture(Fwog::TextureCreateInfo { .imageType = Fwog::ImageType::TEX_2D_ARRAY, .format = Fwog::Format::R32G32B32A32_FLOAT, .extent = {256, 256, 1}, .mipLevels = 1, .arrayLayers = static_cast<std::uint32_t>(1), });;
void ris::renderer::update_heightmap_texture_depth(int depth) {
auto new_heightmap = Fwog::Texture(Fwog::TextureCreateInfo {
.imageType = Fwog::ImageType::TEX_2D_ARRAY,
.format = Fwog::Format::R32G32B32A32_FLOAT,
.extent = {256, 256, 1},
.mipLevels = 1,
.arrayLayers = static_cast<std::uint32_t>(depth),
});
Fwog::CopyTexture({
.source = heightmaps,
.target = new_heightmap,
.extent = heightmaps.GetCreateInfo().extent,
});
std::swap(heightmaps, new_heightmap);
}```but I get OpenGL Debug message (1280): GL_INVALID_ENUM error generated. <srcTarget> or <dstTarget> is not a valid texture target.
maybe im doing this the wrong way?
long robin
It's probably a bug on my end. I'll try to replicate it
long robin
I think I found the issue
@robust bough try pulling from main. your code no longer errors for me
glCopyImageSubData makes you specify the texture target in addition to the texture name even though all textures are under one namespace 😩
tired sandal
is there a requirement for the order of binding operations?
Precisely BindGraphicsPipeline?
Fwog::Render(rt_info, [this](){
Fwog::Cmd::BindGraphicsPipeline(*triangle_pipeline);
Fwog::Cmd::BindVertexBuffer(0, *triangle_buffer, 0, sizeof(vtx));
Fwog::Cmd::BindIndexBuffer(*triangle_indices, Fwog::IndexType::UNSIGNED_INT);
Fwog::Cmd::Draw(3, 1, 0, 0);
});
I get an error when BindGraphicsPipeline is not the first command here
I.e. When Do it Like this:
Fwog::Render(rt_info, [this](){
Fwog::Cmd::BindVertexBuffer(0, *triangle_buffer, 0, sizeof(vtx));
Fwog::Cmd::BindIndexBuffer(*triangle_indices, Fwog::IndexType::UNSIGNED_INT);
Fwog::Cmd::BindGraphicsPipeline(*triangle_pipeline);
Fwog::Cmd::Draw(3, 1, 0, 0);
});
I get this:
[14:26:31][ERROR]GL_INVALID_OPERATION in glVertexArrayElementBuffer(zero is not valid vaobj name in a core profile context)
long robin
I'm trying to think of what would cause this
ok I see. BindGraphicsPipeline creates or sets the current vertex array, and BindIndexBuffer modifies it
so yes, it is order-dependent, and ideally it shouldn't be
to fix it would require quite a bit of work to defer state-setting, so my official recommendation is to always bind the pipeline first
tired sandal
I guess you could do something like this?
Fwog::Render(info, [](Fwog::State& state){
state.BindGraphicsPipeline(...);
state.BindSampledImage(...);
state.PushDrawCommand(...);
state.BindGraphicsPipeline(...);
state.PushDrawCommand(...);
});
or smth like that. But that would deviate a bit too much i guess and overkill, since you would need to save 128 image states 
long robin
yeah exactly, I would have to make a software command list (it could be under the current API)
and although it would make the API slightly nicer to use (no more order issues), it would be a substantial chunk of work and degrade the debugging experience
heavy cipher
you don't need to make a soft cmd list, you can just maintain state yourself and patch the ogl state
long robin
wym
how would that remedy the situation where BindIndexBuffer is called before BindGraphicsPipeline (and thus no VAO exists)?
I guess I could save the index/whatever buffer bindings somewhere and then set them when a draw call is issued
heavy cipher
that is what i meant, yes
long robin
I guess there isn't that much state which can have that problem (just index buffer, vertex buffers, and resource bindings)
heavy cipher
thats mostly what i track in vuk as well
tired sandal
template<typename T>
Microsoft::WRL::ComPtr<ID3D11Buffer> create_vertex_buffer(ID3D11Device* device, std::span<T> data, bool srv) {
Microsoft::WRL::ComPtr<ID3D11Buffer> buff;
D3D11_BUFFER_DESC vertex_buffer_desc;
vertex_buffer_desc.Usage = D3D11_USAGE_IMMUTABLE;
vertex_buffer_desc.BindFlags = D3D11_BIND_VERTEX_BUFFER | UINT(srv ? D3D11_BIND_SHADER_RESOURCE : 0);
vertex_buffer_desc.StructureByteStride = sizeof(T);
vertex_buffer_desc.MiscFlags = D3D11_RESOURCE_MISC_BUFFER_ALLOW_RAW_VIEWS;
vertex_buffer_desc.ByteWidth = UINT(data.size_bytes());
D3D11_SUBRESOURCE_DATA vertex_buffer_data{};
vertex_buffer_data.pSysMem = data.data();
device->CreateBuffer(&vertex_buffer_desc, &vertex_buffer_data, &buff);
return buff;
}
template<typename T>
Fwog::Buffer create_vertex_buffer(std::span<const T> data) requires std::is_trivially_copyable<T>::value {
return Fwog::Buffer(data);
}
tired sandal
Fwog::Buffer constructor triggers Asan 
long robin
which line?
tired sandal
malloc(): invalid size (unsorted)
its not the span i pass in, since it's just a std::vector
long robin
huh
tired sandal
its actually not ubsan, its just a crash lol
uh, how do i check whether glad loaded everything correctly? 
nope, doesn't seem to be glad either
an earlier buffer creation works lol
idk how that helps
long robin
I'm only able to watch 4 seconds of that video before discord gives up, wtf
oh wow, vlc doesn't like it either. random green flickering after the 4 second mark
long robin
@tired sandal does your app otherwise work?
I'm wondering if the span you pass to Fwog::Buffer is being interpreted as the type you want to upload rather than the thing in the span
you could use a TypedBuffer to be safer
tired sandal
Will try. Maybe TriviallyCopyableByteSpan is the culprit? maybe make the const void* overload public?
long robin
I wanted to avoid making the unsafe function public
sequence containers should be implicitly convertible to TriviallyCopyableByteSpan btw. in other words, you should be able to do
auto buffer = Fwog::Buffer(someVectorOfStuff);
that's how it works in the triangle example, but maybe that's only because it uses std::array
hmm, indeed in the scene loader I'm doing this
.vertexBuffer = Fwog::Buffer(std::span(mesh.vertices)),
.indexBuffer = Fwog::Buffer(std::span(mesh.indices)),
TypedBuffer has the same issue
long robin
maybe asan is trippin
robust bough
@tired sandal is your code open source?
tired sandal
its not asan, its a straight crash
long robin
oh
robust bough
btw jaker you were right
i only liked opengl because I hadn't properly used something else
tired sandal
no one really likes opengl. Its just a meme that its easy
long robin
the comfort of familiarity
robust bough
just the validation layers are enough of a reason to go with vulkan
long robin
ok, I was finally able to view that video by re-encoding it
I wonder if that block of mesh processing just before the crash has anything to do with it
does it crash if you have just one room?
tired sandal
Uh. one room works.
two rooms fuck it up
long robin
huh, but you ran with the sanitizers and didn't have any issues before the line where you create the buffer?
because my guess would've been that you did a UB somewhere
tired sandal
omg i have a typo
nvm. Fwog works correctly
line 146 and 144 in the video. maybe you spot it
long robin
were they supposed to be room_{vertices, indices}.size() + ...?
digital lion
what do you think about making ColorBlendAttachmentState part of RenderColorAttachment?
long robin
I could, but then it wouldn't reflect vulkan
if I ever get around to unfucking the state tracker, I could add more dynamic state
but fwog does allow you to call raw gl commands as long as you later call InvalidatePipelineState()
digital lion
Ok so it doesnt sound like there'd be any immediate disadvantages. I was looking at how fwog does as an inspiration for my own
I'll try it out and let you know if I find anything bad about it
long robin
btw, are you switching to C++ or something? I'm curious about why you're trying fwog
nvm, reading comprehension failure
I was looking at how fwog does as an inspiration for my own
tired sandal