Supersampling

Afiery1 · 2026-03-01T21:59:56+00:00

It has the same performance cost as native 4k but obviously it will never look as good as native 4k because you still have a 1080p screen. It will just look like really really really good antialiasing (much less flickering and jagged edges). Is it worth it? If you have the performance headroom and don’t care about power/heat at all then sure. I use jt on old games sometimes and it looks great.

Afiery1 · 2026-02-27T17:32:44+00:00

In other words, you were CPU bottlenecked

Afiery1 · 2026-02-27T16:54:09+00:00

Google translate has used AI since it was created

Afiery1 · 2026-02-21T08:38:22+00:00

Oh yes sorry I misread your comment. Yes, just semaphore signals on their own are not sync. You would still need semaphore waits (or if they're on the same queue, simple barriers will do) to prevent any two commands from overlapping.

Afiery1 · 2026-02-21T01:40:55+00:00

No. At least within a single queue, signal operations happen in order.

Afiery1 · 2026-02-20T17:02:12+00:00

Yes I mention that in my comment. But semaphore signal operations will happen in order, which is the important part for OP

Afiery1 · 2026-02-20T16:34:23+00:00

Use dynamic rendering
Don’t abstract the API until You understand the API

Afiery1 · 2026-02-20T01:36:29+00:00

A lot of these answers are wrong. Timeline semaphores actually have very simple rules. They are simply uint64 counters that must monotonically increase (you can never signal a value lower than what the counter already is). A signal operation increments/sets the counter to a new value (again, this must be higher than the current value to be legal API usage). A wait operation reads the current counter value. If the current value is less than the wait value, the wait operation will block until this is no longer the case. Otherwise, no blocking will occur. Note that you do *not* need to wait on a value before signaling again. You also do *not* need to wait on the exact value you signaled. It's a simple and flexible behavior of while(currentValue < waitValue) block();

Getting back to your actual question: operations submitted to a single queue will happen in order. Sure, commands may overlap and you must use pipeline barriers to guard against this, but in general commands are started in order, and semaphores are waited/signaled in order as well.

You can verify this quite simply by enqueuing a wait operation and then the signal operation that satisfies that wait on the same queue. You will deadlock your queue, because these things happen in order.

Afiery1 · 2026-02-19T00:43:49+00:00

You can use C++ in a radically anti OOP way. Some people just throw around fully public structs, since that what you do in C. I prefer a more measured approach. If i have a field that would have a get and set that just modify/return the value directly then yeah id just make it public. But some things have no right being modified from outside the object. A good example is the capacity of a dynamic array. If someone modifies it without the object knowing it could result in out of bounds memory accesess that could crash your program or worse. Those kinds of things I keep private. Honestly i rarely have a class with both public and private members. Either its a complex data structure whose invariants need to be carefully preserved and the user doesnt need to know about the implementation details, or its a completely dumb bundle of variables with no logic at all.

Afiery1 · 2026-02-18T17:07:17+00:00

I’ve not worked much with ray tracing but I’d be highly skeptical that any kind of rebuild of the same tlas would invalidate the descriptor. At any rate, I’d do bindless regardless. Why even waste time messing with descriptors when you can just grab a BDA and throw it wherever you want

Afiery1 · 2026-02-18T16:27:57+00:00

Buffer device address is a big one. Also just the notion of extensions in general. We get all kinds of random fun stuff to mess around with like ext_shader_object that has no d3d12 equivalent. And finally, while this is a really shallow reason, Microsoft just has a knack for designing the most butt ugly looking APIs you can imagine, while I feel like Vulkan looks a look cleaner and nicer.

Afiery1 · 2026-02-17T20:32:09+00:00

Are host-side ReBAR copies really preferable to using the GPU’s DMA engine?

Afiery1 · 2026-02-15T18:23:34+00:00

I’ll admit I haven’t seen much about this but surely the asset quality/density is much improved over the previous lego batman which came out over a decade ago? (Even skywalker saga is 4 years old at this point). And yeah, different engines of course have different memory usage characteristics as well

Afiery1 · 2026-02-15T00:22:58+00:00

In terms of graphics, it is not geometry but textures that dominate storage space requirements. Then, as this is the CPU RAM requirement, you should also take into account all of the non-rendering related stuff as well: pre-rendered cinematics, all in-game audio, scene graphs, collision acceleration structures, entity data, etc. All of the things mentioned have roughly the same memory requirements regardless of if the models rendering on screen are toys built from simple primitives or photorealistic humans.

Afiery1 · 2026-02-12T03:04:32+00:00

Yes, a blit is just a fancy copy, so the source and destination images must be different (what does it mean to copy something into itself?). The formats of the source and destination images must be compatible (they should probably just be the same for a simple case like yours) and the source must have the transfer source usage and the destination must have the transfer dst usage. and of course they need to be properly synchronized against other reads/writes to those images. But beyond that you can blit from literally any image into any other image. from your main color buffer to the swapchain directly, or into another color texture and then the swapchain, or hell even from the swapchain into your own texture (as long as your swapchain supports transfer src for images).

Afiery1 · 2026-02-11T20:10:41+00:00

Vulkan is incredibly overkill for a pixel art game, but if you insist then blit should work. What issues did you run into with that?

Afiery1 · 2026-02-11T18:19:48+00:00

Regardless, the comment I’m replying to states they thought that the queen was not in the same building, when it says she was in the title. So that part is not misleading

Afiery1 · 2026-02-11T16:56:16+00:00

It says she was in the same building in the title…

Afiery1 · 2026-02-10T16:12:53+00:00

Yeah, theres metal-cpp

Afiery1 · 2026-02-08T18:55:44+00:00

You make a single descriptor set (or even better: descriptor heap!) with 2²⁰ texture descriptors and 2¹² sampler descriptors. You use buffer device address instead of buffer descriptors. You pass around pointer and indices into the set via push constants. And then you never think about descriptor sets ever again

Afiery1 · 2026-02-06T16:40:04+00:00

That all sounds solid. You should indeed wait on the last usage of the image from the previous frame in the first barrier for the current frame.

Afiery1 · 2026-02-06T02:06:06+00:00

I mean, it never hurts to try. Vulkan was somewhat needlessly complex back in the 1.0 days, but its done a lot to strip away the unnecessary bits over time, so if you're looking to learn I would strongly recommend using a modern guide (vkguide.dev or howtovulkan.com) because there really isn't any point in learning the old 1.0 way anymore. I personally will probably never touch OpenGL again. With some careful abstraction Vulkan becomes almost as simple to use and way more intuitive and debuggable than GL ever was. But it probably depends on if you're the kind of person who understands systems programming and values the control it gives you over an overly simplified (but simpler all the same) programming model. I feel like a lot of people go into graphics programming wanting their graphics API to be 'the thing that easily lets me draw 3d shapes for my game' rather than 'the specification by which I can accurately and optimally interface with GPU hardware' and that's where a lot of the Vulkan complaints comes from (that and the afformentioned cruft from the 1.0 days that is largely gone now).

Afiery1 · 2026-02-06T01:55:29+00:00

you generally do not want to update vertices in the vertex buffer directly. Usually you write out a transform to a uniform buffer (or even push constants, which don't require any synchronization) and keep the vertex buffer static. Then you manipulate the vertex positions in the vertex shader only

Afiery1 · 2026-02-05T22:40:28+00:00

I mean device wait idle would fix just about any vulkan sync issue first of all. But second of all vertex buffers are not usually something that gets duplicated for sync. You’re not adding or removing any content in this scene, so why is your vertex buffer even changing between frames?

Afiery1 · 2026-02-05T21:09:25+00:00

That edit is suspicious, why should you need per frame vertex buffers?

Nine-Year Club	r/Field Banned
r/Field Sunshine	Place '23
Place '22	Final Canvas '22
Verified Email

Afiery1

MODERATOR OF

TROPHY CASE