Forum
Ask for help, report bugs, discuss features

Alternatively, if you prefer to send questions through email, you can subscribe and post to our castle-engine-main mailing list.

You can also submit bugs and feature requests to our "tickets" tracker.

If you really want to contact the author directly, send email to Michalis Kamburelis.

Helping in the engine development

If you'd like to help in the development of our engine, here are some proposed tasks:

1. For everyone

• Brag about our engine on blogs and social platforms :)
• Donate.
• Create a page on Wikipedia about our Castle Game Engine and/or view3dscene. Maybe only a page about view3dscene for starters?

2. For 3D worlds creators

If you use our tools to create or browse your 3D worlds, you can:

• Show off your works on our forum, in any way you like (screenshot, link to model, youtube video etc.). If you use some of our engine special VRML/X3D extensions or rendering features, you are strongly encouraged to do so (Michalis loves to see how his work is useful for others :) ! But also post about "normal" 3D models that simply look nice in our view3dscene or such.

• Contribute models to our demo models.

• Look into improving our documentation. Our VRML / X3D documentation is large, and always wants to be larger. Contributions describing how something works, or how to do something practical, are welcome.

  You can add your contributions directly to our wiki. (Once we'll get some user content in our wiki, we'll think how to make it more visible.)

• Test the nightly builds of our binaries. These are build automatically every night using current SVN code. You can test them and catch eventual bugs before the release. This way you can also preview new features before they are released.

  Bugs can be reported on the forum or in the tickets tracker.

3. For ObjectPascal developers

For ObjectPascal (FPC, Lazarus) developers:

• Use our engine to make your next game, of course! :) And make it great :)

• Contribute to our wiki useful tips or tutorials about using our engine.

3.1. Proposed (larger) development tasks

Many areas of the engine could use the help of an interested developer. If you'd like to join, or just send some patches improving something, please contact us, for example through forum.

Below are some ideas for development. Some of them are not trivial, although they may be easy if you have an expertise in a particular area (or you're willing to gain such expertise :) This list isn't exhaustive of course, there are many things we want to achieve, and you most likely have even more ideas of your own. If you don't have time to work on them, but you badly need them, consider also donating to a particular goal.

• Scripting in JavaScript

  Allow to use JavaScript (ECMAScript) directly inside VRML/X3D files (in Script nodes). This will follow VRML/X3D specification. Implementation will be through besen (preferably, if it will work well enough), SpiderMonkey, or maybe some other JS library.

• Physics integration

  Integrate our engine with a physics engine. Most probably Bullet, which will require proper translation of Bullet API to C and then to FPC (as Buller is in C++, it's not readily usable from anything other than C++). Eventually ODE. Allow to easily use it in new games for programmers. Allow to use it in VRML/X3D models by following the X3D "Rigid body physics" component.

• Android port

  Our 3D renderer uses a clean and modern OpenGL, using VBOs and shaders. Some of the 2D control bits have to be still ported to modern OpenGL, but that's a very easy task. Use it to make a modern renderer running on Android. FPC has various ways to develop for Android.

  Same about iOS (iPhone, iPad etc.) port.

• WWW browser plugin

  Most probably using NPAPI, the cross-browser API for plugins. Our CastleWindow code will become handy for this, as it can deal with WinAPI / XWindows window handle (this is what we get from plugin to initialize our plugin viewport).

• Use Cocoa under Mac OS X

  We already have a native look and feel, and easy installation, under Mac OS X, see relevant news and docs for Mac OS X situation in SVN. Our programs no longer have to use X11 and GTK under Mac OS X. Still, current solution is not optimal: we use LCL with Carbon under the hood. Carbon is deprecated and only 32-bit (Cocoa should be used instead), and depending on LCL has it's own problems (mouse look is not smooth with LCL message loop).

  The proposed task is to implement nice Cocoa backend in CastleWindow unit. Contributions are welcome. This is an easy and rewarding task for a developer interested in Mac OS X.

• Support Material.mirror field for OpenGL rendering

  An easy way to make planar (on flat surfaces) mirrors. Just set Material.mirror field to something > 0 (setting it to 1.0 means it's a perfect mirror, setting it to 0.5 means that half of the visible color is coming from the mirrored image, and half from normal material color).

  Disadvantages: This will require an additional rendering pass for such shape (so expect some slowdown for really large scenes). Also your shape will have to be mostly planar (we will derive a single plane equation by looking at your vertexes).

  Advantages: The resulting mirror image looks perfect (there's no texture pixelation or anything), as the mirror is actually just a specially rendered view of a scene. The mirror always shows the current scene (there are no problems with dynamic scenes, as mirror is rendered each time).

  This will be some counterpart to current way of making mirrors by RenderedTexture (on flat surfaces) or GeneratedCubeMap (on curvy surfaces).

• Advanced networking support

  Basic networiking support is done already, we use FpHttpClient unit distributed with FPC, see relevant news entry. Things working: almost everything handles URLs, we support file and data and http URLs.

  Things missing are listed below (some of them may done by adding integration with LNet or Synapse, see also nice intro to Synapse on FPC wiki).

  1. Support for https. By sending patches to add it to FpHttpClient. Or by using LNet or Synapse (they both include https support).

  2. Support for ftp. By using LNet or Synapse, unless something ready in FPC appears in the meantime. Both LNet (through LFtp unit) and Synapse (FtpGetFile) support ftp.

  3. Support for HTTP basic authentication. This can be done in our CastleDownload unit. Although it would be cleaner to implement it at FpHttpClient level, see this proposal. Or maybe just use LNet or Synapse, I'm sure they have some support for it.

  4. Ability to cancel the ongoing download. Add a "cancel" button to CastleWindowProgress for this. See the task below (background downloading) for ideas how to do it.

  5. Ability to download resources in the background, while the game is running. Technically this is connected to the previous point: being able to reliably cancel the download.

     There is a question how to do it. We can use TThread for downloads, maybe even a couple of threads each for a separate download. We can use API that doesn't block (like LNet or Sockets, with Timeout > 0). We can do both.

     Using separate thread(s) for download seems like a good idea, the synchronization is not difficult as the thread needs only to report when it finished work.

     The difficult part is reliably breaking the download. Using something like TThread.Terminate will not do anything good while the thread is hanging waiting for socket data (TThread.Terminate is a graceful way to close the thread, it only works as often as the thread explicitly checks TThread.Terminated). Hacks like Windows.TerminateThread are 1. OS-specific 2. very dirty, as TThread.Execute has no change to release allocated memory and such. The bottom line: merely using TThread does not give you a reliable and clean way to break the thread execution at any time.

     This suggests that you have to use non-blocking API (so LNet or Sockets is the way to go, FpHttpClient and Synapse are useless for this) if you want to reliably break the download. Using it inside a separate thread may still be a good idea, to not hang the main event loop to process downloaded data. So the correct answer seems use LNet/Sockets (not FpHttpClient/Synapse), with non-blocking API, within a TThread; thanks to non-blocking API you can guarantee checking TThread.Terminated at regular intervals.

     I'm no expert in threads and networking, so if anyone has any comments about this (including just comfirming my analysis) please let me (Michalis) know :)

  6. Support X3D LoadSensor node.

  7. Caching on disk of downloaded data. Just like WWW browsers, we should be able to cache resources downloaded from the Internet.

     • Store each resource under a filename in cache directory.
     • For starters, you can use config directory for cache, but that is not adviced long-term, a careful function should be implemented to use good cache directory suitable for each OS (using ProgramDataPath is not good, as it may not be writeable by user account; using the same directory as for config files may not be adviced, e.g. to allow users to backup config without backuping cache; browse freedesktop.org, LSB, Microsoft, Apple specs for good standard ways to calculate a cache directory on Unix, Windows, Mac OS X).
     • Probably it's best to store a resource under a filename calculated by MD5 hash on the URL.
     • For starters, you can just make the max cache life a configurable variable for user. Long-term: Like WWW browsers, we should honor various HTTP headers that say when/how long cache can be considered valid, when we should at least check with server if something changed, when we should just reload the file every time.
     • Regardless of above, a way to reload file forcibly disregarding the cache should be available (like Ctrl+Shift+R in WWW browsers).
     • A setting to control max cache size on disk, with some reasonable default (look at WWW browsers default settings) should be available.

     Note: don't worry about caching in memory, we have this already, for all URLs (local files, data URIs, network resources).

I'm sure you can find other ideas for development. Is there something you miss from our game engine? Is there a particular feature you miss from 3D formats (X3D, Collada etc.) support? Some useful tool, or maybe a useful example?

4. For Blender experts

I think that success of our engine is tightly coupled with the quality of Blender X3D exporter. Of course, you can use anything to generate VRML/X3D for use with our engine. But if you make FOSS game, you have probably already chosen Blender as your main 3D modeller.

Blender is really fantastic. But the current exporter from Blender to X3D lacks some important features. For starters, there isn't any way to export animation to X3D. At least exporting animation of transformations (translation, rotation, scale of objects) would already be very useful. Exporting mesh deformation (from shape keys, or derived from bone animation) would be great. There are also various other small lacks. Many features of VRML/X3D and our engine are not used intensively enough, because there isn't any way to express them and export from Blender.

We have our own customized Blender X3D exporter, so you can start from this. Preferably, changes should be reported and applied to the Blender sources. Only stuff really specific to our engine (cooperation between Blender and some specific features of our engine) should be left inside our custom exporter.

5. For Linux distros package maintainers

Please package view3dscene for your favourite Linux distribution :) It's a great and stable VRML/X3D browser (and viewer for other 3D models, like Collada and 3DS). Some facts in favor of view3dscene, important for package maintainers:

• Stable program, with long development history and regular releases.
• Desktop integration files (SVG icon, .desktop file, MIME xml) are already included in our archive.
• The dependencies of view3dscene are documented. There's nothing weird there (ffmpeg and ImageMagick are only light suggestions; OpenAL may also be a suggestion instead of a recommendation; the rest is standard for any GTK program using OpenGL).
• Build-dependencies of view3dscene include Free Pascal Compiler, but this should not be a problem — all major distros already have fpc packaged.
• Sources of view3dscene are here, get both view3dscene and engine sources, and follow instructions on that page to compile.
• The whole thing is GPL >= 2 (most of the engine may also be used under more permissive "LGPL with static-linking exception" >= 2, but this probably doesn't matter for you).

Michalis uses Debian, and sometimes Ubuntu, and would love to see his software available in your repositories :)