xengine-announce — A low volume list with announcements on major update or other news

[XEngine-announce] Updates to wxWidgets 2.5.3 and Boost 1.32.0

[Martin E. <mar...@li...>]

Hello,

The XEngine code base has been updated to use wxWidgets 2.5.3 and Boost 1.32.0.
Note that Boost.MPL has undergone some incompatible changes. So if you use it in
your own code be aware that you might have to make some code changes. The most
prominent change is the name change of apply_if and apply_if_c to eval and eval_c.
Note also that the gcc/Linux makefiles had to be changed to accommodate the
new wx-config script. The master Makefile for each build configuration now has a
new variable called WXTOOLKIT which defines the wxWidgets toolkit passed to the
new wx-config switch --toolkit.

Also, the directory structure has somewhat changed. Instead of having all header
files in the XEngine/include directory, they are now located underneath
XEngine/include/XEngine. Thus, if an include path is set to XEngine/include - as
was usually the case until now - it is now necessary to prefix the header file
with "XEngine/" in the code, e.g. #include <XEngine/Core/XTexture2D.h>. This
makes code somewhat more readable in that it is immediately clear to which
library a specific header belongs to. It also follows the structure of other
projects, such as wxWidgets.

Some new curve classes were added to XEngineMath:
- HermiteSpline (a new base class for all Hermite-type splines, such as TCB splines)
- CardinalSpline
- LinearSegmentedCurve

Also note that the interface for the functions returning a curve frame was
slightly changed. Curve2 now returns the normal as the counterclockwise rotated
tangent (and not the clockwise rotated tangent as it used to). Curve3 now
returns a Frenet frame in the more common TNB order instead of TBN. Also, new
functions were added to Curve3 that allow to avoid the flipping of the normal of
the Frenet frame at points of inflection with certain curve types. These new
functions return a frame based on a pre-defined up vector. Please consult the
class documentation for details.

Furthermore, some patches relating to building XEngine as Unicode build were
applied. These patches were provided by Christopher Wedman. Thanks to him.

For a possibly more detailed log of all changes see CHANGES.txt in the root
directory of the XEngine module in CVS.

Finally, I'd like to point out that for some time now SourceForge has stopped
its cron service on the project servers. This means that the nightly tarball is
not created anymore every night, but only when I explicitly run the script,
which I usually do every couple of weeks. Sorry for this inconvenience.

Best Regards,
Martin Ecker

[XEngine-announce] ARB_fragment_program Parser and Other Changes

[Martin E. <mar...@li...>]

Hello,

CVS now contains an ARB_fragment_program parser for version 1.0 of the language. 
Some minor bug fixes were applied to the ARB_vertex_program parser as well.

Instead of using raw pointers, instances of the RenderContext and Renderer 
classes are now also passed around as boost::shared_ptr, just like 
RenderResource or RenderTarget objects. This makes it easier to write
exception-safe client code.

RenderContext and Renderer destruction works like this (which has basically not 
changed):
- A Renderer object is destroyed when the last RenderContext that was created by 
that Renderer is destroyed and the client holds no further shared_ptrs to it. 
When the Renderer object is destroyed, the corresponding dynamic shared library 
is automatically unloaded.
- A RenderContext object is destroyed when the client releases the last 
shared_ptr it holds to the RenderContext.
- When a RenderContext is destroyed, all RenderResource and RenderTarget objects 
created by it must have already been destroyed. The debug build will assert if 
this is not the case.

Regarding interaction with wxWidgets there is one important thing to consider: 
If the wxApp-derived class holds a shared_ptr to a RenderContext (or a 
RenderResource or RenderTarget), that shared_ptr must be destroyed before 
wxApp::CleanUp is called. In order to ensure this, either make sure the 
RenderContext shared_ptr is kept in a wxWindow-derived class or any other class 
whose objects are destroyed before wxApp::CleanUp is called, or override 
wxApp::CleanUp in your application class and call reset() on the shared_ptr 
before making the upcall to wxApp::CleanUp. For an example of this, see the 
MultiWin sample.

Finally, XEngine now uses wxWidgets 2.5.2. Please see install.html in the
root directory in CVS for details (and some patches that might need to be
applied to wxWidgets).

Best Regards,
Martin Ecker