Note:  Class demo can now look straight up and down
	Still doesn't have an elevation limiter

I think we'll leave the visuals alone for just a little bit
	Don't we get lighting?
	Maybe...later...Raymond has it and we don't
	I'd like to prioritize getting the engine architecture together

Today:  Threading model and managing the CPU

A few purposes for the CPU:
	Babysitting the GPU
	Player movement (and player collision detection)
		Most important collisions
	General collision detection
	Movement that's not animation
	Animation

How many cores do we have?
	I've used Unix-specific methods for this before, but C++ has one now
		std::thread::hardware_concurrency()
		I *might* have a chance to try it

So how would we divy up the CPU?
	1 core:  Babysit GPU
	1 core:  Player movement and collisions (high resolution)
	1 core:  Move objects (lower resolution)
	1 core:  Animations (lower resolution)
	All the rest: Collision Detection

Questions:
	Do we have exclusive use?
	Should we add more threads than we have cores?

New object interface:
	move
	animate
	Something that can be used to determine a bounding box
	Something to notify the object of a collision
	
Goals:
	1.  Set up animation loop, use it for animated object
	2.  Set up bounding box interface, player collision detection with some kind of box

Other stuff on the "soon" TODO list:
	Set up a loaded object with instances
	Some kind of projectile we can launch
	Improve the Makefile
	Move object definitions somewhere other than Source.cpp, and rename Source.cpp
	Add resize support (easy)
	Replace the cursor with something else
		Easy to get rid of it:
		glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_DISABLED)
		Center mark:  Crosshairs, or just leave off

We're working toward projects instead of labs
	First project *might* be to make a game with a jump sequence
		Caveat:  I hate jump sequences