From f17aead3ea099a73df11c4c4db12d4ae28c4d15b Mon Sep 17 00:00:00 2001 From: Ed_ Date: Thu, 7 Mar 2024 17:58:28 -0500 Subject: [PATCH] Comment cleanup --- code/grime_array.odin | 2 -- code/grime_hashmap.odin | 2 +- code/grime_hashmap_zpl.odin | 3 --- code/grime_linked_list.odin | 2 -- code/grime_stack.odin | 2 +- code/grime_virtual_arena.odin | 3 ++- code/space.odin | 6 ++---- 7 files changed, 6 insertions(+), 14 deletions(-) diff --git a/code/grime_array.odin b/code/grime_array.odin index 59ce953..8abc273 100644 --- a/code/grime_array.odin +++ b/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 ) diff --git a/code/grime_hashmap.odin b/code/grime_hashmap.odin index 5150af0..ac509f2 100644 --- a/code/grime_hashmap.odin +++ b/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 diff --git a/code/grime_hashmap_zpl.odin b/code/grime_hashmap_zpl.odin index a78606a..bc0bbcf 100644 --- a/code/grime_hashmap_zpl.odin +++ b/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 diff --git a/code/grime_linked_list.odin b/code/grime_linked_list.odin index 933a3d2..8b44cd9 100644 --- a/code/grime_linked_list.odin +++ b/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 ) { diff --git a/code/grime_stack.odin b/code/grime_stack.odin index d7f1de1..1aeefdd 100644 --- a/code/grime_stack.odin +++ b/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) diff --git a/code/grime_virtual_arena.odin b/code/grime_virtual_arena.odin index 51d42c2..9e2bf82 100644 --- a/code/grime_virtual_arena.odin +++ b/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. diff --git a/code/space.odin b/code/space.odin index 3a46d12..ca969cb 100644 --- a/code/space.odin +++ b/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 }