[AdmiralRalwood]

I get the same.

[Swifty]

I think i'm just going to take out the fixed function checkbox in the lab viewer. All these new features make it really hard to easily switch between the two rendering modes during runtime.

[tomimaki]

I get too + I don't see damage lightning when enabled.

[DahBlount]

I just noticed this recently but, playing on this build with my motherboards automatic OC system causes the game to stutter. Is there any explanation or precedent for such a thing?

[Swifty]

Turn on Disabled batched model rendering in Troubleshooting

[DahBlount]

That helps a bit, there is still the occasional jump though. Is the problem with overclocking in general or because I'm using an auto overclock mechanism?

[CountBuggula]

That helps a bit, there is still the occasional jump though. Is the problem with overclocking in general or because I'm using an auto overclock mechanism?

In general the auto-overclocking is pretty reliable, but there are certainly applications that just have a harder time with it.  I know for instance that there are even some enterprise applications that require dynamic over/underclocking to be disabled in order to function properly.  Could be a situation like that, could be an issue with your CPU, as I use AMD CPUs with it enabled and haven't really run into the problem at all.

[DahBlount]

I haven't tried to manually overclock before, but the dynamic overclock feature does great with other games so I don't think it's my cpu. I'll write down some base settings and try manually overclocking in the near future.

[Spoon]

Okay so this isn't a bug, but its a quality thing that kind of bugs me (Ha Haaa).



It's the 'lod' of the shadow map (so to say, I dont know the proper term), its very easy to spot the very ugly transition on larger objects when you fly next to them, as it happens pretty much right under the nose. I think the easy fix for this is to just increase the distance for the quality transition. I dont know how much of a hit performance it would be, but some extra 500 range would probably go a long way to make this far less visible.
(Or maybe im just missing some quality setting and the default is set to be kinda low?)

Or maybe I'm wrong about all of these things and it actually is some kind of bug/oddity?
You tell me!

[FrikgFeek]

I don't think that's a problem with a quality swap(like you'd swap models). Looks like regular tearing to me and the FPS counter says you're under 60. Maybe shadows always update at 60 Hz, regardless of your framerate. That would also explain why the "higher quality" shadows appear to be smaller and not really higher in quality.

[Spoon]

No, thats not it, FrikgFeek.
And fps always takes a slight dip when taking a screenshot.

[Kolgena]

The shadow maps are cascaded, so that further shadows are lower resolution to save resources. Here, the transition is obvious. It's not screen tearing, and is probably much more obvious in motion, if it crawls along as your ship moves.

IMO looks like the problem is that the gaussian (?) blurring is tied to shadow texture resolution, so the effective blur radius is larger the lower the shadow texture resolution is.

There's also some blending oddities happening with overlapping shadows there. You can see some "bright" outlines/halos in the shadow under the big metal beam, particularly where the orange and tan metal plates meet. (looks like the silhouette of a house, sort of)

[Swifty]

there are ways to make the cascade transitions less obvious by sampling both cascades within certain thresholds. I wouldn't really say this is a critical thing to do but more like a nice to have thing later down the line.

[Phantom Hoover]

What're the dependencies for this thing? I'm trying to build it myself but I'm getting

Code: [Select]

cutscene/oggplayer.cpp: In function ‘void OGG_video_init(theora_info*)’:
cutscene/oggplayer.cpp:367:44: error: ‘shader_type’ is not a class or namespace
    int sdr_handle = gr_maybe_create_shader(shader_type::VIDEO_PROCESS, 0);
                                            ^

EDIT: oh, this is a build problem, not a dependency one. I have no idea what to do about this, then.

[AdmiralRalwood]

EDIT: oh, this is a build problem, not a dependency one. I have no idea what to do about this, then.

Latest code still builds fine for me: have an SSE2 build and an AVX build.

[Phantom Hoover]

Right, I should've mentioned that I'm trying to do this on Arch Linux. Is this build actually tested on OSes other than Windows?

[chief1983]

That did look like a Linux error and not a Visual C++ one.  It's possible that autotools just needs to have some source files added to it.

[Phantom Hoover]

Is that something I can try?

[chief1983]

I believe you could, I was going to test my theory on my Linux VM first before stating that's the problem though.

Code: [Select]

cliff.gordon@Cliff-Gordons-MBP:~/Freespace-Open-Swifty [shader_transform_deferred]  $ git diff origin/master HEAD code/Makefile.am
diff --git a/code/Makefile.am b/code/Makefile.am
index 8ca29fb..f05ef78 100644
--- a/code/Makefile.am
+++ b/code/Makefile.am
@@ -343,6 +343,7 @@ FS2_SOURCES =       \
        graphics/grstub.cpp     \
        graphics/grstub.h       \
        graphics/line.h \
+       graphics/shadows.cpp \
        graphics/tmapper.h      \
        hud/hud.cpp     \
        hud/hud.h       \
@@ -501,6 +502,7 @@ FS2_SOURCES =       \
        model/modelsinc.h       \
        model/modeloctant.cpp   \
        model/modelread.cpp     \
+       model/modelrender.cpp   \
        nebula/neb.cpp  \
        nebula/neb.h    \
        nebula/neblightning.cpp \

It looks like the .cpp files were added but not the .h files for some reason.  If you edit code/Makefile.am and add the shadows.h and modelrender.h by their respective .cpp entries in that file, it might just work.

[Phantom Hoover]

That doesn't seem to have helped, unfortunately.