Initial commit

blog post - Sectr Prototype.md

@@ -0,0 +1,41 @@
+# Sectr Prototype
+
+<video class="ratio ratio-16x9 mb-1 rounded"  controls src="static/images/news/2024-06_sectr_prototype_UI_Demo_opener.mp4" width="650"></video>
+
+After my last contract in January, I wanted a break from C/C++ projects. So I decided to attempt another go at developing a pragmatic “projectional” editor for code using Odin. The goal is to offer support for multiple “workspaces” where users can compose “views” of code definitions in a flexible manner irrespective of the their composition in the filesystem.
+
+(My last attempt at figuring things out utilizing Godot 4.2):  
+<img src="static/images/news/2024-06-sectr_prototype_godot_ver_last_state.png" alt="img: previous godot prototype" width="650">
+
+## Why Odin
+
+Tired of the C++ toolchain, I chose Odin over Zig. I had been keeping my eye on C/C++ alternatives for a while and had been disappointed in most of them. Initially, there were reservations about using either, as they both seemed too opinionated at a glance. Jai seemed to be up my alley but I don’t have the patience to wait for it. Odin’s seemed like there would be less conflicts with the language so it won out.
+
+That ended up being a great decision. Odin feels better than just being a “C alternative”. The language'’ features, like the “using” keyword and “deferred_” attributes, have been particularly enjoyable to use. Both the provided packages and those sourced from git repos have been easy to learn and integrate.
+
+Exploring the compiler implementation has also been an unexpected bonus. Most toolchains’ source feel too daunting to learn how “a toolchain works”. Odin is the exact opposite. Each file is clear and understandable at a scrolling glance, which is an amazing achievement.
+
+## Bootstrapping
+
+The codebase setup was smooth. The first sign of things to come was how simple and quickly the compiler built after cloning. Making the build script for the project was also surprisingly painless. I was able to get all the info quickly from the build -help command along with reading the flag entries in the src/main.cpp. 
+
+Raylib was chosen to handle input, rendering (Text and 2D), and windowing, which did the job initially.
+
+Hot-reload was up next, I loosely referenced Karl Zylinski’s highly praised article, along with code I had previously written following the Handmade Hero series. Unfortunately that very series exposed me to Casey’s janky replay feature (abusing memory snapshots), and I wanted to port the feature over to this project. The first issue was the core library not exposing the starting address arg for VirtualAlloc in core:mem/virtual. However, a derivative of the virtual arena with the argument exposed was easy to implement. Another issue was allocator procedures not getting auto-remapped across reloads, leading me to roll my own dynamic array and hash table. Later, I realized I could have transmuted the containers to their “Raw” struct counterparts (Raw_Map and Raw_Dynamic_Array in base:runtime/core.odin), which is a simple refactor for the future.
+
+The profiler was added last, and I went with Spall since it was directly setup in the Vendor library. I’ve never pulled together this many libraries in such a short period of time, even while messing around.
+
+## Why an IMGUI from scratch?
+
+The aim was to have an uncompromised ability to compose a UI tailored to this editor. Inspired by Rayn Fleury’s UI Series on substack, I set out to implement a “core” UI that could support all that was required. I dived through his implementation from the RAD Debugger, and some others (VUI, Nuklear, and MicroUI). This provided (probably misguided) confidence to tackle the endeavor. So far it’s at least been a great learning experience.
+
+The result was a core UI that’s surprisingly simple for its ability, along with full “flex-box” auto-layout using less than 1000 LOC. It reached a point where composing any “widgets” using just the composition of the core “box” entities felt achievable. Including all the UI code demonstrated (excluding rendering) amounts to approximately 2250 LOC.
+
+## Current Hurdle: Learning Sokol and Text Rendering
+
+The limits of Raylib’s text rendering capabilities were encountered when shoving a good amount of “Lorem Ipsum” onto the screen:  
+<img src="static/images/news/2024-06-sectr_prototype_raylib_text_profiling.png" alt="img: previous godot prototype" width="650">
+
+Just having ~250 lines of text boxes queued for rendering would increase the frame time by several milliseconds. Technically, this could be ignored for several months while focusing on other features. However, it would feel better to just get the platform and rendering layers down pact. Among the available options, Sokol’s app and gfx libraries seemed to be a great fit, along with a 2D library called sokol_gp. All that was left was to determine the best reference for text rendering, and the Discord community recommended fontstash as it had a hookup defined for sokol_gfx as a util in the sokol repo itself. Since then I’ve been navigating my way learning all these new libraries.
+
+<video class="ratio ratio-16x9 mb-1 rounded"  controls src="static/images/news/2024-06-sectr_prototype_Sokol_Hot_Reload_closing_vod.mp4" width="650"></video>