Merge pull request #2 from AngelMunoz/chore/testing

chore: add tests missing from port initial effort and rendering mechanisms

Author: AngelMunoz

.github/workflows/docs.yml

@@ -37,6 +37,9 @@ jobs:
       - name: Restore dependencies
         run: dotnet restore
 
+      - name: Run Tests
+        run: dotnet test --configuration Release --no-restore
+
       - name: Build Library
         run: dotnet build src/Mibo.Raylib -c Release
 

.github/workflows/release.yml

@@ -72,6 +72,10 @@ jobs:
         if: steps.check_tag.outputs.exists == 'false'
         run: dotnet restore
 
+      - name: Run Tests
+        if: steps.check_tag.outputs.exists == 'false'
+        run: dotnet test --configuration Release --no-restore
+
       - name: Build
         if: steps.check_tag.outputs.exists == 'false'
         run: dotnet build --configuration Release --no-restore

README.md

@@ -4,55 +4,29 @@
 
 Following that spirit, Mibo.Raylib keeps it lean, just F# and the Elmish loop with a handful of commodities to get out of your way and let you enjoy the craft.
 
-Mibo.Raylib is a port of the [Mibo](https://github.com/AngelMunoz/Mibo) micro-framework from **MonoGame** to **raylib-cs**, designed to allow **F#** developers to write games using familiar Elmish patterns for all kinds of game genres and sizes — no Content Pipeline, no `.mgcb` files.
+Mibo.Raylib is a port of my first attempt at this [Mibo](https://github.com/AngelMunoz/Mibo) micro-framework from **MonoGame** to **raylib-cs**, designed to allow **F#** developers to write games using familiar Elmish patterns for all kinds of game genres and sizes.
 
-Mibo aims to solve 90% of use cases for enabling developers to focus on game logic rather than boilerplate code, providing guidelines and architecture for structuring game code, handling input, rendering, asset management, and time management among others.
+Mibo aims to solve 80/20 of use cases for enabling developers to focus on game logic rather than boilerplate code, providing guidelines and architecture for structuring game code, handling input, rendering, asset management, and time management among others.
 
 ## What's in the box?
 
 - **Elmish runtime** (MVU loop) with `Cmd`, `Sub`, optional **fixed timestep**, and **frame-bounded dispatch**
 - **Input** — raw input (`Keyboard`, `Mouse`) + semantic mapping via `InputMap` / `ActionState`
-- **Assets** — texture, font, sound, and model loading with dictionary-based caches (no Content Pipeline)
-- **Rendering** — `IRenderer<'Model>` and `RenderBuffer<'Key, 'Cmd>`:
+- **Assets** — texture, font, sound, and model loading caches
+- **Rendering** — Command buffer based rendering:
   - 2D batch renderer with layers and multi-camera support
   - 3D batch renderer with opaque/transparent passes and custom shader switching
-  - Escape hatches (`DrawCustom`) for custom GPU work
-- **Camera** helpers (`Camera2D`, `Camera3D`) with screen-to-world, orbit, and ray casting
+  - Escape hatches for custom GPU work
+- **Camera** helpers with screen-to-world, orbit, and ray casting
 - **Layout** — 2D procedural grid layout (`CellGrid2D`) with platformer, top-down, and geometric primitives
 - **Layout3D** — 3D voxel-style grid layout (`CellGrid3D`) with terrain, interior rooms, corridors, stairs, and procedural generation
 - **Animation** — sprite sheet slicing, `AnimatedSprite` state machines, and grid-based animation definitions
-- **Input Mapper** — push-based input mapping via reactive `IInput` observables
-
-## Documentation
-
-The docs live in `docs/` and are the authoritative reference.
-
-| Topic | File |
-|-------|------|
-| Elmish runtime | `docs/elmish.md` |
-| System pipeline (phases + snapshot) | `docs/system.md` |
-| Scaling ladder | `docs/scaling.md` |
-| Input | `docs/input.md` |
-| Assets | `docs/assets.md` |
-| Camera | `docs/camera.md` |
-| Animation | `docs/animation.md` |
-| Layout (2D) | `docs/layout.md` |
-| Layout3D | `docs/layout3d.md` |
-| Culling | `docs/culling.md` |
-| Commands | `docs/commands.md` |
-
-To build the docs site locally:
-
-```bash
-dotnet tool restore
-dotnet fsdocs build
-# or for live editing:
-dotnet fsdocs watch
-```
+- **Input Mapper** — Listen to raw input and map it to semantic actions
 
 ## Getting started
 
 Prerequisites:
+
 - **.NET SDK 8** or later
 - A working OpenGL setup
 
@@ -64,49 +38,32 @@ dotnet build
 dotnet test
 ```
 
+To build the docs site locally:
+
+```bash
+dotnet tool restore
+dotnet fsdocs build
+# or for live editing:
+dotnet fsdocs watch
+```
+
 ### Run the samples
 
 **2D Platformer:**
+
 ```bash
 dotnet run --project samples/PlatformerSample
 ```
+
 Controls: **WASD / Arrows** to move, **Space** to jump, **R** to respawn.
 
 **3D Platformer:**
+
 ```bash
 dotnet run --project samples/ThreeDSample
 ```
-Controls: **WASD** (camera-relative), **Space** to jump.
-
-## Project structure
 
-```
-src/
-├── Mibo.Raylib/           # Core framework library
-│   ├── Elmish.*.fs        # MVU runtime (Cmd, Sub, Time, Program, System)
-│   ├── Graphics2D.fs      # 2D render commands + batch renderer
-│   ├── Graphics3D.fs      # 3D render commands + batch renderer
-│   ├── Input.fs           # Raw input polling (Keyboard, Mouse)
-│   ├── InputMapper.fs     # Reactive input mapping (IInput, ActionState)
-│   ├── Camera.fs          # Camera2D, Camera3D, Ray
-│   ├── Animation.fs       # Sprite sheets, animated sprite state
-│   ├── Culling.fs         # Frustum / quadtree culling
-│   ├── Layout/            # 2D grid layout (CellGrid2D, platformer, top-down)
-│   └── Layout3D/          # 3D voxel layout (CellGrid3D, terrain, interior)
-├── Mibo.Raylib.Tests/     # Unit tests (Expecto, 110+ tests)
-samples/
-├── PlatformerSample/      # 2D platformer sample
-└── ThreeDSample/          # 3D platformer sample
-docs/                      # Documentation source (fsdocs)
-```
-
-## Design principles
-
-- **Pure `update`** — keep your model logic functional and testable
-- **Declarative `view`** — submit render commands to a `RenderBuffer` rather than calling draw functions directly
-- **Ladder of complexity** — start with simple sprites, progressively adopt shaders, lighting, and post-processing without rewrites
-- **Zero-cost abstractions** — structs, arrays, `ArrayPool`, and `InlineIfLambda` where performance matters
-- **No Content Pipeline** — all assets loaded at runtime from loose files
+Controls: **WASD** (camera-relative), **Space** to jump.
 
 ## License
 

docs/index.md

@@ -16,6 +16,8 @@ Mibo.Raylib is a lightweight, Elmish-based game framework built on top of raylib
 
 To get started with Mibo.Raylib, you need the [dotnet SDK](https://get.dot.net) installed.
 
+> **NOTE:** Mibo.Raylib is currently in early development. NuGet packages are not yet available, but you can clone the repository and run the samples to see it in action.
+
 Start by cloning the repository and running one of the samples:
 
 ```bash
@@ -42,71 +44,23 @@ You can then start building your game using any of the following:
 
 ## Why Mibo.Raylib?
 
-Traditional game engines often rely heavily on mutable state and complex object hierarchies. Mibo.Raylib offers an alternative:
-
-- **Functional First**: Write your game logic as pure functions that transform state.
-- **Predictable State**: The entire game state (the Model) is centralized and immutable.
-- **Elmish Architecture**: Leverage the robust MVU pattern for clear separation of concerns.
-- **raylib Power**: Benefit from the performance and simplicity of raylib.
-- **Deferred Rendering**: Built-in 2D and 3D batchers that handle sorting and lighting for you.
-
-## Core Patterns
-
-### The Elmish Loop
-
-Shader-based multi-pass rendering. Every Mibo.Raylib game follows a simple loop:
-
-1. **Init**: Define your initial state.
-2. **Update**: Purely calculate the next state based on messages (input, timers, etc.).
-3. **View**: Describe what should be rendered based on the current state.
-4. **Subscribe**: Listen to external events like keyboard or touch input.
-
-### Semantic Input Mapping
-
-Instead of checking for specific keys in your player logic, Mibo.Raylib encourages mapping keys to **Actions**. This allows for easy input rebinding and multi-device support.
-
-### Deferred Batched Rendering
-
-All rendering is deferred into a `RenderBuffer`, sorted by layer, and executed in a single pass per renderer. This enables efficient 2D lighting and post-processing without coupling render logic to the update loop.
-
-## Getting Started
-
-Run one of the samples, then copy its program setup (composition root) into your own project.
-
-## Documentation
-
-- Architecture
-  - [Elmish (MVU) runtime](elmish.html)
-  - [Programs & composition](program.html)
-  - [System pipeline (phases + snapshot)](system.html)
-  - [Service composition](services.html)
-  - [Scaling Mibo.Raylib (Simple → Complex)](scaling.html)
-  - [F# For Perf](performance.html)
-
-- Rendering
-  - [Rendering Overview](rendering.html)
-  - [Camera](camera.html)
-  - [Shaders](shaders.html)
-  - [Culling](culling.html)
-  - [2D Rendering](graphics2d/overview.html)
-  - [3D Rendering](graphics3d/overview.html)
-
-- Input
-  - [Input (raw + mapped)](input.html)
-
-- Assets
-  - [Assets (loading + caching)](assets.html)
-
-- Amenities
-  - [Animation](animation.html)
-
-- Patterns
-  - [Patterns Overview](patterns/overview.html)
-  - [Composable Systems](patterns/composable-systems.html)
-  - [Background Work](patterns/background-work.html)
-  - [Pooled Particles](patterns/pooled-particles.html)
-  - [Layered Rendering](patterns/layered-rendering.html)
-  - [Pre-computed State](patterns/precomputed-state.html)
+Traditional game engines often rely heavily on complex object hierarchies, vendor specific tooling and no specific architecture guidance. Mibo.Raylib offers an alternative:
+
+- **Functional First**
+  - Write your game logic as pure functions that transform state.
+  - When you grow enough you adopt mutable state in a predictable way to squeeze out more performance, but you can start simple and keep it pure as long as you want.
+  - F# inline, compiler optimizations around functions, byrefs, structs and value types allow you to write high-level code without sacrificing performance.
+- **Predictable State**
+  - The MVU architecture enforces a clear separation of concerns with a single source of truth for your game state, making it easier to reason about and debug.
+  - The unidirectional data flow ensures that state changes are predictable and traceable, which is especially beneficial in complex game logic.
+- **Elmish Architecture**
+  - A well-known architecture in the F# community with a twist for games.
+- **raylib Power**
+  - Built on top of raylib, a simple and easy-to-use library to enjoy videogames programming.
+  - Cross-platform support and a rich set of features for graphics, input, audio, and more.
+- **Deferred Rendering**
+  - Be ready for efficient lighting and post-processing effects without coupling your render logic to the update loop.
+  - Be ready for networked games with client-side prediction and server reconciliation without coupling your game logic to the rendering.
 
 ## Built on