topengui

Here are some pedantic details: Added plexiglass panel posts. Added some detail outside the play-field. Update compiler and fix bugs (due to experimental nature of C++ module support in VS) Throw away old pinball project and jump-to-the-top project. The majority of development for both of these was in the engine anyway, and their unique parts are becoming a burden to maintain. That and neither of those projects ever worked very well. Do lots of build-system rework. Remove custom cmake scripts which have been made unnecessary by C++ modules. Cut lots of dependencies. Remove bullet-physics integration. It has documentation, but my experience with it has been very bad. Additionally, there are warts all over the implementation that I am fed up with considering. Combine entity-related libraries into a new library: entity_list. Combine tex2, raster_font, and typesetter into a single library: raster. Remove the old, bad library: tjd. Add ads some ads on hockey arena walls. Add a minimal debug...

I did a bunch of stuff since last post. The easiest to see parts are the lighting changes, but I also: Fixed a gamepad-detection issue. Improved the ergonomics of the collision module. Wrote code to keep paddles on the table. Added believable momentum trading for colliding pucks. Added keyboard controls. Added object-removal support. Fixed some debug settings. Fixed a bug where glancing circles would get stuck. Added the ability to scale meshes in the renderer. Added decal rendering. Made audio buffer accessible to the simulation thread. Increased light smoothness and fixed some light attenuation bugs. Added HSV color functions for sha ders. Added plexiglass panels and tinted the ice.  Oh. And here's what the table looks like when everything is smooth metal:

  I'm working on a new small-scope project: air-hockey! The goals of the project are: To exercise my game development tools. To identify what new game development tools would be useful. To start and finish a project that I can show to people.  Have fun implementing a very movement-focused game. So far, I've found and fixed serious problems in my collision code. The problems I found included logical errors and usability crimes. I had already started and abandoned a new collision system a few months ago, so I revived it and finished it instead of fixing the older one. The result is really nice to work with so far! I did leave some important features out in order to get back to air-hockey faster, but I think those missing features are low-interest technical debt. The hardest part about writing a collision system has been the plumbing, and I made sure to finish all the plumbing for those skipped features. When I need to go implement those features later: all the inputs will be han...

Since the last post, I've started using C++ modules. It has been a pretty nice experience so far. MSVC *does* currently have some non-standard ordering requirements. But that was only an issue for a few days before I worked it out. At some point I may show the dependency graphs of my software and how it's been improved by recent reworks, but for now I have a screenshot showing how asset error messages have improved.     The first message shows what asset-preprocessing error messages used to look like. The second message shows what those error messages look like now. IDE's with CTRL+Click support make the blue-file-paths in the error message very useful. That's all. I just wanted to show off these new error messages :)

Back in February, I started replacing a custom library with one called EnTT. The interface for both tools was quite similar, but a lot of details involved themselves in the replacement process. For example: The renderer relied on a functionality that my previous library provided, and that the new library did not provide. So there was a big renderer rewrite. Another example: Lots of my libraries assumed themselves to be plugins for the library I was replacing! Basically, I found that I had halted all progress on my game development by March because I was like 7 tasks removed from my initial intent. It was annoying to even think about working on my project! Anyway. Last week, for the first time since February, I was able to see images from my software! The internals have become much more modular, and it has again become enjoyable for me to work on it :) Here are some recent images!   A new CPU performance chart! The histogram on top shows timings for the selected row. Frametime and t...

I've created an infographic to help me understand frametime and ticktime, and to help me understand how they effect latency. I was trying to answer a bunch of questions with this graphic. What is the theoretical minimum for latency for a simulation? How does a higher framerate effect latency? How should I define latency? How does VSync relate to all of this? Can a multithreaded approach achieve latency as low as the theoretical minimum? How do I keep the simulation from getting too far ahead of the renderer (for example when the render thread is suspended by the user dragging the window around)? How should an implementation be written that juggles all of these concerns? This post isn't really meant to explain much (outside of the infographic itself). I just wanted to communicate that I found this subject challenging, and I wanted to share the cool picture I made :)