Member GameScoreData::mPlayerOneCounters: Make naming of Player A and B consistent.
Member GameScoreData::mPlayerTwoCounters: Make naming of Player A and B consistent.
Member House::canMove (const Piece &gamePiece) const: We shouldn't need Piece here, just PieceIdentity should do.
Member Player::getPiece (PieceTypeID pieceType): Why did I make this a pointer in the first place? I forget.
Member Player::mPieces: Once again, why did these need to be pointers?
Member QueryClick::mPreviousQueryResults: We're storing shared pointers to nodes in the scene tree here. There's a bug in waiting if we have a reference to a node that was taken off the active scene tree between queries. I don't really know how to think about the problem just now.
Member ToyMaker::ActionDefinition::mValueType: Find out where this is used.
Member ToyMaker::BaseInstanceAllocator::_upload (): I'm actually at a loss as to what I was trying to accomplish here.
Member ToyMaker::BaseOffscreenRenderStage::detachTargetTexture (std::size_t targetTextureID): Figure out what my intentions were re: this method.
Member ToyMaker::BaseOffscreenRenderStage::removeRenderTarget (const std::string &name): Figure out what my intentions were re: this method.
Member ToyMaker::BaseOffscreenRenderStage::setTargetTexture (std::shared_ptr< Texture > texture, std::size_t targetID): Figure out whatever it was I might have wanted this for.
Member ToyMaker::BaseRenderStage::mVertexArrayObject: In practice, we end up doing that anyway because I'm an idiot.
Member ToyMaker::BaseRenderStage::setup (const glm::u16vec2 &targetDimensions)=0: Much of this is finicky and poorly defined. Stricter requirements needed.
Member ToyMaker::BaseRenderStage::validate ()=0: Much of this is finicky and poorly defined. Stricter requirements needed.
Member ToyMaker::BaseSimObjectAspect::handleAction (const ActionData &actionData, const ActionDefinition &actionDefinition) override final: Shouldn't this be private? Will something bad happen if we make this private?
Class ToyMaker::BuiltinModelMatrixAllocator: I think a generalization of BuiltinModelMatrixAllocator::upload() is possible and should be explored at some point.
Member ToyMaker::CommonActionData::mActivated: Find out what this does.
Member ToyMaker::ComponentManager::handlePreSimulationStep (): rename to handleSimulationPreStep
Member ToyMaker::InstanceAttributeDescriptor::operator== (const InstanceAttributeDescriptor &other) const: code duplicated from VertexAttributeDescriptor. Refactor needed.
Class ToyMaker::Material: Not happy with all the redundant code for getters-setters and material property registrators. Maybe replace with a templated version somehow?
Member ToyMaker::ObjectBounds::create (const VolumeBox &box, const glm::vec3 &positionOffset, const glm::vec3 &orientationOffset): Oriention offset should just be a quaternion. Multiple quaternions may produce the same forward vector while still altering the up and right vectors.
Member ToyMaker::ObjectBounds::create (const VolumeCapsule &capsule, const glm::vec3 &positionOffset, const glm::vec3 &orientationOffset): Oriention offset should just be a quaternion. Multiple quaternions may produce the same forward vector while still altering the up and right vectors.
Member ToyMaker::ObjectBounds::create (const VolumeSphere &sphere, const glm::vec3 &positionOffset, const glm::vec3 &orientationOffset): Oriention offset should just be a quaternion. Multiple quaternions may produce the same forward vector while still altering the up and right vectors.
Struct ToyMaker::OpaqueRenderUnit: Maybe there's a better order for opaque queues? Investigate.
Class ToyMaker::RangeMapperLinear: Does this really need to be a class when it seems as though every usage instantiates and calls this "functor" in the same step? What was I thinking?
Member ToyMaker::RelativeTo: Make this feature actually work.
Member ToyMaker::RenderSet::RenderType: Split this out into different configuration files for the render system instead of their current "if-else" structure.
Class ToyMaker::Resource< TDerived >: Determine whether it is actually necessary to have all a Resource's construction and assignment operators defined when using the ResourceDatabase for something.
Member ToyMaker::SceneNodeCore::inScene () const: We can't be certain the value returned by this method and the one in the SceneSystem are in sync. Remove this redundancy somehow.
Member ToyMaker::SceneNodeCore::isActive () const: We can't be certain the value returned by this method and the one in the SceneSystem are in sync. Remove this redundancy somehow.
Member ToyMaker::SceneNodeCore::onCreated (): Sit down and figure out whether this operator will ever actually need to be used.
Member ToyMaker::SceneNodeCore::onDestroyed (): Figure out whether this is actually necessary, and why it was we couldn't just use the virtual destructor.
Member ToyMaker::SceneNodeCore::SceneNodeCore_del_ (SceneNodeCore *sceneNode): See whether onDestroyed actually gets called, and whether this function is even necessary given that virtual destructors already exist.
Member ToyMaker::SceneNodeCore::setPrototype_ (std::shared_ptr< SceneNodeCore > prototype): Think of a safer way to accomplish this.
Member ToyMaker::SceneSystem::isSingleton () const override: This is obviously stupid and I should do something about it.
Member ToyMaker::Signal< TArgs >::resetSignal (SignalTracker &owningTracker, const std::string &name): Investigate the behaviour of this method.
Member ToyMaker::SignalObserver< TArgs >::resetObserver (SignalTracker &owningTracker, const std::string &name, std::function< void(TArgs...)> callback): Figure out what the intention for this method was.
Member ToyMaker::SimObject::simulationUpdate (uint32_t simStepMillis): Figure out whether this operator will actually ever be useful.
Class ToyMaker::SpatialQuerySystem: SceneHierarchyData isn't required by this system, as far as I can tell.
Class ToyMaker::SpatialQuerySystem::LightBoundsComputeSystem: This sort of makes it so that an object with LightEmissionData and StaticModel components gets conflicting results for ObjectBounds. Do we want to allow entities to have both? If not, should we do something to explicitly prevent it?
Member ToyMaker::SpecialEntity: Figure out if there's actual any use for this or if my brain farted when I was writing the scene system.
Member ToyMaker::TextFont::renderText (const std::string &text, glm::u8vec4 textColor) const: Unnecessary; remove.
Struct ToyMaker::VertexLayout: This isn't particularly intuitive or useful yet; expand on this so that shaders can declare their vertex layouts in their json headers maybe? At present we've just hardcoded this into the render stages.
Member ToyMaker::VolumeBase_::getVolumeRelativeBoxCorners () const: I forget why I was doing this in the first place. Do we have a problem here?
Member ToyMaker::WindowContext::getDimensionsMaximum () const: Compute and cache minimum window dimensions in pixels instead.
Member ToyMaker::WindowContext::getDimensionsMinimum () const: Compute and cache minimum window dimensions in pixels instead.
Member ToyMaker::WindowContext::getPosition () const: Compute and cache the window position in pixels instead.
Member ToyMaker::WindowContext::getTitle () const: This shouldn't be returning a const reference.
Member ToyMaker::WindowContext::mCachedWindowMaximumDimensions: Make it so that this is stored in pixels instead, somehow.
Member ToyMaker::WindowContext::mCachedWindowMinimumDimensions: Make it so that this is stored in pixels instead, somehow.
Member ToyMaker::WindowContext::mCachedWindowPosition: Make it so that this is stored in pixels instead, somehow.
Member ToyMaker::WindowContext::mpAssetImporter: move this out of the window context manager, or move window management itself into a class with a smaller scope.
Member ToyMaker::WindowContext::mpGLContext: move this out of the window context manager, or move window management itself into a class with a smaller scope.
Member ToyMaker::WindowContext::mSigWindowDisplayChanged: Figure out what this means.
Member ToyMaker::WindowContext::mSigWindowICCProfileChanged: Figure out what this means.
Member ToyMaker::WindowContext::mSigWindowSizeChanged: Figure out how this is related with mSigWindowResized()
Member ToyMaker::WindowContext::s_windowContextManager: Eventually support multi-window applications.
Member ToyMaker::WindowContext::setPosition (const glm::uvec2 &position): Have position be specified in pixels instead.