Page 1 of 2

DgVoodoo, recording, and general quality & performance considerations

Posted: Sun Apr 22, 2018 11:41 am
by Mechanist
I've been experimenting with recording OOTF gameplay, and here's what I've learned so far.

I'm using Radeon ReLive for recording - it's free, and seems to be doing a fairly good job; nVidia users have Shadowplay, which has largely the same functionality.
At 1920x1200, 59fps and maximum bitrate, the video quality is only very slightly (nearly imperceptibly) worse than what the game outputs, and the resulting footage takes up only a few GB per hour - a far cry from Fraps, which does around 2 orders of magnitude worse!
The performance hit due to recording is only a few %; totally irrelevant in this case, considering that without the limiter I'm normally getting 80-300fps in OOTF, with forced 4xEQ FSAA + 8x anisotropic filtering, on my R7 260x.
But using 8xEQ FSAA + 16x anisotropic causes it to dip as low as 40-50fps sometimes; even though >90% time it's still above 59fps.

I've tested this with dgVoodoo (which only does MSAA, not FSAA) - as well as without dgVoodoo, but with forcing FSAA + anisotropic through Radeon Settings.
Performance-wise, it's about the same.
Quality-wise, it's also very similar for the most part; a careful side-by-side comparison reveals very little, if any, difference - however, dgVoodoo makes the smallest text appear rather blurry, whereas by using Radeon Settings it stays properly sharp.

Out of curiosity, I also tested the 10th Anniversary mod (and also forcing 4xEQ FSAA + 8x anisotropic, on top of it): with the shaders disabled, I'm getting a solid 59fps pretty much everywhere.
After enabling the shaders, I still get 59fps most of the time, but in some areas it can then dip as low as 30fps - still very much playable, but not too great for an HD recording.
Of course the bump mapping has to go for that, and there are still minor graphical glitches (eg. some thin straight white lines forming a "broken frame" around the moons); as well as noticeable straight line patterns on the ground (due to the texture seams?).

Other observations:
  • Do not enable lens flare effects - not only they appear to not work in the first place, but also cause weird lag spikes at times.
  • Disabling the framerate limiter caused significant microstuttering at such high fps (likely due to frame timing inconsistencies?); effectively degrading the perceived framerate roughly by an order of magnitude.
  • AMD ReLive has serious stuttering issues when trying to record 24-bit audio. Don't even bother. 16-bit sounds perfectly fine, too - and at least it records properly.
  • ReLive also can't record the desktop (nor a subset of it, such as a game window) under Win7, if a non-Aero theme is being used - and then returns a very misleading error message. Just switch to Aero for doing whatever you want to record, and switch back when done. Fullscreen recording is not affected, either way.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Tue Apr 24, 2018 11:38 pm
by UCyborg
lens flare effects
You know the setting works if you see those green round light shaped things in this scene:

As for the actual thing known as lens flare (notice the circles):

From what I can tell, the effect may not render with modern drivers through legacy Direct3D, but works with dgVoodoo (with lag spikes). Would be good to know the reason for lag spikes. This setting is enabled by default, so we might assume that it didn't cause issues on the hardware of the time.

I ran the game on the PCem emulator with Voodoo 2 card, though things were too slow there to be able to tell if this setting had any significant impact. FPS was around 15 constantly regardless of the setting (if that tells anything).

I remember having crashes with this setting on the old ATI Radeon HD 4890 as well as with much older NVIDIA GeForce 4 MX 440 card (2002 era, so only 3 years younger than the game). I don't remember if the effect rendered correctly on either card or if there were lag spikes. No crashing problems in the emulator from my quick testing.
ReLive also can't record the desktop (nor a subset of it, such as a game window) under Win7, if a non-Aero theme is being used - and then returns a very misleading error message.
The message being that the desktop composition is disabled? If so, then that's the accurate description of the state of things. Classic and Aero Basic themes tend to work that way on Windows 7.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed Apr 25, 2018 4:20 am
by Mechanist
Interesting. Seems as though it warrants further testing on my part.

I didn't notice any of those effects in the bonding cutscene when using dgVoodoo, but I was getting a bunch of lag spikes (FPS momentarily dropping to ~25-40) when the lightning effects were visible, and the "lens flare effects" option was enabled.
Disabling it prevented the lag spikes (solid 59FPS throughout), but I didn't notice any visual differences.

I'll experiment with that a bit in the next couple of days.

EDIT: Done some quick testing.
With dgVoodoo + lens flare effects set to "enabled", the graphical effects are there, but there are bad lag spikes.
Without dgVoodoo, the setting has no effect; regardless of what is selected, there are no lens flare effects being rendered, and also no lag.

As for the ReLive error message - I consider it to be very misleading, because it assumes that the user has a decent technical knowledge of the operating system's inner workings. But this kind of assumption is absolutely unreasonable in a consumer setting. Gamers, maybe; but certainly not the general public.
The usual reasoning goes more like this: "Can't record desktop when desktop compositions are disabled" :arrow: check options: "Desktop compositions = enabled" and the relevant service is running; all looks good :arrow: recording still doesn't work :arrow: WTF do you want now, AMD? :?:
The only reason that I was able to fix the problem at all, is because I randomly stumbled upon a YT video which showed the actual cause.
All the other "fixes" pointed to enabling desktop compositions in the options, which wasn't even the problem here. :evil:

Would it have killed them to change the wording to "(...) when desktop compositions are disabled, or a non-Aero theme is being used"?
Sadly, the Radeon control center has a lot of other problems with bad/nonexistent descriptions: a lot of the settings have either only a very brief explanation, which doesn't really explain the important facts, or no explanation at all. :evil:

A "good" error message should at least point in the right direction for solving the problem, which certainly isn't the case here.

There's a similarly aggravating problem with our CNC/CAM software at work: if the XY coordinates of the tool height sensor are defined outside the machine's allowed range of motion (which happens very frequently in a production setting, due to copy-pasting older machine config files to newly built machines), then attempting to execute any G-code causes the machine to just sit there like a lemon, not moving even a single micrometer, and immediately throwing the following fault: "Error! Machine did not reach the position specified".
Yeah, thanks - that's very helpful for solving the problem, really. :evil:
Which position? At least give me the XYZ coordinates, dangit.
And the position of what, anyway? There are tens of other possible culprits in the machine config file!

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed Apr 25, 2018 4:47 am
by UCyborg
Interesting... On my end, without dgVoodoo, there are no lens flare effects and no lag spikes when enabled. dgVoodoo gets me both. Same story on a laptop with Radeon R2.

Agreed, that message is a bit technical.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Mon Apr 30, 2018 11:05 am
by Mechanist
Regarding the lens flare effects: I've done some testing; please check my previous post for details.

In other news, I have partially solved the issue of audio levels being very weak when recorded through ReLive. :|
This is a general problem, not at all specific to OOTF.
Not sure if it's caused by my Asus Xonar, but ReLive generally has rather poor audio recording support, so it's probably just that.

It turns out that ReLive is being too zealous, and captures the audio stream at the last possible point - which is to say, after ALL of the effects (including the output volume control; usually set to around 10% in my case) had already been applied! :evil:
What on Earth were the AMD programmers thinking??? :shock: :shock: :shock:
In hardware terms, it's more or less the equivalent of connecting the audio output directly to the line input with a short cable, and recording the line input; of course actually doing that would cause extra signal degradation due to the analog/digital conversions, but you get the point.

This also had the very nasty side effect of applying my EQ settings to the captured sound stream. :!:
Playing the recording back caused the EQ to be applied, again, over the already-equalized (and highly level-reduced) recording, resulting in an auditory experience comparable to listening to a cat farting underwater, while having a banana inserted in each ear. :x

Unfortunately, there is no way to fix this from either ReLive, or the Xonar DGX control panel. :evil:

There's an easy workaround... kinda: use an audio loopback driver (sort of a virtual audio cable), have ReLive capture that instead, and have an audio repeater set up so that the sounds play normally through the soundcard.
Of course OOTF must be set up to use the audio loopback device, instead of the real soundcard. :!:

It's a bit fiddly, since the audio repeater needs to be active every time OOTF is started, otherwise it isn't possible to hear any of the game's audio output - it still records just fine in such a case, just can't be heard while playing.

However, there's a catch: when doing that, EAX support is lost :x
I'm currently looking into a way to keep EAX and record the audio without the EQ and without the volume level being changed...

At this moment, it looks like the only quick solution is to disable all audio effects in the Xonar control panel, set volume sliders to get the correct audio level in the recording, and do NOT touch the system volume control!
Of course this requires using some form of hardware volume control between the soundcard and the headphones... preferably a hardware EQ, as well, otherwise it sounds like utter crap.

Another idea - a real kludge, but maybe it'll work?
Reenable the onboard audio, route the output from the Xonar to the onboard's input via a virtual cable. Use the onboard for EQ and volume control.
Though this be a method, yet there is madness in't!

Final idea, which is a workable compromise between these 2:
  • Insert a 10:1 level attenuator inline with the headphone cable, to bring the typical volume control setting into the 50-100% range - this avoids degrading the signal resolution by about 3 bits due to the very low signal level. (wouldn't be needed when using 24-bit audio recording, but sadly that doesn't work in this case)
  • Keep the EQ active, and create a custom EQ preset in GoldWave, which is an inverse of the system EQ setting.
  • Record as normal, but do NOT touch the volume controls - it would mess up the recorded audio!
  • Now extract the audio track, open it in GoldWave, apply the conjugate EQ preset to cancel the effect, then correct the volume level, and reinsert the track into the movie file.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed May 02, 2018 1:23 am
by UCyborg
What about OBS Studio ?

With dgVoodoo + lens flare effects set to "enabled", the graphical effects are there, but there are bad lag spikes.

I notified Dege about the problem over on VOGONS forums, though he's busy with other things, so it may take a while.

These effects however work with 10th Anniversary Mod without lag spikes. One thing it gets right! Having a general purpose wrapper to convert the game to Direct3D 9 would be nice. I'm only aware of crosire's D3D8 -> D3D9 wrapper.

Would be good to figure why those effects break in the first place. At least with the black menu background bug, one of the DirectDraw functions returned an error code.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed May 02, 2018 6:07 am
by Mechanist
OBS was one of the alternatives I had been considering from the start.

As of right now, the primary reasons that I'm using ReLive are:
  • It's free,
  • Very easy to set up,
  • Miniscule performance penalty when recording, at least with my hardware.
So yeah, that's very nice about ReLive - despite me having had exactly zero experience with computer AV capture until then, it only took all of a few minutes to get everything ready for recording.
Well, that's if we don't count this audio issue - but it can't all be that easy, can it?

As for OBS, one thing that discourages me is that I can't seem to find a simple, step-by-step "quick start guide".
It's similar to the situation with our proprietary CAM/CNC software we use at work: most of the UI has no tooltips or labels of any sort, only cryptic and somewhat arbitrary pictograms. However, it's actually very easy to use once you know which button does what; but good luck with that if you don't have a manual at hand - or better yet, someone else to explain it first.

The audio virtual loopback device would've been the perfect solution to this problem... if if weren't for a loss of the hard-won EAX support :(

The more I test it, the more I start to think that it's actually the soundcard's fault.
It seems that the root of the problem is due to the audio level on the "Wave" loopback input being both very low, as well as directly dependent on the volume setting.

And after that fiasco with the Creative Audigy FX, I'm not particularly amused by the prospect of replacing the soundcard... again.

I think I've come up with a combination of hardware and software workarounds that will do the job without causing me undue aggravation (only some minor aggravation!), so I'll be testing that out in the upcoming weeks.

As for the lens flare effects, I find the whole problem highly baffling. It's just a couple of blurred circles and scaled transparent sprites, so why is it causing such issues?

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed May 02, 2018 12:07 pm
by UCyborg
As for the lens flare effects, I find the whole problem highly baffling. It's just a couple of blurred circles and scaled transparent sprites, so why is it causing such issues?

Only thing I'm sure about, Drakan is special in some ways. They only started working at all with very recent dgVoodoo versions. There's Lens Flare Demo (flare.exe) in DirectX 6.1 SDK, this one works flawlessly.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed May 02, 2018 12:33 pm
by Mechanist
I'd say it sounds like a bad case of reinventing the wheel, then?

"Sure, why use the tried-and-tested reference implementation that everyone else had been using, when we can whack something together ourselves?" :roll:

I see a lot of that kind of attitude at work (but relating to hardware, as in: machine parts), and it drives me nuts. Invariably turns out to be a huge waste of everyone's time and money.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Wed May 02, 2018 1:05 pm
by UCyborg
From what I've read, graphics driver devs must implement a lot of hacks in their drivers to workaround issues in games that are not doing things correctly. And when things evolve, things just get worse, especially when it comes to legacy compatibility. Not sure if that's the reason, but it seems plausible. Ya know how MS supposedly promised in the old days Direct3D will give great backwards compatibility. Graphics drivers are insanely complex.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Fri May 04, 2018 10:19 am
by Mechanist
Good news, everyone! :wink:

I've managed to find a purely software workaround for my audio recording issue. It's quite crazy in its execution all right - but most importantly, it works!
It's quite complicated, so I'll spare the details, unless someone's interested. For now it's sufficient to say that it involves a clever abuse of Equalizer APO.
And a nice side effect is that it can also apply an equalizer to the microphone input in real time.

The only (minor) problem is that when recording, I need to have the Dolby Headphone effects disabled - but that's pretty much inevitable with this setup.

This method works just fine for recording the (singleplayer) gameplay footage and/or the microphone, even as separate tracks (but only those two sources).
However, it falls flat on its face for recording the multiplayer, since that's when you throw in another source of audio output (eg. Skype) which has to be recorded as a separate track, yet which I still need to be able to hear in real time.

It would be a rather trivial issue to solve, it if weren't for the fact that the easy methods (using virtual audio devices) cause EAX effects to be unavailable. :x

EDIT: I've tested one of 2 most obvious solutions (the software one), and it works perfectly fine!

It involves using the dreaded onboard Realtek sound chip as a second-stage mixer, so that I can record the sources separately (with EAX effects functioning in Drakan), and yet hear both the game audio and Skype at the same time, while recording all of the tracks separately!
Of course this still requires replugging the headphones into a different socket, so it's not strictly software-only; and the output level is rather low, since the Realtek card lacks a built-in headphone amplifier - but I can live with these minor drawbacks, since I only really need to use this method once.

For reference, here's the (grossly simplified) final setup for this kind of multi-track recording:
  • Create a virtual audio cable (as in, a loopback device): {virtual line out} :arrow: {virtual line in}
  • Select {virtual line out} as the default Windows sound output device. This is required for these applications which expose no means of audio device selection - which, as it happens, is a lot of them.
  • Start one instance of an audio repeater. Connect {virtual line in} :arrow: {Realtek onboard speaker output}
  • Start a second instance of the audio repeater. Connect {Xonar's internal, horribly broken "Wave" "input"} :arrow: {virtual line out}
  • In Riot Engine Options, select the Xonar DGX as the audio output device to use, and enable EAX effects (but GX mode must be enabled in the Xonar control panel!)
  • Now both of the sound sources (OOTF & voice communicator app) are mixed together by the virtual audio cable, but can still be recorded separately! (for more independently-recordable sources, just add more virtual cables and audio repeaters, as needed)
  • Kinda optional: use Equalizer APO as a real-time workaround for Xonar's badly broken wave capture support, and/or to equalize the mike. Also turn on HF mode in the Xonar control panel, to disable the Dolby Headphone effects.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Sun May 06, 2018 3:29 pm
by UCyborg
I tried Drakan on Windows XP x64 yesterday and got some curious results. Lens Flare Effects would sometimes work, sometimes not. Restarting the game was not a guaranteed fix. When they worked, forced anti-aliasing made them visible only when looked from certain angle (from below).

The game also crashed in system DLL (ntdll.dll) once when loading a saved game. I didn't have debugger at hand so don't have any more details. Running it fullscreen would also sometimes make mouse cursor choppy in menu. I only get consistent choppiness on newer Windows versions if I force anti-aliasing. Happens on XP randomly without anti-aliasing. May be fixed temporarily by tabbing out and back in. The choppiness in menu in general has something to do with combination of Drakan's menu background feature and NVIDIA drivers. At least I never got it with ATI card on newer Windows versions, no idea if it's any different on XP.

Using NVIDIA driver version 368.81, last version for XP.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Sun May 06, 2018 3:43 pm
by Mechanist

On that old system I had XP x86, and never noticed any such performance issues - although I think that I never forced antialiasing or anisotropic filtering before; at least not until that test a few days ago.
Don't remember which nVidia driver version, but probably a few years old by now.

On Win7 x64, performance is consistently very smooth in fullscreen, with AA+anisotropic forced through Radeon Settings. Haven't tried in XP x64 yet, though.

Guaranteed atikmdag.sys BSOD on startup, at least on this system, if both CrossFire and ULPS are enabled. Haven't tested after disabling ULPS, because what's the point? It's not like CrossFire would work in OOTF anyway.
Disabling ULPS did fix all the atikmdag BSODs in a few other games, though :D - including Alekhine's Gun and Divinity: DC.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Mon May 21, 2018 4:09 pm
by UCyborg
One laptop that has Intel Core i3-3110M clocked at 2,40 GHz and Intel HD Graphics 4000 shows significantly better results natively than through dgVoodoo. Intel's CPU single-threaded performance really helps with Drakan. Intel's 2,40 GHz really blow my AMD's 3,00 GHz out of the water. :D Also my AMD is 3 years older (Phenom II X4 920, slight overclock, from the time AMD was getting a little better). The minimum FPS was about 10 frames higher on Intel. On my AMD, there were dips to 30 FPS when being bombarded by enemy dragons.

Re: DgVoodoo, recording, and general quality & performance considerations

Posted: Mon May 21, 2018 5:45 pm
by Mechanist
Good news, everyone! :mrgreen:

After a lot of trial and error (mostly error, though), I've figured out the recording setup required to successfully record all the audio tracks separately, while keeping the EAX effects active - and it works now!

3 audio processing tools are required for this:
  • VoiceMeeter Banana (thanks for the help with that, Killy!),
  • Virtual Audio Cable - use it to create 2 virtual cables (one with 2 channels, and one with 6),
  • Audacity, or some other program with similar recording capabilities. Highly recommended if you want to record for more than approximately 1 hour in a single session.
Also required: a second soundcard. Can be an onboard audio device, or whatever other cheap soundcard is easily available; you only need it for the physical audio output it provides.

Connect as follows:
  • Drakan audio output device :arrow: your EAX-enabled soundcard,
  • Discord audio output :arrow: virtual cable 1 "line out",
  • Your EAX-enabled soundcard's "Wave In" device :arrow: VoiceMeeter physical input 1,
  • VoiceMeeter physical input 1 :arrow: BUS A1 & A2,
  • Microphone :arrow: VoiceMeeter physical input 2,
  • VoiceMeeter physical input 2 :arrow: BUS A2,
  • Virtual cable 1 "line in" :arrow: VoiceMeeter physical input 3,
  • VoiceMeeter physical input 3 :arrow: BUS A1 & A2,
  • VoiceMeeter A1 bus output :arrow: your other soundcard's speaker/headphones output,
  • VoiceMeeter A2 bus output :arrow: virtual cable 2 "line out" (this is the crucial step that makes this whole setup work!),
  • Virtual cable 2 "line in" :arrow: Audacity audio input device,
  • Physically connect your speaker/headphones jack to the 2nd soundcard's output socket.
Banana settings part 1.png
Banana settings part 1.png (135.61 KiB) Viewed 3178 times

Then patch the audio channels in the VoiceMeeter System Settings menu as follows:
  • IN#1 LEFT :arrow: BUS ch1,
  • IN#1 RIGHT :arrow: BUS ch2,
  • IN#2 LEFT :arrow: BUS ch3,
  • IN#2 RIGHT :arrow: BUS ch4,
  • IN#3 LEFT :arrow: BUS ch5,
  • IN#3 RIGHT :arrow: BUS ch6,
  • Leave the BUS ch7 & ch8 unconnected.
Banana settings part 2.png
Banana settings part 2.png (59.62 KiB) Viewed 3184 times

Keep the following in mind:
  • Do NOT use Banana's recording feature; it only records uncompressed multichannel audio. After about an hour, you'll hit the 2GB hard limit on the file size, and irretrievably lose the remainder of the recording!
  • Apparently using the BWF format makes it possible to record files >2GB in size, but it's still an uncompressed recording...
  • Remember to set Audacity up to record all 6 channels.