Follow-up from the last post:  the live VectorStorm trunk has been updated.  The updated version is now available at the usual subversion repository on this server, and also from a git server on gitorious.  Links to both repositories are available from the “VectorStorm Test Games” link in the sidebar.

For those who are more interested in binaries than in source code, there are updated binary builds for both Windows and Mac.  These builds match svn revision 1501.  For those who are interested in iOS, that port has also been updated to build successfully again (though it still has no sound support.  I really need to either get SDL working under iOS or else find a sound solution for iOS).

Notable changes since the last VectorStorm update:

• The old vsBuffer is now vsRenderBuffer, and is declared in VS_RenderBuffer.h, instead of VS_GPUBuffer.h
• The old vsTextureMaker is now vsImage, and now supports loading images from disk.  Saving images back to disk is supported on Mac, but that functionality hasn’t yet been set up for Win32 (just needs me to get around to compiling libpng for Win32).
• Pre-compiled Mac frameworks for all non-standard frameworks (SDL, Glew, etc) are now provided in the version control repository.  These are all (currently) of the latest version of those libraries, and these are configured correctly for embedding into an application bundle.  Pre-compiled Win32 dlls/headers are not yet being provided, but I’m looking into whether there might be a clean way to add these in the near future.
• The input system’s mouse capture support has been changed.  Previously, it would warp the mouse cursor to the middle of the game window each frame.  Now, it merely constrains it inside the game window.  This means that if you’re capturing the user’s mouse in order to control turning (as happens in an FPS, for example), then you want to stop using the mouse’s absolute position in the window, and instead use the mouse’s relative motion since the previous frame.
• Oh.  As implied by the above, you can now ask the input system to return the mouse’s relative motion since the previous frame.  This relative motion is always correct for the mouse’s motion, even if the mouse cursor is being artificially constrained within the bounds of the game window.  (i.e. if the mouse is captured by the window and the cursor is at the far right edge of the window, when the user moves his mouse further to the right, the input system will report the same position for “getMousePosition()”, but will still report motion to the right for “getMouseMotion()”.)
• Big optimisations under the hood of render material batching.  For games which were receiving a lot of batching, this could be a really big improvement.