Two large news from engine development:
1. Android games created using our engine now run happily in Android emulator :) You no longer have to spend your money to see your game on that beautiful 10-inch tablet :) https://sourceforge.net/p/castle-engine/wiki/Android%20development/#is-it-possible-to-test-our-games-using-android-emulator-from-sdk is updated.
2. Text node (text inside a 3D or 2D scene) rendering has been completely rewritten in the engine.
(Warning: a lot of technical details about Text rendering follow. Read only if you're curious :)
The old code rendered complex meshes for each letter, using custom OpenGL code. It is now replaced with sleek code that uses font texture, with a single quad for each letter, by generating a QuadSet for each Text node.
The new implementation has many advantages:
- It's much more efficient. Long text will not kill your framerate anymore.
- It uses the font information from TTextureFont, the same font class used for 2D fonts in TCastleFont. This means that we have simpler code in the engine. No need to deal with separate concept of "outline fonts".
- Rendering works on OpenGLES (Android, iOS) too.
- Rendering works with all modern features: shaders and multitexturing and shadow maps etc. It just goes through our standard renderer pipeline. No more ancient tricks with display lists and GLU tesselator.
- The implementation merely converts Text node to QuadSet underneath (or IndexedFaceSet, for VRML 1.0 or OpenGLES). This makes it much simpler to extend Text/FontStyle implementation.
- Ugly Windows-only outlinefont2pascal program disappears. New fonts information are inside TTextureFontData, which is extracted using TTextureFont and texturefont2pascal cross-platform utilities (based on FreeType).
- Adding extra textures on Text node now works better, you can use Text.texCoord to specify a TextureCoordinateGenerator for them, and text can even be a normal shadow map receiver. See http://castle-engine.sourceforge.net/x3d_implementation_texturing_extensions.php#section_ext_tex_coord
And some disadvantages:
- Font may look bad from very close distance. (Although we will fight with that using http://code.google.com/p/libgdx/wiki/DistanceFieldFonts in the future.)
- Text3D extension node does not make sense anymore (we depend on texture alpha channel to make mesh invisible, so it's not easily possible to render Text3D sides), and right now it just uses flat Text rendering. See http://castle-engine.sourceforge.net/x3d_implementation_text_extensions.php#section_ext_text3d
- Since the font is now rendered using a texture, a usual tradeoff between alpha blending and alpha test occurs: http://castle-engine.sourceforge.net/x3d_implementation_text_extensions.php#section_ext_fontstyle_blending
- VRML 1.0 text with explicit textures is no longer supported. Since the text is now rendered through proxy (converting Text node to QuadSet (VRML 2.0, X3D) / IndexedFaceSet (VRML 1.0) node), and VRML 1.0 doesn't support MultiTextureCoordinate, it is not possible to support in VRML 1.0 an AsciiText node with extra texture (as it would require MultiTextureCoordinate with 2 texture slots --- for font texture and for custom texture).
1. Android games created using our engine now run happily in Android emulator :) You no longer have to spend your money to see your game on that beautiful 10-inch tablet :) https://sourceforge.net/p/castle-engine/wiki/Android%20development/#is-it-possible-to-test-our-games-using-android-emulator-from-sdk is updated.
2. Text node (text inside a 3D or 2D scene) rendering has been completely rewritten in the engine.
(Warning: a lot of technical details about Text rendering follow. Read only if you're curious :)
The old code rendered complex meshes for each letter, using custom OpenGL code. It is now replaced with sleek code that uses font texture, with a single quad for each letter, by generating a QuadSet for each Text node.
The new implementation has many advantages:
- It's much more efficient. Long text will not kill your framerate anymore.
- It uses the font information from TTextureFont, the same font class used for 2D fonts in TCastleFont. This means that we have simpler code in the engine. No need to deal with separate concept of "outline fonts".
- Rendering works on OpenGLES (Android, iOS) too.
- Rendering works with all modern features: shaders and multitexturing and shadow maps etc. It just goes through our standard renderer pipeline. No more ancient tricks with display lists and GLU tesselator.
- The implementation merely converts Text node to QuadSet underneath (or IndexedFaceSet, for VRML 1.0 or OpenGLES). This makes it much simpler to extend Text/FontStyle implementation.
- Ugly Windows-only outlinefont2pascal program disappears. New fonts information are inside TTextureFontData, which is extracted using TTextureFont and texturefont2pascal cross-platform utilities (based on FreeType).
- Adding extra textures on Text node now works better, you can use Text.texCoord to specify a TextureCoordinateGenerator for them, and text can even be a normal shadow map receiver. See http://castle-engine.sourceforge.net/x3d_implementation_texturing_extensions.php#section_ext_tex_coord
And some disadvantages:
- Font may look bad from very close distance. (Although we will fight with that using http://code.google.com/p/libgdx/wiki/DistanceFieldFonts in the future.)
- Text3D extension node does not make sense anymore (we depend on texture alpha channel to make mesh invisible, so it's not easily possible to render Text3D sides), and right now it just uses flat Text rendering. See http://castle-engine.sourceforge.net/x3d_implementation_text_extensions.php#section_ext_text3d
- Since the font is now rendered using a texture, a usual tradeoff between alpha blending and alpha test occurs: http://castle-engine.sourceforge.net/x3d_implementation_text_extensions.php#section_ext_fontstyle_blending
- VRML 1.0 text with explicit textures is no longer supported. Since the text is now rendered through proxy (converting Text node to QuadSet (VRML 2.0, X3D) / IndexedFaceSet (VRML 1.0) node), and VRML 1.0 doesn't support MultiTextureCoordinate, it is not possible to support in VRML 1.0 an AsciiText node with extra texture (as it would require MultiTextureCoordinate with 2 texture slots --- for font texture and for custom texture).
