BASKETBALL


Notes/Post-Mortem

Basketball was an older project that I wanted to update. My first project in 3D. My goals for the project were to update the older systems to my new systems, add audio, a stadium crowd, and basic animation. So many unexpected problems! I. Collision with Acceleration: My old collision system used a relative-t epsilon to prevent entities from passing through each other. This system only anticipated the velocity of an entity, in which case, the relative-t is always a set distance relative to the speed of the entity. Once acceleration is added these infinitely small numbers become even infinitely smaller. The relative-t is no longer a constant distance. To resolve the issue, I convert the relative-t of the collision back to an absolute distance value. In future projects, I want to experiment with a system that would use thick planes for the collisions. II. Optimized-Build Times: So, how to explain this issue? In previous projects, I wanted a debug font that was hard-coded directly into the executable and not loaded from a file. I wrote a utility that: 1. rasterizes a font at a selected font size 2. generates a cpp file, with the function genFont(), which takes a pointer to some block of memory 3. converts the rasterized font data (font meta-data and textures) to text hex values 4. writes the hex values as initializer blocks for the block of memory (using custom types for 128-byte and 16-byte blocks) One just has to include the cpp file in their project and call the function, and, voila, they have a font hard-coded into the executable. This did not cause any noticeable difference in compile times for debug builds. I would only compile optimized builds when the project was completed, and, you guessed it, did not contain a debug overlay and debug font. Rendering 2000+ stadium fans requires optimized builds to make development tolerable. Suddenly, optimized build times were taking 2-3 minutes to complete. I was definitely irritated, but was too focused on other issues to investigate further. I just kinda assumed that optimized builds with this much code took that long. So, one day towards the end of the project, I was updating the asset/texture system and removed the debug font. Optimized builds were back to compiling in 2-3 seconds. Double take. Face palm. The font utility now wraps genFont() in a #pragma to always disable optimization. III. Inconsistent World-Axis/Model-Axis and Generating Models: Models were generated by the application, and not by a modeling program, which means all the math came from me. Early model generation contained a lot of busywork: generating vertices from previous vertices or other models, triangle facing direction, etc. In some early models I would accidentally flip the z-axis. There were also axis issues in the movement and collision code. The models contained a lot of symmetry, so issues were not noticed until later. Also early on, collision data was taken from the model data, but not in a consistent way. Any model change would then cause busywork changes to the collision data. Untangling the issues was an exhausting process: 1. diagram all models and axis on paper 2. determine most foundational model information and anchor models to this 3. many utility functions for generating and storing the vertices 4. no premature-optimatization work: all collision data is taken directly from the model data; optimize later, if needed The project was a long, tiring fight to maintain motivation. My previous project, Advanced Linguistic Studies, was completed in two weeks. This project took seven weeks to complete. Seven weeks of busywork. I took many breaks and cut out the audio plans in order to drive the project to the end. It's also much more of a toy than a game. Still, I did learn a lot on this project, and I'm glad that I completed it.