diff --git a/20150111.html b/20150111.html new file mode 100644 index 0000000..55af805 --- /dev/null +++ b/20150111.html @@ -0,0 +1,67 @@ +
+

20150111 - Leaving Something for the Imagination

+
+ + +Lack of information can invoke the perfect reconstruction of the mind. +For visuals, seems like the deepness and slope of the uncanny valley is proportional to the spatial temporal resolutions of the output device. +This 4K and eventual 8K crazyness, while awesome for 2D and print, has an unfortunate consequence for real-time realistic 3D: +available perf/pixel tanks simultaneously as required perf/pixel skyrockets due to the increased correctness required for perceptual reality.
+
+The industry continues to shoot itself in the foot focusing on quantity instead of quality, +raising the baseline cost required for digital 3D content to climb out of the uncanny valley.
+
+The industry also seems to be on a roll reducing the quality of display technology. +Sitting through an "IMAX" film at a DLP based theater destroyed the respect I had for that brand. +Paying extra for a "cubism" filter applied to what otherwise might have been a good experience is not what I had in mind when going to the theater. +Quite a shock for someone who grew up with analog IMAX and OMNIMAX (IMAX projected in a dome).
+
+Scan-and-hold LCDs have killed the quality of motion, and strobed LCDs have insane frame-rate requirements compared to a similar experience on a CRT. +With typical HDTVs and LCD displays, 60Hz sits in the no-man's land +between having more perf/pixel for something visually interesting, +and having enough frame-rate on a scan-and-hold device to remove enough blur in motion (120Hz and higher required). +For this scan-and-hold generation the true purpose of the "motion-blur filter" +is not to add realistic motion blur, but remove enough visual quality to mask the distortion caused by scan-and-hold in motion.
+
+Making Lemonade +
+Display technology trends provide a powerfull polarization: +general flexible rendering solutions attempting to solve all problems will result in mediocre results +(jack of all trades and the master of none of them). +IMO everything interesting can only be found by sacrificing something +others view as required, +but which enables you to do something otherwise impossible.
+
+Giving up frame-rate, for example the hot path for realistic rendering on PC: +leverage variable refresh rate (to be able to simultaneously maximize the quality of animation and GPU utilization), +render letterboxed around 30Hz (to maximize perf/pixel), +run all game logic on the GPU reading input from CPU-filled persistent mapped ring buffer (minimize input latency), +use heavy post processing like motion blur and extreme amounts of film grain (remove enough exactness to invoke the mind's reconstruction filter).
+
+4K presents a serious problem in that in-display up-sampling can add latency, +and often in-GPU-scan-out or in-display up-sampling is total garbage (for example too strong negative lobe adds a halo effect). +The way I'd tackle the 4K display is actually the oppsite of convention: +output native but use the increased resolution to simulate a synthetic CRT shadow mask +or maybe a very high ISO film (massive grain), +to reduce the required internal target resolution to something under 1080p. +On that topic, the majority of the trending "pixel art" games completely missed the point of the arcades: +ultra-low-latency input with constant frame-rate (not possible on mobile platforms or in browsers), +arcade joystick input (something well-grounded and precise which can take a pounding), +and high-quality non-block pixels produced by a CRT.
+
+My personal preference is for the most extreme tradeoffs: +drop view dependent lighting, go monochome, drop resolution, drop motion blur, drop depth of field, no hard lighting, no hard shadows, +remove aliasing, add massive amounts of film grain, maximize frame-rate, and minimize latency. +Focus on problems which can be solved without falling into the valley, +produce something which respects the limits of the machine, +and yet strives for timeless beauty. + + + + + + + +
+ + diff --git a/20150221.html b/20150221.html new file mode 100644 index 0000000..b436443 --- /dev/null +++ b/20150221.html @@ -0,0 +1,58 @@ +
+

20150221 - 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. +
+ + + +
+ + diff --git a/20150809.html b/20150809.html new file mode 100644 index 0000000..9753e41 --- /dev/null +++ b/20150809.html @@ -0,0 +1,46 @@ +
+

20150809 - 1536-4 : Coloring

+
+ + +Night 4 on 1536. +Brought up most of the "x56-40" (x86-64 in hex) assembler now. +Also have majority of the forth-like words needed to assemble self-documenting constants {add,mul,neg,not,and,or,xor,...}.
+
+(Lost Image When Minus Went Down)
+
+Started on the editor. +Just enough of a quick prototype to render the text view in the editor (sans cursor for now). +All screens on this post are captured from the editor running in an x86-64 emulator. +Keeping the fixed 64 character lines makes everything very simple. +Syntax highlighting was carefully designed to only need one line of context. +Just a simple backward sweep to color, then a forward sweep to correct the color for comments (the \ marks rest of line as comment). +Adjusted the font, {_,-,=} all now extend out full font cell width so they can double as lines. +Adjusted the colors closer to what I like for syntax highlighting. +Still experimenting with how to comment and arrange source.
+
+
+
+Have 16 characters to the right of the source window to use for real-time debug data. +Like viewing values of registers, memory, etc. +Thinking through details in the background. +Next step is to bring up the non-USB throw-away keyboard driver, +then get the editor functional.
+
+Bugs +
+Still finding the no-errors, no-tools, know-everything path, easy to work with. +This time lost some time to an opcode assembly bug. +A full class of opcodes was broken, something never validated from last time, just forgot to make a RIP relative offset RIP relative for non-branch instructions. +Everything else working out of the box with no human errors. +When the mind can reason about the entire system, +and the edit/execute loop is near instant, +bugs normally are instant fix. +Quite satisfying to work this way. + + + + +
+ + diff --git a/index.html b/index.html index 341b819..11d9f86 100644 --- a/index.html +++ b/index.html @@ -79,16 +79,22 @@ Below this is active random migration (373 prior posts still to filter through)
2015
20151222 - Random Holiday 2015
+
20151116 - Mixing Temporal AA and Transparency
+
20151025 - Finer Points of Living in the Raleigh North Carolina Area
+
20150930 - Tonemapping and Slot Mask Simulation
20150915 - Bacon Wrapped Sour Cream
20150914 - Tearaway Unfolded PS4 on Wega CRT HDTV
20150910 - September Trip to Iceland
+
20150829 - Ketogenic Diet Working on Year 2
20150828 - Atari Shock Reloaded?
20150814 - The Written Word
20150810 - 1536-5 : Keys
+20150809 - 1536-4 : Coloring
+
20150722 - 1536-3 : Simplify, Repeat
20150719 - CRT Shadow Masks vs LCD
20150718 - Stochastic 1 Sample/Pixel Lit Fog stills
@@ -98,13 +104,16 @@ Below this is active random migration (373 prior posts still to filter through) 20150712 - Oh How Programming Has Changed
20150710 - Inspiration Reboot
20150709 - GPU Unchained ASCII Notes
+
20150630 - Sugar Free Peppermint Chocolate Chip Custard Ice Cream
20150624 - AMD Fury X (aka Fiji) is a Beast of a GPU Compute Platform
20150623 - BenQ XL2730Z Blur Reduction vs CRT
20150604 - Panasonic CT-34WX59 = Piece of Junk
+
20150525 - OS Project : 7 - PS/2 and Misc
20150522 - The Other Project Cleaned Up
20150509 - OS Project : 6 - Hashing
+
20150430 - The Other Project Getting Wired
20150426 - Source-Less Programming : 5
20150424 - Source-Less Programming : 4
@@ -117,11 +126,16 @@ Below this is active random migration (373 prior posts still to filter through) 20150414 - From Scratch Bug
20150406 - End of an Era
20150403 - Why I'm Using Fedex From Now On
+
20150328 - Stills From My Talk
20150309 - Quick Thoughts on Strobbed LCD Displays for VR Perf Proxy
20150327 - Other CRT Options
20150308 - CRTs

+20150221 - Great Example of Horrible API Interface Design
+
+20150111 - Leaving Something for the Imagination
+
2014
20140926 - Post Depth Coverage
20140826 - Scifi Reading Suggestion List From Twitters