ZDoom

[quote="dpJudas"]Okay, so maybe I was wrong about the OpenGL backend. :)
[/quote]

Originally the camera texture was rendered into the main framebuffer, because when the feature was invented, framebuffers weren't universally available and even if they were, were slower on most hardware out there. So the restriction surely existed at some point in time.

[quote]
I can move the allocation to VkHardwareTexture like that, but using a depth buffer for each individual camtex texture seems a bit wasteful though. I guess it comes down to what the typical size of a camtexture is anyway. What decides this? The modder?[/quote]


Yes, the modder. But you can do some analysis on what is needed yourself by scanning through all the textures, see which one is a camera texture and collect the maximum size in both dimensions. For OpenGL this buffer separation was unfortunately necessary because of their idiotic framebuffer-completeness specs and how drivers implement it. At least back in the day it just didn't work to share this buffer.

Okay, so maybe I was wrong about the OpenGL backend. :)

I can move the allocation to VkHardwareTexture like that, but using a depth buffer for each individual camtex texture seems a bit wasteful though. I guess it comes down to what the typical size of a camtexture is anyway. What decides this? The modder?

//===========================================================================
// 
//	Creates a depth buffer for this texture
//
//===========================================================================

int FHardwareTexture::GetDepthBuffer(int width, int height)
{
	if (glDepthID == 0)
	{
		glGenRenderbuffers(1, &glDepthID);
		glBindRenderbuffer(GL_RENDERBUFFER, glDepthID);
		glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8, 
			GetTexDimension(width), GetTexDimension(height));
		glBindRenderbuffer(GL_RENDERBUFFER, 0);
	}
	return glDepthID;
}


//===========================================================================
// 
//	Binds this texture's surfaces to the current framrbuffer
//
//===========================================================================

void FHardwareTexture::BindToFrameBuffer(int width, int height)
{
	width = GetTexDimension(width);
	height = GetTexDimension(height);
	glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, glTexID, 0);
	glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, GetDepthBuffer(width, height));
	glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, GetDepthBuffer(width, height));
}

Really? I thought I had this changed when transitioning the camtex rendering to an external frame buffer to create a dedicated depth buffer for the texture.

[code]
//===========================================================================
//
// Creates a depth buffer for this texture
//
//===========================================================================

int FHardwareTexture::GetDepthBuffer(int width, int height)
{
if (glDepthID == 0)
{
glGenRenderbuffers(1, &glDepthID);
glBindRenderbuffer(GL_RENDERBUFFER, glDepthID);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8,
GetTexDimension(width), GetTexDimension(height));
glBindRenderbuffer(GL_RENDERBUFFER, 0);
}
return glDepthID;
}


//===========================================================================
//
// Binds this texture's surfaces to the current framrbuffer
//
//===========================================================================

void FHardwareTexture::BindToFrameBuffer(int width, int height)
{
width = GetTexDimension(width);
height = GetTexDimension(height);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, glTexID, 0);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, GetDepthBuffer(width, height));
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, GetDepthBuffer(width, height));
}
[/code]

That's an artifact of a decade old hack in GZD. The render to texture implementation in the OpenGL backend always used the existing frame buffer zbuffer. As this varies in size it effectively meant only smaller texture sizes actually works, but nobody officially put a limit to what that size is - i.e. on a 1920x1080 monitor the max camtex size is 1080. The line you pasted puts the formal size limit to a 1024x1024 texture.

builder.setSize(1024, 1024);

Huh?

[code]
builder.setSize(1024, 1024);[/code]

Fix confirmed. Thanks!

I [url=https://github.com/coelckers/gzdoom/commit/e1ae8bbc594424a0e622ea908ff52231e52a9882]pushed a fix[/url] for the vulkan errors reported on my computer.

It never crashed here, but maybe that's what makes it crash on other systems.

Yep, this is a dupe. I'm going to merge them together.

Also - setting "gl_multisample 1" makes the map I was testing also not crash.

An added note: setting gl_multisample back to its original value after the map is loaded is ok.

So this seems to be a duplicate of what Rachael and I reported there: https://forum.zdoom.org/viewtopic.php?f=290&t=64420

More info on this: I tried reproducing with a fresh gzdoom.ini, and couldn't. I then did a visual diff and started re-adding the stuff from my old config (nothing of which is very unusual, just a few tweaks here and there), and identified the line that causes it to start hanging: setting "gl_multisample" to 4 from its default of 1.

Start GZDoom in windowed mode under gdb. When it hangs, switch to terminal where gdb is running and do Ctrl+C.
Check callstack with bt command. Try to step out from the current function with u command until it switches to GZDoom without returning to gdb.

Usage of any IDE like CodeBlocks or Qt Creator may simplify this investigation.

Likely the same as [url=https://forum.zdoom.org/viewtopic.php?f=290&t=64420]this[/url]. (Maybe this should be merged instead of closing as duplicate? Will let Graf or dpJudas decide)

steps to repro:
1. build latest GZDoom git master in Linux
2. run the latest build of my mod Mr Friendly (https://jp.itch.io/mr-friendly) with it, using the Vulkan renderer
3. open E1M1 on HMP skill
4. observe: GZDoom hangs, and the process has to be killed from command line (tty)

This does not happen with any combination of the following:
- OpenGL renderer
- Windows 10
- any map I've tried so far besides E1M1

Because the program freezes completely, I can't see anything useful in the log. The level appears to finish loading, as the last line is the map's name.
Happy to provide any needed info or do debugging on my own if someone can help me get started; I'm used to debugging conventional crashes (call stack and core dump) and zscript VM aborts.

[quote="XxMiltenXx"]I tested it myself and I think it's the same bug that I reported here, only that I get a more or less proper error message:
https://forum.zdoom.org/viewtopic.php?f=290&t=64422

So mine's a duplicate.[/quote]
I merged it in because your's provides more info. It can be split if you or I were wrong.

[quote="_mental_"]MAP09 is SPOOK09, right? For me it loads in pretty much the same time regardless of rendering backend.
BTW, what is this freeze exactly? Is it significant delay or just complete hang?[/quote]
Yes, MAP09 is SPOOK09 - it's referred to as SPOOK09 internally.

The freeze is a complete hang.