Welcome to the
XEngine Project Homepage
This project was initially developed for a diploma thesis at the
GUP Institute of the
University of Linz.
As of today the CVS repository for the XEngine project is deprecated. Its contents has been moved to the Subversion repository now provided by SourceForge (thanks!). For details on how to access the Subversion repository for the XEngine project please refer to the project-specific page on Subversion.
XEngine's code base has been upgraded to use wxWidgets 2.6.1 and Boost 1.33.0. Older versions might still work but are no longer supported.
After a bit of restructuring, CVS is stable again. Some no more required directories were removed and all directories previously found in the /include directory have been moved to a new subdirectory /include/XEngine. This was done in order to conform to the directory structure of other projects such as wxWidgets.
I have requested some CVS maintenance and restructuring from the SourceForge.net staff. This means that CVS might be in an instable state over the next week until the restructuring is done and I get a chance to adapt some of the source files to the new structure. Basically, most changes only involve removing no longer needed (i.e. empty) directories from CVS. But there is one big change: All subdirectories of the /include directory will be moved to /include/XEngine and this requires changing a large number of #include directives in the XEngine code base. I will post a news item when CVS is stable again.
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. Additionally, instances of the Renderer and RenderContext classes are now also passed around as boost::shared_ptr instead of raw pointers. For more details on this change please see this forum post. Finally, XEngine now uses wxWidgets 2.5.2.
I've set up a mailing list on sourceforge.net to which all news on the project will be posted to in the future. The list is a low volume mailing list with not more than one mail per month and only administrators are allowed to post to it. All news entries that are put up on the main project website will also be posted to the list. I see the list as convenience for people who want to keep updated with what's going on with the project without having to actively check the news on the website. You can subscribe to the mailing list by going to the SourceForge project page or directly via this page.
Completely rewritten PixelFormat and PixelFormatConverter classes have been committed to CVS. They allow for much more flexible definitions of all sorts of pixel formats and also offer better extensibility than the previous classes.
Additionally, a mipmap LOD bias texture sampler state class has been added to XEngineCore. This is the first texture sampler state available.
Finally, XEngine now requires wxWidgets 2.5.2, although I believe version 2.5.1 will work just as well. Note that there is a bug in wxExecute of the wxMSW port that causes an 8 byte memory leak every time it is called. XEngine's internal Cg runtime uses wxExecute to call the Cg compiler, so all samples that use the internal Cg runtime will leak 8 bytes for each shader they compile.
Some recent changes have been committed to CVS. Most notably, XEngine now requires wxWidgets 2.5.1. Please see the installation instructions for details as you might have to patch a few things of the wxWidgets distribution to get it to build correctly. Additionally, support for point sizes and point sprites has been added with a new render state class, RSPointParameters. Furthermore, the RenderTarget::Format class now generally uses a pixel format to describe the color buffer surface format, instead of using a simple color bit depth value for render windows as was the case until now. Note that due to time constraints most of the new code is not very well tested, especially a sample program that uses point sprites should be written for the new point parameters render state class. There are furthermore some issues under Linux that causes sample programs to crash with a Gdk-Error when creating the primary render window and I have yet to find out why this happens. Debugging with gdb under Linux on my slow machine is a major pain. Any help regarding these issues is greatly appreciated.
I recommend that only the adventurous or those that want to help with the issues update to current CVS until the code base has stabilized some more. For full details of all the changes see the change log in CHANGES.txt.
It has been available for a while for free already with the .NET framework download, but now Microsoft has even made a nice little toolkit download that contains the full optimizing Visual C++ compiler that ships with Visual Studio .NET 2003 Professional. Since XEngine requires this compiler and does not build with any earlier Microsoft compiler it might be interesting for some people, so here's the link: http://msdn.microsoft.com/visualc/vctoolkit2003/.
Also this free toolkit is a nice upgrade for people with Visual Studio .NET Standard, which only comes with a non-optimizing compiler but is much cheaper than the Professional edition.
I'll be on vacation in the US from March 5 until March 22, so don't expect any CVS commits or response on the forum or to e-mails during these two weeks.
I've done some first tests with wxWidgets 2.5.1 and got XEngine to build with it under both Windows and Linux. However, there are still some things to work out, particularly under Linux where I get segfaults with XEngineCore samples :-(
The DirectX PSA 1.4 to ATI_text_fragment_shader translator has been completed. More efficient sharing of OpenGL rendering contexts when using render-to-texture has been implemented. The RenderTarget::Format class now contains a PixelFormat member variable so that the surface format for all render targets is now specified by a pixel format (not only for render textures as it was before). This replaces the previous color depth parameter and allows for future expansion with floating point render targets. All these changes are not yet commited to CVS because they require some more testing, which won't happen until I return from my vacation.
Also the problems with not being able to use GLX 1.3 with the ATI Linux drivers still needs to be solved. If anyone with an ATI Radeon running Linux has any pointers on how to correctly use GLX 1.3 with these drivers I'd appreciate any hints. Thanks.
The DirectX renderers of XEngine now fully support pixel shaders version 1.4 with a new Spirit parser for this low-level shading language. A translator to ATI_text_fragment_shader is also in the works (and mostly already committed to CVS) that will allow running 1.4 pixel shaders on ATI hardware in OpenGL as well.
Additionally, the StateSet class has been pretty much rewritten from scratch (once again) to consume less memory at the expense of some performance. This change has also reduced header dependencies which in turn has greatly reduced build times on my machine with gcc under Linux (almost up to MSVC speed). With the new StateSet class, the RenderContext::GetState member functions, and similar functions provided by the texture sampler/coordinate stage and texture classes, are now template members. To retrieve a particular state, the GetState functions must be instantiated with the type of the state class. For example, RenderContext::GetState<RSDepthBuffer> retrieves the state of the depth buffer. If demand is high enough I might consider bringing back the old way of retrieving states via the type enum in addition to the new, much type-safer way.
XEngine now requires Boost 1.31.0 and the Cg runtime 1.2. The switch from wxWindows 2.4.2 to wxWidgets 2.5.1 will occur within the next few days/weeks.
For more details on all the changes that have occured since the last CVS commit, please consult the new text file CHANGES.txt in the XEngine root directory. I will try to keep a more or less detailed change log of all changes that are made to the code base in that file.
As final note, after I reported the bug some time ago, the most recent NVIDIA Windows drivers 56.55 finally fix the VBO bug when using multiple rendering contexts, which caused access violations in the render-to-texture samples of XEngine.
A number of changes in XEngineMath have been committed to CVS. The curve classes have all been moved to their own directory and their own namespace called 'Curves'. A template BezierCurve class has been added that can represent Bezier curves of arbitrary degree.
In preparation for the scene graph a BoundingVolume class has been introduced from which all volume classes that can also be used as bounding volumes (currently Box, AxisAlignedBox, and Sphere) are derived. The BoundingVolume base class has member functions to set the bounding volume from a set of points and from all other volumes and member functions to merge with any other bounding volume. To implement these functions a Householder tridiagonalizer and an Eigenvalue solver for real, symmetric matrices of arbitrary size have been implemented. To support this, template matrix and vector classes have been added.
The Direct3D 9 renderer now has simple support for vertex and fragment shaders using Microsoft's HLSL. Except for the fact that a different compiler is used there is no advantage of using HLSL over Cg. Additionally, due to an API limitation in Direct3D 9, vertex attributes to vertex shaders have to be specified via binding semantics and not via the actual variable names as with Cg.
Because of work and the the upcoming Christmas holidays I don't have a lot of time to spend on developing XEngine at the moment. The situation should, however, improve at the end of January 2004 when we finish the current project at work. Around that time I will probably start development of a scene graph component together with a 3ds max plugin for XEngine. I'm currently doing some research and design work in this area.
A lot of changes have been committed to CVS today, the most important being the move away from XEngine's own smart pointer class, RefPtr, to boost::shared_ptr. Also the Cg bindings parser has been rewritten with Spirit and, with it, a number of issues have been fixed in XEngine's internal Cg runtime. XEngineUtil has been extended and changed in various ways (note that the 3ds file loader has temporarily been removed until it is rewritten). For details of all the changes please see this forum post, which you should read carefully before considering a CVS update. Please report any issues on the forum. Thanks.
XEngine now has a translator that can translate the DirectX pixel shader assembler (PSA) versions 1.0-1.3 to ATI_text_fragment_shader or ATI_fragment_shader. When using XEngine's internal Cg runtime this also means that it is now possible to have Cg fragment shaders run on older ATI Radeon cards, such as the Radeon 8500 or 9200, with the OpenGL renderer. Please see the DirectX PSA page in the related pages section of the documentation for details and restrictions of the translation process. Furthermore, the ATI_text_fragment_shader parser has been more intensively tested and debugged.
All flex++/bison++ shading language parsers have finally been ported to Spirit and are now checked into CVS. An ATI_text_fragment_shader parser has been added. Also a number of other changes have been commited, in particular in XEngineMath and XEngineCore. The current CVS version now requires a compiler that properly supports partial template specialization, such as gcc 3.2 or MSVC 7.1. Rumour has it that the .NET Framework SDK, which can be downloaded from the Microsoft homepage for free, includes the optimizing version of the MSVC 7.1 compiler. So if you don't already have it, you can get it from there. It should even be possible to use it as drop-in replacement for Visual Studio 6.0 or Visual Studio .NET 2002 since AFAIK it is command-line compatible with older versions.
For all details regarding the recent CVS changes, please take a look at this thread in the forums.
I'd like to announce something well in advance that might upset some people. With the next bigger CVS commit, which will happen within the next 4-6 weeks, support for compilers that cannot handle partial template specialization, including any gcc version before 3.0, MSVC 6.5, and MSVC 7.0, will be dropped. This step is necessary because I want XEngine to be written in modern C++ using modern libraries - in particular Spirit and a number of other Boost libraries - that can only unleash their full power with modern compilers. The Spirit project has also just recently dropped support for these compilers and XEngine will follow this decision since after the next CVS commit all shading language parsers will be Spirit parsers. Additionally, I've just had enough of spending hours to work around internal compiler errors and other anomalies of MSVC 6.5 and 7.0. Now that I have a fulltime job during the day I'd rather spend the time I have for XEngine on something more useful.
There is a tag in CVS called 'Last_MSVC6_Version' which is the last version of XEngine that will build with MSVC 6.5 and 7.0 and possibly other older compilers. Therefore, compilers that can build XEngine from this point on will be MSVC 7.1 (that comes with VS.NET 2003), gcc 3.x, Digital Mars C++, and any compiler that uses the EDG front end, such as Intel C++ or Comeau C++.
Looking back, it was a bit arrogant to just use the one-letter name 'X' as namespace name for the engine. Therefore, I have decided to change the namespace name to 'XEngine'. All classes, structs, constants, functions, etc. of XEngine are now in the XEngine namespace and its subnamespaces. Each of the main components has its own subnamespace. So now all of XEngineMath is in the XEngine::Math namespace, all of XEngineCore is in XEngine::Core, and all the renderer libraries are in XEngine::Core::Renderers.
Existing applications can very easily switch over to the new namespace system by replacing the
using namespace X;
directives with the following:
using namespace XEngine;
using namespace XEngine::Math;
using namespace XEngine::Core;
If an application used fully qualfiied class names, such as X::RenderContext, the following could be used to get everything to compile again without making any source code changes:
using namespace XEngine;
using namespace XEngine::Math;
using namespace XEngine::Core;
Also I added 3-dimensional cubic spline classes that I had lying around for a while to XEngineMath. These classes are not yet very optimized and should be considered highly alpha. Expect some other curve types and maybe surfaces soon. Contributions are welcome.
XEngine's render buffer system has been extended to support different types of buffers, most importantly dynamic buffers. Dynamic render buffers are vertex or index buffers that are locked, changed, and unlocked again each frame, possibly even multiple times per frame. They are typically stored in AGP memory to allow fast write access for the application and fast read access for the GPU.
The interface for render buffers (including vertex and index buffers) had to be slightly changed, but it should be relatively easy to port old applications to the new interface. Basically, the vertex and index buffer factory functions of the RenderContext class have been slightly changed and now accept a parameter to specify the desired buffer type. Additionally, two new member functions, RenderBuffer::SetData and RenderBuffer::GetData, have been added to the RenderBuffer class. Also the usage flags have been extended and their names changed. To get familiar with the new interface I suggest to read the updated class documentation of the RenderResource, RenderBuffer, VertexBuffer, and IndexBuffer classes.
Furthermore, the OpenGL renderer now supports the ARB_vertex_buffer_object extension for its render buffers. If the extension is not supported, regular vertex arrays are used as before. Note that relatively new drivers are required to take advantage of ARB_vbo. Also in most drivers ARB_vbo support is still beta and might not work as expected. For example, with the 44.65 NVIDIA drivers, using dynamic render buffers (that are filled by mapping the buffer with glMapBufferARB) doesn't work on my GeForce 4. The buffer contents isn't changed and consequently no geometry is rendered, even though no GL errors are returned.
Please note that anonymous CVS access on SourceForge currently runs off the backup server. Therefore, the changes might not be visible until 24 hours after I have posted this message. For more details on the current CVS situation on SourceForge please see the site status page.
I have made big changes to the build system of XEngine and I recommend doing a complete update from CVS (deleting any old local copies). The build files (Visual Studio project files, gcc make files, etc.) are now automatically generated and no longer located in the XEngine/src directory but have been moved to a new directory XEngine/build. This directory contains additional directories, each directory representing a different compiler/environment. For example, XEngine/build/msvc6 contains the build files for Visual C++ 6.0, XEngine/build/gcc3-gtk the make files for gcc 3.x using wxGTK. Similar changes have been made to the samples. So there is now a XEngine/samples/Core/build directory which contains build files for all XEngineCore samples for various compilers/environments.
With the build system overhaul I have also changed the names of the XEngine Windows DLLs to correspond to the naming scheme used previously for the Linux shared objects. The old XEngineMath10d.dll is now called XEngineMath-1.0d.dll. This change simplifies the code somewhat in various places and also makes the automatic generation of the build files easier.
The new build files are automatically generated by a little tool I wrote, called XEngineBuildTool. The tool is not necessary to build XEngine, but those interested can find it in a new module called XEngineBuildTool in CVS. The tool is written in Python and uses wxPython for the GUI. In fact it was my first ever Python project after having studied the language for only about two days, so if you are an experienced Python programmer and want to have a good laugh, you might want to take a peek at the source code ;-)
Furthermore, XEngine now requires the latest official, stable wxWindows distribution, wxWindows 2.4.1. Additionally, STLport is no longer required when building with gcc 3.x, Visual C++ 7.0 or 7.1 because the STL implementations of these compilers are finally in a usable state. It is, however, still recommended to use STLport (and I also still use it with all compilers) because of its excellent debug mode.
MSVC 7.x has a bug that causes wxWindows RTTI to not work correctly. Due to this wxWindows appllications built as release builds (including all release build XEngine applications) will crash during startup. I did some debugging and posted a (temporary) fix for wxWindows 2.4.0 on the forums here. Everyone using MSVC 7.x should apply this fix to their local copy of wxWindows. Thanks.
Heck, it doesn't have anything to do with XEngine, so please forgive my ignorance, but I've just passed my final diploma exam with honors and can now officially call myself "Diplomingenieur" (similar to Master of Science in other countries). Now somebody give me a job, preferably in the computer graphics/game industry and preferably in Australia, the USA, or Canada ;-)
The Direct3D 9 renderer is now completely checked into CVS and should hopefully pretty much work in the same way the Direct3D 8.1 renderer already does. It additionally supports separate alpha and color frame buffer blending, a scissor rectangle, and automatic mipmap generation in hardware, if available. So in practice there's not much difference between the two Direct3D renderers as of yet. However, the Direct3D 9 renderer will be extended in the future to support the new low-level shading languages, HLSL, float buffers, and a two-sided stencil buffer render state.
Spirit, a template-based parser generator library that uses C++ as metalanguage to describe parsers, has finally passed the formal peer review and is now officially part of the recent release of the Boost libraries. Spirit must be one of the coolest C++ libraries I have seen to date and I recommend everyone to check it out and learn to appreciate its beauty. After spending some time studying the Spirit documentation, I have begun porting some of the bison++ parsers of XEngine to Spirit. These parsers are not yet in CVS, but I will gradually replace existing parsers with Spirit parsers in the near future. The Spirit parsers will not (yet) use closures or lambda expressions because I do not yet want to give up support for Visual C++ 6.0. However, due to the more and more intensive use of the Boost libraries and templates in general in XEngine, Visual C++ 7.1 might become the required Microsoft compiler for the engine in maybe 8-12 months.
Note that replacing the parsers won't happen before the Direct3D 9 renderer for XEngine is finally in CVS which should happen sometime next week. I'm currently cleaning up the code a bit and also need to fix a bug in the ARB_vertex_program parser that I accidentally built in during the last bigger internal code restructuring.
I've replaced the previous documentation papers with new documents that also include the recent design changes. The programming guideline document has been updated and the component and render system design documents combined into a single document that describes the entire system design (including the current basic design of the not yet publicly released scene graph, for those interested). If you're wondering where the document that describes the peculiarities of using various shading languages with the engine went...it has been integrated into the doxygen-generated API reference documentation in the form of related pages. The short introduction to programmable shaders that was part of that document has been revised and moved to the paper titled Programmable Graphics Pipeline Architectures. That paper also introduces most of the currently used low-level and high-level real-time shading languages. Well worth a read if you're new to programmable shading. Follow the documentation link in the navigation menu to download the new papers.
What I've announced in various places before, has finally happend. Texture stages have been split up into texture sampler stages and texture coordinate stages. This is a massive change from the original design of XEngine (which was done at a time where the necessity for this change was unforeseeable). I want to ask anyone who has a local CVS copy of XEngine to please delete that copy and do a complete update from CVS. With this change done nothing stands in the way of a Direct3D 9 renderer now. I hope this will be the last big design change for a while.
Furthermore, the render states that dealt with texture blending have been removed and replaced by a fixed-function fragment shading language. The grammar of this language can be found in a new section called "Related Pages" in the API documentation.
As always there were other bug fixes, small changes, and the API reference documentation has been updated accordingly. The design documents currently on the site still represent the old design. Updated versions of these documents will be prepared and uploaded within the next one or two weeks.
XEngine now supports multiple vertex buffer streams which is useful for various techniques, such as keyframe animation, where only certain vertex attributes change each frame. Also the RenderContextCaps class has been pretty much rewritten from scratch, and the minimum requirements for the engine to start up lowered a bit, in order to solve some issues with the DirectX renderer on older ATI Radeon cards.
XEngine's internal Cg runtime has been updated to support multi-dimensional arrays. In addition, XEngine now also supports NVIDIA's Cg runtime, if desired. By default, this is turned off in the configuration header files. The advantage of using NVIDIA's Cg runtime is that Cg compiler profiles can be used that are not yet supported by the XEngine-internal runtime. The disadvantage is that NVIDIA's Cg runtime does not support vertex attributes of type ShaderVarType::TypeColorARGB, or in other words 32-bit packed ARGB colors. This is a deficiency of NVIDIA's Cg runtime.
I also added a couple of new shading languages to the OpenGL renderer, in particular NV_vertex_program2, NV_fragment_program, ARB_fragment_program, and ATI_text_fragment_shader. Note that for none of these a parser or cross-compiler to DirectX is yet available, so they can be used exclusively by the OpenGL renderer.
Furthermore, the ShadingLanguage and ShadingLanguageCaps classes have been cleaned up and partly rewritten. The engine does not distinguish between vertex attribute bindings for the fixed-function and the programmable pipeline anymore. Until now, by design, the fixed-function pipeline was considered to be a special shader program that contains fixed-function shaders. This is now also really implemented that way in the renderer libraries. So there are special shader classes that implement fixed-function pipeline functionality and they have the special shading language ShadingLanguage::FixedFunction.
The next things to do will be to add support for multiple vertex attribute streams and separate the TextureStage class into a TextureSamplerStage and a TextureCoordStage class in XEngineCore. Lexers and parsers for the new OpenGL low-level shading languages will be written and corresponding cross-compilers, as time permits. In particular, a DirectX pixel shader to ATI_text_fragment_shader cross-compiler seems to be very interesting to me, since it would allow Cg to run on older Radeon cards. Also a Direct3D 9 renderer is in the works.
Over the last couple of days I did a bit of a code review and cleaned up a couple of things in the engine. One thing is the consistent use of the size_t standard type instead of unsigned int in various places, and another is that XEngine now uses some of the nice template classes of the Boost library. Boost doesn't need to be built to be used by XEngine, since I'm only using some simple template classes at the moment. The compiler just needs to be able to find the header files. That might change however in the future (Python scripting anyone? :-)
Also I've added support for the DevIL image library. So now XEngine can load all image formats supported by DevIL and the wxImage loaders of wxWindows. I've also updated the installation instructions (which I've also changed to HTML) to reflect these new library dependencies.
Furthermore, there are now configuration header files for each of the engine's components. Currently it's possible to turn off the use of DevIL and lib3ds to reduce dependencies on third-party libraries, if desired.
As usual, there have been numerous other small changes and fixes here and there. Please consult your favorite CVS client and diff tool for details ;-) XEngineCore is slowly getting a maturity level that allows an official release version 0.1 in a couple of months. I want to release with a basic version of XEngineSceneGraph though.
The scene graph has made considerable progress and it is now in a state where I almost feel like releasing it publically (unlike what I said in the last news entry). Expect something...hm...maybe in a month or two.
On another note, the OS/2 port of wxWindows, wxOS2, is now fully functional and I feel the urge burning under my fingernails to port XEngine to wxOS2. Maybe I'll go and buy a copy of OS/2 in the near future ;-)
I was sick through almost all of December. That's why not a lot happened with XEngine lately. However, I applied some small bug fixes and updated the Cg bindings parser to work with the new Cg compiler version 1.0 (non-beta). XEngine now requires the final Cg compiler and probably won't work anymore with any of the beta compilers.
Also I made the first steps towards a Mac OS X port of the engine with the help of someone. But since I do not own a Mac it's very hard to do the port myself. It's probably not a lot of work to finish the port, but I'd really need somebody who owns a Mac with Mac OS X 10.2 running on it and prefereably a GeForce 3+ graphics card to do the rest of the port and also, if possible, maintain it in the future.
Regarding the scene graph component I've made somewhat of a progress and it's already possible to load Quake 3 level data (without shaders), but since I'm a bit under time pressure regarding my diploma thesis due to my illness I'll probably just do some quick hacks to get the scene graph done. I don't know yet, if I'll ever release it the way it is now. And after I'm done with my thesis (in something like 3-4 months) I'd rather concentrate on polishing XEngineCore, adding support for new shading assembly languages, and writing a Direct3D 9.0 renderer. So if anybody wants to contribute a scene graph API on top of XEngine, be my guest ;-)
Finally, a happy new year to all of you. May 2003 be a good year for you.
I've put up a phpBB2 discussion board to discuss everything related to XEngine. Feel free to use it. The sourceforge forums are now deactivated.
In other news, work on the scene graph component is progressing, albeit a bit slowly as I'm mostly writing on my diploma thesis at the moment.
Great news! The OpenGL renderer can now translate DirectX pixel shaders version 1.0 to 1.3 (with some minor restrictions) to NVIDIA register combiners/texture shaders. This means that you can now use DirectX pixel shaders with the OpenGL renderer as you would with the DirectX renderer. Also the Cg dx8ps profile is now fully supported with the OpenGL renderer. Not even the Cg runtime supports this at the moment ;-)
For supported features and restrictions please look at the updated Shading Languages document in the documentation section.
I didn't feel like working on the scene graph component today, so I added a Quake 2 Model (.md2) mesh loader to XEngineCore.
As promised, I've checked in all the recent changes into CVS, and there have been quite a few changes:
- StateSet class for easy management of the entire set of states of a render context
- Shader::SetParameter and Shader::TrackParameter have been moved to the ShaderProgram class
- 3DS file format loader using lib3ds
- Mesh class
- Internal optimizations in the OpenGL renderer
- Various bug fixes, code and documentation cleanups
- New samples: Flag, MeshViewer, and RenderToTextureTest
I have also updated all design documents and the API reference extensively to reflect the changes.
This update means a feature freeze for XEngineCore for now. I'll be working exclusively on XEngineSceneGraph in the coming weeks. I'll only fix bugs in XEngineCore, if I come across any.
I've uploaded a new document in the documentation section of the site describing the programming guidelines used in the XEngine source code.
Also expect a big CVS source code checkin sometime next week with some rather big changes to the internal XEngineCore structure, various bug fixes, a new state set class, a new mesh class, and basic 3DS file loading support. The most notable structural difference is that the Shader::SetParameter and Shader::TrackParameter routines have been moved to the ShaderProgram class. This big design change was necessary after I've noticed that the engine wouldn't be able to support Glslang with the current design. I think it's also semantically more correct to have the SetParameter and TrackParameter methods in the ShaderProgram class.
I've just uploaded three design documents that should be read by everyone interested in XEngine, especially if you want to start working with it. I suggest to first read the Component Design document and then the Render System Design document. You can get the files in pdf format from the documentation section. Happy reading! :-)
I've finally uploaded the source code to CVS. Please consider that the source is not yet in a state to be released. Everything is still in an alpha stage of development, but it should compile fine, if you follow INSTALL.txt properly. If you're having troubles, give me a shout or post on the forum.
I'm still looking for help. In particular, I'm looking for a maintainer for the Linux port that changes the make system to use autoconf. I don't have the time nor the experience to do this at the moment. If anyone is interested, please send me an email.
Since I'll still be working intensively on the project (most notably on the not yet even begun
scene graph component) for at least 4 months, I'm not looking for any full-time help, but I
need some assistance with evolving/maintaining the Linux port. In particular I'm looking for
- Somebody who has a deep understanding of ld under Linux and can help me with solving
the problems regarding dynamic runtime loading of renderer libraries
- Somebody to make a better make system with configure under Linux
- People interested in compiling and trying out the engine on other Unix systems
- People who are interested in writing test applications with the engine, e.g. you could
port some OpenGL or Direct3D NVIDIA samples to XEngine
- Somebody interested in porting the OpenGL renderer to Mac OS X
If you can help with any of these, even a little, please send
me an email. Thanks.
The most important help I need is somebody who can help me a bit with the dynamic loading
of libraries at runtime using dlopen under Linux. There are a couple of problems that I didn't
manage to solve on my own, being a relative Linux programming newbie. I need someone with
profound knowledge of how ld works and how exactly it links modules, because it is apparently
very different from the Windows runtime linker. You don't even have to contribute some
code, maybe just do a little debugging of the problem (I've pretty much pinned it down already,
even with my limited knowledge of gdb, so I can probably give you a lot of assistance/hints in
A Mac OS X port should be fairly easy and not require a lot of coding. I could probably give
a lot of help and contribute some code. But since I do not own a Mac I cannot test anything.
So if anybody is interested in having DirectX vertex shaders running on a Mac, give me a shout.
I finally managed to put some web pages together for the XEngine project homepage on sourceforge.
Well, since you're reading this you should be pretty much aware of that by now ;-)
I'm currently putting the finishing touch on the source code and will upload a snapshot of my
source tree to CVS in a couple of days. Everything is still in alpha and not well tested. I'm having
heaps of trouble getting everything to run under Linux, especially dynamically loading .so files
at runtime. I hope somebody out there might be able to assist me with the Linux port, or possibly
even become the maintainer of the Linux port of XEngine.
Things that already work very nicely but could still use more extensive testing are the Windows port,
all the vertex shader translators (currently: ARB_vertex_program to DirectX VSA, NV_vertex_program to
DirectX VSA, DirectX VSA to NV_vertex_program, DirectX VSA to ARB_vertex_program, NV_vertex_program to
ARB_vertex_program), Cg support with the vp20, arbvp1, dx8vs and dx8ps profiles and all the basic
rendering stuff. Render to texture in the OpenGL renderer could still use some performance tweaking,
but that's not a priority right now.