update checkpoint doc

1 files changed, 38 insertions, 22 deletions

diff --git a/docs/Checkpoint.md b/docs/Checkpoint.md
index 1f10548..ec891e0 100644
--- a/docs/Checkpoint.md
+++ b/docs/Checkpoint.md
@@ -9,9 +9,9 @@ Team members:
 
 ## Summary Description
 
-Embark on a classic roguelike dungeon-crawling adventure. Players will explore 
-procedurally generated, tile-based dungeon floors crafted using Binary Space Partitioning. 
-Battle through waves of enemies with real-time combat, collect powerful items, and 
+Embark on a classic roguelike dungeon-crawling adventure. Players will explore
+procedurally generated, tile-based dungeon floors crafted using Binary Space Partitioning.
+Battle through waves of enemies with real-time combat, collect powerful items, and
 push your limits to see how deep you can delve into the ever-changing depths.
 
 ## Checkpoint Progress Summary
@@ -28,33 +28,46 @@ We've even managed to achieve some stretch goals and additional features:
 However, we still have yet to implement a full enemy/player combat loop (attacking and defending).
 
 ## Lessons Learned
-With the work completed so far, we've gained a greater understanding of creating Rust 
+With the work completed so far, we've gained a greater understanding of creating Rust
 programs from the ground-up, however this came with some roadblocks.
 
-### Goodbye Wave Function Collapse 
-The nixing of the Wave Function Collapse Algoritm for dungeon generation was an unfortunate 
-but nessesary step in the development of this project. After fully writing a generic 
-implementation of the algorithm and testing it, we learned that tragically WFC does not 
-guarantee it's constraints are imposed globally, only in small local patches. This means 
+### Goodbye Wave Function Collapse
+The nixing of the Wave Function Collapse Algoritm for dungeon generation was an unfortunate
+but nessesary step in the development of this project. After fully writing a generic
+implementation of the algorithm and testing it, we learned that tragically WFC does not
+guarantee it's constraints are imposed globally, only in small local patches. This means
 that it doesn't guarantee every dunegon room will be accessable from the player's start location.
-While there are workarounds for this, it usually involves pairing WFC as a post-processing step 
+While there are workarounds for this, it usually involves pairing WFC as a post-processing step
 on a complely different generation algorithm that does guarantee connectivity. So ultimately
-after more thourough research, we switched to Binary Space Partitioning for generating the 
-map instead. 
+after more thourough research, we switched to Binary Space Partitioning for generating the
+map instead.
 
 ### Float vs u64 vs usize
-Another issue during development was the standardizarion of our data types for dungeon structure, 
-traversal and generation. With several of us working on differnent but interconnected components, 
+Another issue during development was the standardizarion of our data types for dungeon structure,
+traversal and generation. With several of us working on differnent but interconnected components,
 there were some instances where we would define our type fields for storing location information.
 This lead to refactoring later to standardize most of our dungeon-related types into u64, as placing
-expect(clippy::cast_possible_truncation) every few lines isn't what I would call "good practice". 
+expect(clippy::cast_possible_truncation) every few lines isn't what I would call "good practice".
 
 ### Raylib Double Free
-TODO
+Working with C libraries are always fun, especially when it comes to memory management. When using
+these libraries with Rust, the bindings must gurentee that it encapsulates all C-like memory
+shenanigans such that any safe use of the rust bindings do not result in a panic/segfault/undefined
+behavior. Sadly, `raylib-rs` seemd to miss this when it comes to deallocating its structures. The
+`RenderTexture2D` (pretty much just a Frame Buffer Object or FBO), is created by using the raylib
+handle, but is not lifetime bound to it. Thus its possible for the raylib handle to be dropped first,
+and then the render texture next. The issue is the raylib handle will deallocate all of raylib when
+dropped, and thus cause a double free when the render texture is attempted to be dropped. The solution?
+Re-order the fields on the `Window` struct. Very cool.
 
 ### Windows HATES Default Features
-TODO
-
+Well maybe not? To optimize a rust binary, its normal to go through default features and disable
+what is not used. For `raylib-rs`, there are a ton of default features, as all raylib modules
+are enabled by default, along with support for all file formats. Most of this is not needed
+and therefore can be disabled. Turns out, at least on windows, when these features are disabled,
+the program fails to link with raylib on windows only. It attempts to link to symbols like
+`LoadModelFromMesh`, even though its never called. Why, who knows? The word around was to enable
+default features for raylib on windows builds.
 
 ## Structure
 
@@ -66,7 +79,7 @@ Contains the core functionality for interacting with a dungeon and it's componen
 - **[astar](dungeon\src\astar.rs)** -  Generic A* Pathfinding Algorithm Implemented for Player Movement.
 - **[bsp](dungeon\src\bsp.rs)** -  Binary-Space Partitioning Algorithm for Dungeon Tile Generation.
 Recurively splits the dungeon into randomly sized rooms, then collapses the tree upwards connecting each root node.
-- **[bsp_tests](dungeon\tests\bsp_tests.rs)** - Integration tests to verify all moveable tiles are connected. 
+- **[bsp_tests](dungeon\tests\bsp_tests.rs)** - Integration tests to verify all moveable tiles are connected.
 - **[entity](dungeon\src\bsp.rs)** -  Contains the structures for all entities, including the player, items and enemies.
   Implemented features:
   - Enemy movement
@@ -77,11 +90,11 @@ Recurively splits the dungeon into randomly sized rooms, then collapses the tree
 - **[wfc](dungeon\src\wfs.rs)** -  **Not Used** Wave Function Collapse Algorithm for Dungeon Generation.
 
 ### **Graphics Crate**
-Core functionality for 
-- **[audio](graphics\src\render.rs)** -  Framework for loading audio assets during runtime. 
+Core functionality for
+- **[audio](graphics\src\render.rs)** -  Framework for loading audio assets during runtime.
 - **[render](graphics\src\render.rs)** -  Defines wrappers for calling the raylib library for sprite displaying.
 Implemented Features:
-  - UI 
+  - UI
   - Text
   - Texture loading
   - Debug view
@@ -92,6 +105,9 @@ Implemented Features:
 
 
 ## Work To Do For the Final
+- Finalize game textures
+  - Many textures are placeholders, or straight up "error" textures
+
 TODO
 
 ## Additional Details