spritesheets / animation

finally … spritesheet support

spritesheets

added a new SpriteSheetComponent with:

• texture
• rows / columns
• optional row + column spacing
• start frame
• animation length
• FPS
• looping
• playing / paused state
• current frame

basically the renderer can now render only a specific UV region of a texture

animation

also added a small sprite animation system that advances frames based on FPS and handles looping / stopping at the end etc etc

animations also update while in the editor… might be annoying for some, might be less annoying for others.. but thats how i like it

editor stuff

you can pick the texture, set rows / columns and spacing, choose the start frame + animation length, change FPS, toggle looping / playback, scrub the current frame, restart the animation, etc. etc

EngineLib

scripts can inspect stuff like the current frame, frame count, FPS, rows / columns and texture, and can also change the texture/grid/animation, set frames, play, pause, restart and stop animations.

Collider also has a proper EngineLib component wrapper instead of collision only being accessible through the callback hooks. right now that’s just getting / setting whether it’s a trigger, but it’s there.

also added both Collider and SpriteSheet to the normal GetComponent, AddComponent, RemoveComponent, HasComponent, etc. obviously.

some cleanup

did a bit of registry / EngineLib locking cleanup while I was in there too, mostly around entity wrappers being created while the registry lock is already held.

also fixed one very stupid collision callback typo where on_collision_stay was looking up the wrong hook… oops…..

im also starting on documenting this stuff…. yep.. pain…

spritesheet used in video attached for testing is : https://opengameart.org/content/animated-butterfly

collision callbacks

scripts can do collision things now….!!!

script collision callbacks

ObSL scripts can now define collision hooks:

• on_collision_enter(other)
• on_collision_stay(other)
• on_collision_exit(other)
• on_trigger_enter(other)
• on_trigger_stay(other)
• on_trigger_exit(other)

the other argument is a normal EngineLib entity wrapper, scripts can do stuff like check its name, components, etc.

collision events get collected by the CollisionWorld, then dispatched to the relevant script instances afterwards. they’re also run through the existing script command buffer ofc

2D collider shapes are back too…

added explicit 2D shapes alongside the 3D ones:

• Rectangle
• Circle

so the full set is now:

• Box
• Sphere
• Cylinder
• Rectangle
• Circle

rectangle / circle are flat shapes. which is nicer for sprites and other 2d things

movement actually respects colliders

hex movement now checks whether an entity can actually occupy its next tile before moving there.

added a CanOccupy() collision query which builds the entity’s collider at the target position, it blocks the move if something solid is in the way.

triggers don’t block movement.

collision robustness stuff

also did a bunch of smaller fixes around the collision

• added a shared collision tolerance instead of random 1e-6s in different places
• AABB overlap now uses that tolerance too
• improved collider validation depending on the actual shape
• fixed gizmo world-to-local conversion to use the proper inverse transform
• more finite-value / clipping checks in the collider gizmo
• GJK Indeterminate results preserve the previous collision state instead of automatically counting as a collision

p.s, heres a lil photo of my attempt at making syntax highlighting for obsl using textmate grammar… :D

collision system round 2 i guess

ended up pretty much reworking most of the collision system…..

the first version was still basically 2D, with separate box vs box / circle vs circle / box vs circle functions. that worked as a starting point, but it was gonna get annoying …

so… it is 3D now.

colliders

ColliderComponent now supports:

• boxes
• spheres
• cylinders
• 3D offsets / dimensions
• triggers
• entity-space or billboard orientation

billboard colliders follow the same camera-facing basis as billboard rendering, which means billboard sprites can still have colliders that actually line up with how they appear on screen.

GJK

got rid of all the individual boxVBox, boxVCircle, etc. collision functions and replaced them with support-mapped collision detection using GJK.

each collider shape just provides a support point now, the intersection test doesn’t care what combination of shapes it’s checking.

i dont fully understand the math completely yet.. but it kinda makes sense :D

still no collision response / physics yet. this is just detection + events, i think ill prolly get it into EngineLib.. soon…

events

the CollisionWorld still tracks collisions between frames and generates:

• Enter
• Stay
• Exit

trigger state is kept with the collision too.

this is for EngineLib integration.
scripts should be able to react to collisions / triggers like unity

I have not gotten around to this yet though…

collider gizmos

also had to redo the collider gizmos now that colliders aren’t just flat 2D shapes anymore…
its a lil janky
but it works..

billboard cleanup

while doing the billboard collider stuff I also cleaned up billboard rendering a bit

billboards used to have their world transform temporarily modified by SpriteBillboardSystem before rendering. now the billboard matrix is generated when the entity is submitted to the renderer instead, so the actual ECS transform can stay as the real entity transform

there’s now one shared billboard matrix helper used by both rendering and collision, which is considerably less cursed.

um
scripting integration next i guess.. if something dosent explode ! :D

collision stuff

been working on a collider system.
still pretty early and not hooked into EngineLib yet, but most of the basic backend + editor stuff is there

planning to expose it to scripts in a similar way to how Unity handles collision callbacks / triggers, but that’s for later…….

collision

added a new ColliderComponent with:

• box and circle colliders
• offsets
• size / radius
• trigger support

collision system currently handles:

• box vs box
• circle vs circle
• box vs circle
• collision normals + penetration depth
• ‘trigger’ collisions

also added a CollisionWorld that keeps track of collisions between frames and generates Enter, Stay, and Exit events. mostly groundwork for when I hook this into EngineLib…

collider editing

colliders are editable from the editor

theres a collider inspector widget for changing the shape, offset, size/radius, and whether it’s a trigger, plus a viewport gizmo for directly moving and resizing them

collider edits also go through the undo system, because every new editor feature needs to become an undo/redo problem eventually……… :D

other editor fixes

• entity copy/paste now copies the whole child hierarchy instead of only the selected entity
• pasted hierarchies keep their parent relationships
• added copy/paste to the entity and UI context menus
• fixed stale entity / UI selections after the thing being selected gets deleted
• fixed single-key shortcuts like V, T, R, etc. firing while Ctrl/Alt/Shift was held
• keyboard camera movement no longer fights with Ctrl/Alt shortcuts
• a few smaller include / cleanup things

mostly collision work though. next step is probably getting the collision events into EngineLib and experimentiung w. it

its still a bit jank of course but it works i guess :DDDDD

copy paste (kinda)

also too much time fighting windows builds

tried to get entity copy/paste working and it’s… janky.

also ended up wasting a stupid amount of time just getting windows builds to actually build again because i lowk forgot again about how it wont let me pass paths as strings implictly as it does on every other damn os…

changes

copy/paste (wip, kinda broken)

• started on ctrl+c/ctrl+v for entities & ui in the editor it kinda works but is really janky and does not feel good to use, also tried implementing it in the context menu but its not workiong at all -.-

other

• the windows fixes….

• some resharper reccomendation inspection type shi

but lowk its been a while since i logged soo yep

sllight hub overhaul

redid the project hub screen and added recent projects tracking, since up to now opening anything meant going through a file dialog every single time…

changes

• recent projects get tracked in a PROJECTHIST file (next to the editor executable) …dead simple format, one filepath per line, each pointing at a project’s .json. capped at 5 entries, oldest just get removed off the list.
• hub screen is basically remade two docked panels now instead of one. left panel is the same buttons as before (new project, open project, etc), right panel is the new recent-projects list, up to 5 entries since that’s all the history file holds.

also

• removed some unused dead code i found…

QoL type stuff i guess :D

too many post proc fx?

followup to the post processing / shader experiments…

changes

shader includes

shaders can #include "rand.glsl" etc and it resolves properly. it checks the project VFS first, then falls back to the engine’s own shader helper directory if it isn’t found there.

engine shader helpers also get packaged into exported games under engine/shaders/, so includes keep working at runtime.

added a few helper include files:

• rand.glsl / auto_rand.glsl - seeded hash-based random, with auto_rand reseeding per frame from u_Time
• color.glsl - HSV conversion, lift/gamma/gain, contrast, saturation, and three-way color wheels
• commons.glsl - engine-provided uniform declarations so you don’t have to redeclareu_Resolution, etc. in every shader for engine-provided uniforms

the helpers use #ifndef / #define guards, so auto_rand.glsl can include rand.glsl without causing double declarations if the effect shader or another include declare the same uniforms or includes.

more built-in effects

added a few more built-in post processing effects:

• ColorGrading - exposure, contrast + pivot, saturation, lift/gamma/gain, and shadow/midtone/highlight color wheels using color.glsl
• FilmGrain - chunky per-cell grain with u_GrainSize controlling the cell size
• Vingette - yes i know its mispelled.

uniforms with Wheel in the name now get the wheel-style color picker instead of the regular color picker, since a normal RGB slider

cleaned up effect registration

used to have two separate lists, one for raw shader registration and one for the default effect chain. this meant adding an effect involved touching two different structs in two different places.

merged those into one PPRegistration list with an inDefaultChain flag

shader debug name

added an actual m_DebugName field and made error messages / the material inspector fall back to it when there isn’t a real file path.

docs

wrote up some post-processing editor docs ….. i hate writing docs..

also

• .shader is now a valid extension for importing custom effect shaders, alongside .frag / .glsl
• trimmed down the miniaudio CMake config by disabling its examples, tests, and tools, along with Vorbis/Opus/FLAC support since i’m not using any of that….

shader preprocessing

been working on a small shader preprocessor thing while also finishing up the final bits of post-processing

right now the preprocessor is pretty simple, mostly just adding support for:

• #include
• #pragma once

I haven’t actually needed it yet, I just kinda had the urge to make it… so now I have a shader preprocessor …?

its pretty extendable and all though so usefull to have ig :)

more post processing!!!!

this took way longer than i thought it would but uh whateveer. i think i still gotta fix some small things but its working pretty alright :D

editor ui

• added a proper ui for post processing :)
• threw in an import button and stuff so you can load in fragment shaders as post proc fx
• you can edit the uniforms directly in the ui now

stuff

• glsl uniform parser: wrote a very simple basic glsl uniforms parser. this is what makes the ui editing possible, but it also helps a ton with serialization so i don’t have to hardcode everything

• serialization: implemented saving and loading for post processing effects and also made post processing effects bound per-scene instead of being a global engine thing

yay post processing funny effects shaders aaaaaaaah

experimenting with post processing

working on a lil post-processing pipeline
still very wip but im mostly just playing around with various shaders and stuff

changes

the pipeline

PostProcessor is a simple “ping-pong” chain: scene renders to an off-screen FrameBuffer,
then each enabled effect runs full-screen-triangle shaders bouncing between two ping-pong buffers, in whatever order they were added

I’m working on a system via variants to get uniforms to be easily serializable and such, it seems to be working but I havent actually wired it into anything just yet.

editor and runtime

a lil bigger change than expected.
i implemented a unified fbo for both editor/runtime rather than the weird jank i was doing before

• editor: scene renders into m_SceneFrameBuffer, post effects run, then it gets sent into the ImGui viewport image like before
• runtime: same scene framebuffer, same post effects, then PresentToScreen goes to the default framebuffer instead

just some general cleanup for that ig

crt shader

i wrote a lil silly CRT looking shader to test it out as shown below, it’s cool but kind of useless, but very fun to play with!!!

custom meshes

im trynna make it so you can draw your own custom 2d meshes in the editor

its still a lil buggy but it’s mostly working, serializes and all that :)

very fun…

ui editing gizmos!!!1

you can finally drag UI elements around in the editor
(instead of typing position/scale values into the inspector)

changes

ui gizmo

added a proper UI gizmo with resize handles and dragging support and that

• corners resize both axes, edges resize one axis
• dragging the body moves the element
• resizing from the top/left keeps the opposite edge anchored
• added a small drag deadzone so clicking doesn’t accidentally create an undo step
• UI transforms now go through TransformUIElementCommand, so they’re undo/redo -able

also renamed the existing entity gizmo code and naming gets confusing otherwise…

coordinate stuff

the gizmo needed mouse coordinates relative to the viewport rather than the whole window, so added some better viewport coordinate handling for that… maybe a lil late

ui editing mode

buttons won’t randomly enter their hover/pressed states just because your mouse is sitting over them now in the editor beccause its a lil annoying when editing

small optimization

also fixed UIText and UIButton recalculating their text layout every frame when nothing changes

feels nice :)

hardening + performance stuff

so this is kinda the continuation of the last log(s) where i was going through some old code
kinda boooring but its important

performance

mainly been trying to get rid of unnecessary allocations and full scans stuff

• optimized ECS entity/component lookups and removal
• reworked hierarchy propagation to avoid unnecessary registry scans
• reduced allocations in scripting and UI command buffers
• cached script wrappers so they can be reused instead of constantly recreated
• improved UI lookups with a proper name index
• made particle/lightmap updates only rebuild when actually needed
• cached project browser directory scans
• capped the editor console and added clipping for large logs

also did a bunch of smaller optimizations around scripting task scheduling and resource loading things

thread safety

went through a lot of the cross-thread stuff as well

• made ResourceManager access properly synchronized
• experimenting with the audio locking
• guarded FreeType access
• made window size and pending scene state thread-safe
• fixed some render thread / GL context handling

basically trying to make all the multithreading stuff a little less “it seems to work” type stuff

though alot of this probably wasnt actually causing any issues YET, it would be very hard to debug in the future if I didn’t try to fix it now so yeahh

correctness

• fixed several out-of-bounds issues in VFS/package parsing
• made VFS path resolution properly stay inside the VFS root (oops…)
• fixed hierarchy reparenting allowing cycles
• fixed a few dangling references in hierarchy code
• fixed some component pool and packaged asset lifetime issues
• undo history now clears when loading a scene
• cleaned up a few map editor edge cases
• fixed text centering
• fixed the triangle mesh
• made engine context non copyable

also updated the demo template while I was at it (since a recent movementcomponent update it wasnt behaving properly due to the addition of a new field)

there are other small things i probably didn’t mention here too but it’s mostly all a collection of a bunch of small things

im still testing this though and looking into a few other small things…..

code cleanup & optimization

currently going through a bunch of older code and fixing / optimizing things.

prolly way too much to actually write about,
and most of it is just boring small changes, bug fixes, and a lil cleanup

big pr i guess soon idk

mostly windows fixes

changes

• SetLightmap took a raw Lightmap* and just held onto it for the frame swapped it for a small value type the renderer copies out immediately instead… this sometimes caused crashes but seemingly only on windows?.. just my luck..
• LightingSystem had the same issue, was writing back into ECS memory through a raw pointer from a GL init task. now creates the framebuffer/vao up front and just calls Invalidate() on them
• SubmitPersistent was also holding a raw pointer into caller-owned memory, now copies into the staging buffer like everything else does
• RenderBatch used to just silently not draw anything if a batch went over MAX_INSTANCES. now it chunks into multiple draw calls instead of dropping the whole thing
• InvalidateGLCache wasn’t resetting the dynamic instance buffers, only the VAO cache, so they could point at dead GL objects after a context loss

actual windows fixes

• opening files tries to open via already existing file associationg, otherwise falls back to the “open with” dialog if there’s no default handler
• also the paths get normalized to backslashes now
• asset import for scripts and so just does a file copy now instead of going through the old import path

persistent entities… again

kinda scrapped most of the first attempt at persistent entities and decided to redo it
instead of setting persistence in the editor, I went with something closer to Unity’s DontDestroyOnLoad, where scripts explicitly mark entities as persistent. makes more sense and is a lot less weird around scene changes.

(i.e this.SetPersistent(true); )

changes

scripting

added:

• entity.SetPersistent(true)
• entity.IsPersistent()

persistence

persistent entities are tagged before the scene unloads, serialized normally, then re-injected and reparented when the new scene loads.

the persistence tag itself isn’t serialized, so it won’t accidentally end up saved into the scene

dedup

added some basic deduplication so persistent entities don’t get duplicated if the new scene already contains an entity with the same name.

its name based for now… not very great, but good enough

persistent Entities

been working on persistent entities via a tag.. the same idea as Unity’s DontDestroyOnLoad, except you mark entities as persistent in the editor instead of doing it through scripts (scripts can do it too though).

everything keeps breaking or half-working
help.

more docs… and some bug fixes

some small bugs that have been annoying me for a while finally got fixed… and I wrote more docs than I probably needed to…? or maybe too litte.. who knows

changes

entity selection actually clears now

fixed an issue where clicking empty space in the viewport wouldn’t reliably clear the current selection.

the pick-result handling was structured wrong, so the “nothing was selected” case basically never got handled properly.
also explicitly clear the entity ID framebuffer attachment every frame so it doesn’t leave stale IDs around from previous frames.
i knew this was broken, and figured the fix would be pretty simple for a while.. but i just kinda forgot to fix it.. oops….

fixed parent transforms during scene loading

fixed a bug with parented entities getting their transforms messed up when loading a scene.

the issue was that scene loading was using the same Reparent() logic as interactive editor reparenting. that function intentionally recalculates the local transform to preserve world position,
which is what you don’t want when loading a transform that’s already been serialized correctly… was eepy when writing that i guess

added Registry::SetParentDirect() for scene loading, which just sets up the parent/child relationship without touching the transforms.

interactive reparenting still uses the old behaviour, so dragging entities around in the hierarchy still preserves their world position

misc

• cleaned out some old commented-out code

docs, docs, docs

also wrote proper editor documentation section covering things like:

• editor concepts
• usage
• scenes
• prefabs
• components
  and some even have screenshots.. yes i know.. fancy

the help button in the editor links to some of these pages now.

i guess “figure it out yourself” wasn’t really an acceptable documentation strategy anymore….
i mean i had some docs.. but they weren’t that good for editor-usage and more technical stuff.. so yep..

also made the README headers slightly more obvious because people were still asking where the download link was ….

scrips can change things on the map yippie

changes

scripting

scripts can now modify maps through EngineLib

added:

• Map_SetHexWalkable
• Map_SetTileType

yes, i made sure changes to walkability properly update the map’s pathfinding data instead of leaving it with stale information…

sanitizers

added sanitizer builds….

got ASan + UBSan working through CMake, along with presets for testing… it has helped already :)

timers

SetTimeout:

if a script created a timer and then the scene changed before it fired, the callback could still run against the old scene state.
timers now use generations, so changing/reloading a scene invalidates any timers belonging to the previous scene.

editor

fixed another map editor bug where discarding unsaved changes didn’t actually discard them… it would clear the dirty state but leave the edited map in memory…
i knew about this bug and fix for a while, but i kept on forgetting about it… but its finally done -.-

also added an Edit button to script entries in the project browser so scripts can be opened directly (launches default app it detects for the file via ur os)

mostly ui stuff (and fighting windows wide chars)

yay pretty ui

editor ui theming ui blah blah idk what to call it

• kinda cleaned up some stuff into proper members so the ui state doesn’t get all weird and persistent when you close the theme window
• discarding changes: actually works now. closing the window used to revert colors but keep your staged font changes, which was dumb (didnt really cause issues since changes werent applied anyways unless you saved beforehand but still.)
• font role indicators: added a little visual thingamabob where the font list now shows a star next to whatever font is actively set as the body font (also font name is now rendered in its proper font)
• path tooltips: added a hover tooltip on the font list items that shows the full file path of the font
• also some placeholder stuff in the code for searching the customization menu i might be implementing soon

windows compat

• std::filesystem::path everything: went through and switched out the raw std::string usage for font paths inside FontConfig, replacing them with std::filesystem::path. this was purely because my windows ci build was failing. i was passing raw char strings around and doing weird string conversions, which completely blows up on windows because it expects wide chars for paths and i didnt consider that when i was being lazy and doing silly conversions and stuff because i just wanted to pass ez pz to a c library.
• freetype & serialization cleanup: updated all the internal freetype helper functions (GetFontName, etc.) and the json theme serializer to play nice with the new paths instead of passing raw char pointers

kinda mostly just making it a lil more prettier

fighting with fonts

font-management rabbit hole in the theme editor… still wip

changes

font management in the theme editor

the theme editor now has a proper Fonts section

• import .ttf / .otf fonts directly from the editor
• assign fonts to roles like Body, Bold, Monospace, Icons, etc.
• merge fonts together so icon fonts can be stacked on top of regular fonts
• rename, delete, and change the size of fonts
• fontsets are now saved as part of the theme, so imported fonts persist across restarts

the role system isn’t fully wired up yet currently Body is used as the default editor font and Monospace is used for the console.

im still working on the whole font management system here and its very unfinished and kinda untested.. very WIP!!!

hot-reloading

the annoying part was getting font changes to work while the renderer is running on another thread.

rebuilding the ImGui font atlas in the middle of a frame was… not ideal, and eventually resulted in an assertion.

now font changes mark the atlas as dirty, and the editor waits for the render thread to finish before rebuilding the atlas at a safe point.

not the prettiest solution, but it seems to be working.. kind of

dpi & freetype

also experimented with DPI handling for fonts and wrapped FreeType into a single shared instance instead of creating separate instances everywhere.

still figuring out exactly how I want the DPI/font sizing stuff to behave, but it’s getting there.

bug fixes

while doing all of this I also ended up fixing a few unrelated things:

• fixed an old GUI rendering bug where text could stop rendering or become garbled because of a pointer race
• thanks to @staneko for helping test/report that one since I couldn’t reproduce it properly on my system
• fixed a weird compilation issue related to namespace escaping
• bumped the vendored ImGui version for some dynamic font-related fixes
• a few other small UI changes and cleanup

still working on this, and the font management side definitely isn’t finished yet…

most of this time was just spent trying to get it to half-work so.. yep..

…the default imgui theme

first off, huge thanks for all the incredibly kind reviews on my last ship !!!

most of this work was also inspired by someone pointing out that i was still using the default imgui theme.
fairs… so i spent some time making the editor actually customizable and messing around with having some kinda-nice defaults :)

editor ui & theming

• live theme editor: built a proper window to tweak colors, spacing, padding, rounding, etc. in real-time.
• semantic palettes: added a semantic color system so you can build out a theme from a small set of base colors, rather than manually adjusting every single internal imgui color enum (though you can still override individual colors if you need to).
• serialization: themes dump straight out to a theme.json sitting right next to the editor executable.
• undo/redo: the theme adjustments go through the undo/redo system!
• help menu: put in a placeholder help menu. turns out literally nobody likes reading docs, so i guess i gotta start explaining how to use the engine from inside the engine… not implemented yet though

editor groundwork

did a bit of backend cleanup as well.

• added an EditorContext for editor-specific state, separate from the runtime EngineContext (currently just used for theme stuff)

• started working on editor font support with a FontSet for things like Body, Bold, Monospace, and Icons, not implemented though

the font stuff is mostly groundwork for now, but the theming system is actually working and makes the editor feel nice :D

scripts can schedule stuff for later

Added SetTimeout to the scripting API

changes

SetTimeout

SetTimeout(fn, ms) calls fn() after ms milliseconds. simple to call from obsl

• timers live in a plain std::vector<Timer> in a new Platform::Time namespace, polled once a frame from Scene::Update no threads, no async bs or whatever :)
• the callback itself is a SmallTask, which falls back to a heap allocation if the closure is too big to fit inline fine for this since timeouts aren’t really a hot path
• timeout callback fires from an arbitrary point in Update, so it gets its own ScriptCommandBuffer set up on the worker just for the duration of the call, then flushed right after
• also gc.add_root/remove_root the function around the callback so it doesn’t get collected while it’s sitting in the timer list waiting to fire

Documented it in the api reference alongside the other Time functions

also

• tiny UI tweak in the tile editor: it now warns “no tile types defined, no map will be visible!” instead of just “no tile types defined” was seeing people get confused about why a new map looked empty after trying to paint

• also small updates to docs in general and stuff but nothing super interesting

Lighting Fixes

been fixing a few small things with the lighting system

mainly fixed lights using the wrong entity transform I forgot to account for entity parenting when I implemented that…

also added a per-scene toggle for enabling/disabling the lighting system

the repo is public

been working on gettin things ready for that,
mostly writing some docs and getting GitHub Actions set up so I can build and release cross-platform builds

also did some small code cleanup / fixes while I was going through everything.

changes

github actions

i setup a workflow to compile the project on linux, windows, and mac, and then publish a release (mac is untested but compiles).
im real happy though that its actually compiling on all “major” platforms though

docs

finally wrote some actual documentation… there are a few files in the docs/ folder now and a proper README

still a WIP obviously, but at least there’s something there…

misc

implemented create new map button i forgot about completely

repo

there is already a build published as a test of the github actions thingy, try it out if you want :D
https://github.com/torkelicious/obliberry

Bugs bugs bugs…

I’ve been working on a demo project to both test the engine properly (looking for bugs and all), and also have something to actually show off made in my engine…
this is the project you’ve been seeing in the last couple logs btw :)

of course… since I’ve been using the editor for actual “work”, I have found a bunch of bugs.

the biggest one being the entity ID situation… or.. disaster?

changes

the entity ID mess

in the past, out of laziness…
entity ID 0 was being used as both a real, valid entity handle and the “no entity / invalid” value depending on where you looked.

which worked fine… mostly because of pure luck.

the annoying part was that after working on this for a while I wasn’t even sure anymore if I was using 0, -1, or something else for invalid entities.. yep..

so I finally cleaned it up

there is now a proper INVALID_ENTITY_ID constant, and entity index 0 is reserved for invalid entities. real entities now start from 1.

went through and replaced a bunch of random == 0 / != 0 checks across ECS, serialization, prefab handling, editor panels, and scripting bindings.

project templates

added support for multiple project templates.

new project creation now scans the Templates/ folder instead of everything being hardcoded to “Default”.

currently has:

• DemoProject
• Empty

the demo project is mostly there to show off the newer UI/scripting stuff (the same demo as mentioned before), while Empty is just a completely blank scene.

hierarchy & transforms

fixed entity and UI reparenting.

previously moving something to a new parent could randomly change its position because it was just applying the new local transform

now reparenting keeps the world transform, so dragging things around in the hierarchy behaves properly

UI & text rendering

fixed a bunch of UI text issues.

• text now centers vertically using actual glyph metrics instead of a random offset I was “pretty sure” was correct

  it was not, in fact, correct

• button text now scales to fit inside the button
• fonts can now load directly from VFS memory instead of requiring a real filesystem path

the VFS font loading one was something I completely forgot about when testing outside packaged projects… oops.

packaging

implemented .pakignore

instead of a hardcoded ignore list, the packer now supports gitignore-style patterns in a .pakignore file and properly skips ignored folders/files

also fixed a few smaller packaging issues while testing exported projects.

misc

a bunch of smaller things:

• map save/load dialogs now default to the project maps folder
• fixed scene switching bindings in editor play mode
• fixed a lightmap redraw bug
• font importer now only accepts .ttf / .otf
• added a small README with build instructions since im planning on publishing the repo soon (and writing all the docs… scary..)

nothing super flashy this time.. but important

Windows Build

The Windows build seems to be working..
I don’t have proper OpenGL passthrough in my VM…
However, the Windows executable compiles perfectly in the VM and is running fine under Wine.
so I consider that a win for now…

working in a windows vm trying to get it to compile on windows… it is obviously going great… -.-

Entity Hierarchy & Scripting Integration

finally caved & added actual parent/child relationships to entities

changes

entity hierarchy

• entities can now have a parent & children via a new RelationshipComponent. Registry::Reparent() handles moving an entity under a new parent, with cycle & self-parenting protection so you cant do anything silly like parenting an entity to its own descendant.
• TransformComponent now has a worldTransform alongside the existing local one, a new HierarchySystem
• systems that care about actual position (i.e AISystem) read worldTransform now instead of assuming local == world.
• destroying an entity recursively destroys its children too & unlinks it from its parent’s child list
• scene serialization now saves & restores the hierarchy

editor

• the Registry panel is a proper collapsible tree now instead of a flat list
• drag & drop reparenting, plus a right click menu for “Create Child”, “Detach”, & “Set Parent”.

scripting

• pulled all the entity/component script bindings out into their own EngineLibRegistry.cpp module, they were kind of scattered around before & this makes them way easier to find & extend.
• scripts can now walk the hierarchy too (get children, etc), same module.
• added SetFont/GetFont bindings so scripts can assign or query a button’s font, small thing but script generated buttons wont have visible text without it :)

misc cleanup

• small modernization stuff while i was in these files anyway: dropped redundant ternary parens, swapped a bunch of auto x = ...; if (x) into if-with-initializer, dropped some unnecessary global qualifiers, const-correctness fixes on UISystem::Update & UIRenderer::Flush.

(yes i know the gizmos are offset and buggy, i kind of forgot to update the gizmo code after changing transforms :p )

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

Project Packaging

been working on a packaging format for projects.

the goal is basically to package an entire project into a single container while preprocessing assets that make sense to preprocess. Also makes shipping a game made in the engine in the future alot easier / cleaner, and portable.

changes

packaging

implemented the start of a proper project packaging system.

currently it:

• parses ObSL scripts ahead of time and stores serialized ASTs instead of source code (basically very similar to some sort of a very very simple AOT compiler)
• converts project, scene and prefab JSON files into MessagePack
• stores media and other binary assets directly in the package
• optionally compresses package entries with LZ4

the idea is that the engine has less work to do at runtime since scripts don’t need parsing and JSON doesn’t need parsing either.
and a single “package” file is alot cleaner in general for a finished game “build”

package format

also implemented the actual container format itself.

different asset types are stored as different entry types (scripts, binary JSON, media, shaders, etc.), so the loader knows exactly how each asset should be handled.

tools

added standalone packaging tools as well for packing and unpacking projects, mostly for testing.

still a work in progress, but the whole packaging pipeline is starting to come together.

editor Gizmos! :DD

this took a lot longer than I’d like to admit… but it’s finally working.

changes

gizmos

• got all gizmos working.. but had issues with rotation and scale at first
• figured out the issues with rotation/scaling
• ended up patching ImGuizmo at first to get things working, but after digging through the code I eventually figured out how to do it properly with the normal library
• translation, rotation, and scale gizmos all work now :))))))

honestly I learnt quite a bit just from messing around with the ImGuizmo internals.. but it was painful

editor

added a few more UI improvements as well.

i.e billboard sprites now explicitly mention that rotation doesn’t do anything, instead of letting you wonder why nothing happens

gizmos are one of those things I’ve been waiting on implementing.. but im finally happy to have them

actually working on the editor

I’m finally getting around to actually implementing the editor ..it still looks pretty similar (well mostly the same) but most of the UI before was just placeholder.

changes

editor

• implemented a Project Settings window
• implemented a Scene Properties window
• made the component widgets actually do something now
  • load textures
  • assign scripts
  • change material colors
  • change meshes
  • change shaders
  • etc….
• added an Add Component button
• added Remove buttons to components

it works.. so thats good :D

ObSL Scripting Library

Moved the scripting language into its own repository :)

It’s now included in the engine as a library using git submodules and public headers instead of living directly in the engine source code

Makes the project structure a lot cleaner .. for both projects

( ObSL can now be found at https://github.com/torkelicious/ObSL )

Script multithreading (and concurrency)

scripts now run on other thread(s) :D

this took a fair bit of cleanup, but it’s working.

changes

script workers

• moved script execution onto worker thread(s)
• worked on script worker concurrency
• dynamically clamp the number of active workers based on how many callbacks are actually running, so idle threads aren’t just spinning doing nothing

garbage collection

did some work on the GC as well.

• introduced external root tracking
• fixed a few issues around GC roots while getting multithreaded script execution working

cleanup

spent some time cleaning up a bunch of backend stuff while getting all of this working.

build system

updated CMake so all executables, scripts, and (project) templates are output to a single build/bin directory instead of being messy.

multithreading yay :)

ive been mostly messing around with getting the ObSL language to be thread-safe and refactoring some things, so I don’t have much to show but my end goal is to be able to get scripts to run concurrently and outside of the main thread

Editor & Scene Management

been working on the editor mostly.

changes

ECS

implemented generational ID masks for the ECS.

this should prevents issues with stale entity references since IDs can now properly track generations instead of just relying on raw IDs. (i encountered this issue when testing multiple scenes in one project)

scene manager

fully implemented the SceneManager so it can actually be used by the editor & game layer.

this allows the editor to properly load/save/validate/find and generally handle scenes through a unified API (goes for gamelayer aswell but it only really loads them)

bug fixing

spent a lot of time fixing various issues around:

• project folder management
• scene management
• loading / saving behaviour
• asset loading (cache was causing some problems on loading scenes but its all fixed now :D)

mostly backend work but things are becoming a lot more stable and the editor foundation is starting to come together….

Namespace Refactor & Project Management Work

Dependencies finally caused me to run into a namespace conflict after being lazy and unorganized…

instead of being sane and just renaming one class.. I decided to refactor the entire project to use proper namespaces everywhere..

changes

namespaces

• Refactored the entire codebase into proper namespaces

project management / editor backend

I don’t really have much visually to show this update since I’ve mostly been working on backend stuff.

Working on:

• project management
• scene management
• VFS improvements
• editor saving/loading

I’m using nativefiledialog-extended to work on proper file dialogs for saving and loading from the editor.

Also been doing a lot of testing around project creation and loading.

alot of this is in the hope i can get this working multi-platform and not just on linux (though i have yet to try and compile on another os)

Things are working… for now… so progress :D

Editor Picking & Project Management

because my EditorLayer uses a framebuffer, I can now utilize framebuffer color picking in the editor

i updated the shaders to store an entity ID, so now I can click on entities directly in the editor scene view and it selects them.

…and it’s pixel perfect :D

changes

editor layer

• added framebuffer based entity picking
• clicking entities in the scene view selects them!!!!
• selection is based on the exact pixel under the mouse

(i mean to implement gizmos i first need to know what the hell my mouse is on)

project management

also started laying the groundwork for actual project management.

now that I have some sort of VFS implemented, I’m working on a way to properly manage Projects instead of relying on the current setup.

still figuring out the exact structure, but ive been working on setting up the Project class

VFS & Editor layer

implemented a basic VFS (Virtual File System).

all asset loading is now routed through the VFS instead of directly loading files.
this is mainly preparation for adding proper project management later instead of relying on a hardcoded project.json in the project root i was testing with

changes

VFS

• added a basic VFS implementation
• routed asset loading through the VFS

the idea is that the VFS will make it easier to manage project assets and not have everything depend on hardcoded paths.

editor layer

still experimenting a bit with the editor placeholder UI.

added:

(new EditorCamera derived class of Camera )

• camera panning in the editor viewport
• camera zoom
• toggling top-down / isometric perspective with keybinds

the top-down view should be useful later when I add actual map editing stuff

most of the editor UI is still just placeholder right now, I’m mostly testing layouts and figuring out how I want the editor to feel and look

ImGuizmo

also added ImGuizmo to the project since I’m planning to start implementing proper editor stuff soon..

…and well… you need gizmos…

I’ve reinvented the wheel enough already, so using a proper gizmo library seems like the better choice :) (also integrates very nicely with ImGui)

Editor UI & Framebuffer Experiments

i’ve started experimenting with the ImGui docking branch in the EditorLayer.
(switched branch had some build errors blah blah blah but its all set up now)

Implemented some placeholder editor UI to test out the docking stuff and get a feel for how the editor layout might end up being like

changes

editor layer

• placeholder UI using ImGui docking features
• testing editor panel layouts

framebuffer

implemented a framebuffer system for the editor viewport.

• the scene is currently rendering in the editorlayer via a frame buffer so it can fit in the little thingy (i forgot the name)

while testing I noticed some resizing issues when running on my nvidia dGPU:

the framebuffer resize works, but resizing the viewport can appear somewhat choppy?

the framebuffer and docking setup seem to be working, so i guess this im close to actually start to build proper tooling :)

refactoring for editor foundation

Refactored rendering and culling systems and made broader architectural changes to decouple the game from the application layer.

Rendering & Culling

• Refactored frustum culling logic to be lil more performant and generally cleaner
• Cleaned up and improved parts of the rendering pipeline since i had alot of old unused code lurking in them since i switched to a multithreaded architechture

Application Architecture

the engine is now structured around an ApplicationLayer system.

• The core Application class now runs a single active ApplicationLayer
• Each layer exposes:
  • Init
  • Update
  • Render
  • Shutdown

Game class refactor

• The Game implementation has been converted into a derived ApplicationLayer
• Game logic is now fully driven through the layer system instead of hardcoded to the application class (the different executable mains decide now)

Editor Layer

• added a new EditorLayer
• Intended for a future scene editor application.
  (right now all it does is render a given scene on the screen)

CMake changes

reworked the project to generate multiple executables:

• obliberry_engine core engine executable (ig runtime)
• obliberry_editor editor application layer

changes:

• Engine and core systems (i.e ObSL, Renderer, etc) are now compiled as libraries
• Executables link against shared engine libraries instead of duplicating code
• Editor executable links against engine modules

summary

• Game logic is now layer-based
• Engine and tools are separated
• Editor can proceed independently from the game runtime

multithreading & rendering

I think I got some form of multithreading working now.

The renderer has been moved onto its own dedicated thread, separating rendering from the main engine thread :)

Changes

Rendering Thread

• Moved rendering execution to a separate thread

(alot had to be refactored for this to work lol)

Thread Safety

• i tried

  (imgui was a pain)

Rendering Optimizations

Added frustum culling to the renderer.

big optimizeD?

actual rendering (i.e gpu calls) is now seperated from the main thread :D

…it looks like its working for now

I think i fixed most of the silly bugs from trying to make rendering thread safe, im still gonna double check some stuff and do some testing but moving rendering to its own render thread will be coming soon :))))

kinda reverted changes from the last log and tried again to convert everything to be thread safe before actually trying to run on a seperate thread… things are going.. interestingly

im trying to make the renderer run on another thread… few issues… cant see (entity) meshes?, and closing the window seems to cause a freeze…. :))

Been mostly just fixing some window rendering stuff
Moved away from hardcoded resolution / aspect ratio and made it handle itself on the fly
also removed the padding bars i had before so rendering actually takes up full screen
New native engine binding in EngineLib too:
Window_SetFullscreen

(takes a bool)

I’m planning on starting to work on making the engine multithreaded soon…

“project” file system prototype

Started implementing support for engine project files instead of hardcoding a scene path like i was before for testing.

The engine will now deserialize a project.json file containing configuration,

includes:

• name Project name (unused for now)
• version Project version (also unused)
• start_scene Path to the scene the engine loads on startup
• Window configuration:
  • width
  • height
  • title
  • fullscreen

while implementing this, I uncovered some unexpected behaviour related to fullscreen handling caused by how window sizing was previously managed.

i spent time refactoring and fixing the window size logic to make fullscreen behaviour… work..

project loading is now starting to come together, less hardcoded stuff yippie

(im planning on making an editor in the future so.. this is why)

Porting ECS systems to ObSL

Fully ported the InteractionSystem to ObSL through EngineLib.

Camera movement and player movement are now handled through dedicated ObSL scripts instead of being hardcoded ECS systems. This moves more gameplay logic into the scripting layer and makes systems easier to modify and iterate on :)

Changes

System Migration

• Ported InteractionSystem from ECS code to ObSL

Basically Moved camera movement & player movement logic into ObSL scripts

• Interaction system is no longer hardcoded engine-side gameplay system

New EngineLib Bindings

Math / Hex Grid

• Math_WorldToHex Converts world coordinates into hex grid coordinates
• SetSelectedHex Updates the currently selected hex tile

Camera

• Camera_SetZoom Sets the camera zoom level

Window

• Window_GetHeight Gets the current window height
• Window_GetWidth Gets the current window width

Input

• Input_IsKeyReleased Checks if a key was released
• Input_IsMouseDown Checks if a mouse button is currently held
• Input_IsMouseReleased Checks if a mouse button was released
• Input_GetMouseX Gets the mouse X position
• Input_GetMouseY Gets the mouse Y position
• Input_GetScrollX Gets horizontal scroll input
• Input_GetScrollY Gets vertical scroll input

Please ignore the weird graphical artifacting in the attached video, my pc has been acting up recently :(

more EngineLib work

Implemented several improvements to the scripting and entity systems.

changes

prefab caching

• Added caching for prefabs to improve performance when repeatedly instantiating entities

Entity Access in Scripts

• Added GetEntity, which returns the entity Object that the script is attached to.
• Added support for the this keyword in ObSL scripts.

this is a wrapper around GetEntity() to provide direct access to the current entity

custom components

Added support for script-defined components:

• entity.AddCustomComponent
• entity.GetCustomComponent

This allows scripts to attach and retrieve custom data/components without requiring engine side component definitions

entity validation

Updated all entity object calls (such as GetComponent) to validate the entity before executing
(in both native bindings & engine source code)

Entity operations now check:
registry.isValid(id)
before accessing the entity.

This prevents errors caused by accessing deleted entities during scenarios such as scene unloading/loading cleanup

EngineLib

I may have forgotten to mention this in my previous log, but I also implemented an Instantiate method in EngineLib.

Instantiate takes an entity definition as a JSON file (ig a prefab) and spawns the entity into the current scene.

I also added scene related functionality to EngineLib:

• LoadScene Loads a scene from a given path
• GetCurrentScenePath Returns the path of the currently loaded scene

I’m using miniaudio to implement audio support in the game engine, with an AudioEngine class to abstract the audio functionality.

I’ve also updated SceneProperties to include a new background_music property.
This allows each scene to define a background music track (via filepath) that will automatically loop through the AudioEngine while that scene is active.

It all seems to be currently working well,

Next I’m starting to integrate audio functionality into EngineLib so that scripts can interact with the audio system.

changes

• Added AudioEngine abstraction layer using miniaudio
• Added background_music support to SceneProperties (w. proper serialization/deserialization ofc)
• Implemented looping background music per scene

EngineLib Script Integration

I fully replaced the previously hardcoded PlayerMovementSystem with an ObSL script implementation using new EngineLib bindings.

The movement logic is now handled externally through scripting instead of being directly implemented in C++.

New EngineLib Bindings

entity management

Added bindings for basic entity operations:

• CreateEntity Creates a new entity
• Destroy Removes an entity
• HasComponent Checks whether an entity has a specific component
• RemoveComponent Removes a component from an entity

global functions

• get_dt Retrieves delta time
• CloseWindow Closes the glfw window

Input System

Added script access to input handling:

• Input_IsKeyDown Checks if a key is currently held
• Input_IsKeyPressed Checks for a key press event
• Input_IsMousePressed Checks if a mouse button is pressed
• Input_GetMouseWorldPos Gets the mouse position converted to world space

Movement / Hex Grid Functions

Added bindings for interacting with movement components:

• GetSelectedHex Gets the currently hovered hex tile
• SetPathToHex Sets a movement target path for an entity with a MovementComponent

Camera

Added camera manipulation support:

• Camera_GetPosition Gets the camera position
• Camera_SetPosition Sets the camera position
• Camera_Move Moves the camera
• Camera_PanScreenSpace Moves the camera relative to screen space
• Camera_GetZoom Gets the current camera zoom

Hex Rendering

Added bindings for controlling grid visuals:

• ClearSelectionOverlay Clears the hex selection overlay
• ClearPathTarget Clears the path target visual marker

ClearPathTarget is currently named poorly. It only clears the grid overlay visualization, not the actual movement target!!!

summary

• Removed the old hardcoded PlayerMovementSystem
• Migrated player movement logic into script format
• Added engine bindings required for script-driven gameplay
• Camera movement, input handling, and hex selection now work through scripts
• Even more gameplay code can now be modified without recompiling the engine :)

I’ve got a good basis for the Engine integration library for the ObSL Scripting Language.

In the attached video, I’m changing the player’s size using a ping-pong function (?forgot the name…), fully through an ObSL script (ScriptComponent) attached to the “Player” entity.

The language now has support for the following through the EngineLib:

Entity Objects

• Find
• GetName
• SetName
• GetComponent

Components

Transform

• SetPosition

• SetRotation

• SetScale

• GetPosition

• GetRotation

• GetScale

  (uses ObSL arrays)

Point Light

• SetColor (Vec3)
• SetIntensity
• SetRadius

MovementComponent

• GetIsMoving
• SetIsMoving
• SetTimePerStep

MapStateComponent

• GetHasSelection
• GetSelectedHex
• GetPathToHex

DirectionalTextureComponent

• SetIndex
• GetIndex

PlayerInputComponent is still w.i.p.

Tag Components currently don’t have any methods since they are only used as tags.

Planned

I’m planning to keep expanding the EngineLib api with more methods, such as:

• Has(component)
• AddComponent
• RemoveComponent(name or ref)
• Destroy(EntityID)
• GetEntityID(entity object ref)

I’ve got the scripting language integrating with the engine via a ScriptComponent on the player entity,

seems to be working all good though I still have to implement the actual Engine library for everything…

but I have simple scripts running on entities as components in the game engine, which went faster than I expected, so i’m happy with it :)

Drafting a readme for the scripting language before I plan on the Engine bindings

added switch statements, foreach-loop, objects, modules (imports), and a standard library to the scripting language

I’m working down my todo-list for the scripting language (ObSL). Right now i’ve got arrays implemented!

i also made a method to define functions from the c++ source so that I can access c++ stuff
(like std::chrono functions that im using for testing right now from the test.obsl script),
and whatever other functions i want to have accessible,

this will be very useful later on as I to integrate the scripting language with the game engine, as now i have an easy way to call functions already defined in the engine source code from the scripting language by just calling interpreter.bind_native(args blah blah); and then I can call the function from the interpreted scripts.. very useful :D

the scripting language now has some more mathematical operators and functions !

The scripting language is now technically Turing complete, as i have added state environment (basically variables persist throughout the session), conditional branching via if / else statements
basic repetition via while & for loops

the screenshot below shows a fibonacci sequence &
an example of the conditional branching w. looping .

of course it’s not done yet though, i still have a lot of work ahead :)

still working on parsing and implementing new nodes :)

Working on trying to implement a scripting language for my game engine…

i’ve got a simple parser working,
it definitely went faster than i expected. Going back and reviewing an old parser i made in C# a while ago helped a lot in this :)

I’d like Entities to be scriptable in a future editor application / in general without having to edit c++ source files of the editor to implement new logic systems for one entity, so i’m planning on implementing a very basic scripting language, the way i plan on it working is that you attach a script to an entinty as a component, and it will hold the actual game logic in that script, im not great at explaining with words but what im doing now is starting on implementing lexical analysis for a simple interpreter just to test things out, while I have written small interpreters before, alot of this is still new to me so I am learning along the way. the idea is that its just a very basic scripting language to interact with entities and the current scene, with basic apis for interacting with the current scenes ECS registry,we will see how it goes :)

I’m working on a simple map lighting system, which seems to be working alright.

Also scene files now have background color information (which ends up getting wired into glClearColor), also implemented name field for entities because why not.

I’m also messing around a bit with the UI since im not super experienced with ImGui but I like trying things out…

I’ve been focusing mostly on my scene serialization lately.
First, I refactored the maps to remove the hardcoded TileTypes enum, which used to map 0 to grass and 1 to sand.
Instead, I implemented a system where this is defined in the grid section of the scene’s json file. The “id” property is now a generic unsigned integer for the tile type, and the “texture” property references a specific asset loaded in the scene.

I also added a “properties” section for the scene’s name and a “clear_color” array. This lets you dynamically change the window’s background color on the fly instead of always defaulting to a hardcoded black.

Writing the new methods and sorting out the custom serialization logic took a bit of work, but it is working great now.

also bumped the map file “version” to 2, even though the reading/writing of map files didn’t change at all, the usage of some bytes did kind of change (for the tiletype) so i felt it was fitting

i’ve been playing with loading in entities and meshes..
ignore the weird fps drops and generally low fps (compared to normally), screenshots and recordings loves messing with performance for some reason

i’ve implemented instanced draw calls alongside regular draw calls in my renderer, which currently im using instancing for drawing the map, I also implemented culling for the map depending on viewport and some other small optimizations, I also spent some time on fixing and improving my “Systems” and some general cleanup

Managed to fix the segfault..
Mesh::Upload was updating buffer data without binding its own VAO first, which polluted the global OpenGL state. When a new scene loaded, the driver tweaked out on the broken index bindings and crashed on the next draw call …

I’ve got saving scenes working fully now! ^-^,

but an issue ive run into is a segmentation fault on switching scenes, I theorize that it’s due to me not cleaning up / reassigning things when I load in new meshes etc from the scene, thus leaving old pointers in the render queue which don’t exist anymore. This i will work on fixing next..

But for now I am quite happy that i have scenes loading and saving to json :)

I’ve got loading in scenes working pretty well,
but I still have work todo before I can save them properly, im pretty tired already since i spent all day chasing a bug regarding render sorting and ended up refactoring a ton of stuff that i probably didnt have too as i was searching for the issue, but atleast the codebase is somewhat cleaner

running some tests.. messing around with funny map generation shapes too but i dont know how i feel about them

rather than using another custom file format i decided to just use json to serialize scenes which is coming along rather nicely …

I’ve been restructuring the and moving things to run actual game logic via “Systems”.

I’ve temporarily been testing this in a messy way directly in the scene class, but I’m planning on implementing maybe some sort of basic scripting language that can be used for game logic in entities as a Component w. accompanying systems ofc,
so game logic can be defined outside of engine source files and serialized into a scene’s registry from a given file rather than the things im messing around with now.
serialization of scenes is what im planning to implement next once im happy with how scenes are working, but i need to plan ahead alot.
So for now I’m still going to focus on making sure my Scene implementation is good enough before I focus on implementing serialization and scripting etc, and I have alot to think about regarding the design and architecture of this thing that seems to have evolved into a Game Engine :)

working on getting Scenes implemented

I completely refactored my ECS into an actual proper entity component system and added a lil fancy inspector for entities/components in the UI, everything works with the new system :)
Now that my ECS is properly implemented I’m going to start focusing on implementing proper Levels/Scenes rather than the mess I have right now in my “Game” class which I’ve been using for testing stuff

(ignore the weird framedrops my screen recorder was tweaking out)

i made a npc (the red super mutant) that just wanders around

I’ve been having a bit of fun with player sprites (currently som fallout 1 super-mutant sprites i found online) and the renderer sorting sorting code to avoid the player appearing under the ground

I implemented reading from the previously saved map file, with some tests ofc :D
please ignore the player flying away at the end.. as of the time of writing it was a sloppy bug which is already fixed

I’ve implemented saving the current grid to my own custom file format, and some tests to check that it’s working and all seems good.. but now, the real test is to see if I can load back in that file properly :)

I did a few things

i made it highlight what hex the player is currently moving towards in white

fixed a bug causing it to crash when i tried to use my dgpu (issue with my GLdebug class trying to load unavailable glDebugMessageCallback since my dgpu driver uses an older OpenGL version than my igpu and i kinda forgot to check if it the callback function was available BEFORE calling it.. .-.)

refactored some of my Hex code to prepare for making some sort of system to load maps from files, so i generally cleaned up some stuff and opted for smaller datatypes for my needs (i.e using int16_t rather than ints for hex coords r & q, since that’s really all you need unless your map is massive)

i also added some more fancy ui with imgui to play around with and generally just cleaned up some code…

in short im basically preparing myself to implement some sort of map file loader w. accompanying filetype?

I managed to setup a basic ImGui window to control map generation, I also tried to optimize my rendering by fixing a sloppy bug i had in my batching implementation and caching transformation matrices per transform (dirty flag pattern)
fps does seem stable :)

(please ignore the video artifacting)

I redid almost everything with what i’ve learnt from trying the first time

(ECS, ResourceManager & MeshFactory are basically the same though)

I managed to implement A* pathfinding for the player movement.

I got to render out the map with textures i made.
tried to recreate movement like Fallout has, where you move the mouse to pan and click to move to a tile with stepping.

The hex grid is reperesented via an odd-r offset layout.

Experimenting with camera stuff and input, now i can zoom with the scrollwheel and i’m trying to get an isometric perspective working better

im getting a simple resource manager implemented :)

It may not look like much, but I’ve been working on implementing a form of an ECS , rewriting some stuff too. I kind of broke some camera stuff in the process which I’m going to fix soon, and actually get this stuff to be the correct perspective and such….

i’ve been experimenting with some stuff back and forth, now im working on testing basic “Player” movement with WASD

I’ve implemented proper debug logging for OpenGL, optimized rendering with a queue that sorts RenderCommands to avoid unnecessarily binding & unbinding, a basic InputManager class, and very basic materials.

i’ve got a basic hex grid “map” rendering and working well

Implemented a basic camera which im messing around with a bit to rotate (around) my mesh

I now have textures working, and a basic “meshfactory”

I’ve gotten transforms and basic rendering implemented of objects implemented via a “Mesh” class that gets passed to Draw() in the Renderer Class :)

Setup basic GLFW Window boilerplate & CMake Project :)