Recent content by cwjs

DX12 (along with hlsl, dxc, and all of the rest of the ms rendering development stack) is updated all the time -- the fact that you see changelogs all the time for steam and never for developer APIs is because you play games on steam, but don't develop software.

Or, you know, use box/sphere/capsule collision primitives for high traffic stuff like every other game has for decades.

I don't misunderstand you -- why do you expect this to significantly improve your frame time?

This is a nonsense methodology. The goal of the geometry rendering pipeline in either alan wake or ue5 is to render a lot of triangles on screen in a small number of milliseconds. Nanite renders vastly more triangles at a similar speed, it makes no sense to compare some settings based delta...

Id wager money on “lots of raycasts” and “designer driven callback/event hell” — the ai behavior is very cool, very expressive, very reactive, and very unlikely to be architected well.

I get the disappointment, and I'm sure it's possible to get a game like dd2 running at 60fps, but if games with actually interesting and novel ai, enemy behaviors, environmental interactions, etc, are going to be cpu bound I give them a pass. It's easy to make a game with fairly simplistic...

Really impressive. The cuts to geo are a hard to see for the open outdoor environments but the town scenes look great.

it gets you 4ms at 30fps and 2ms at 60fps? Especially without VRR, 10% is a lot. An entire 2ms of cushion to keep a locked 60fps target is great, you can get a lot done in 2ms.

Not a necessary seeming remaster to me, the first game looks quite a bit better overall. Seems like they hit their locked target fps on all three platforms though.

Not a matter of can't, just don't, since different games' needs vary and a more general solution might not best fit your game's specific needs. Physics engines run on simplified versions of the world and do a limited number of specific comparisons in order to achieve the effect of a complete...

Hmm, if that's true game development might be a whole lot easier than I thought.

If it was that easy I don't think there'd be a market for middle ware like havok -- I don't know what (if anything) nintendo altered but a physics engine is not a pristine set of physical rules that applies equally to any kind of content or situation.

I suspect on fixed hardware this is more of an academic point than a practical one, you can schedule around whatever tiny infefficiency you encounter here, it’s unlikely to be a bottleneck in a real production. On pc any wrinkle like this much bigger challenge due to the variety of hardware...

Ubisoft's art team (and budget, surely) is a lot better than the team at ark, at a certain point any AAA game with up-to-date tech is going to look 100x more interesting, complex, layered, etc, than these early ue games.

This is not what's being said here. They're discussing significant overhead to pipeline binding, which brings challenges and could certainly cause a game to run slower, but is absolutely not the same as the api not providing options to reduce cpu overhead.