「Variable Rate Shading」（VRS）這項技術（官網），是 NVIDIA 在推出 Turing GPU 架構時（2018 的事了），針對 VR 的需求推出的一項新功能。
這項技術的基本概念，主要就是透過局部性地降低 rasterization 階段的解析度，來減少 Pixel Shader（Fragment Shader）的計算量，藉此達到加速的目的。
下面就是他的基本流程：
標籤：程式設計
Qt 安裝腳本更新
之前有寫了一篇《在 Windows 命令提示字元安裝 Qt SDK》，大概紀錄了一下，在沒有圖形介面的環境下，使用腳本來安裝 Qt SDK 的方法。
腳本在當時是沒問題的，但是沒想到前幾天要用的時候，卻發現又無法使用了…
網路上找了一下資料，發現似乎是在過沒幾天、Qt 把安裝程式更新到 3.1.x 後，又改了一些東西造成的。（拜託顧一下相容性啊…）
找到的資料是 StackOverflow 上的《Bypassing “User Data Collection" screen》這個回應。根據他的說法，這次改版主要是加入了「User Data Collection」的畫面，另外在選擇元件的部分也多了分類的選擇。
也因此，腳本要針對這兩個變化，做出修改：
在 Windows 命令提示字元安裝 Qt SDK
這篇算是《GitLab CI + Windows Docker 的一些紀錄》的延伸。由於 Heresy 這邊的開發專案有用到 Qt SDK（官網），所以在建置用的 Docker 容器裡面，也需要安裝 Qt 的 SDK。
但是由於 Qt 現在的線上安裝程式也都是以圖形介面為主，並在圖形介面中選擇要安裝那些套件；所以要怎麼在沒有圖形介面的 Docker 內安裝，就需要稍微研究一下了。
在找了一些資料後，可以知道 Qt 的安裝程式框架（Qt Installer Framework、QTIFW、官方文件）是有支援使用腳本（script）來做控制的！（官方文件）
而在網路上，也可以找到使用這樣的機制，來自動安裝 Qt 的腳本範例。Heresy 這邊是參考《How can I install Qt 5.2.1 from the command line in Cygwin?》的例子。
Boost ASIO WebSocket Server 網站憑證設定
Heresy 這邊很早之前，就有開始使用 WebSocket++ 來開發自己的 WebSocket Server；而後來其實也有改用 Boost.Beast 來做同樣的工作。而這兩套函式庫的底層，其實都是 Boost::asio（官網），所以其實在某些地方還滿接近的。
而之前用起來都還算很正常，不管是老老的 IE 還是 Chrome 都可以使用，在有申請 SSL 憑證的情況下，就算建立加密的 WSS 也是可以正確使用的。
但是，前陣子當想使用 node.js（官網）來進行 WebSocket 的連線的時候，卻發現會出現「unable to verify the first certificate」的錯誤。
enum class 的 bitwise operation
這篇算是之前《使用 enum class 取代傳統的 enum》的後續。
當時介紹的 enum class 基本上是 C++11 引入、強化列舉型別的型別強度的設計；透過這樣的設計，可以避免一些程式設計上可能會碰到的問題。
但是，當 Heresy 後來實際要使用的時候，才發現 enum class 在某些方面上，似乎還有一些地方沒辦法和 enum 一樣地使用。
其中一個比較大的困擾，就是 enum class 沒有預設提供 bitwise operation，所以沒辦法直接把 enum class 當成 bitmask 來用。
C++11 的錯誤碼標準 part 3：補充與實作
針對 C++11 提供的 <system_error> 這個函式庫，Heresy 之前已經在 part 1 寫了 error_code 的基本使用，也在 part 2 寫了 error_condition 的東西。而在 part 2 的時候也有提到，由於 Heresy 在寫 part 1 的時候，其實對於 std::error_code 和 std::error_condtion 的關係有點誤解，導致有一些東西沒講到，所以這邊就先回到 std::error_code 的部分，做一些補充。
首先，之前在實作 error_code 的時候，總共實作了：
- enum class ErrorCode
- class ErrorCategory
- message()
- name()
- make_error_code()
- is_error_code_enum<Heresy::ErrorCode>
C++11 的錯誤碼標準 part 2：error_condition
這篇是延續之前的《C++11 的錯誤碼標準：error_code》一文，繼續來講 <system_error> 裡的另一個類別、std::error_condition（文件）。
不過老實說，Heresy 在繼續寫這篇的時候，才發現之前對於這邊的設計有些誤解，所以其實在 error_code 這篇文章有的內容可能不夠完整，預計會在用第三篇文章繼續補齊。
error_condition 和 error_code 非常地接近，不管是實際儲存的資料，或是介面的設計，基本上都沒有太大的差異；兩者的差別，主要是概念上、使用時機的差別。
兩者的差異，主要是：
- error_code 基本上是比較底層的錯誤碼，針對有可能會因為作業系統實作的不同
- error_condition 則是和平台差異無關（platform-independent）的錯誤碼，主要是用來做比較用的
C++11 的錯誤碼標準 part 1：error_code
<system_error> 這個函式庫是 C++11 時，加入標準函式庫裡的一個功能（C++ Reference、cplusplus），主要是為了在 exception 以外，提供一個更有架構、同時也有擴展能力的錯誤回報機制。
為什麼不都用 exception 呢？主要是因為並不是所有的錯誤都是例外。
像是以網路的程式來說，有一些錯誤狀況，會是有相當高的發生機會、本來就應該要在程式的流程中被考慮到的、而不應該用例外來處理。
所以在這種狀況下，使用 exception 來處理這些錯誤狀況，並不見得是個好的方法。
而 <system_error> 最初是 Boost C++ Libraries 中的東西（參考），後來才被整合到 C++11 裡的，所以如果有在用 Boost 的話，對他應該不至於太陌生；像是在 Boost::ASIO（參考）裡面，主要就是透過 error_code 來做錯誤的回報。
VisualStudio 的視覺化偵錯工具：Graphical Debugging
「Graphical Debugging」（網頁）是 VisualStudio 的一個延伸模組，它的功能是可以把 C++ 與 C# 中特並類型的資料、視覺畫出來、方便在偵錯的時候觀察。官方的說明是：
Visualization of C++ and C# variables during debugging, e.g. Boost.Geometry models, containers of values, arrays of points, etc.
Heresy 最早看到是很久以前的「Boost Debugger visualizers」（網頁），最初應該是只有針對 Boost C++ Libraries 的型別來做監看的修飾，但是看來現在功能多了很多了～
C++14 與 C++17 Lambda Expression 的改變
在很久以前，Heresy 就曾經曾對 C++11（當時還叫做 C++0x）的新語法、Lambda Experssion 寫過簡單的介紹、《C++0x：Lambda expression》了～
由於 lambda 這種匿名函式再搭配需要使用 function object 的時候，會是一個相當方便的東西，所以 Heresy 也常常在使用。
而在 C++11 引進後，其實在後面的 C++14 和 C++17 中，也都有針對 lambda 再做一些改進；雖然之前其實也有簡單提過，不過這邊就在整理一下，這兩次改版中，Heresy 個人覺得比較用的到的變化吧～
