Day 42 complete

Found and fixed bugs with gencpp when generating the vector math stuff.

docs/Day 025.md

@@ -1,13 +0,0 @@
-# Day 25
-
-Him doing replay save states at the platform layer is causing issues for me...  
-I'm going to most likely end up doing two categories of save states, one for engine level and one for platform level.
-
-The engine level can just store it in the memory struct, and the game memory can just stay where it is.
-I want to use the same "save state" slots for both engine and game since there is no need different memory buckets for that. They will at worst case be ofcourse the size of engine's memory block.
-
-So if there is 4, we are looking at 5x the actual memory size. This is fine for now since the engine block is 2 gigs.  
-Snapshots of of memory are are handled using take and load snapshot functions. They can be used separate from the replay looping functionality.  
-Replay looping however is dependent on snapshots so if a replay is save/loaded it will use the same snapshot slot of memory to do that state management.
-
-Feels great to be past the platform layer bulk!!!

docs/Day 026-40.md

@@ -0,0 +1,77 @@
+# Day 27
+
+Definitely feels refreshing to not touch win32.
+
+# Day 30
+
+Tile map stuff is looking alright. Doing my best to not clean-up the code as Casey pleads in the vods.
+
+I would have perferred if he didn't just do one tilemap at a time and instead I would have had the current tile map and surrounding loaded at the same time (He might do this in the future). Since were aren't constrained memory wise like the old machines, we could have those loaded as well and it would make the management of the tilemaps easier (possibly...).
+
+Looking foward to when he introduces a proper vector space for the positioning.
+
+# Day 31
+
+This was really a prepatory day for day 32 so I did some extra stuff...  
+I setup codebase so now that the build translation unit files have every single file included for that unit explicitly.  
+I do not (or should not) have nested includes other than from `grime.hpp`
+
+## Side Tracking
+
+I did some refactoring and added `INTELLISENSE_DIRECTIVES` preprocessor conditional blocks throughout the codebase.
+
+I wanted to see if I could get all IDE/Editors I've ever used to support the project without bad errors from parsing failures.  
+Unfortunately getting Visual Studio and Rider's intellisense to behave was not possible.  
+This is mostly from how the code is structured across files currently.  
+I'll have to re-sturcture it down the line to make it more IDE friendly.
+
+10xEditor Needs help with the intellisense directives macros, but otherwise was able to parse everything quite accurately.
+
+VSCode has some failures in few files, they are nearly the same failures as VS2022, however like 10xEditor I saw that it has include awareness beyond a single file's scope!  
+In fact, if I open all the files, the parser corrects itself (you can close them afterwards). It essentially cached the include graph for the project by doing so for the lifetime of the process.
+
+VS2022 has issues due to it strictly parsing each file, without awareness of whats going on in other files.  
+(It doesn't build a proper include graph).
+
+Rider just straight up broken, it seems to not work every well with NMake projects.  
+At least, you can't depend on it to use the external include directories field properly.  
+It will show errors for all external include symbols.
+
+# Day 32
+
+Vod was more of a pain to follow along than usual...
+
+I updated the scripts to only build each module if it detects changes (just using md5 hash on the files).
+
+# Day 33
+
+I thought the last few vods were not great to follow... That was just training for today.
+
+# Day 34
+
+Casey decided to start offloading tile map definitions to separate files so I took the time to also cleanup some of the organization of the code.  
+I'm still keeping some cpp files directly included within engine.cpp and win32_platform.cpp for now (instead of their translation unit files). I'll problably wait till much later to offload them.
+
+Making that first baby step for procedural gen, and proper tile_chunk memory felt pretty good after many vods of stumbling.
+
+# Day 36
+
+Just dealing with Casey's "methods" for going about the code exploration...
+
+Loading an image was nice, I got it to render somewhat properly with draw_bitmap but until he does it I kept the bad way hes doing it.
+
+# Day 37
+
+I went ahead and did some extra stuff.  
+My "hero" is a mojito bmp for now. I'll eventually do something else for it.  
+I also added incremental build support for the codegen metaprograms.
+
+I originally wanted to make the assets on the fly (just as a break from the code),  
+but decided to just use his assets as this series is already going to take forever.
+
+I have the assets mapped to an "offical" directory within content, however they'll be naturally ignored on the repo.
+
+# Day 40
+
+Its finally done with this phase of the project.  
+Looking forward to seeing some vectors after all these days.

docs/Day 027.md

@@ -1,3 +0,0 @@
-# Day 27
-
-Definitely feels refreshing to not touch win32.

docs/Day 030.md

@@ -1,7 +0,0 @@
-# Day 30
-
-Tile map stuff is looking alright. Doing my best to not clean-up the code as Casey pleads in the vods.
-
-I would have perferred if he didn't just do one tilemap at a time and instead I would have had the current tile map and surrounding loaded at the same time (He might do this in the future). Since were aren't constrained memory wise like the old machines, we could have those loaded as well and it would make the management of the tilemaps easier (possibly...).
-
-Looking foward to when he introduces a proper vector space for the positioning.

docs/Day 031.md

@@ -1,26 +0,0 @@
-# Day 31
-
-This was really a prepatory day for day 32 so I did some extra stuff...  
-I setup codebase so now that the build translation unit files have every single file included for that unit explicitly.  
-I do not (or should not) have nested includes other than from `grime.hpp`
-
-## Side Tracking
-
-I did some refactoring and added `INTELLISENSE_DIRECTIVES` preprocessor conditional blocks throughout the codebase.
-
-I wanted to see if I could get all IDE/Editors I've ever used to support the project without bad errors from parsing failures.  
-Unfortunately getting Visual Studio and Rider's intellisense to behave was not possible.  
-This is mostly from how the code is structured across files currently.  
-I'll have to re-sturcture it down the line to make it more IDE friendly.
-
-10xEditor Needs help with the intellisense directives macros, but otherwise was able to parse everything quite accurately.
-
-VSCode has some failures in few files, they are nearly the same failures as VS2022, however like 10xEditor I saw that it has include awareness beyond a single file's scope!  
-In fact, if I open all the files, the parser corrects itself (you can close them afterwards). It essentially cached the include graph for the project by doing so for the lifetime of the process.
-
-VS2022 has issues due to it strictly parsing each file, without awareness of whats going on in other files.  
-(It doesn't build a proper include graph).
-
-Rider just straight up broken, it seems to not work every well with NMake projects.  
-At least, you can't depend on it to use the external include directories field properly.  
-It will show errors for all external include symbols.

docs/Day 032.md

@@ -1,5 +0,0 @@
-# Day 32
-
-Vod was more of a pain to follow along than usual...
-
-I updated the scripts to only build each module if it detects changes (just using md5 hash on the files).

docs/Day 033.md

@@ -1,3 +0,0 @@
-# Day 033
-
-I thought the last few vods were not great to follow... That was just training for today.

docs/Day 034.md

@@ -1,6 +0,0 @@
-# Day 34
-
-Casey decided to start offloading tile map definitions to separate files so I took the time to also cleanup some of the organization of the code.  
-I'm still keeping some cpp files directly included within engine.cpp and win32_platform.cpp for now (instead of their translation unit files). I'll problably wait till much later to offload them.
-
-Making that first baby step for procedural gen, and proper tile_chunk memory felt pretty good after many vods of stumbling.

docs/Day 036.md

@@ -1,5 +0,0 @@
-# Day 36
-
-Just dealing with Casey's "methods" for going about the code exploration...
-
-Loading an image was nice, I got it to render somewhat properly with draw_bitmap but until he does it I kept the bad way hes doing it.

docs/Day 037.md

@@ -1,10 +0,0 @@
-# Day 37
-
-I went ahead and did some extra stuff.  
-My "hero" is a mojito bmp for now. I'll eventually do something else for it.  
-I also added incremental build support for the codegen metaprograms.
-
-I originally wanted to make the assets on the fly (just as a break from the code),  
-but decided to just use his assets as this series is already going to take forever.
-
-I have the assets mapped to an "offical" directory within content, however they'll be naturally ignored on the repo.

docs/Day 039.md

@@ -1,18 +0,0 @@
-# Day 39
-
-My `draw_bitmap` proc has been already setup to have the position specified
-from the assumped position of the center of the image.  
-Its how I'm used to anchoring images by default so thats why I decided to go with it.
-
-Casey however is using the corner however...  
-and then is doing some offset alignment based on what he sees for the coordinates on GIMP..
-
-I decided to hand calibrate the alignment by eye. Since I already have it centered on X, the `align_x` could  
-stay zeroed for now and all I needed to do was align_y.
-
-I also did not do the difference using a `tile_map_diff` like he did,
-I just returned a tile_map_position and switch the map coodinates to be signed 
-(which tbh is fine I'll just adjust the math later when I need to).
-
-I'm assuming it won't matter because the tile map setup we currently have is before he revamps the project with proper
-vector math data structures, and he might switch to signed coordinates for them in the stream.

docs/Day 042.md

@@ -0,0 +1,8 @@
+# Day 42
+
+I decided to generate the vectors since I wanted f32 and s32 vectors. However, I didn't want to use templates.  
+I ended up messing aroudn with templates a bit for the `Zero(type)` macro which is just an alt for `type {}`.  
+Pattern is useful for other constant inits though (if I want to do it that way...)
+
+Found bugs in gencpp which was nice!
+Compressing the code with vector abstraction was nice, hopefuly these pixel will soon as well...