The entire render-on-demand system is quite too manual and very easily allows these flaws (from both engine-side and user-side). Should maybe take an abolitionist approach here and redesign the "whether things have changed" detector, instead of solving this bug directly. For example, there's no clear way to tell the engine that things have changed from a constructor function.
Placing the detector within functions such as Object::Move(), Texture::Simple(), adders, enterers, etc. also means wrapping variables such as Object::m_pos within a setter (and perhaps an additional getter for safety), which to me sounds insane in terms of backwards-compatibility (although at the current stage this isn't so important) and code sanity (just how many trivial variables will get wrapped in functions?), deeming this solution inviable, unless there's a good balance of inserting the detector.
It seems I have forgotten how the system I myself have written works, as it's fundamentally completely fine. The idea is things can only change while the game is running, and the user can change things only from callback functions, which may be input handling functions, on-tick functions, and invoked functions, but it just so happens I have forgotten to add the detector to the latter. It should be quite noticeable from the user's perspective that all of these callback functions must return a boolean, so they will likely refer to the documentation to figure out how to fulfill this requirement (return true if things have visually changed, otherwise false).
The entire render-on-demand system is quite too manual and very easily allows these flaws (from both engine-side and user-side). Should maybe take an abolitionist approach here and redesign the "whether things have changed" detector, instead of solving this bug directly. For example, there's no clear way to tell the engine that things have changed from a constructor function.Placing the detector within functions such asObject::Move(),Texture::Simple(), adders, enterers, etc. also means wrapping variables such asObject::m_poswithin a setter (and perhaps an additional getter for safety), which to me sounds insane in terms of backwards-compatibility (although at the current stage this isn't so important) and code sanity (just how many trivial variables will get wrapped in functions?), deeming this solution inviable, unless there's a good balance of inserting the detector.It seems I have forgotten how the system I myself have written works, as it's fundamentally completely fine. The idea is things can only change while the game is running, and the user can change things only from callback functions, which may be input handling functions, on-tick functions, and invoked functions, but it just so happens I have forgotten to add the detector to the latter. It should be quite noticeable from the user's perspective that all of these callback functions must return a boolean, so they will likely refer to the documentation to figure out how to fulfill this requirement (return true if things have visually changed, otherwise false).