#Fwog and co.
1 messages Β· Page 18 of 1
the blue orange pink purple thing is mine and the red sky stuff i dont rember where i got hat from
thank you! I can save all of these just for my own uses too :)
I just use a long y texture strip for cubemaps
Wonder if other layouts are better
i love this eye majeek stuff
yay
I have it toggleable too
so on the page it can show both. Off by default :D
now I can backport it to Alberquerque as a template lol
how tf did deccer manage to build deccer in 1 hour
it's taking half that long to just download deps
now it's been compiling for 15 minutes with no sign of slowing down
it finally finished with apparently no errors
oh that was just the deps 
blender puts the build files in the parent folder of the git root directory 
deccer cmake?
i have no idea what that is
I'm building blender
ooh
it's very "and co."-related
I forgot to delete the Deccer Cube models in Fwog Cmake Template so imma do that
Once opened it's very important the following steps are taken:
In the solution explorer find the INSTALL project, right click it and select 'Build' this will copy all the required files the the blender output folder. NOTE: This needs to be done atleast once for every solution configuration, ie: if you switch from Debug to Release configuration you need to redo this step.
where
ah, it's in CMakePredefinedTargets
was pretty easy to build, just took a while
didn't have to change my python install or anything π
idk where they load gltf though
wtf this version of blender doesn't even have gltf support
wtf
I made a post in the blender discord begging for help, so we'll see
Barely anyone posts in the coding channel so eh
maybe theres an irc if you had no luck?
Nano seems to post there, so I pray he sees
Yeah the official modes of communication aren't even discord
But I don't want to sign up for a discourse account or whatever (yet)
or you also use them in your example π
the gltf is a separate plugin as i mentioned in my #1019740157798273024 message
building blender was total waste of time π
albeit a not a unpleasant experience
with having to install this and that and config this and that first
: )
the plugins also has tons of weird comments π but im not complaining about it
made by volunteers
so I guess I need to edit this
https://github.com/KhronosGroup/glTF-Blender-IO
how might I go about invoking gltfpack from python in a platform-agnostic way, I wonder
I plan on having the deccer cube example be like a different Project so it can also act as an example of how the same Project.Library can allow more than one Project
I could just ship windows and linux binaries, then conditionally call those with subprocess.run π³
but i dont wanna do Deccers Cube (Fwog Version) rn because I gotta plan out the architecture if I wanna do it without using that SceneManager example and wanting to do it blind with either fastgltf or cgltf or tinygltf
altho i guess i can try a naive one since all I need is the vertices and transforms
actually thats a good suggestion. I was already thinking of a separate Project example in the Fwog Template that refactors the structs into classes (and hence separate cpp and h files) (I kept it in same .h file to keep it 'in the spirit' of the Fwog Examples originally and will keep that as a defualt example)
but now I can also have Deccer Cube inside there too good point
hmm I'm too much of a python noob to do this properly
I don't know the correct way to ship a python script that needs to invoke another executable that it also shipped with
using python to parse gltf π
it's no surprise that it takes like 2 minutes to import the bistro
i believe python has a process class of sorts you can invoke and just call gltfpack from it
and i was also wondering that you can have some of the gltfpack options show up as checkboxes
which influence the params of the process call then
that's exactly what I wanted to do
same here π
except I dunno how to package gltfpack
more like medlenno
is gltfpack part of the vulkansdk by any chance?
or some other "pack" one can "install"
||can we get peter here to explain the joke||
otherwise, perhaps have a config file or blender setting somehoe where you specify the gltfpack path
hmm i'd think deccer is multilingual enough to stand in for peter
seems like not
that peter thing is currently flying over my head
ah, that's unrelated to the joke (which I do not get) 
it's part of meshopt
meshopt is part of gltfpack i sink
deccer doin a brb to learn the language
perhaps
they are one and the sameβ’οΈ
I would if I didn't have to explain that peter thing
π
but now I'm forced to learn how to ship gltfpack with a python script (how)
"bistro" means fast (or faster) in russian, the legend says that when russian troops sacked Paris they were demanding fast service and thats where the name came from - and "medlenno" means slow
you rewrite the whole thing in python

you know, I'd actually rather rewrite the whole thing to just call fastgltf or something
so it's not so painfully slow
it likely doesn't matter
but for now I just want to invoke gltfpack to make my life easier
all the python CPU overhead will be far more anyways
well if the entire import function just invoked someOtherProcess.exe -import, the overhead shouldn't be too bad
honorary peter
what was martty's canon event
you dont, let peeps install it themselves, and make a file path available in blender's settings which i assume plugins can access somehow, when the path is valid, possible options are visible and gltfpack can be called
russians in paris? in which war? π
napoleonic
but it is just a legend
hon hon
That simplifies things a lot btw
yeah
MUSIC:
Dan Bodan - "City Plaza"
MOUNTAIN SOURCE IMAGE:
Eberhard Grossgasteiger - "Snowy Mountain", from Pexels.com
TWITTER: https://twitter.com/LukeCorreiaVA
PATREON: https://www.patreon.com/LukeCorreia
KO-FI: https://ko-fi.com/lukecorreiava
interesting issue
https://github.com/JuanDiegoMontoya/Fwog/issues/86
this user seems to really enjoy building other people's projects and letting them know if it works or not π
masochistic
btw, I think I could use a lee diagram to make cooler/more dynamic rainbows/atmospheric effects
it's basically a 2D version of the scattering lut I have now, where the x-axis is the size of the suspended water particles
#1082662796233293834 message
this doesn't actually really make sense to me
well
isn't it more like you can't instance the right functions because you don't know about usage when compiling that file?
because notapenguin is a rust man
lel
the problem should be that when you compile the .cpp file, you don't know what usages of it there are, i think what you said is correct, but i think it can be misleading
wdym
I think what I said is pretty clear
the reason is that you cannot instantiate a template without seeing its definition
the implication from usages instantiating is not obvious
especially for someone new to templates
instantiate = "plug in the template args and generate code for it"
yes, most functions don't work that way though
oh well, maybe i'm just correcting my own way of thinking
can you elaborate
normal functions don't instantiate? idk
I'm talking about template functions though
i think what you said is correct (...)
oh well, maybe i'm just correcting my own way of thinking
:)
i don't naturally think of template usage instantiating code, i could imagine a world where they're not inlined and the usage just asks for a signature
I guess what I'm saying is that writing
someTemplateFunc<Foo>();
may cause a function to be emitted in the binary, if the definition of someTemplateFunc is visible (since non-specialized template funcs are implicitly inline)
if the definition of someTemplateFunc isn't visible, then I guess the linker must find it (which means someTemplateFunc<Foo> must have been instantiated elsewhere)
yes that makes sense (more independently π)
which is why you get linker errors if you define template funcs in cpps and try to call them
chad. my role model
idk how I haven't thought of this already 
https://github.com/JuanDiegoMontoya/Fwog/issues/87
anyways, good idea @tired sandal

I'm also considering redoing pipelines and making them more dynamic
i.e., providing the graphics pipeline state as a struct instead of a "compiled object" (so you can change stuff if needed)
the whole Vulkan saga of moving away from pipelines is making me rethink them as well
from what it sounds like that's more to cater to people (aka legacy ports) who can't into pipelines
embrace the pipeline
yeah, that's certainly an aspect
so they went full circle 
Fwog has almost 0 "dynamic state", so anything that requires changing a specific bit between draws will require a bunch of pipelines and binds
@tired sandal please setup a proper github pfp, the default ones suck
done 
@long robin how stable is fwog? I'm thinking of using it
wdym stable
how often will the API break
and I'll try to put a bunch of breaking changes into releases/tags
so you can stick to one version for as long as possible
i will just use fetchcontent with tags so everything works nicely
time for henlo world
oh
i need to bring my own glad?
do I do core / compat @long robin ?
you don't have to bring glad, but you can
After you have created a window and OpenGL context (e.g., with GLFW) and loaded OpenGL function pointers (e.g., with Glad)
lel
thanks docs
good docs
I should mention in the docs what features are required
is it not possible to just ship glad?
doing compat should work right?
fwog ships glad, but you need to just call the load function yourself
oh neat
now lets see if i remember how to open a window
we have window
im trying to recreate a game i used to play a long time ago
the company made it bad π
I have finally bit the bullet, I will now make my own gameβ’οΈ
time to get stuck in a hell loop of refactoring
this formatting hurts my soul
fwog provides glad 
yeah
Lets go Fwog Tanks @robust bough
Oui
@tired sandal implemented your issue
took a moment to convert all the examples π
hmm I'll make a tag at the latest commit
Dang Iβve been away from everything too long
Looks like fwog progressed a lot
Nice!
hmm I need to make sure the docs are still up-to-date
triangle!
Now make triangle soup
And after that, make triangle soup have pretty colors
im not entirely sure how im going to do my GUI
since before it was based on raw OpenGL, but I think it shouldn't be too bad to translate it
When I want to create a Tex2DArray, what is the Z component of Extent3D and numArrayLayers?
struct TextureCreateInfo
{
ImageType imageType = {};
Format format = {};
Extent3D extent = {};
uint32_t mipLevels = 0;
uint32_t arrayLayers = 0;
SampleCount sampleCount = {};
bool operator==(const TextureCreateInfo&) const noexcept = default;
};
Does Extent3D contain the array size or arrayLayers?
nvm.
layer is just a really weird term. I guess its because OpenGL calls them this aswell.
2d array images have z=1 and arraylayers > 1 i expect
Well, you specifiy the Texture Type anyway, so someone might expect Extent3D.z to be the array size.
A Texture2D is similar to a Texture3D, where Depth determines the Array Size.
and there is no Texture3DArray
Is there any documentation on how to use uniforms with fwog?
you can check how it's done in this example
and the shader that goes alongside those uniforms: https://github.com/JuanDiegoMontoya/Fwog/blob/main/example/shaders/ShadeDeferred.frag.glsl
thanks
got it all working
now for camera stuff
fun fact I've never used fwog before
what a noob, look at my amazing scene
There are reflective triangles, transparent triangles, and emissive triangles (but they're set to have emission of 0)
This is to simulate a blind person playing a game
impressive, very nice
thank you
now let's see Paul Allen's black window
its not a black window
it's a fully fledged RTGI renderer, made to render as if you were a blind person
seems pretty accurate, coping is definitely involved when you're using opengl
heh
what am I doing wrong?
#version 450
layout (location = 0) out vec2 out_uv;
void main() {
out_uv = vec2((gl_VertexID << 1) & 2, gl_VertexID & 2);
gl_Position = vec4(out_uv * 2.0f + -1.0f, 0.0f, 1.0f);
}
#version 450
layout(location = 0) in vec2 in_uv;
layout(location = 0) out vec4 out_color;
layout(binding = 0) uniform sampler2D image;
void main() {
out_color = texture(image,in_uv);
}
Fwog::GraphicsPipelineInfo create_fullscreen_pipeline_info() {
std::ifstream vs("shaders/fullscreen.vert.glsl");
std::string vertex_source((std::istreambuf_iterator<char>(vs)),std::istreambuf_iterator<char>());
auto vertex = Fwog::Shader(Fwog::PipelineStage::VERTEX_SHADER,vertex_source);
std::ifstream fs("shaders/fullscreen.frag.glsl");
std::string fragment_source((std::istreambuf_iterator<char>(fs)),std::istreambuf_iterator<char>());
auto fragment = Fwog::Shader(Fwog::PipelineStage::FRAGMENT_SHADER,fragment_source);
Fwog::ColorBlendAttachmentState blend_state{};
auto info = Fwog::GraphicsPipelineInfo{};
info.name = "fullscreen triangle";
info.vertexShader = &vertex;
info.fragmentShader = &fragment;
info.colorBlendState = Fwog::ColorBlendState{false,{},{&blend_state,1}};
return info;
}
smh should've rung the town bell
"unknown reason", see left side
ah
do the source strings look correct when you load them (i.e., they are what you expect them to be)
I can compile and link your shaders fine, so it's probably the loading that's messed up
confirm by trying to load these strings
const char* gVertexSource = R"(
#version 450
layout (location = 0) out vec2 out_uv;
void main() {
out_uv = vec2((gl_VertexID << 1) & 2, gl_VertexID & 2);
gl_Position = vec4(out_uv * 2.0f + -1.0f, 0.0f, 1.0f);
}
)";
const char* gFragmentSource = R"(
#version 450
layout(location = 0) in vec2 in_uv;
layout(location = 0) out vec4 out_color;
layout(binding = 0) uniform sampler2D image;
void main() {
out_color = texture(image,in_uv);
}
)";
the construction of Fwog::Shader works
even empty strings compile (for some reason)
doesnt work either
huh
is this a lifetime issue?
ah
yeah
the info struct is holding a pointer to the shaders, which die when you return from this function
have the function return a graphics pipeline instead of the info for it, and that should resolve the issue

@long robin nitpick:
ClearColorValue takes either float[4],int32[4], or whatever T[4].
When you clear a texture you explicitly assert for float[4].
I'd convert the values to float when possible (i dont really see a reason to support anything else?)
the reason is to allow clearing uint and int textures
I only assert that it's float for rendering to the swapchain methinks
and for this (clearing float/norm textures)
case detail::GlBaseTypeClass::FLOAT:
FWOG_ASSERT((std::holds_alternative<std::array<float, 4>>(ccv.data)));
glClearNamedFramebufferfv(context->currentFbo, GL_COLOR, i, std::get_if<std::array<float, 4>>(&ccv.data)->data());
break;
a very fwoggy triangle.
First Rendered to a Texture and then to the Swapchain 
What will you be doing with our lord and savior Fwog
Fwog not having a way to output glsl errors to a logger is something i noticed and thought about making a Issues for
But I cant think of an alternative other than compiling shaders potentially allowing it to return the string as an error or allow passing in a callback logger function something
thats why i return a std::expected in my pipeline compiler
Yes i like how Cmake Template does it xD
when successful you grab the cooked pipeline, othrwise you can access the error and print and peace out
You can think of it like that
except in a language without pattern matching std::expected is more of a chore to use than actually being useful
Thats the std::expected use case here (why i didnt consider exceptions is performance concerns, although in my code that uses fwog i only make pipelines once if someone wants to make them a lot itd be bad)
I googled out of curious and found https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/#the-results (altho it predates std::expected)
"performance" "concerns"
my exact thoughts too : )
generally you'd use an expected for stuff like parsing
where you have a function that maps some T to some U, but can fail
it's a pretty nice way to validate data coming in from the outside for example
which handles failure quite nicely
especially since failure isn't exceptional in parsers, you might have multiple parsers you try in a row, where if one fails you use the next
stuff like that
Thank u for teaching i did not know this
it's not in c++ just yet, but there's lots of libraries for it
it's basically just an optional with a T instead of a monostate
so it's not too hard to implement
expected is in c++ since c++23
which is in December, iirc
"not in c++ yet" sounds like it doesnt even have a draft.
Its in the standard and some compilers already implemented it
but i get what you mean π
true, true
nah you're right
anywhoo it's nice, but as LVSTRI said, it's quite annoying to use without pattern matching
same for std::variant or std::any 
how am I supposed to tell Fwog that it should generate a texture with as many mips as possible, when the size isn't known?
Do I need to calc the amount myself or is that done automatically via magic number?
1 + floor(log2(max(w, h)));
Further explantation for ^
Can you elaborate
Fwog throws an object containing the info log if compilation or linking fails
Do you think it would be helpful if there was a way to easily get the max, like a named constant
Fwog::MAX_LEVELS or something
oh im just a clown
The best part about my clown act is I have a PR on this exact code (fixing the bug where glDeleteShader and glGetShaderInfo order)
but because im a clown I always read the infoLog from Visual Studios when the exception is thrown by MSVC and forgot that... i can... catch... exceptions...
oh is that why I didn't make the ticket about it... becuase... because it already does throw it...
wdym constant? I would make it like DX11. When you say MipLevels =0, it will generate a full mipchain
which also means it will storage for mips as a default, which is 99% of cases
I've seen multiple users here get trolled by that behavior already π
0 is the same thing, just not as well documented
Explicit > Implicit
most times you make a render target, you only want 1 level. if you load a compressed texture, you want to load a specific number of levels, which may not be the full chain
Fwog::GenerateAllMips declared as 0xFFFFFFFF 
i guess you are right
can we getsome verbose logging? Idk maybe a #define?
Logging that displays the inner workings (basically log constructor/destructor calls, when a framebuffer gets cleared, or rendered...) and reports errors 
I could add a logging callback instead of integrating a fat library like spdlog
and then use its config properly
you could
and peeps can add their lib of choice
but
spdlog makes me sad because it's a good library that annihilates compile times
does it really?
Would RenderDoc suffice though
I realized that it would definitely be more thorough
also known as a not so good lib
whats wrong with it
I guess what I mentioned
obliterating compile perf is a bit of a deal breaker in some cases
hmm
newer versions have a header with forward declarations, which may help
would pch help there as well?
Don't worry guys, modules will come and save the day!
modules are as away as fusion power, another 10 years
Fusion Power is still a dream because German, American and Japanese engineers are slacking smh
i had hopes that modules are shrimpler than fusion : >
at least when working on nuclear fusion you can easily guarantee the presence of a filesystem
here's what I'm thinking
- recoverable errors (very few of these) are exceptions
- bugs (failed pre/post-conditions) are checked with asserts
- other potentially notable things (like when samplers, vertex arrays, and framebuffers are implicitly created) can be logged
I dunno about logging the construction and destruction of every object though. I suppose it's something I can do if you'd like (and I can see some value in visualizing when you create or destroy API objects)
the first two are already implemented
@long robin is there any documentation on creating my own framebuffer?
framebuffers don't exist
swapchains?
Fwog::Render accepts a list of render targets
hm, so how do I create a render target?
ah, they're just textures
hm? what about depth buffer then?
so do I just create the textures myself and give them to render info?
yeah
I'll show you a code example
forgive the formatting
https://github.com/JuanDiegoMontoya/Fwog/blob/main/example/02_deferred.cpp#L438
insh'allah the fwog will render
the gui lib i use renders on CPU
so I need to upload it to a texture
so basically I create a framebuffer to render all the game stuff to, then a texture for the gui
then I do fst to blit both (or either) to the final framebuffer
hm
where's that bufferless fst trick again
i can never find it
π black screen
Fwog::GraphicsPipeline tanks::renderer::finalize_render::create_pipeline() {
auto vertex_shader = Fwog::Shader(Fwog::PipelineStage::VERTEX_SHADER, tanks::read_file(std::string(TANKS_ASSET_PATH) + "/shader/finalize_render/shader.vert"));
auto fragment_shader = Fwog::Shader(Fwog::PipelineStage::FRAGMENT_SHADER, tanks::read_file(std::string(TANKS_ASSET_PATH) + "/shader/finalize_render/shader.frag"));
return Fwog::GraphicsPipeline{{
.vertexShader = &vertex_shader,
.fragmentShader = &fragment_shader,
.inputAssemblyState = {.topology = Fwog::PrimitiveTopology::TRIANGLE_LIST},
.vertexInputState = {}
}};
}```
Fwog::Cmd::BindGraphicsPipeline(pipelines.finalize_render.instance);
Fwog::Cmd::Draw(3, 1, 0, 0);```
this should be everything I need right?
are you compiling for debug
yes
raw opengl call?
no, I'll show
I think the full screen tri that I showed is clockwise-wound
which is really dumb, considering that the default winding is ccw
btw I think you can flip the winding by simply swapping 0 and 2 here
then you won't need to change your pipeline
@long robin maybe it could be a good idea to create a sort of framebuffer / swapchain abstraction?
so you can create a swapchain to render to
hmm
you can just save your RenderInfo, no?
just make sure it's not holding dangling pointers
potentially
maybe something like
auto swapchain = Fwog::CreateSwapChain({
.extent = {1920, 1080},
.capabilities = Fwog::SwapChainCapabilities::Depth,
.colorFormat = Fwog::Format::<>,
});```
oh is this for the window
then you could get the default swapchain somehow?
I'd have to use magic
hm
opengl sucks, so you can't actually get the swapchain as a texture
yeah i dont mean getting the texture
that's why I need a special function for rendering to it
fwog also doesn't handle window creation
make it so you can't access the default swapchains texture?
yeah this wouldn't create a window
Fwog::RenderToSwapchain(Fwog::Swapchain::Default, [&]{
renderer.render(view_matrix);
});```
thats how you could render to the default one
and then with the code from here
Fwog::RenderToSwapchain(swapchain, [&]{
renderer.render(view_matrix);
});```
I think I'm having trouble understanding what this is for
its not for anything specifically
it maybe seems like you want just one function for rendering
instead of split into Render and RenderToSwapchain
what would this do under the hood
just create a framebuffer
hmm
what would these do under the hood?
.extent = {1920, 1080},
.capabilities = Fwog::SwapChainCapabilities::Depth,
.colorFormat = Fwog::Format::<>,
extent is just how big it is, capabilities would just be (for example depth). if it's specified, it'll create a depth buffer for the framebuffer to use as well, then color format is just the format of the color texture
oh I see
when I say Swapchain, I'm basically referring to the window-created textures (like in D3D and Vulkan)
I see what you're asking for now
basically a shrimpler way to make the list of targets for rendering
yep
then if there's a sentinel "default", it lets you have a single path for everything
I do have a couple functions for easing the creation of common kinds of textures
Texture CreateTexture2D(Extent2D size, Format format, std::string_view name = "");
Texture CreateTexture2DMip(Extent2D size, Format format, uint32_t mipLevels, std::string_view name = "");
i might be doing textures wrong lol
texture.UpdateImage({
.offset = {0, 0, 0},
.extent = {extent.x, extent.y, 0},
.format = Fwog::UploadFormat::RGBA,
.type = Fwog::UploadType::UBYTE,
.pixels = pixels
});```
i just proposed the "swapchain creation" idea because I think it would be nice to consolidate everything?
it would make it so then it's really shrimple to create targets and stuff
and then there's no need (for the user) to discriminiate between their own swapchains / window provided one
UpdateImage (and many other functions) has a bunch of defaults btw
yeah I saw
the way Im going through this is just going through functions that look like what i need
and checking the source
would it return a vector of textures?
not sure? potentially a Fwog::Swapchain class
there you can keep track of the capabilities / what it can do
or a Fwog::RenderTarget
then you can pass that to render
hrm
then the sentinal Fwog::RenderTarget::Default
or WindowProvided (naming is just bikeshed)
yeah a sentinel render target is something I've thought of
that way the user is still being clear about who they're targetting
only difference is that they didn't create it
the only thing is that I dunno how much typing this would actually save. I guess you could have something like
auto rts = Fwog::CreateRenderTargetTextures({
.extent = windowExtent,
.colorFormats = {Fwog::Format::R8G8B8A8_SRGB, Fwog::Format::R16G16_SNORM},
.depthFormat = Fwog::Format::D32_FLOAT,
});
the only problem is that it doesn't create the render targets (which include the loadOp and the clear value) as well
Fwog::Render({
.name = "Bababooey pass",
.colorAttachments = ???
.depthAttachment = ???
[&]
{
// draw calls
});
so maybe CreateRenderTargetTextures also takes parameters to fill in the render target info structs
auto bababooey_target = Fwog::CreateRenderTarget({
.extent = windowExtent,
.colorFormats = {Fwog::Format::R8G8B8A8_SRGB, Fwog::Format::R16G16_SNORM},
.depthFormat = Fwog::Format::D32_FLOAT,
.loadOp = Fwog::LoadOp::CLEAR,
.clearColor = {0.0, 0.0, 0.0, 1.0f},
});
Fwog::Render(bababooey_target, [&] {
// Draw calls
});
auto rts = Fwog::CreateRenderTargetTextures({
.extent = windowExtent,
.colorTargets = {{Fwog::Format::R8G8B8A8_SRGB, Fwog::LoadOp::DONT_CARE}, {Fwog::Format::R16G16_SNORM, Fwog::LoadOp::DONT_CARE}},
.depthTarget = {Fwog::Format::D32_FLOAT, Fwog::LoadOp::Clear, 1.0f},
});
rts would be a structure containing a list of render targets (attachments) and a list of textures
then you can do
Fwog::Render({
.name = "Bababooey pass",
.colorAttachments = rts.colorAttachments,
.depthAttachment = rts.depthAttachment,
[&]
{
// draw calls
});
i dont see many downsides?
if they want to access the texture, you could make a method to access them somehow
the main one is that you can't easily take a random texture and make it a render target π
how would you do that?
tbf I haven't had a need to do that
this wouldn't let you do that?
because you can only create render targets, and render to them
you can't just yeet a random texture into a render target
the idea in my head is that CreateRenderTargetTextures creates an object which owns some textures as well as some attachment info structs that reference said textures. The "problem" with this is if you want to reference an external texture (without owning it), or maybe reference a texture in multiple render passes
I just need to think about it some more
hm I see
Yeah the referenceing a single texture in multiple targets seems a bit iffy
are there any actual use cases for that?
yeah
hm
maybe
yes
in 05_gpu_driven, the depth attachment is used in multiple render passes, but is only cleared in the first
auto bababooey_target = Fwog::CreateRenderTarget({
.extent = windowExtent,
.colorFormats = {Fwog::Format::R8G8B8A8_SRGB, Fwog::Format::R16G16_SNORM},
.depthFormat = Fwog::Format::D32_FLOAT,
.loadOp = Fwog::LoadOp::CLEAR,
.clearColor = {0.0, 0.0, 0.0, 1.0f},
});
auto using_depth_target = bababooey_target.CreateTargetUsing(Fwog::Target::DepthBuffer,
.extent = windowExtent,
.colorFormats = {Fwog::Format::R8G8B8A8_SRGB, Fwog::Format::R16G16_SNORM},
.loadOp = Fwog::LoadOp::CLEAR,
.clearColor = {0.0, 0.0, 0.0, 1.0f},
);
hm, someone has to own the textures
what about something like what you did with creating something that owns some metadata / textures
then you can create a render target from them? (and select which you use)
I could still offer it like this, so you can use the "old" (current) way or get 90% of the shrimplification of the proposed way
so the render target doesn't own anything
it's just a way to create a render target from some textures
auto rts = Fwog::CreateRenderTargetTextures({
.extent = windowExtent,
.colorTargets = {{Fwog::Format::R8G8B8A8_SRGB, Fwog::LoadOp::DONT_CARE}, {Fwog::Format::R16G16_SNORM, Fwog::LoadOp::DONT_CARE}},
.depthTarget = {Fwog::Format::D32_FLOAT, Fwog::LoadOp::Clear, 1.0f},
});
auto target = Fwog::CreateRenderTarget("Bababooey pass", rts);
Fwog::Render(target, [&]
{
// draw calls
});
texture.UpdateImage({
.offset = {0, 0},
.extent = {extent.x, extent.y},
.format = Fwog::UploadFormat::RGBA,
.type = Fwog::UploadType::UBYTE,
.pixels = fake_data.data()
});
bitmap->UnlockPixels();
return &texture;```
```cpp
Fwog::Cmd::BindGraphicsPipeline(pipelines.finalize_render.instance);
auto sampler = Fwog::Sampler(Fwog::SamplerState{});
Fwog::Cmd::BindSampledImage(0, *context.gui_texture, sampler);
Fwog::Cmd::Draw(3, 1, 0, 0);```
```glsl
layout(location = 0) out vec4 o_color;
layout(location = 0) in vec2 v_uv;
layout(location = 0) uniform sampler2D gui_texture;
void main()
{
// o_color = vec4(v_uv, 1.0, 1.0);
o_color = vec4(texture(gui_texture, v_uv).xyz, 1.0);
}```
is there anything im doing obviously wrong here @long robin ?
im just getting a black screen
and for some reason, when I launch this with renderdoc it crashes
texture(Fwog::CreateTexture2D({extent.x, extent.y}, Fwog::Format::R8G8B8A8_UINT))
not sure
if the app is on gh, I can try to build it
Can't, using some libs that are closed source / can't share
does renderdoc crash, or just your app?
the app
also is it a working directory issue
but somehow it's stopped crashing
i commented out code that had to do with something else
What conditions does RenderDoc crash (like what code is commented in/out)
its unrelated
it seems it's black?
auto fake_data = std::vector<std::uint8_t>(extent.x * extent.y * 4);
std::generate(fake_data.begin(), fake_data.end(), [](){
return 250;
});
texture.UpdateImage({
.offset = {0, 0},
.extent = {extent.x, extent.y},
.format = Fwog::UploadFormat::RGBA,
.type = Fwog::UploadType::UBYTE,
.pixels = fake_data.data()
});```
yeah that's a debugging feature π
dunno
wish I could just, see what im calling with it
see if making your sampler nearest fixes it
or making your texture unorm (since uint seems odd for a gui texture, assuming you want [0,1] color output)
srgb might also be a better choice
combined depth+stencil formats were a mistake
I wish you could make a span from an initializer list {a, b, c, d} like you can with a vector
heap allocation just for minor programmer convenience π©
lets roll a d15, what is your willpower stat
nat 1
How tho, std::init_list does not allow const refs rvalue refs
You accept a const T(&)[E]?
incredible
the convenience of fwog hinges on this constructor existing
all this for a drop of convenience
I'll just put std::vector and accept the inevitable horrible perf when there are 2 heap allocs per frame
ship fwog with a patch for the user's stl
step 1: get good at boxing
name of that heap alloc? adolf hitler
well here is the prototype for this "simplified" render target system (try to ignore the epic auto formatting)
// on init
auto renderTargets = Fwog::MakeFoo({
.extent = {800, 600},
.colorTargets = {{Fwog::Format::R8G8B8A8_SRGB, Fwog::AttachmentLoadOp::DONT_CARE}, {Fwog::Format::R16G16_SNORM}},
.depthTarget = Fwog::DepthStencilTargetInfo{Fwog::Format::D32_UNORM, Fwog::AttachmentLoadOp::CLEAR, {1.0f}},
});
// on render
Fwog::Render(
{
.colorAttachments = renderTargets.colorAttachments,
.depthAttachment = renderTargets.depthAttachment,
},
[&]
{
Fwog::Cmd::BindComputePipeline(...);
Fwog::Cmd::BindSampledImage(...);
Fwog::Cmd::Dispatch(...);
});
it's a little shorter overall, but I'm still not super hot on the concept
I did find some places that could be otherwise be improved (changing pointers to optionals or references) at least
what thar fuk is D32_UNORM
as opposed to D32_FLOAT
is that actually a thing in ogl
yes
what a horrible day to have eyes
whats the problem with it?
well there's probably a reason it doesn't exist in vulkan 
I'm guessing 8 bits of this are just discarded in practice
huh? why would it?
or it corresponds to VK_FORMAT_X8_D24_UNORM_PACK32
cuz hw might not actually support it
D32 float is much better
esp with reverse
Me during moments of insecurity: "Man I gotta start using imperative mood or else I might not get hired"
Jakar:
ok looks like while its a good habit to have I feel a lot reassured that perfection really is the enemy of good
more of a self-roast
lately ive been like obsessed over stuff like "How to write good commit messages" and feeling insecure about it
like that everyone would make fun of me if I write 'Added' instead of 'Add' or not have the 50 word wrapping stuff all the time even in personal projects
so I was like 'I wonder how Fwog does the commit and merges' and I realize that perfect is the enemy of good
oh lol
and that there's a time and place to have different degrees of tryhard
basically im thanking you for reassuring me that id be fine
yeah a good commit message just gives you an overview of what changed
no need to format it perfectly or whatever
yea. My plan is keeping this loose, casual and informal in my local branch commits then in the remote when i squash merge I can practice the tryhard professional 'I dont want Linus to make fun of me' type of commits
does linus make fun of people for that
yea its where I started to becoming more awware of it
this is funny to me
Let me dig out the post
also, there is a difference between making commits to the linux kernel (which is used by millions) and commits for your personal project that has maybe 1 or 2 users (including yourself)
commit messages usually don't even matter usually
in a production environment you won't be commiting straight to whatever dev branch unless you're working on something very small
It was actually a pull request and I think I found it in like some blog post: https://github.com/torvalds/linux/pull/17
but yea there's a post where he gets pissed off at how ```
the fact that other projects apparently have so low expectations
of commit messages that these things get used is just sad. People
should try to compare the quality of the kernel git logs with some
other projects, and cry themselves to sleep.
(Torvalds, L 2012)
Torvalds, L. (2012, May). Add support for AR5BBU22 [0489:E03C] by REEJK Β· pull request #17 Β· Torvalds/Linux. GitHub. <https://github.com/torvalds/linux/pull/17#issuecomment-5659933>
i am learning i do not like this man π
I noticed there's a strange weird 'thing' lately where I noticed where super respected authority figure who likes to yell at subordinates seem to attract a certain personality type that really likes to being yelled at
There's a lot of people who fantaize about having a Gordon Ramsay type to scold them in the kitchen. I see it in school too where like there was one whole team where all the subordinates considered the mocking feedback by the tech lead (whom does have strong technical skills) to be like being given angelic visions from the heavens
You think he'd show up to Basedcon?
i think he kinda has a point for linux repo because a lot of people work exclusively in TUI or CLI there
WAIT NO I JUST GOT IT
you do word-wrapping at
the
the
the
its me
the
but yea Jakar is my sanity check that like, no nobody is making fun of me that my personal projects have commit messages like 'fix bug maybe?'
this is an unhinged opinion tbh
yeahhhhhh
bro probably never had to do webdev
Don't the Linus, Jonathan Blows and Casey Muratoris of the world hate web dev
because it allows people of all kinds of skill levels to collaborate π
I looked at some of the commits in linux and they are super structured. Multiple paragraph explanation, sign-off, cc, reviewed-by, etc. even for one-liners π©
it makes sense for linux
You know if I see that in a game dev project maybe it should be a red flag in an ironic way
Like 'oh shit is this run by a micromanager?'
idk but I assume none of them know anything about accessibility
the game i'm working on has commits nothing like this, and they're all even squashed from PRs
man the CMake Generating Stuff loading can be a productivity drain as I get distracted forgetting about it lol but this is an enlightening convo
no one gives a fuck because we're not managing an open source project with thousands of contributors (potentially infinite), and we're not able to slow ourselves down
our productivity needs to be higher, and our barrier for entry doesn't need to be as low
I think I'd pick up a lot of the 'how to write code professionally' skill better once I am writing code professionally more at my internship
I do try and like self learn but its hard to tell the balance on my own
i think like a week after starting i accidentally added every single engineer (~75 people) to my PR on accident because of some weird git shit, and one single person messaged me telling me how to fix it and that was it 
LMFAO thats amazing
mmm pushed some breaking changes
when i make breaking changes:
for the good of the code
actually improving
aesthetic
when i have to contend with someone else's breaking changes:
you fucking donkey
no respect for my time
big nothingburger for a syntax change
Idk if you saw the commit, but basically all of these would accurately describe it 
still better than to deal with raw opengl 
im gonna be dealing with raw d3d12 (or maybe d3d11? idk) in my win32api experiments (I never touched the d before)
I figured since I am using Fwog and not touching Vulkan I should have some raw api to be regularly exposed to anyways to not get too soft
ΡΡΠΎ Π·Π°ΠΊΠ°Π»ΡΠ΅Ρ Ρ Π°ΡΠ°ΠΊΡΠ΅Ρ
what am i reading
ah yes
is d3d11 still worth using? Because if it is I can try it as I want to contribute to #d3d11-tutorial-wip too if I use that
but otherwise I'd prefer to use the more modern d3d12 if its not as good ROI
is this the right channel
oh sorry
Its because I saw the word 'raw opengl'
and then it flow naturally
I apologize friend
API parkour
does fwog work with imgui? since imgui changes the state of the context
the default gl imgui backend undoes all changes it makes to the state
I use it in the fwog examples with no issues
idk but at least they were fun to make
I looked at the examples so much I accidentally used it as a template at first naively
(hence why I end up making a separate template meant for Fwog: https://github.com/ClementineAccount/Fwog-CMake-Glfw-OpenGL-Template which has Dear Imgui, shows Fwog working out of the box with FetchContent, the depth buffer enabled by default, using single draw instead of multidraw (more noob friendly) in a project u can use as a base to do whatever, and skybox example as that was one thing the examples didnt show how to do)
I kinda wish Jaker would give feedback on stuff he wants changed for it or if he wants to take it/link it on the Fwog page
hey he actually tried to make sure the head goes over just like u taught me
but he went forward instead of side
I'm editing the readme right now, so I can link it there
π«’
I think it's a good exshrimple of a standalone project
no changes are really needed since you don't do anything heinous in the cmake
Thanks!
I do think like this stuff could be in its own .h files and stuff but I also wanted to make it look as close to Deccer's Cmake as I can for first version at least.
Arguably they can even be moved to the .Lib but I actually rather keep a Simple Template here and I'd just make the more refactored version either as an additional template (that this can link to) or put it into Alberquerque
I think it's good
Thanks :)
pls tell me which one says "i use imgui"

all the calls that make imgui windows and widgets are made inside OnGui
https://github.com/JuanDiegoMontoya/Fwog/blob/main/example/common/Application.cpp#L235
which is implemented in the examples
deferred and gltf viewer has them
here's the simplest one
https://github.com/JuanDiegoMontoya/Fwog/blob/main/example/06_msaa.cpp#L186

Itd help if you opened the files I think
Interview with the Help Vampire
Nahh, didnt mean to imply that
tbf I think raildex was expecting a single example that used imgui
nah its ok I just had that line in my mind for awhile
Just like, open the repo in a vscode thing in the browser, ctrl+shift+f imgui
I was a newborn vampire, weeping at the beauty of the 'guys how do i use gcc'.
that's a lot of thingies to look at
its quite sad actually
given how long raildex is on this very server already
you shouldve knowve raildex!

now make something great with fwog π
btw I just discovered that khronos maintains another set of opengl ref pages 
https://www.khronos.org/opengl/wiki/GLAPI/glTextureView
https://www.khronos.org/opengl/wiki/Category:Core_API_Reference
uh, they just redirect when you click on them
I managed to get to this cursed page by searching for glTextureView in the search bar
@fiery sorrel I linked your thingy in the readme
I might put it in an extended "examples" or "showcase" section of the readme in the future to give it better visibility
Its in a good spot
One reason I made that is that its pretty easy to assume 01_hello_triangle is a 'starting template' otherwise too, at least I made that "mistake" (arguably its actually ok if someone knows to then go back and fetch/gitsubmod Fwog as a library but this makes it more obvious to ppl who aren't as familiar)
@tired sandal how do you feel about this shrimple thing for a debug callback
struct ContextInitializeInfo
{
void (*debugMessageCallback)(const char*) = nullptr;
};
void Initialize(const ContextInitializeInfo& contextInfo = {});
I don't see a use for warning levels atm because other severities would be handled by exceptions or asserts
aight, I'll implement calls to this and push it tomorrow (probably)
debugMessageCallback is oddly specific to the underlying tech, but i frogive you, because fwog only deals with one specific one, other wise its a huge red flag in abstracting things
I'm not understanding
ah
I should clarify that this has nothing to do with the opengl debug callback 
good come back π
it's solely for logging stuff that fwog is doing
i thought so
but your right side of the brain was hanging on to glDebugMessageCallback
idk a better way to name this
whenever this callback is issued the user's computer calls Jaker on a phone using a text-to-speech program
hmm
I'm gonna use it for logging when GL objects are created and destroyed, and maybe a few other things
wdym by that?
OpenGL lets you set a message callback as well, which is unrelated to this one
and people typically call it the "debug message callback", which can be easily conflated due to my naming
oh wait, it was that "oddly specific to the underlying tech" that put me off 
I thought he meant opengl has some platform specific stuff for that
the gl one is for logging API misuse (validation) mainly
hehe
maybe I'll call the new thing perfMessageCallback or performanceMessageCallback
as long as I can retrace what Fwog does I am happy 
doc string: "Use this callback to lower perf"
btw what will this cb do? i am curious now
#1019779751600205955 message
niet to "performance" or "perf"
raildex requested it because of some C++ lifetime issues (classic), but I see it as a way for the user to see when Fwog is implicitly creating and destroying shit (gl objects), thus affecting π ±οΈerf
I wouldn't expect Fwog::Shader to just store a pointer to the source and instead store it internally 
it doesn't store anything itself besides a gl handle
nor does it reference anything
the issue in your case was referencing the shaders in a returned object (pipeline create info)
oh wait it was the pipelinecreateinfo
yeah. i would it expect it to be owning (because well RAII) 
the workers must own the means of pipeline production comrade Jaker
I'd have to make it hold a shared ptr in order to have safety and be reusable
because shaders can be used in multiple pipelines
I guess this is one of the downsides to using parameter structs- the user might pass around the struct before actually calling the function
Rule of thumb when using these: call the function immediately. Ideally, you don't even reference the parameter struct by name
auto foo = CreateFoo({.bar = 2});
or just a copy? 
I'm having a C++ dementia moment
https://godbolt.org/z/TWGs3GqcE
my brain cant fit c++ rules
c++ page fault
I cannot comprehend what I'm doing wrong here
uh
I think I see
the first arg had to be std::format_string<Args...> fmt for the compiler to see
it's aight, I fixed it already (second godbolt link)
epic
good idea π
now there is ebic logging
Fwog: Created buffer with handle 1
Fwog: Created buffer with handle 2
Fwog: Destroyed buffer with handle 2
Fwog: Destroyed buffer with handle 1
well this compiles
nullptr_t bababooey = *(nullptr_t*)(1234);
actually I don't even know why I'm surprised. It's not like I directly assigned it a weird value
I accidentally pushed this
/// @brief Callback
ffs only gcc13 adds support for <format>
https://github.com/JuanDiegoMontoya/Fwog/actions/runs/5433962264/jobs/9882026342
just use streams
byeah
wheres fwog for 2023 dr deccer
I'm trying to use va_list right now and it's like dragging my froge through a field of broken glass
yeah but it's not supported except on the version of gcc that released like a month ago 
I guess I'll have to unironically use streams
except I forgor how to make a stream from a fixed size buffer
hmm, how do I get the number of args from a printf format string? va_start requires a count except in C23
apparently there is no standard way, epic
I'm trying to format in exactly one place
I don't want to include a lib for one line of code 
absolutely not web dev irl
apparently it is impossible to do this in c
void printer(const char* fmt, ...)
{
char buf[512];
vsnprintf(buf, 512, fmt, /* how tf do I send the variadic args here */);
}
va_start requires a count, which is encoded in the format string, but I have to parse it manually to get that 
ass language
why is it so goddamn hard to write a formatted string to a buffer in both C and C++
https://stackoverflow.com/questions/7781898/get-an-istream-from-a-char
it only starts to not suck once you have <format>
hinged af code
char messageBuffer[1024] = {};
std::stringstream stream;
stream.rdbuf()->pubsetbuf(messageBuffer, std::size(messageBuffer) - 1);
((stream << args), ...);
context->verboseMessageCallback(messageBuffer);
hinged
Thinking of making my mid July blog post a review of Fwog as a user @long robin
Should I refer to you as 'a friend's' or something π€
Might have a section on the existing examples too.
ah i can link it together
anything in particular u want me to focus on in addition that stuff? @long robin
it's your blog
ok!
but ye those topics are good
be more negative!!!
i kid, if this was not conveyed through text
i'm like four steps removed from even possibly having anything negative to say about fwog
same
1 exclamation mark is a sarcasm indicator to me
oohh u meant the review
yuhhh
btw this code inexplicably fails to write to the buffer on msvc π’
somehow the stream contains the text, but the buffer isn't written to 
@fiery sorrel can you run this code in a local project (using msvc) as a sanity check
#include <iostream>
#include <sstream>
template<class... Args>
void printy(char* buffer, int bufferSize, Args&&... args)
{
std::stringstream stream;
stream.rdbuf()->pubsetbuf(buffer, bufferSize - 1);
((stream << args), ...);
printf("%s\n", buffer);
}
int main()
{
char buf[16] = {};
printy(buf, std::size(buf), "baba", "booey");
}
you can just use a project that you have open too
Was afk. Ill do it in 15 mins
Jakar
S03 DROPPED
I was suggesting plugging the code into an existing project so you wouldn't have to create a new one (since it was just for a shrimple test)
I guess it's easy to make a new VS project though
[...]/external/fwog-src/src/detail/VertexArrayCache.cpp:66:15: error: no member named 'InvokeDebugMessageCallback' in namespace 'Fwog::detail'; did you mean 'InvokeVerboseMessageCallback'?
[build] detail::InvokeDebugMessageCallback("Destroyed vertex array with handle {}", vao);
[build] ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
[build] InvokeVerboseMessageCallback
[build] [...]/external/fwog-src/include\Fwog/detail/ContextState.h:87:8: note: 'InvokeVerboseMessageCallback' declared here
[build] void InvokeVerboseMessageCallback(std::format_string<Args...> fmt, Args&&... args)
[build] ^
[build] 2 errors generated.
i am on the newest main
yeah I goofed
resharper failed to refactor the function correctly and somehow shit still built
what breakpoint is this?
just see if it prints anything
ok your buffer is empty too
idk what's wrong then
I noticed that rdbuf returned a null pointer, which is rather sus
what are you trying to achief, chief?
I want to achief printing to a buffer of my own provision
attempt 1 was using format_to_n, which didn't work because gcc sucks
attempt 2 was using va_start and vsnprintf, which didn't work because c sucks
attempt 3 (this one) is me trying to back a stream with my own buffer, then write to it
but the answer provided by SO uses IB, amazing 
if your own buffer is a std::string, then you can call str()
the stringstream, you mean?

std::string has no member called str
yes, call str() on the stringstream
man i fucking love *stream names in the stl, so descriptive
yeah that'll work, but muh unnecessary allocations
wher
I presume the stringstream can alloc when writing to it, as might calling str
but it's a smol worry
i do not follow
where does the storage for stringstream come from
holy shit str is overloaded 
fml
it does two completely different things
yes i mean call str(std::string&/&&)
you can also keep the stream around and rewind it
jeez will you are getting paid bank for this commercial, get off your phone
willy isn't free of his phone addiction
now thats an old reference
justn't like myself
age is just a number int old = true;
@tired sandal latest commit is no longer failing to build btw, and it has the logging callback thingy (you provide it in Fwog::Initialize now)
setting up a project with vs only from scratch for c++ is a can of worms and you can make 2139048094358 things wrong
ah great, thank you discord
cmake my love
@golden schooner
Jak'ar Al-Ahmdee
wtf two health bars
My beloved
Second Crack xD
Oh no
I like how they don't even start exporting materials until "100%"
I done goofed
does an example level come with deez mups?
the level in the screenshots, does it come witht he asset pack?
I dunno why unreal didn't just use the glTFforUE4 plugin instead of making their own, shittier version
it doesn't like when you don't bake the materials, yo
: S
You could use shrimple material baking, where it bakes it into a quad instead of the whole mesh
I counted the pixels, it's 4
rasterizationβ’οΈ
turd.gltf
stupid 1m vs 100cm thing
hmm
side panels do be looking a little dubious
but the space the sun shines on looks neat, almost as if you have some bloom going already
oh
so it's just straight albedo and π ±οΈertex normals
why are you not using normals?
that's coming in the pbr update
of what
pbr dlc 
the asset pack?
03_gltf_viewer
the asset pack comes with peebeeare materials ofc
how big is the model btw with its assets, exported to gltf/glb?
131mb with 1024^2 materialz
hmm ~twice as old sponza
if i show you a receipt of me buying that pack too, would you be willing to share the gltf?
I noticed that Fwog heavily relies on either std::optional or std::unique_ptr a lot of its constructors call OpenGL functions like glNamedBufferSubData which means that that code must be called after the window is initialized (and hence Fwog is initialized). At least, in the case of Deccer's Cmake Template I can't just have class member variables living in an Application.hpp without there being issues (because Application.hpp's constructor is called before Run()).
lol materials look like ass, I think I need to re-export
I don't think fwog uses unique_ptr anywhere actually π€
no I didnt mean that Fwog uses it. I mean I have to use either optionao r unique ptr to use Fwog stuff
why do you have to use unique_ptr?
that is why i load all the shtuff in Load() not in Initialize()
no its an option.
i'd like a subscription to Jaker's Completely Legal GLTF File Emporium too
i dont think i can install ue here on lunix, and i dont want to switch to windows :3
It I make a camera class like
class Camera
{
public:
Camera();
void Update();
private:
struct CameraUniforms {
glm::mat4 viewProj;
glm::vec3 eyePos;
};
Fwog::TypedBuffer<CameraUniforms> cameraUniformsBuffer;
//Skybox doesn't pass in the translation
Fwog::TypedBuffer<CameraUniforms> cameraUniformsSkyboxBuffer;
glm::vec3 camPos = glm::vec3(3.0f, 3.0f, 3.0f);
glm::vec3 target = glm::vec3(0.0f, 0.0f, 0.0f);
glm::vec3 up = glm::vec3(0.0f, 1.0f, 0.0f);
float nearPlane = 0.01f;
float farPlane = 5000.0f;
CameraUniforms cameraStruct;
};
That Fwog means that I cannot just have a Camera myCamera inside ProjectApplication.hpp
I can only have an std::optional<Camera> myCamera
i dont have any glismin my camera, because you perhaps stuff more things into the cbuffer where youd store camera stuff as well
btw glb turns into 529mb when I export 2048^2 textures
just 70mb after gltfpackerino is done
The constructor for Application gets called before Run() and hence before Initialize() and Load()
So if I am calling any Fwog constructor, it has to be called inside Load() which means I have to make that variable's constructor not called when ProjectApplication's constructor is called.
i c
This is actually fine tbh
I don't mind stuffing std::optional everywhere until I eventually will figure out a better way to organize and architecture my code over time
yeah you can use std::optional to defer initialization as you noticed
I can't think of other methods to defer initailization other than std::unique_ptr but I rather use std::optional if I don't need nullablity: https://devblogs.microsoft.com/cppblog/stdoptional-how-when-and-why/
you can make your own deferred init class too
that way you don't have the "overhead" of a single bool
constructor() = delete;?
no
a class that holds some aligned storage, then provides a construct method
i'd say most likely the architecture is the problem, and I wouldn't do deferred init
make your renderer do this stuff, not the camera
you can embrace long initializer lists
Reject constructors, embrace static Self make(CreateInfo)
yea it'd eventually be decoupled over time. I am using this project as a way to learn how to develop an architectural instinct from first principles and books rather than 'oh this engine do it like that i copy' type mindset
The renderer itself would need to be an std::optional if its a class tho with that same limitation but it is better to have one optional than a bajillion (or ensured its constructed after Iniitalize() so not stored inside Application.hpp*)
*context: Deccer's Cmake Template
but dw im not askin for help or anything just an observation

le



