ed/odin_june_newsletter_24
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

adjustments

Browse Source
This commit is contained in:
Edward R. Gonzalez 2024-05-26 23:19:16 -04:00
parent 1305f93d7c
commit 7a013de392
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
blog post - Sectr Prototype.md
View File

@ -1,17 +1,15 @@
# Sectr Prototype # 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 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.
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): (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"> <img src="static/images/news/2024-06-sectr_prototype_godot_ver_last_state.png" alt="img: previous godot prototype" width="650">
## Why Odin ## 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. Tired of the C++ toolchain, I chose Odin over Zig. Jai seemed to be up my alley but I don’t have the patience to wait for it. Odin’s looked 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. That ended up being a great decision. Odin feels better than just being a “C alternative”. Llanguage features, like the “using” keyword and “deferred_” attributes, have been particularly enjoyable to use. Both the provided packages and those sourced from third-parties 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. 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.
@ -21,7 +19,7 @@ The codebase setup was smooth. The first sign of things to come was how simple a
Raylib was chosen to handle input, rendering (Text and 2D), and windowing, which did the job initially. 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. Hot-reload was up next, Karl Zylinski’s highly praised article was loosely referenced, along with code 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 near 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. 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.
@ -31,11 +29,13 @@ The aim was to have an uncompromised ability to compose a UI tailored to this ed
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. 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.
<video class="ratio ratio-16x9 mb-1 rounded" controls src="static/images/news/2024-06_sectr_prototype_UI_Demo.mp4" width="650"></video>
## Current Hurdle: Learning Sokol and Text Rendering ## 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: 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"> <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. 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, I wanted 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. There was an avaialble 2D graphics library called sokol gp avilable as well. All that was left was to determine the best reference for text rendering, and the Discord community recommended fontstash as it had a setup defined for sokol_gfx 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> <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>

0
static/images/news/2024-06_sectr_prototype_UI_Demo_opener.mp4 → static/images/news/2024-06_sectr_prototype_UI_Demo.mp4
View File