Other CRT Options

29" Makvision CRT SVGA Arcade Monitor
Link: XGaming has these for roughly $500 and around $60 shipping to where I live.
Uses VGA input. Looks like there are three kHz spec ranges depending on version of display: {90 Mhz, 15-40 kHz or 30-40 kHz or 30-50 kHz (model C2929D1), 47-90 Hz, 800x600 max}. The peak kHz model might have capacity for 800x600 @ 80 Hz. Wonder what kind of persistence this display has.

Sony GDM-FW900 24" Widescreen CRT Monitor
Possible to find on ebay. Does {30-121 kHz, 48-160 Hz, 2304x1440 max}. Seems possible to do 960x600 at 160 Hz, and peak resolution around 80 Hz.


Oxide Games and Stardock talk DX12, Mantel, and Vulkan (GDC 2015)

Quick Thoughs on Strobbed LCD Displays for VR Perf Proxy

Using numbers from Alex Vlachos's Vive VR Talk at GDC, Vive with stencil optimization and super-sampling required for regular rendering: 378 Mpix/s (rectangular projection), or with just stencil optimization for ray tracing: 193 Mpix/s (derived from the Valve numbers, no 1.4x multiplier, shoot rays in warped view directly). Interesting that tracing or non-standard rendering tech might be able to leverage a 50% cut in the number of pixels to process.

Looking for a non-VR perf proxy? Something non-VR to target to get in the ballpark for frame cost for VR? For the regular rendering target: 2560x1440 at 100 Hz is still under the Mpix/s target. The 100 Hz figure is the highest ULMB strobbed refresh supported by the first strobbed IPS LCD panel: Acer XB270HU. Other than the viewing angle advantage of that IPS panel, it has roughly the same {gamut, brightness, etc} as the 1080p TN BenQ XL2720Z (roughly $450), and the TN has the advantage of supporting ULMB strobbed refresh all the way up to 144 Hz. For 1440p personally I think the larger BenQ XL2730Z is a better option than the Acer: the BenQ supports the VESA Standard Adaptive-Sync instead of being vendor locked for adaptive frame rate. Getting back to the numbers: 1920x1080 at 120 Hz is roughly 1.3x the "ray tracing" target for Vive, and 1920x1080 at 144 Hz is roughly 0.79x the "regular rendering" target (so would need some amount of super-sampling to be a perf proxy). It would be relatively easy to use the 1080p BenQ as a low persistence non-VR perf proxy for either case.



Awesome link: listing of large CRTs by size and refresh range.
For example,
NEC XP3791 (MultiSync XP37 Xtra) - 36". Apparently this via VGA cable can do 1536p max and 720p at 120 Hz.


Khronos Vulkan Presentation

GLAVE Demo: Debug tool for the Vulkan API

Really awesome to see great capture+replay+debug tools getting done in parallel with the API!


Vulkan (aka GLNext) Information Starting to Surface

Overview from www.khronos.org/vulkan
Khronos Reveals Vulkan API for High-efficiency Graphics and Compute on GPUs
As one of the members of Khronos directly involved in Vulkan, both at Epic and now continuing at AMD, I'm very excited about this API and looking forward to getting into more detail after the technical previews on Thursday!


NX Gamer Does Some Great In-Depth Technical Analysis

Great Example of Horrible API Interface Design

Linux gamepad support (via /dev/input/event) is one of the best examples of horrible interface design that I can remember. It should serve as a reminder of "how not to do it".

(1.) Sparsely Segmented IDs
Every large gap in a sequence of IDs say for input event codes has an associated increase in complexity for the developer: results in special branching, etc.

(2.) Mix of Same Buttons With Different and Similar IDs on Different Devices
There is a dead obvious common mapping between XBOX and PLAYSTATION controllers which should be used for common IDs. When instead the devices have subsets of different IDs for the same buttons, this results in angry developers.

(3.) The Same IDs Getting Used for Different Buttons on Different Devices
Another example of the same disease: creating extra complexity for the developer. The point of a interface is to reduce complexity. When the app needs to special case the device, right the app is now writing the driver too.

(4.) Using Base 10 Numbering Without Leading Zeros
Talking about the ordering of "event#" in "/dev/input/event" file names. Instead of something dead simple for a program like just "/dev/input/event##" where "##" is a hex number with a leading zero when under 0x10, lets instead make it base ten and require the developer to special case numbers under 10 (remove the leading zero). Fail.

(5.) Keeping Information Used Together On Unaligned Memory
For example, "struct input_id { __u16 bustype; __u16 vendor; __u16 product; __u16 version; };", it should be dead obvious that many developers would want to load "{vendor, product}" as a 32-bit value.

(6.) Providing No Good Way to Know if a Device is a Gamepad
The logic of the interface seems to be that developers need to keep an up-to-date {vendor, product} table for all current and future gamepads, this way they can write all the special case per device code required, or alternatively an even worse option of using a string table by device name.

(7.) Resorting To User-Space Daemons to Translate
Fantastic idea. First lets add extra latency to input. Second lets make it so that applications which handle the native /dev/input/event(s) manually now see duplications of the same device as some other kind of device, but with no obvious way to know the device was duplicated? Third lets push the problem to the user, creating another thing which needs to be configured by an expert and can easly go wrong.

Suggestions on How to Fix This Mess
Add INPUT_PROP_GAMEPAD so devs instantly know if the device is a "gamepad" or not. Any device which has the INPUT_PROP_GAMEPAD property uses a standard common set of contiguous input event codes.


The Order 1886!

This review contains no spoilers...

The Order 1886 is a fantastic game, one of my personal favorite games of all time.

Initially I was caught off guard by the doubt cast by various critics out to smear the game. They ended up doing me a favor, in that I now have a great list of online publications which I know to avoid spending any future time reading.

My quest started with a pre-order roughly 16 hours prior to launch. Followed by a playthrough on easy, beginning in early morning then wrapping a regular working Friday.

Why Easy? And a Word on "Replay Value"
When I want a gaming challenge, aka something on "hard", and something with "replay value", I take on the best humans I can find in competitive multiplayer: often in Call of Duty or Killzone. It is the people who bring you back, not specifically the game. The Order 1886 serves a different purpose in my eye, to provide a self-contained story experience which can be consumed, enjoyed, and remembered, and in this regard The Order 1886 excels. There is no expectation or need for replay value in this kind of game, just like there is no need for shoes to double as a toaster oven.

Quality Over Quantity
The game had the right length for me: not too long paired with high production value. To experience the ultimate in a given art form, to be immersed in attention to detail so fine that the mind is transplanted into the scene: this is where The Order takes you. The Order is a ride, part film, part cover shooter, with time inbetween to get absorbed in the style, sound, material and environment of years past. Gunplay feels refined, with fantastic audio/visual feedback expressed in the technology of the era. The focus on quality pixels brings The Order to a place no other game has yet to venture visually.

Too all those at Ready At Dawn, your hard work is much appreciated. Look forward to whatever you have in store next!