obliberry
- 86 Devlogs
- 266 Total hours
Fallout inspired isometric game engine with it's own intergrated scripting language (C++ w. OpenGL)
Fallout inspired isometric game engine with it's own intergrated scripting language (C++ w. OpenGL)
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?
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.
added support for multiple project templates.
new project creation now scans the Templates/ folder instead of everything being hardcoded to “Default”.
currently has:
DemoProjectEmptythe 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.
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
fixed a bunch of UI text issues.
it was not, in fact, correct
the VFS font loading one was something I completely forgot about when testing outside packaged projects… oops.
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.
a bunch of smaller things:
.ttf / .otf
nothing super flashy this time.. but important
working in a windows vm trying to get it to compile on windows… it is obviously going great… -.-
finally caved & added actual parent/child relationships to entities
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
AISystem) read worldTransform now instead of assuming local == world.EngineLibRegistry.cpp module, they were kind of scattered around before & this makes them way easier to find & extend.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 :)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 )
alot of bug hunting…
scripts can now actually interact with the UI system.
added bindings for things like:
these return wrapped objects with basic getters/setters for position, visibility, and button state
spent a fair bit of time cleaning up the map editor flow.
mapFilePath now stays project dir relative instead of randomly becoming absolutei’ve been doing alot of testing recently, so i found alot of bugs…
this was probably the biggest pain point.
Shader::Default() singleton hack with a real fallback shader (internalshaders base)Texture move bug that was double-deleting GL handles sometimesalso cleaned up a bunch of editor behavior while I was in there.
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 :)
been continuing work on the UI system.
made some good progress UI system
currently have:
it’s still very much WIP
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…
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.
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
started prototyping a custom UI system
it’s very early, but I’ve got the basic rendering pipeline up and running
currently working on:
UIElement systemright 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)
been spending some time on the particle system…
expanded the particle system quite a bit.
currently supports:
also added an editor preview mode, so particles can be previewed while editing instead of only showing up in play mode
had to do a bit of renderer work to support all of this
also did a some more project cleanup, splitting up my Utils header into multiple files.. nothing special though
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.. :)
Ive started working on a particle system.
i have got the core pieces in place and it seems to be working nicely so far….
implemented the foundations of the particle system
currently has:
ParticleEmitterComponentParticleSystemParticlePoolemitters currently support:
so far it’s all behaving pretty well…
next up is getting particles exposed through the EngineLib API so scripts can spawn and control emitter components
we will see how it goes…
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
i built a dedicated graphics configurator window in the window, for the current project (GraphicsConfigEditor).
UndoManager using the command pattern (GraphicsConfigUpdateCommand)graphics.json.QuerySupportedSampleCounts which asks the active GL context (before it gets handed to the render thread)the editor now supports prefab management that i implemented earlier
.. instead of directly writing it in the scene json file
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
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.
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?)
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.
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
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
rewrote the lighting system.
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
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:
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
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.
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 allocsbeen cleaning up how the main thread interacts with the render thread.
m_ReadyFrames deque main pushes a frame index, render pops it. much cleaner :)(ive put off fixing that hack for a while so its nice to finally come around to it).
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.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.VFS::ReadVirtualView to hand out string_views directly into memory instead of owned stringsContainerReader 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 charsstat() syscall on every script file every frame. oops. now polls every 300 frames & caches resolved paths.. thought i already debounced this.. guess not..
on_update & on_destroy work buckets used to be freshly allocated vectors every frame… now static, so they just clear & reuse capacityGameUI.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
(this one was annoying to figure out.. god bless strace & gdb)
typeMats from an unordered_map to a flat vectornothing 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
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).
expanded the command system to cover most editor actions.
currently supports:
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
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.
did a bit of cleanup around the editor while wiring everything together.
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
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
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:
(with the exception of
ScriptComponentfor 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:
its still pretty basic, but it works and feels nice to use.
for this, I added proper key-combination support to the input manager.
things like:
Ctrl + SCtrl + ZCtrl + Ycan now be handled properly instead of manually checking modifier keys everywhere
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
still nothing super flashy.., mostly a bunch of small things
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
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)
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
fixed up some more logging :)
replaced all the random std::cout / std::cerr calls scattered throughout the project with an actual logging system
implemented a proper logging system.
std::cout / std::cerr throughout the enginenothing 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 :)
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..
actually got the map editing tools working for real this time.
spent some time making the tile palette and material editing.. work.. video explains better ngl im not good at describing ui stuff
Lerp, CubeRound, and GetHexLine)still a WIP…
map editor preveiw ig kinda didnt have much time to do anything today but im working on the tile editor
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.
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.
started putting together the map editor.
currently i have:
the actual editing logic isn’t implemented yet, but the foundations are there now :)
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)
fixed a few editor rendering issues while i was at it.
doesn’t look massively different in screenshots, but makes future work alot easier/cleaner
map painting is next ?..
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
.obpak
(just 2 files for full project!, executable and .obpak)
the whole process is pretty much one click now instead of manually packaging everything together.
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 :)
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?)
implemented the full packaging/loading pipeline yippie :D
currently the packer:
.obpak containerassets like textures, audio and shaders just get copied into the package without any conversion
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)
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
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.
implemented the start of a proper project packaging system.
currently it:
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”
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.
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.
this took a lot longer than I’d like to admit… but it’s finally working.
honestly I learnt quite a bit just from messing around with the ImGuizmo internals.. but it was painful
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
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.
it works.. so thats good :D
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 )
scripts now run on other thread(s) :D
this took a fair bit of cleanup, but it’s working.
did some work on the GC as well.
spent some time cleaning up a bunch of backend stuff while getting all of this working.
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
been working on the editor mostly.
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)
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)
spent a lot of time fixing various issues around:
mostly backend work but things are becoming a lot more stable and the editor foundation is starting to come together….
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..
I don’t really have much visually to show this update since I’ve mostly been working on backend stuff.
Working on:
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
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
(i mean to implement gizmos i first need to know what the hell my mouse is on)
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
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
the idea is that the VFS will make it easier to manage project assets and not have everything depend on hardcoded paths.
still experimenting a bit with the editor placeholder UI.
added:
(new EditorCamera derived class of Camera )
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
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)
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
implemented a framebuffer system for the editor viewport.
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 :)
Refactored rendering and culling systems and made broader architectural changes to decouple the game from the application layer.
the engine is now structured around an ApplicationLayer system.
Application class now runs a single active ApplicationLayer
InitUpdateRenderShutdownGame implementation has been converted into a derived ApplicationLayer
EditorLayer
reworked the project to generate multiple executables:
obliberry_engine core engine executable (ig runtime)obliberry_editor editor application layerI 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 :)
(alot had to be refactored for this to work lol)
i tried
(imgui was a pain)
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…
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 startupwidthheighttitlefullscreenwhile 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)
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 :)
InteractionSystem from ECS code to ObSLBasically Moved camera movement & player movement logic into ObSL scripts
Math_WorldToHex Converts world coordinates into hex grid coordinatesSetSelectedHex Updates the currently selected hex tileCamera_SetZoom Sets the camera zoom levelWindow_GetHeight Gets the current window heightWindow_GetWidth Gets the current window widthInput_IsKeyReleased Checks if a key was releasedInput_IsMouseDown Checks if a mouse button is currently heldInput_IsMouseReleased Checks if a mouse button was releasedInput_GetMouseX Gets the mouse X positionInput_GetMouseY Gets the mouse Y positionInput_GetScrollX Gets horizontal scroll inputInput_GetScrollY Gets vertical scroll inputPlease ignore the weird graphical artifacting in the attached video, my pc has been acting up recently :(
Implemented several improvements to the scripting and entity systems.
GetEntity, which returns the entity Object that the script is attached to.this keyword in ObSL scripts.
thisis a wrapper aroundGetEntity()to provide direct access to the current entity
Added support for script-defined components:
entity.AddCustomComponententity.GetCustomComponentThis allows scripts to attach and retrieve custom data/components without requiring engine side component definitions
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
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 pathGetCurrentScenePath Returns the path of the currently loaded sceneI’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.
AudioEngine abstraction layer using miniaudio
background_music support to SceneProperties (w. proper serialization/deserialization ofc)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++.
Added bindings for basic entity operations:
CreateEntity Creates a new entityDestroy Removes an entityHasComponent Checks whether an entity has a specific componentRemoveComponent Removes a component from an entityget_dt Retrieves delta timeCloseWindow Closes the glfw windowAdded script access to input handling:
Input_IsKeyDown Checks if a key is currently heldInput_IsKeyPressed Checks for a key press eventInput_IsMousePressed Checks if a mouse button is pressedInput_GetMouseWorldPos Gets the mouse position converted to world spaceAdded bindings for interacting with movement components:
GetSelectedHex Gets the currently hovered hex tileSetPathToHex Sets a movement target path for an entity with a MovementComponentAdded camera manipulation support:
Camera_GetPosition Gets the camera positionCamera_SetPosition Sets the camera positionCamera_Move Moves the cameraCamera_PanScreenSpace Moves the camera relative to screen spaceCamera_GetZoom Gets the current camera zoomAdded bindings for controlling grid visuals:
ClearSelectionOverlay Clears the hex selection overlayClearPathTarget Clears the path target visual marker
ClearPathTargetis currently named poorly. It only clears the grid overlay visualization, not the actual movement target!!!
PlayerMovementSystem
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:
FindGetNameSetNameGetComponentSetPosition
SetRotation
SetScale
GetPosition
GetRotation
GetScale
(uses ObSL arrays)
SetColor (Vec3)
SetIntensitySetRadiusGetIsMovingSetIsMovingSetTimePerStepGetHasSelectionGetSelectedHexGetPathToHexSetIndexGetIndexPlayerInputComponent is still w.i.p.
Tag Components currently don’t have any methods since they are only used as tags.
I’m planning to keep expanding the EngineLib api with more methods, such as:
Has(component)AddComponentRemoveComponent(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
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 :)