Comment cleanup

code/grime_array.odin

@@ -1,7 +1,6 @@
 // Based on gencpp's and thus zpl's Array implementation
 // Made becasue of the map issue with fonts during hot-reload.
 // I didn't want to make the HMapZPL impl with the [dynamic] array for now to isolate
-// what in the world is going on with the memory...
 package sectr
 
 import "core:c/libc"
@@ -195,7 +194,6 @@ array_fill :: proc( using self : Array( $ Type ), begin, end : u64, value : Type
 		return false
 	}
 
-	// TODO(Ed) : Bench this?
 	// data_slice := slice_ptr( ptr_offset( data, begin ), end - begin )
 	// slice.fill( data_slice, cast(int) value )
 

code/grime_hashmap.odin

@@ -1,4 +1,4 @@
-// TODO(Ed) : Make your own hashmap implementation (open-addressing, round-robin possibly)
+// TODO(Ed) : Roll own hashmap implementation (open-addressing, round-robin possibly)
 package sectr
 
 

code/grime_hashmap_zpl.odin

@@ -17,7 +17,6 @@ import "core:slice"
 
 // Note(Ed) : See core:hash for hasing procs.
 
-// This might be problematic...
 HMapZPL_MapProc    :: #type proc( $ Type : typeid, key : u64, value :   Type )
 HMapZPL_MapMutProc :: #type proc( $ Type : typeid, key : u64, value : ^ Type )
 
@@ -115,8 +114,6 @@ zpl_hmap_grow :: proc( using self : ^ HMapZPL( $ Type ) ) -> AllocatorError {
 zpl_hmap_rehash :: proc( ht : ^ HMapZPL( $ Type ), new_num : u64 ) -> AllocatorError
 {
 	// For now the prototype should never allow this to happen.
-	// We use this almost exclusively in persistent memory and its not setup for 
-	// dealing with reallocations in a conservative manner.
 	ensure( false, "ZPL HMAP IS REHASHING" )
 	last_added_index : i64
 

code/grime_linked_list.odin

@@ -1,5 +1,3 @@
-// I'm not sure about this, it was created to figure out Ryan's linked-list usage in the UI module of the RAD Debugger.
-// The code takes advantage of macros for the linked list interface in a way that odin doesn't really permit without a much worse interface.
 package sectr
 
 LL_Node :: struct ( $ Type : typeid ) {

code/grime_stack.odin

@@ -42,7 +42,7 @@ stack_peek :: proc ( using stack : ^StackFixed( $ Type, $ Size ) ) -> Type {
 
 /* Growing Stack allocator
 	This implementation can support growing if the backing allocator supports
-	it without fragmenting the back allocator.
+	it without fragmenting the backing allocator.
 
 	Each block in the stack is tracked with a doubly-linked list to have debug stats.
 	(It could be removed for non-debug builds)

code/grime_virtual_arena.odin

@@ -1,5 +1,6 @@
 /*
-Odin's virtual arena allocator doesn't do what I ideally want for allocation resizing or growing from a large vmem reserve.
+Odin's virtual arena allocator doesn't do what I ideally want for allocation resizing.
+(It was also a nice exercise along with making the other allocators)
 
 So this is a virtual memory backed arena allocator designed
 to take advantage of one large contigous reserve of memory.

code/space.odin

@@ -2,11 +2,9 @@ package sectr
 
 import rl "vendor:raylib"
 
-// TODO(Ed) : Do we want to have distinct types for cm/pixels/points ? This will make mistakes with unit conversion happen less.
-
 // The points to pixels and pixels to points are our only reference to accurately converting
 // an object from world space to screen-space.
-// This prototype engine will have all its spacial unit base for distances in centimetres.
+// This prototype engine will have all its spacial unit base for distances in pixels.
 
 Inches_To_CM  :: cast(f32) 2.54
 Points_Per_CM :: cast(f32) 28.3465
@@ -132,7 +130,7 @@ screen_size :: proc "contextless" () -> AreaSize {
 }
 
 screen_get_corners :: proc() -> BoundsCorners2 {
-	state         := get_state();using state
+	state         := get_state(); using state
 	screen_extent := state.app_window.extent
 	top_left     := Vec2 { -screen_extent.x,  screen_extent.y }
 	top_right    := Vec2 {  screen_extent.x,  screen_extent.y }