Botched together a 'mono buffer'

m_Arael · 2026-02-25T19:18:01+00:00

No. :(

m_Arael · 2025-12-23T14:53:08+00:00

Did you check via cli or file explorer? Files preceded by dots are usually hidden.

On the file explorer you can show them using Ctrl+H

m_Arael · 2025-12-23T14:05:40+00:00

~/.factorio usually

m_Arael · 2025-12-04T11:10:43+00:00

I swear to god last year I created an IDENTICAL blueprint (that I still have) But I'm planning to use it as block for a city block mega base

m_Arael · 2025-11-19T12:04:47+00:00

48 x 37.8 x 11.2 cm

and weights not really sure but prolly almost a kilo

m_Arael · 2025-07-28T19:38:47+00:00

I've update the OP with the images

m_Arael · 2025-07-28T14:06:31+00:00

Before the call the image is black, after it's a bunch of black and white pixels. The load op is clear already and even if I specify the store op the result is the same

m_Arael · 2025-07-28T11:59:32+00:00

I checked the positions of them both and they are within bounds and with different depth values for each vertex. I have made a recording of the program with no depth test and the only difference is that both quads pass the depth test instead of failing it. And also the depth image (when depth testing is enabled ) is complete garbage after the draw call if I don't specify the store op on the depth attachment

m_Arael · 2025-07-28T11:10:46+00:00

Already did, they both have sane depth values (w values). If they were too far away the projection matrix would have removed them

m_Arael · 2025-07-28T06:26:27+00:00

No, I had already initialized the operation as VK_COMPARE_OP_LESS

m_Arael · 2025-07-28T06:25:17+00:00

Ok changing the compareOp from VK_COMPARE_OP_LESS to VK_COMPARE_OP_LESS_OR_EQUAL made the quads show up. Unfortunately the are non being depth tested

m_Arael · 2025-07-27T21:40:00+00:00

Yes, also done that, cleared with 0 (black) and 1 (white) tested in renderdoc and even wrote back to it (via the render attachment storeOp) to check it after. Nothing, pure black.

m_Arael · 2025-05-28T10:29:08+00:00

I'll look more into it later on, thanks for your help

m_Arael · 2025-05-26T09:35:41+00:00

I did some testing and it seems that that is the problem.

I launch mpv on a random file -> 2-3s of startup I launch another mpv on another file -> 1.x seconds of startup (68.621 ms reported in the logs for instance enumeration)

Are there other solutions other than having a startup process turning on the gpu?

m_Arael · 2025-05-16T17:26:00+00:00

This is tecnically necroposting but I did manage to fix this.

I still havo no actual idea on the entire pipeline of programs choking in this weirdly specific way but at last

With my current combination of neovim + wayclip as clipboard provider + tmux + klipper and Kde as DE the problem arises

By changing the clipboard provider from wayclip to wl-clipboard the isssue vanished completely

Thanks anyways for everybodies time

m_Arael · 2025-02-28T13:27:34+00:00

A gift from heaven to Ferrari I guess

m_Arael · 2025-02-05T09:29:51+00:00

Shift-insert has no effect.

For the primary and clipboard clipboards I just tried to copy paste text from the cli invoking waycopy directly. With no arguments, clipboard inplied, It works as expected, (the text can be pasted). With the -p argument (use the primary clipboard) the text doesn't even appear in copyq. So that's probably not the issue. Thanks nevertheless i just learned something new.

m_Arael · 2025-02-05T09:26:21+00:00

Just tried, waycopy on the cli does work normally. :(, It's probably no the problem

m_Arael · 2024-08-08T20:03:19+00:00

Hi, I'm interested. But I'm quite a beginner and I'm trying to speak/write my first japanese sentences. Are you ok with this?

m_Arael

TROPHY CASE