ed/TimothyLottes.github.io
1
0
Fork 0
mirror of https://github.com/gomson/TimothyLottes.github.io.git synced 2026-08-04 14:48:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add files via upload

Browse Source
This commit is contained in:
TimothyLottes
2016-11-10 21:09:19 -05:00
committed by GitHub
parent 8658a0a1ac
commit 726ced4e6c
4 changed files with 185 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
20150111.html
+67
View File
@@ -0,0 +1,67 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20150111 - Leaving Something for the Imagination</h1>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
<b>Making Lemonade</b>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.
</div></body></html>
20150221.html
+58
View File
@@ -0,0 +1,58 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20150221 - Great Example of Horrible API Interface Design</h1>
<br>
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 "<i>how not to do it</i>".<br>
<br>
<b>(1.) Sparsely Segmented IDs</b>
<br>
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.<br>
<br>
<b>(2.) Mix of Same Buttons With Different and Similar IDs on Different Devices</b>
<br>
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.<br>
<br>
<b>(3.) The Same IDs Getting Used for Different Buttons on Different Devices</b>
<br>
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.<br>
<br>
<b>(4.) Using Base 10 Numbering Without Leading Zeros</b>
<br>
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.<br>
<br>
<b>(5.) Keeping Information Used Together On Unaligned Memory</b>
<br>
For example, "<tt>struct input_id { __u16 bustype; __u16 vendor; __u16 product; __u16 version; };</tt>",
it should be dead obvious that many developers would want to load "{vendor, product}" as a 32-bit value.<br>
<br>
<b>(6.) Providing No Good Way to Know if a Device is a Gamepad</b>
<br>
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.<br>
<br>
<b>(7.) Resorting To User-Space Daemons to Translate</b>
<br>
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.<br>
<br>
<b>Suggestions on How to Fix This Mess</b>
<br>
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.
<br>
</div></body></html>
20150809.html
+46
View File
@@ -0,0 +1,46 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20150809 - 1536-4 : Coloring</h1>
<br>
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,...}.<br>
<br>
<i>(Lost Image When Minus Went Down)</i><br>
<br>
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.<br>
<br>
<center><img src="20150809.png"></center>
<br>
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.<br>
<br>
<b>Bugs</b>
<br>
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.
</div></body></html>
index.html
+14
View File
@@ -79,16 +79,22 @@ Below this is active random migration (373 prior posts still to filter through)
<br>
<b>2015</b><br>
<a href="20151222.html">20151222 - Random Holiday 2015</a><br>
<br>
<a href="20151116.html">20151116 - Mixing Temporal AA and Transparency</a><br>
<br>
<a href="20151025.html">20151025 - Finer Points of Living in the Raleigh North Carolina Area</a><br>
<br>
<a href="20150930.html">20150930 - Tonemapping and Slot Mask Simulation</a><br>
<a href="20150915.html">20150915 - Bacon Wrapped Sour Cream</a><br>
<a href="20150914.html">20150914 - Tearaway Unfolded PS4 on Wega CRT HDTV</a><br>
<a href="20150910.html">20150910 - September Trip to Iceland</a><br>
<br>
<a href="20150829.html">20150829 - Ketogenic Diet Working on Year 2</a><br>
<a href="20150828.html">20150828 - Atari Shock Reloaded?</a><br>
<a href="20150814.html">20150814 - The Written Word</a><br>
<a href="20150810.html">20150810 - 1536-5 : Keys</a><br>
<a href="20150809.html">20150809 - 1536-4 : Coloring</a><br>
<br>
<a href="20150722.html">20150722 - 1536-3 : Simplify, Repeat</a><br>
<a href="20150719.html">20150719 - CRT Shadow Masks vs LCD</a><br>
<a href="20150718.html">20150718 - Stochastic 1 Sample/Pixel Lit Fog stills</a><br>
@@ -98,13 +104,16 @@ Below this is active random migration (373 prior posts still to filter through)
<a href="20150712.html">20150712 - Oh How Programming Has Changed</a><br>
<a href="20150710.html">20150710 - Inspiration Reboot</a><br>
<a href="20150709.html">20150709 - GPU Unchained ASCII Notes</a><br>
<br>
<a href="20150630.html">20150630 - Sugar Free Peppermint Chocolate Chip Custard Ice Cream</a><br>
<a href="20150624.html">20150624 - AMD Fury X (aka Fiji) is a Beast of a GPU Compute Platform</a><br>
<a href="20150623.html">20150623 - BenQ XL2730Z Blur Reduction vs CRT</a><br>
<a href="20150604.html">20150604 - Panasonic CT-34WX59 = Piece of Junk</a><br>
<br>
<a href="20150525.html">20150525 - OS Project : 7 - PS/2 and Misc</a><br>
<a href="20150522.html">20150522 - The Other Project Cleaned Up</a><br>
<a href="20150509.html">20150509 - OS Project : 6 - Hashing</a><br>
<br>
<a href="20150430.html">20150430 - The Other Project Getting Wired</a><br>
<a href="20150426.html">20150426 - Source-Less Programming : 5</a><br>
<a href="20150424.html">20150424 - Source-Less Programming : 4</a><br>
@@ -117,11 +126,16 @@ Below this is active random migration (373 prior posts still to filter through)
<a href="20150414.html">20150414 - From Scratch Bug</a><br>
<a href="20150406.html">20150406 - End of an Era</a><br>
<a href="20150403.html">20150403 - Why I'm Using Fedex From Now On</a><br>
<br>
<a href="20150328.html">20150328 - Stills From My Talk</a><br>
<a href="20150309.html">20150309 - Quick Thoughts on Strobbed LCD Displays for VR Perf Proxy</a><br>
<a href="20150327.html">20150327 - Other CRT Options</a><br>
<a href="20150308.html">20150308 - CRTs</a><br>
<br>
<a href="20150221.html">20150221 - Great Example of Horrible API Interface Design</a><br>
<br>
<a href="20150111.html">20150111 - Leaving Something for the Imagination</a><br>
<br>
<b>2014</b><br>
<a href="20140926.html">20140926 - Post Depth Coverage</a><br>
<a href="20140826.html">20140826 - Scifi Reading Suggestion List From Twitters</a><br>