Scripted UI, Map Workflow, & a Bunch of Bug Fixes

alot of bug hunting…

changes

scripting & ui

scripts can now actually interact with the UI system.

added bindings for things like:

• creating UI buttons, text, rects, and images
• finding UI elements
• destroying UI elements

these return wrapped objects with basic getters/setters for position, visibility, and button state

map workflow

spent a fair bit of time cleaning up the map editor flow.

• maps no longer get a fake default path on creation
• switching to the Map Editor tab now auto-creates a map (empty) if there isn’t one yet
• mapFilePath now stays project dir relative instead of randomly becoming absolute
• tile materials are now shared properly instead of silently duplicating state

rendering & lifetime bugs

i’ve been doing alot of testing recently, so i found alot of bugs…
this was probably the biggest pain point.

• renderer submissions now keep materials and meshes alive for the frame instead of trusting the caller
• replaced the old Shader::Default() singleton hack with a real fallback shader (internalshaders base)
• fixed the lightmap quad so it keeps its own VAO and clears correctly when there are no lights
• fixed a Texture move bug that was double-deleting GL handles sometimes

editor polish

also cleaned up a bunch of editor behavior while I was in there.

• Ctrl+S now behaves correctly depending on whether editing a scene or a map
• scene loading now rebinds editor panels properly
• save/load dialogs now append file extensions automatically
• added more inline warnings in the inspector and panels (i.e if an entity has no material it will tell you it wont render)

and ive probably forgotten something else …

in summary ive just been testing out some UI/UX changed and hunting down bugs untill I feel it is ready to maybe start prearing some sort of demo :)

more ui

ive been kinda sick so i aint really had the motivation to do a lot but ive been working more on the UI system

im kinda tired so i dont really feel like writing more for now -.-

game UI Progress

been continuing work on the UI system.

changes

UI

made some good progress UI system

currently have:

• font importing working
• texture support for UI elements
• basic text rendering
• a simple editor view panel for UI

it’s still very much WIP

editor

right now it’s pretty basic, but it’s enough to start experimenting with how creating and editing UI might actually work inside the editor

there’s still a lot left to do before I’d call it usable, but im making progress..

getting text working is painfull, and still unfinished.. but im workin on it…

UI Experiments

since working on the particle system, I feel like it’s in a pretty good place for the current scope. I don’t really know what else I want to add to it right now, so I decided to finally start on something that’s been sitting in the back of my mind for a long time…

a proper UI system.

changes

particles

mostly just spent some time testing and polishing the particle system to make sure everything behaves properly
I’m pretty happy with where it’s at for now

UI

started prototyping a custom UI system

it’s very early, but I’ve got the basic rendering pipeline up and running

currently working on:

• a UIElement system
• a dedicated UI renderer
• text rendering
• font loading using FreeType

right now it’s mostly just enough to prove everything works, but it’s the foundation for the runtime UI system ive wanted for a long time

the goal is for games made in the editor to be able to have their own UI, with everything exposed through EngineLib so scripts can create and interact with UI elements as well

honestly, for now.. I was expecting it to go alot worse.. FreeType isn’t as bad as it seems once you get it working with GL

The screenshot below dosent show much, but you can see the rendering of Text and rects, it also supports textured rects (which is what the text is currently using to render from a texture atlas)

More Particle work…

been spending some time on the particle system…

changes

particles

expanded the particle system quite a bit.

currently supports:

• randomized size ranges
• randomized rotation
• configurable emitter shapes (support quad, circle, and soft circle)
• alpha and additive blending
• configurable render order (still kinda broken but im working on it)
• per-particle color over lifetime
• particle presets that can be saved and loaded (as JSON)

also added an editor preview mode, so particles can be previewed while editing instead of only showing up in play mode

renderer

had to do a bit of renderer work to support all of this

• particles now use their own dedicated shader
• added support for per-instance colors during instanced rendering
• added an overlay render pass for effects that should render on top of the scene

cleanup

also did a some more project cleanup, splitting up my Utils header into multiple files.. nothing special though

misc

• particle emitters can now be saved as reusable presets (some which will be shipped as defaults ofc) as suggested by @sol4r_on_hackclub
• cleaned up a few asset importing edge cases
• fixed a couple of packaging issues too

I’m pretty happy with how the particle system is coming along :D

mostly just spent some time going through some old code.. nothing really important, but i’ve also replaced the placeholder assets.. with my own placeholder assets that i drew in GIMP, considering i probably do not have the rights at all to distribute the previous assets.. :)

Particles! :)

Ive started working on a particle system.

i have got the core pieces in place and it seems to be working nicely so far….

changes

particles

implemented the foundations of the particle system

currently has:

• ParticleEmitterComponent
• ParticleSystem
• ParticlePool

emitters currently support:

• configurable particle limits and emission rates
• randomized lifetimes and velocities
• “gravity”
• size over lifetime
• color over lifetime
• world space simulation
• materials obviously

so far it’s all behaving pretty well…

EngineLib

next up is getting particles exposed through the EngineLib API so scripts can spawn and control emitter components

we will see how it goes…

Editor QoL, Graphics Configs & Prefabs

new devlog… mostly been focusing on editor ui and qol changes this time around.
kinda tired of hardcoded settings for the graphics settings, so i finally built a proper interface for it,
plus some prefab management stuff in the editor

---

changes

graphics settings

i built a dedicated graphics configurator window in the window, for the current project (GraphicsConfigEditor).

• it hooks directly into the UndoManager using the command pattern (GraphicsConfigUpdateCommand)
• serializes everything out to graphics.json.
• added QuerySupportedSampleCounts which asks the active GL context (before it gets handed to the render thread)
  what MSAA sample counts it supports.
• the editor now dynamically generates the dropdown and snaps to a valid sample count (i.e 1, 2, 4, 8, 16).

prefab management

the editor now supports prefab management that i implemented earlier
.. instead of directly writing it in the scene json file

• you can spawn entities directly into the scene from prefab json files
• you can revert a prefab, which wipes any local overrides and resets the entity back to whatever is saved in the file
• you can break a prefab, severing the link to the json file and turning it into a normal, standalone entity in the registry

ui & editor cleanup

spent some time making the editor less annoying.. in general

• the editor layout stops resetting itself ,
  it now checks if imgui.ini exists on startup, and if it does, it skips rebuilding the default dockspace

• ripped the hardcoded hub drawing code out of the EditorLayer and made it its own state for the editor state machine

• refactored the config windows (ProjectConfigEditor, SceneConfigEditor, and the new GraphicsConfigEditor) to inherit from a base ConfigEditor class so its cleaner and easier to maintain..

• fixed the script widget since the ui was kinda messy

the OpenGL State Machine Strikes Back…

I spent the entire day trapped in hell: debugging a corrupted OpenGL state…

it may not show up as tracked hours.. since most of it was just staring at various forms of text.. but it was painful.

problem

so since i turned the lightmap to run on gpu .. well… Whenever I transitioned from the editor (MapEditState) into Play mode, the map would turn into like a bunch of weird diamonds, and the corruption would persist indefinitely until I remounted the current project.

because it only happened on state transition, i spent hours chasing ghosts in my state management code and scene cleanup routines…

(in the end though i did make some changes to the cleanup routines, but between states rather than scenes.. so i guess i was halfway there?)

the culprit

It was the lighting pass…

took me forever to figure it out, but i had the genius and definitely NOT a very late and obvious idea i shouldve had hours ago, to see if the issue happened when i turned off the lighting system.
so i put some early returns in my lighting system functions and.. it didnt corrupt..

inside LightingSystem::Update(), the renderer was modifying global OpenGL state changing depth functions, blending modes, and texture bindings, but not restoring them to their original defaults properly

When the engine swapped states, the next frame inherited this dirty, half configured state, causing the whole thing to become a mess.

the fix

I went through the lighting system and made sure the state changes are wrapped and properly restored through the render thread..

• LightingSystem.h: Full GL state save/restore around the light pass. now explicitly backing up and restoring the FBO, program, VAO, blend state, draw buffers, clear color, viewport, and active texture.
• MapEditState.cpp: OnExit() now properly nulls out m_MapComp and m_CurrentGrid. OnEnter() and will refetch them from the current registry so it isnt holding onto outdated references.
• EditorLayer.cpp: Added a call to renderer->Clean() after state transfers to clear out stale VAO and mesh caches.(bc its multithreaded things go kinda weird but.. it works now)

glad thats over with :D

---

Also heres a fun peek of what ObSL can do with EngineLib, yes, it can make your entire map look like hell..!

i am totally not going insane

GPU Lighting & Graphics Settings

been doing a bit of rendering work again… mostly trying to optimize things.

the biggest change is that I completely rewrote the lighting system

previously all the point light calculations were happening on the CPU, and after doing some profiling (and spending way too long staring at compiler generated assembly annotations) it became pretty obvious that this was one of the bigger performance bottlenecks (well THE biggest excluding driver overhead)

lighting now runs entirely on the GPU through shaders instead

changes

lighting

rewrote the lighting system.

• lighting is now shader-based and runs on the GPU
• removed the old CPU-side lighting calculations
• moved engine shaders (like the base shader and lighting shader) into built-in InternalShaders (hardcoded string literals, it might seem messy but i prefer it like that)

the internal shader change mostly exists because they’re pretty fundamental to the renderer. if they were treated like normal project assets and someone accidentally deleted them… well… suddenly nothing renders (unless they had setup their own shaders, which is fully supported!) and lighting completely falls over, also i prefer it to loading them from the filesystem anyways

overall I’m pretty happy with how the new lighting system turned out

graphics settings

also started working on configurable graphics settings

instead of baking them into the project, the engine now loads graphics settings from a separate JSON file. this doesn’t get packed into the .obpak, so users can tweak their graphics settings after exporting a game

currently supports:

• resolution
• fullscreen
• MSAA (toggle + sample count)
• target FPS
• VSync

it’s weirdly fun actually being back in OpenGL code again instead of just working with engine abstractions
sometimes it’s nice to get back into the weeds.. even if its.. painfull :D

Performance & Zero Copy Assets

been spending some time under the hood…

this one’s almost entirely backend. no new features, mostly went through the render thread, asset pipeline, & a handful of ECS loops to squeeze out more performance.

it was incredibly rage inducing at times.. but seeing the profiler diff against baseline.. i am satisfied.. almost at peace.. but was considering becoming a farmer & never touching a computer again.. mostly because i thought i’d messed up more than i did.. but.. im happy now.

changes

threading & ecs

i’ve reinvented the wheel enough already… but had to redo how tasks are dispatched.

• ThreadPool used to take a std::function, which heap allocates if you capture more than a couple pointers. scripts dispatch through this every frame, so it added up. swapped it for a custom Task type a 56-byte inline buffer, no heap allocs
• swapped the pending-task counter to a lock free atomic decrement instead of a mutex on every completion…

rendering

been cleaning up how the main thread interacts with the render thread.

• the main & render threads used to awkwardly poll eachothers framebuffers. now theres a m_ReadyFrames deque main pushes a frame index, render pops it. much cleaner :)
• ImGui draw data is now reused in-place instead of allocating & freeing a fresh clone every frame

(ive put off fixing that hack for a while so its nice to finally come around to it).

• instanced draws no longer store a vector<mat4> per draw call, transforms get appended into one giant staging buffer per frame now. added SubmitPersistent for things that already own a long-lived buffer (like the map tile renderer) to skip the copy entirely.
• swapped a bunch of unordered_maps for flat vectors in the texture/VAO/uniform caches for a handful of items, linear scan beats hashing. batched rendering also caches the last bound texture & color uniform so b2b batches sharing a texture dont rebind needlessly.
• added a zero-size window safeguard for Wayland so it stops wrecking the renderer when the window briefly reports 0x0 during resize (also turned vsync back on, weird syscall spam otherwise)

assets & packaging

• added VFS::ReadVirtualView to hand out string_views directly into memory instead of owned strings
• for packaged builds, ContainerReader now mmaps the .obpak file directly, uncompressed stuff (textures, uncompiled maps) gets handed right to the parser without a copy. also now move only, with a destructor that unmaps memory instead of holding a copied vector of chars

scripting

• the script hot-reloader was doing a stat() syscall on every script file every frame. oops. now polls every 300 frames & caches resolved paths.. thought i already debounced this.. guess not..
• the on_update & on_destroy work buckets used to be freshly allocated vectors every frame… now static, so they just clear & reuse capacity

editor & ui

• finally ripped out the old in game debug UI (GameUI.cpp), it had fallen out of sync with the ECS anyway

(used it for debug visuals while implementing the first version of the ecs.. then forgot about it) the editors inspector does all of this better now, so replaced it with a minimal FPS counter

audio & map

• audio engine now sets an explicit period size (2048 frames) via miniaudio to cut IPC roundtrips to the audio daemon..

(this one was annoying to figure out.. god bless strace & gdb)

• the map’s visible transforms buffer is now double buffered, rebuilds write to the back buffer while the render thread reads the front, no race conditions. also swapped typeMats from an unordered_map to a flat vector

nothing user facing changed this time, but frame pacing feels noticeably smoother (somewhat suprised), & the packaged build starts noticeably faster

i know it could probably be a lot better, but im still a bit of a noob at C++, so this is one hell of a learning project

Undo/Redo …again!

been working on the editor again

the undo/redo system now covers a lot more than just gizmo transforms. but there’s still a few things left (entity creation/deletion mainly).

changes

undo/redo

expanded the command system to cover most editor actions.

currently supports:

• entity transforms
• adding/removing components
• adding/removing scripts
• editing project settings
• editing scene properties

also fixed the undo/redo shortcuts so they only trigger once per key press instead of repeatedly firing while the keys are held… which is probably how they should’ve worked from the start

map editor

continued working on map editing.

painting and erasing now properly integrate with the command system. also, an entire brush stroke is treated as a single undo step instead of undoing one tile at a time.

also cleaned up a couple of edge cases while doing this, like preserving existing tile data and avoiding unnecessary commands when nothing actually changed.

misc

did a bit of cleanup around the editor while wiring everything together.

• centralized a few bits of duplicated UI logic
• cleaned up window title updates
• continued refactoring the command system

the undo system is still unfinished, but it covers most of the important stuff and feels nice..

---

also.. still gotta fix some ui window-size stuff soon too but .. thats for later

Undo/Redo! :)

been working on some editor QoL stuff again…

the biggest addition this time is a proper undo/redo system. it’s still very early and pretty barebones, but having the foundations in place is nice

changes

editor commands

implemented the beginnings of a proper command system for the editor

instead of modifying things directly, editor actions now go through commands, which means they can be undone and redone

currently supports:

• entity transforms
  • movement
  • rotation
  • scaling
• adding components
• removing components

(with the exception of ScriptComponent for now.. that’ll get its own custom command due to the way it works)

also keeps a command history, and the usual shortcuts are hooked up now:

• Ctrl + Z : Undo
• Ctrl + Y : Redo

its still pretty basic, but it works and feels nice to use.

input

for this, I added proper key-combination support to the input manager.

things like:

• Ctrl + S
• Ctrl + Z
• Ctrl + Y

can now be handled properly instead of manually checking modifier keys everywhere

logging

did a bit more cleanup to the logging system as well.

the logger now goes through a proper interface instead of everything depending directly on one concrete implementation, which should make it a bit easier to swap things around later if I ever want to.

mostly backend work again… but undo/redo is fire

editor polish

still nothing super flashy.., mostly a bunch of small things

changes

window titles

the editor now updates its window title based on what youre working on.

it’ll now include things like the current project and scene, or map

project loading

cleaned up project loading a bit.

the editor now properly syncs the loaded project configuration into the engine context instead of relying on stale data

also added menu in the map editor that lets you save and load map files (create new is just placeholder for now)

UI

added a small helper for rendering framebuffer textures in ImGui without needing to remember to flip the UVs every time. and made the tile Editor use it

also forgot to mention in the last log that i cleaned up the “project browser” ui a bit

logging

fixed up some more logging :)

Logging Cleanup

replaced all the random std::cout / std::cerr calls scattered throughout the project with an actual logging system

logging

implemented a proper logging system.

• replaced std::cout / std::cerr throughout the engine
• added support for different log levels
• optional logging to a log file
• centralized all engine logging into one place
• thread safe !!!!

nothing particularly flashy or fancy, but its cleaner, easier to work with, and generally just nice

i probably should’ve done this a long time ago :)

Map Editing, Brushes,

and a 4(?) hour ImGui Bug

The map editor is finally coming together
It’s still a bit… rough
but it does feel nice to be able to paint a map in the editor

I did, however, spend an embarrassing amount of time trying to figure out why my click and drag “painting” wasn’t working…
well.. ImGui was eating my inputs because it thought I was trying to drag the Scene View window around.. yeah..

changes

map editor

actually got the map editing tools working for real this time.

• the paint and erase tools actually place and remove tiles now instead of just being placeholder buttons
• added a brush radius slider, so you can paint in bigger hex rings
• added a preview outline that renders around your cursor so you can see before clicking
• toggling “is walkable” on a tile now properly syncs with the grid pathfinding

editor ui

spent some time making the tile palette and material editing.. work.. video explains better ngl im not good at describing ui stuff

math

• laid some groundwork in the hex math system (Lerp, CubeRound, and GetHexLine)
• this is mostly for some future evil plans…

still a WIP…

map editor preveiw ig kinda didnt have much time to do anything today but im working on the tile editor

editor rework & map editing groundwork

been working on the editor again

this update was mostly about cleaning up the editor architecture so I can actually keep adding features without everything turning into spaghetti. I also finally started laying the groundwork for proper map editing.

changes

editor

reworked the editor state system.

instead of instantly swapping between states, transitions are now deferred until a safe point during the update loop. this makes switching between Edit, Play, Map Edit, and the Hub a lot cleaner, and the editor now remembers which editing mode you were in before hitting Play.

(i’ll admit… i was getting a bunch of weird, seemingly unexplainable crashes before eventually realizing my mistake was instantly switching states while things were still being updated/rendered…)

also moved more UI responsibility into the individual states instead of having EditorLayer decide how everything should be drawn.

map editor

started putting together the map editor.

currently i have:

• map hover and tile selection working
• placeholder Paint / Erase / Select tools
• the beginnings of a tile palette system
• a placeholder tile editor panel

the actual editing logic isn’t implemented yet, but the foundations are there now :)

asset picker

ripped out the old “open a native file dialog for every asset field” flow.

instead, the editor now lets you pick existing textures, meshes, materials and shaders directly from the ResourceManager, which is a lot nicer to work with and also avoids accidentally importing duplicate assets.

(the old workflow would happily create a brand new object every time you imported something… which was fine for testing, but definitely wasn’t something i wanted to keep)

rendering

fixed a few editor rendering issues while i was at it.

• materials with invalid shaders now fall back to the default shader instead of silently disappearing
• fixed some edge cases with framebuffer entity picking
• currently unused, but functional shader hot reloading tests

misc

• smoothed out editor camera movement and zoom
• added a few helper utilities for the map editor
• reorganized the editor UI code a bit

doesn’t look massively different in screenshots, but makes future work alot easier/cleaner

map painting is next ?..

Project Exporting

been working on making projects exportable from the editor
it’s now able to export a project to the selected folder, package all the assets into an .obpak, and then copy over the runtime so the exported project is runnable

changes

project exporting

• added export to the editor
• choose an output folder for the exported project
• packages the project into an .obpak
• copies the runtime into the export folder
• renames the runtime to match the project name

(just 2 files for full project!, executable and .obpak)

the whole process is pretty much one click now instead of manually packaging everything together.

file dialogs

• refactored my entire filedialog implementation cuz it was kinda broken

packaging

did some more work on the packaging pipeline while implementing exporting and put it in the editor ui

im pretty happy that its all working and i can actually export stuff, and run it feels cool :)

Project Packaging is Working

been spending a lot of time working on project packaging, and it’s finally working now.

the engine can now load projects directly from .obpak files, and I’ve got basic tooling to create them as well.

the plan is to integrate the tooling i have now with the editor to “build” an obpak archive (i think its called an archive?)

changes

packaging

implemented the full packaging/loading pipeline yippie :D

currently the packer:

• pre-generates ASTs for ObSL scripts
• converts project, scene(s) and prefab(s) JSON into MessagePack
• bundles everything into a single .obpak container
• compresses the package with LZ4

assets like textures, audio and shaders just get copied into the package without any conversion

runtime

the engine can now load packaged projects directly instead of relying on loose project files.

all of this goes through the VFS, so from the engine’s point of view it doesn’t really matter whether assets are coming from a folder or from an .obpak

(i.e it can still load loose project files of course)

tooling

added command-line tools for packing and unpacking projects, i originally made it for testing but it’s actually pretty nice to work with so im probably keeping it.

still probably things to polish, but it’s pretty satisfying seeing the engine load an entire packaged project properly

---

pls ignore the lag in the video, i promise its not as terrible as it looks, its just that recording is pretty buggy for me