@jzakiya , I’m thinking we start with creating a shard that has most of the pieces of your code (so others can re-use it), along with an ‘examples’ folder containing the code that will later be re-submitted to GitHub - edin/raytracer: Performance comparison of various compilers. This way, we can work thru the steps of splitting it up, formatting, adding tests, etc. so that we make sure we (or I) didn’t break things along the way. I started a repo at: https://github.com/drhuffman12/crystal_ray_tracer/; send me your github handle and I’ll add you as a contributor/editor.
For the first PR (drhuffman12_based_on_jzakiya by drhuffman12 · Pull Request #1 · drhuffman12/crystal_ray_tracer · GitHub), I basically just set up the repo and pulled in your code basically as-is; and I made sure I could run it and generate the example image. See the README.md file for instructions.
For the next PR (drhuffman12_split_code_and_add_tests by drhuffman12 · Pull Request #2 · drhuffman12/crystal_ray_tracer · GitHub), I started reorganizing your code into smaller pieces under the src folder, add tests, etc. The PR has a couple simple specs (all of which pass), but before I add more tests, I need to look into Windows Compatibility for both Ameba (Windows compatibility? · Issue #230 · crystal-ameba/ameba · GitHub) and Spectator (Windows compatibility? (#58) · Issues · Mike Miller / Spectator · GitLab), which will affect how I might deal with linting/etc and how I might code the tests.
I noticed you use the same handle for your github account, so I sent you an invite for this repo. I’d be glad to collaborate with you on this.