penquinz01/lazzo-engine

1. Repo shape and build boundaries

This repository is split into two main Visual Studio projects: Lazzo/ is the engine code, and SandBox/ is a small test application that exercises the engine. premake5.lua and GenerateProject.bat are the build-generation layer, while vendor/ holds third-party dependencies.

2. Engine core as the reusable boundary

The engine lives under Lazzo/src/Lazzo/ and is structured as a reusable runtime library rather than a standalone game. The key public-facing pieces are Application, Window, Events, GraphicsAPI, UI, and Log, with Core.h and Lazzo.h likely acting as umbrella/include and export-definition headers.

3. Application lifecycle and main loop

Application.cpp/.h appears to define the engine-owned runtime loop and high-level app lifecycle. EntryPoint.h suggests the executable entry point is centralized in the engine and calls into a user-defined application class, which is the usual boundary between engine startup and game/app code.

4. Sandbox as the consumer app

SandBox/src/SandboxApp.cpp is the testbed for engine features. Architecturally, this is where an application built on top of the engine would plug in custom behavior without modifying the engine core.

5. Windowing and platform integration

Window/Window.cpp/.h is the abstraction over native window creation and event pumping. The README says SDL is used for window and input handling, so SDL is the platform boundary where OS events enter the engine.

6. Event system as the input/data translation layer

Window/Events/ contains the engine’s internal event types, such as KeyDownEvent. This layer likely translates SDL callbacks/events into engine-specific event objects so the rest of the engine does not depend directly on SDL types.

7. Rendering backend abstraction

Window/GraphicsAPI/GraphicsAPI.h plus OpenGLAPI.cpp/.h indicate a backend interface with at least one concrete implementation: OpenGL. GraphicsFactory.h suggests the engine selects or constructs the active rendering backend through a factory boundary, keeping higher-level code independent of the API choice.

8. UI integration on top of the graphics context

Window/UI/ImguiUI.cpp/.h shows Dear ImGui integration as an engine subsystem layered on top of the window and graphics context. This is probably used for editor/debug UI and depends on the OpenGL/SDL setup being initialized first.

9. Logging as a cross-cutting service

Log.cpp/.h is a shared diagnostic subsystem used across engine modules. It is likely initialized early and available to both engine internals and sandbox code for runtime tracing and debugging.

10. Dependency and initialization flow

The runtime order implied by the structure is: build system generates the solution, the executable starts through the engine entry point, Application creates/owns the Window, the Window initializes SDL and an OpenGL context via the graphics API layer, then the main loop processes SDL events, dispatches engine events, renders, and optionally draws ImGui UI.

11. Technology choices that affect architecture

The important external technologies are C++, SDL2, OpenGL, and ImGui. SDL is the platform abstraction for windowing/input, OpenGL is the rendering backend, and ImGui is an immediate-mode UI layer tied to the graphics context.

12. Current maturity and planned expansion

The README roadmap shows the engine is still early-stage: only core runtime, windowing, events, logging, and basic OpenGL/ImGui integration are present. Future layers like ECS, renderer systems, lighting, animation, and physics will likely sit above the current engine core rather than replace it.