Thanks to a comment on the last post, the audio crash which affected some should now be fixed in version 6.1901.
Also, I investigated the reports of trouble capturing PS3 output, and there was something strange going on. It seems like in some conditions the BMI Pro 4k driver can enter an error state, and nothing will work until the next reboot. Anway, after some debugging I got 1080p5994 capture with full ARGB quality working on PS3:
I recently got an Intensity Pro 4k to replace my Intensity Pro, which served me well for more than 6 years. It has mixed reviews on the internet, but mostly because of one of two reasons:
- Noise, which was indeed terrible but is fixed completely by updating the firmware.
- Software compatibility, which I can’t speak for. I only use one piece of software and I make that one compatible if it isn’t.
BMI Pro 4k to the left, BMI Pro to the right
I have to say that the device has worked pretty flawlessly for me. Nice to finally get full RGB input and 1080p60 capture.
Of course, to actually make use of those features I had to release a new version of PtBi. Since it’s a pretty major upgrade I decided to call it version 6 now. More specifically, the release is 6.1877. In addition to supporting the new pixel formats PtBi should now also produce somewhat more useful messages on errors.
It’s still not quite user-friendly though. You have to select the pixel format and video mode with command line parameters, e.g.
PtBi.exe -disable-audio -pf=ARGB -mode=1080p5994. The supported modes are ARGB, BGRA and YUV (which is the default and only option in previous versions). I don’t support 10bit modes since I don’t need it — if anyone really does it shouldn’t be too hard to add.
I also pushed the current source to GitHub, what was there was completely outdated. It’s still terrible though, which is about what you’d expect from a project developed for a few days here and there over 6 years, and built on code even older than that. However, it does it’s job, and it’s the only thing which does that particular job, and I still use it all the time, so perhaps it’s useful to someone.
An article I wrote for PC Gamer has now come online:
The features PC gamers want — an open letter to developers and gamers
I really liked the idea for this article when I was first approached about writing it. While writing, I turned it from something addressed mostly at developers into also trying to make gamers understand the cost of features and how to interpret comparative performance across games.
The final article is about 50% longer than initially planned, but I still missed at least two important features, which I will shortly discuss here. I’d add those to the “important” category.
- Audio support: Just like with display devices, people use a lot of different audio setups on their PCs, both in terms of output and in terms of processing. Decent positional audio should be supported for at least the common speaker configurations and headphones.
- Custom Server Hosting / Server Browsers: For online games, supporting match-making is nice, but it should never be the only option in a PC game. Traditionally, PC games which offer the option to host custom servers and browse servers by various criteria have a much longer active online life and foster a stronger sense of community.
One thing I did certainly not expect is to get feedback from some developers within a few hours of the article going live. I know of at least three who are forwarding it to the relevant parts of their team (some having it translated even), and others have said that it’s nice to have something “official” (even if it’s just an article) to show the decision makers when discussing PC features. This is honestly already a much better outcome than I had expected!
Development on GeDoSaTo and PtBi
As some of you might have noticed, development on these projects has slowed down considerably over the past few weeks. This is primarily due to my “real world” work load, which has increased significantly due to the unfortunate confluence of the semester starting in October here (teaching), paper deadlines (research), and project proposals in-flight (shit).
I still try to merge external contributions to both projects regularly, so please help out if you can. My own situation should normalize somewhat in November, and allow me to work on them once again. (By the way, I actually wrote most of the article discussed above roughly two weeks ago)
Some recent emails reminded me that there are still people out there who use PtBi. It seems like AMD got more strict in their interpretation of the GLSL standard somewhat recently. This new version should hopefully fix that issue, and it also includes a few other things:
- Various sound bug fixes. This time around, audio is really fixed.
- A new, more readable console font.
- Statistical tracking of frame processing time and audio buffering.
- A snazzy overlay display for that information (the default toggle key for it is bound to “T”).
Here’s a screenshot:
I just released a new version of PtBi.
This is a minor update that should fix the audio problems introduced previously.
I just released a new version of PtBi (5.1729). It’s a minor update that adds a few small features people were asking for:
- A nearest neighbour scaling mode.
- The ability to bind keys to switch directly to a given AA or scaling mode (instead of going through the available modes step by step). See keys.ini for details and some examples.
More importantly, I also uploaded an initial commit of the PtBi source to GitHub. It’s probably a bit hard to get to build initially due to the dependencies, but I hope it is useful for someone.
I just released a new major version of PtBi, with 2 new features.
Dolby Digital 5.1 decoding
PtBi can now decode audio streams transmitted in Dolby Digital 5.1 format. Together with the existing DTS 5.1 decoding, this should now allow for true surround sound from almost any source. I believe that PtBi is the only Blackmagic Intensity capture program with this type of audio support.
This was easier than I expected, at least at first, because the decoding library functions very similarly to the one I used for DTS, but I was stuck for hours without any progress. It turns out that someone thought it would be a good idea to standardize a bitstream format such that it can be either big-endian or little-endian. Ugh.
In addition to the existing FXAA, PXAA and TPXAA post-processing AA modes PtBi now also supports SMAA1x. SMAA1x has slightly better edge quality and motion stability than FXAA. I’ll look into integrating SMAA with my predication filters at some point in the future.
Also, I plan to release the source code for PtBi soon-ish. I was always reluctant to do this, since some of it is based on code I wrote almost a decade ago which is pretty terrible, but I cleaned it up slightly now. And some parts of it, like how to integrate the AA modes in OpenGL or how to use the various libraries for audio decoding/playback might be useful to someone. Also, it could help people identify and solve problems with AMD cards, which are always very hard for me to test/debug without access to the hardware.
I just fixed the crash bug in PtBi introduced with the latest NVidia WHQL drivers.
If anyone from NV is reading this, I really don’t think having a:
uniform writeonly restrict image2D targetBuff;
Should cause the shader compiler to spit out this:
(7) : fatal error C9999: *** exception during compilation ***
It works just fine without the “restrict”.
Anyway, if you’re using PtBi with a NV GPU then you can find an updated, working version on the PtBi homepage. Sorry for the delay in fixing this.
It has been brought to my attention that the latest beta GeForce drivers break compatibility with PtBi. Since the error message they report isn’t particularly helpful, I’d like to wait until there’s a WHQL release to investigate this further.
For now, I suggest sticking with the 306.97 driver release.
The next release of PtBi (which I’ll make after the final release of the new driver, and after I fixed the issue if it still persists in that release) should also slightly decrease latency in some configurations.
I’ve wanted to measure this for a while, and since I was asked about it today I finally got around to doing it.
The question is this: how much latency does the BMD Intensity Pro Hardware/Software stack add to the captured stream? The answer I arrived at is 48 to 62 milliseconds, with an arithmetic mean of 56. This is on a 720p60 stream.
I measured this by mirroring my PC’s GPU output and feeding it directly to my monitor as well as to the BMD card via HDMI. Then I opened PtBi, disabled all postprocessing, and took a lot of screenshots like this:
Then it’s just a matter of subtracting the 2 numbers, removing the known latency introduced by PtBi (just a few ms) from that, and repeating the measurement.