The WIP Thread

[Brohnesorge]

little something I've been working on the past week.

[Nash]

Made a tutorial on paletted spriting techniques!

[Captain J]

Nicely detailed procedure of making satisfying retro sprites. Good tips!

[xenoxols]

Working on a gunslinger update. Monster mod is bratwurst and mapset is zblood.

[Angel-Neko_X]

[RastaManGames]

Trying to "transfer" arsenal from "Delta Force: Black Hawk Down" to the "GZDoom" source-port...

[Bjecinst]

property damage!!! >:D
song in BG is The Wizard's Last Rhymes by Rhapsody of Fire, if youre wondering

[Bjecinst]

got bored, added duke's pistol to my mod

[22alpha22]

Needed a drop pod model for my mod and remembered that Quake II had a drop pod model that would work perfectly. Turns out that it isn't a model at all but actually part of the map geometry instead for some reason.

Even though I don't have hardly any modeling experience, I've only ever made simple crates and bullets, I figured I could recreate Quake II's drop pod in blender, it didn't look very complex. Well here are the results, took me over 4 hours, I started over from scratch several times, and it is far from perfect but I am satisfied.

I have never used a Quake II map editor, so I had Quake II running in another window and alt tabbed frequently to get a look at it, as result it is not a perfect 1:1 and the texturing job is awful. (I never really model, so I didn't know how to unwrap a model as complex as this, despite it actually being really simple and low poly) None the less as I intend to use it, it should work just fine, the player isn't intended to be able to get close and inspect it. As my fist "complex" model, I am happy with the results.

[InsanityBringer]

got tired of having never done anything real with vulkan so on a whim I started working on a vk refresh dll for Quake 2 as a test project. Two weeks of on and off progress, and I'm finally able to draw the console in a horrific "let's just throw literal thousands of draw calls at the problem" means. It's actually been pretty fun and productive so far and I haven't had any serious issues.. however I think I am an overly salty individual sometimes

Code: Select all

	/*Validation Error: [ VUID-vkCmdExecuteCommands-flags-06026 ] Object 0: handle = 0xa92f690, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x2465f7e2 | vkCmdExecuteCommands(): 
	Secondary VkCommandBuffer 0xa92f690[] is executed within a dynamic renderpass instance scope begun by vkCmdBeginRendering(), 
	but VkCommandBufferInheritanceRenderingInfo::flags (1) does not match VkRenderingInfo::flags (1), excluding VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR. 
	The Vulkan spec states: If vkCmdExecuteCommands is being called within a render pass instance begun with vkCmdBeginRendering, 
	the flags member of the VkCommandBufferInheritanceRenderingInfo structure included in the pNext chain of 
	VkCommandBufferBeginInfo::pInheritanceInfo used to begin recording each element of pCommandBuffers must be equal to the VkRenderingInfo::flags parameter 
	to vkCmdBeginRendering, excluding VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT
	(https://vulkan.lunarg.com/doc/view/1.3.231.1/windows/1.3-extensions/vkspec.html#VUID-vkCmdExecuteCommands-flags-06026)*/
	//1 != 1 apparently, quality work guys
	
	if (!strcmp(pCallbackData->pMessageIdName, "VUID-vkCmdExecuteCommands-flags-06026")) //filter out broken validation message
	{
		return VK_FALSE;
	}

[dpJudas]

I haven't experienced a single time that the validation layer has been wrong. Are you absolutely sure you didn't miss something?

The error is saying that the flags passed into vkBeginCommandBuffer doesn't match the flags passed into vkCmdBeginRendering.

[InsanityBringer]

I start rendering with

Code: Select all

	VkRenderingAttachmentInfo colorinfo =
	{
		.sType = VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO,
		.clearValue.color.float32 =
		{
			0, 0, 0.3f, 1.0f
		},
		.imageLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
		.imageView = colorview,
		.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR,
		.storeOp = VK_ATTACHMENT_STORE_OP_STORE,
	};

	VkRenderingAttachmentInfo depthinfo =
	{
		.sType = VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO,
		.clearValue.depthStencil.depth = 1.0f,
		.imageLayout = VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL,
		.imageView = r_depthbuffer->viewhandle,
		.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR,
		.storeOp = VK_ATTACHMENT_STORE_OP_STORE
	};

	VkRenderingInfo renderinfo =
	{
		.sType = VK_STRUCTURE_TYPE_RENDERING_INFO,
		.layerCount = 1,
		.colorAttachmentCount = 1,
		.pColorAttachments = &colorinfo,
		.pDepthAttachment = &depthinfo,
		.renderArea =
		{
			.offset.x = 0,
			.offset.y = 0,
			.extent.width = vid.width,
			.extent.height = vid.height
		},
		.flags = VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT
	};
	
	vkCmdBeginRendering(currentcmdbuffer, &renderinfo);

and start the secondary command buffer with

Code: Select all

		VkFormat renderformat = vk_state.phys_device.surfaceformat.format;

		VkCommandBufferInheritanceRenderingInfo renderinginfo =
		{
			.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO,
			.colorAttachmentCount = 1,
			.depthAttachmentFormat = VK_FORMAT_D32_SFLOAT, //todo: move to vk_state so depth format can change if needed
			.flags = VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT,
			.pColorAttachmentFormats = &renderformat,
			.rasterizationSamples = VK_SAMPLE_COUNT_1_BIT,
		};

		VkCommandBufferInheritanceInfo inheritanceinfo =
		{
			.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO,
			.pNext = &renderinginfo,
		};

		VkCommandBufferBeginInfo begininfo =
		{
			.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
			.flags = VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT | VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT,
			.pInheritanceInfo = &inheritanceinfo
		};
		VK_CHECK(vkBeginCommandBuffer(drawbuffer, &begininfo));

My confusion and saltiness stems from the validation message explicitly mentioning that both flag values are 1 (which is just VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT), so I'm not sure what I am missing here. It's so strange, since as you've mentioned they're almost always correct and have been a huge help in bug testing this mess.

[dpJudas]

Hmm yes that is weird. I am not spotting any error in what you pasted. Either it must be talking about another part of the code (if there is such a thing), or there indeed is an actual bug in the validation error. Seems such a basic place to have an error though - this would be noticed by pretty much anyone using secondary command buffers, would it not?

[InsanityBringer]

I grabbed the validation layer repo and found this

Code: Select all

                    if (sub_cb_state->activeRenderPass->use_dynamic_rendering_inherited) {
                        const auto rendering_info = cb_state->activeRenderPass->dynamic_rendering_begin_rendering_info;
                        const auto inheritance_rendering_info = sub_cb_state->activeRenderPass->inheritance_rendering_info;
                        if (inheritance_rendering_info.flags !=
                            (rendering_info.flags & ~VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR)) {
                            skip |= LogError(
                                pCommandBuffers[i], "VUID-vkCmdExecuteCommands-flags-06026",
                                "vkCmdExecuteCommands(): Secondary %s is executed within a dynamic renderpass instance scope begun "
                                "by %s(), but VkCommandBufferInheritanceRenderingInfo::flags (%u) does "
                                "not match VkRenderingInfo::flags (%u), excluding "
                                "VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR.",
                                report_data->FormatHandle(pCommandBuffers[i]).c_str(), cb_state->begin_rendering_func_name.c_str(),
                                inheritance_rendering_info.flags, rendering_info.flags);
                        }

so it's only clearing the VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR flag on the rendering info and not the inherited info. Maybe I misinterpreted the spec and don't need it in the inheritance information, so a closer reading is in order.

[dpJudas]

It kind of makes sense that it isn't needed, since the spec says it ignores the entire inherited info field if the command buffer isn't a secondary buffer. So it already knows it is a secondary buffer at the point where it would read the flag.