Making a 3D modeler in C in a week

Raylib and Alternative Frameworks

• Several commenters like raylib for its simplicity and fast prototyping, especially for small games.
• As projects grow, people report frustrating limitations: inconsistent fullscreen behavior across platforms, poor screen‑mode enumeration, weak runtime toggling of features, shader handling, and awkward text/font APIs with performance issues.
• Some are “too far in” to replace raylib mid‑project, but say they’d choose SDL or sokol next time; SDL is praised for scaling to large projects and documentation quality, sokol for its minimal single‑header design and successful shipped games.
• There’s criticism of raylib’s lack of parameter validation (e.g., segfaults on NULL) and vague docs; others argue this is normal, even desirable, in C if clearly documented.

Smooth Scrolling, Timing, and Web Builds

• A raylib WebAssembly parallax example shows noticeable jitter for some users; others see mostly smooth foreground but jittery background.
• Suspected causes include: fixed per‑frame movement without using delta time, sub‑pixel snapping for pixel art, and browser requestAnimationFrame behavior at varying refresh rates.
• A detailed comment describes “micro‑stutter” as inherent to modern OS/browser timing jitter and limited access to precise frame durations and presentation timestamps, especially post‑Spectre/Meltdown.
• Raylib’s web frame pacing is described as crude (fixed sleeps instead of requestAnimationFrame), exacerbating issues.

Fullscreen, Windowing, and Performance

• Many treat “true” fullscreen as broken on modern desktops, preferring borderless windowed fullscreen plus resolution scaling.
• On Windows, borderless can match exclusive fullscreen if the compositor is bypassed; otherwise it can add significant latency.
• On Linux/X11 and Wayland, fullscreen is largely implemented as borderless/maximized windows with heuristics to unredirect compositing.

C, Memory Management, and Productivity

• Several praise C’s simplicity, explicitness, fast compile times, and ease of targeting both native and WebAssembly.
• With modest libraries for strings/arrays/maps, some claim C can be nearly as productive as higher‑level GC languages for many tasks.
• Others counter that garbage collection and not worrying about object lifetimes saves substantial time and bugs, especially for larger teams.
• There’s debate over memory safety vs. performance and tooling: some see GC ecosystems as fragile and opaque; others point to C/C++’s history of memory‑related vulnerabilities.
• Static allocation and avoiding dynamic memory entirely is highlighted as feasible and safer for many constrained applications.

SDF/CSG Modeling and Relation to Existing Tools

• Commenters connect the project’s SDF/CSG workflow to features in existing tools (e.g., metaballs, boolean modifiers, beginner CAD) and specialized SDF modelers.
• SDF is praised as “digital clay” and good for certain shapes and CAD‑like workflows, especially when paired with SDF renderers.
• Others stress it’s not a drop‑in replacement for mesh‑based pipelines: SDF‑to‑mesh via marching cubes yields poor topology for animation/rigging, requiring cleanup in traditional tools.
• Extended debate covers SDFs vs meshes on resolution, scalability, and whether SDFs could ever displace meshes; consensus leans toward “complementary, not replacement” in the near term.

Reactions to the Project and Jam

• Many are impressed that a usable 3D modeler and polished video demo were produced in a week; some say the video likely took longer than the tool.
• The static 100‑shape array design is praised as a pragmatic, non‑overengineered choice that avoided premature abstraction.
• Several express interest in future “wheel reinvention” jams and in building small, bespoke tools instead of always relying on heavyweight engines.

UI and Text Rendering Observations

• Some appreciate the crisp, pixel‑style text in the WebAssembly build, contrasting it with widespread blurry antialiased UI text in modern systems.
• Others note that achieving sharp text across browsers and scaling setups is harder than it looks, due to past browser filtering behavior and compositor interactions.