I haven't noticed any changes to the layout, only thing I would say is that it looks a little brighter...maybe?
The old one was almost rollercoaster like. So many dramatic changes of elevation. Pretty impressive difference!
That's actually useful to know, we were looking at a similar issue that happens on trees in DXVK (also happens for NV in DXVK btw). Let's hope we can do something about it
Yes, on trees with AT that's usual because their intricate cutout nature usually causes the alpha channel to have some gray values, and even if you have a clearly cut out alpha for the main diffuse, then the mip map alphas can need some optimization to avoid large gray areas automatically introduced on downscale, where it was mostly 0/255 on branches and stuff. That extra contrast can make so that trees don't look completely dithered as a whole at greater distances instead of just around detailed cutout zones. Some export tools offer options for that, like the NV Texture Tool Exporter ("cutout alpha", "scale alpha for mip-map coverage" at the bottom. I've been away from AC modding for long so haven't tried them). That partially dithered look on AT trees it's something I've always got with an AMD card (Polaris, and now RDNA2) in native DX11 titles like AC or now LMU, and the number of different dither patterns to approach transparency levels directly depends on the MSAA setting. IIRC in those instances NV cards behave differently and can render some mid transparency steps (also dependent on MSAA levels), I don't have any close to check atm. I guess then under DX9>DXVK they'll behave like AMD cards do in many DX11 native titles, and resort to dither. AMD users will just find it normal .
I don't know if this is the appropriate place to comment, but since you're commenting on the topic of DXVK... I've noticed that the exhaust smoke from the Porsche 934 is much blacker and thicker in DXVK compared to DX9.
OT: On that matter, I've just A-B's them, if it's of any use. I've seen the same comment before, but can't reproduce an obvious difference now on a RDNA2 (6700XT) and before on a Polaris (RX480) where I had already checked. And just to be clear, I'm using DXVK 2.3.1, just the d3d9.dll placed in raceroom racing experience\Game\x64, and a dxvk.conf in raceroom racing experience\Game (in RE3 needs to placed one folder above) with: Code: # dxvk.hud = fps,frametimes,gpuload # dxvk.hud = devinfo,fps,frametimes,gpuload,api,version,memory,compiler d3d9.maxFrameRate = 72 d3d9.maxFrameLatency = 1 to introduce a lower frame limiter on a 75Hz FreeSync monitor to avoid vsync lag, and reduce pre-rendered frames, but it shouldn't affect visuals. First two hud/debug related lines aren't active. It's not humanely possible for me to screenshot at the exact same animation frames, but I tried to match two caps on idle and within a burst of smoke right before the first exhaust flame as it starts to rise. IMHO, they look to have similar transparency/density, taking in account differences in animation time frame and overlayed smoke frames (DX9>DXVK): The proper way to do this would be matching frames of videos, if you wish to check it further . What card to you have? Could it be only happening on NV cards, and/or from the start in DX9 it'll look less dense vs AMD? PS: In regards to the previous post, under native DX9 the way AT alpha rounds to one of the absolute values instead of dither (as in DXVK) causes the fence detail to completely disappear.
Shortly interrupting the tech talk to say thank you for bringing us the adjustable abs settings with this update. Didnt like how the abs cars felt since december but now ive played around with the settings a bit and can finally properly enjoy them again Now off to do some laps on the nordschleife and the tech talk may continue
I've an Nvidia card (RTX 3060). I'll try to take some screenshots or record a couple of videos to show the differences. But it's a very obvious difference, the light gray smoke in DX9 turns into thick black smoke in DXVK.
I've confirmed this on my 3080, smoke turns black in DXVK. Let's move the DXVK talk to the old thread about it, these comments are quite helpful, as we are looking into supporting it a bit more: https://forum.kw-studios.com/index....-improve-performance.18014/page-2#post-249227
if you look at the abslevel property you will see that it reports unsupported. always used in other situations and games. unless they called it something else.... key assignment works perfectly
The track in the new Portimao version seems to be wider than in the old version. Some of the corners are less cambered than before and in general, the height differences seem to be less pronounced. The surroundings are completely different anyway.
to be sure, did you check the link in the changelog to the github with the example/info? don't copy/paste from another game, always do it game by game
no because it mentions abslevel which is a standard property that exists and reports still unsupported. i will look into it but if you know what they called it tell me