#video of four hours of #Blow on #IMGUI. He’s programming in #Jai and struggling to understand why his UI isn’t doing the right thing. I think this video might be from 02021, halfway through his Sokoban game. In watching frame by frame, I notice that he has one (or sometimes two) frames of lag before initiating mouseover effects (tweened animated fades to brighter colors, etc.) on his IMGUI widgets. (Some of them “breathe” at about 1Hz when the cursor is over them.) Also a frame or two of lag is visible with the mouse pointer when he’s dragging windows. He sure spends a lot of time restarting his game; it takes 8 seconds from recompile initiation to seeing the cutscene, and then by default it plays for a few seconds, though it can be cut short to a single second. if ui.begin(panel, resizable=false) { ... defer { ui.place_rect(0, outer_margin); ui_end(); } ... ui.radio_button(*debug_mode, .Lightmap, *theme); ... ui.separator(); ui.label("Paint color", w=100); ui.same_line(); ui.color_edit(*paint_color, linear=false); ... if ui.button("Swap colors") { Swap(*paint_color, *clear_color); } ... ui.separator(); ui.checkbox("Airbursh", *airbrush); It seems like his .separator() is a small amount of vertical space. For tooltips, ui.hint("Radius of the brush - Wheel"); ui.input_float(*radius, w=64); ui.same_line(); ui.label("Radius");. There are ui.indent(); ... ui.unindent(); pairs for some visual hierarchy, but the indents are very subtle indeed. There’s a ui.enable(bool) for graying buttons out until a ui.enable(true);. The video shows how useful it can be to have video recordings of GUI interaction for debugging; at 43'33” a bug misinterprets a mouse movement dragging a window as also moving a slider, which mystifies Blow, and at 43'57” he erroneously speculates, “Must’ve accidentally dragged that, real fast?” At 45'16” he’s looking at another bug where a “clear” button isn’t being clipped properly and is overdrawing an accordion-control button in its parent. He gets into the implementation arount 54'44”. His definition of “em” is wrong by a factor of 2. He sure spends a lot of time manually doing small table layouts that a sort of elastic tabstops would solve for him. The implementation figures out when to pop up “hints” (tooltips) with rect := place_rect(w, h); over := is_over(rect); update_hint(over); and detects clicks with over && (ui.mouse_button_left_state & .START), and I think place_rect handles moving you to the next line and widening the current line. It’s interesting to hear him using Tk terminology like “entry” for “text field” in 02021. The RGBA color picker is interesting; I thought maybe you dragged up or down from R, G, B, and A buttons to adjust the respective color components, which changes the colors of the buttons to the corresponding primary shade, but in fact they’re just “checkbuttons” that change color when you click them. I like text_height, text_width := text_size(text);. Fading out a border around the window to α = 0 gives a nice cheap fuzzy-drop-shadow-like effect. I feel like for indentation some kind of current-drawing-origin stack might be a good complement to the clipping stack (“scissor stack”, maybe nomenclature borrowed from glScissor). He spends a lot of time debugging problems induced by how Jai’s static type system doesn’t have an Option type for optional parameter defaults. His defensiveness is grating: “The last thing I need is for someone who’s been programming for 5 years to tell me what I do and don’t know.” He’s hashing the addresses of callsites (plus an optional integer for loops) to get unique widget IDs for the IMGUI library. Casey #Muratori pops on at 2'56”, explaining that nowadays he streams his IMGUI drawing commands into a command buffer, sort of like ocornut’s dear-imgui, but higher level so he can run layout algorithms over it afterwards. “The reason I like the command buffer approach is because I like to be able to have more logic in the layout stuff.” Muratori’s definition: “IMGUI just means that you don’t call Create and Destroy on widgets. It means that there’s no need for you, the user, to like record what they are. (...) The core problem that you're trying to solve, and the one that determines whether I call it an IMGUI or not, is, can you just run some code on your side to output the current state of the UI, and you never have to think about whether some previous thing you said will make the UI, like, appear different, right? So you can just say, one pass, here’s what the UI should look like, and that is what the UI will look like.” Blow asks at 3h14m8s: “Was it Sean who used to do the IMGUIs where you would like call the function twice, once with display off and once on?” Muratori: “Yep.” Blow: “Did you ever do it that way?” Muratori: “I think I have played with doing it that way but I don't remember ever liking that.” At 3h19m55s Muratori explains how he did the React virtual-DOM diff and merge thing on his “command buffer” to draw an IMGUI with Qt, pointing out that you could do the same thing with HTML. Oh, at 3h45m50s there’s how scrollable sections work (though it has some bugs where scrollbars don’t show): ui_begin_scrollable_section(*results_scroll_value, w=..., h=...), with presumably a corresponding end call later. He has just a ui.selection_list inside it in that case, which turns out to be a loop calling ui.button for each item in the array which returns the index of the selected button. And I’m amused to see that ui.button is just a call to ui.checkbutton which passes a null pointer for the state, which ultimately calls draw_button with 8 positional parameters, which calls draw_label, which calls text_origin to figure out where to draw the text. Very educational video, even though I think some of the code is kind of naff, like ui_end(false, true). I managed to finish the whole video.
#video of Jon #Blow’s presentation at Reboot Develop in 02017 about designing #Jai for #videogames. Photoshop takes 7 seconds to start up to display you an image, during which time it’s displaying you a high-resolution image on its splash screen that isn’t the one you wanted to see, and “now” in 02017 opening the File→New menu window takes an entire second. (Indeed, in this 30fps video, it takes 30 frames to finish drawing the menu.) On his i7-7700HQ. He says single-core performance had improved 24× since 02000 based on SPECfp, but it’s also quad-core. Demo of his in-progress Sokoban game, started a year earlier at the same time as Jai, starts at 16'36". Roughly 100kloc per second unoptimized compilation speed on the i7-7700HQ. A thing I hadn’t realized before is that his compile-time execution represents a repudiation of the idea of simple DSLs like the shell, which is consistent with his dislike of things like Lua. The video is unfortunately very hard to read his screen from. This is one of the videos where he says that the syntax is temporary. His reflection system is useful for not just compile-time computation but also run-time debug messages and experimental interfaces. He never mentions the name of the language, so maybe he hadn’t settled on “Jai” yet, but the compiler is already called “jai.exe” and the filenames end in “.jai”. Also he already had the #LLVM backend, which he described as the “short-term plan” for optimization. #compilers
on 02025-08-03possibly better #video #toread of the Lambdaconf demo of Jon Blow’s language #Jai, video from yesterday, demo from May.
on 02025-07-10#video of the Lambdaconf demo of Jon Blow’s language #Jai, video from yesterday, demo from May. Totally screwed up audio/video rates.
on 02025-07-10