Problem/Bug:
------------
There were no way to have proper unicode characters (e.g. Japanese) in Blender Game Engine. Now we can :)
You can see a sample here: http://blog.mikepan.com/multi-language-support-in-blender/
Functionality Explanation:
--------------------------
This patch converts the Blender Font Objects to a new BGE type: KX_FontObject
This object inherits KX_GameObject.cpp and has the following properties:
- text (the text of the object)
- size (taken from the Blender object, usually is 1.0)
- resolution (1.0 by default, maybe not really needed, but at least for debugging/the time being it's nice to have)
The way we deal with linked objects is different than Blender. In Blender the text and size are a property of the Text databock. Therefore linked objects necessarily share the same text (and size, although the size of the object datablock affects that too). In BGE they are stored and accessed per object. Without that it would be problematic to have addObject adding texts that don't share the same data.
Known problems/limitations/ToDo:
--------------------------------
1) support for packed font and the <builtin>
2) figure why some fonts are displayed in a different size in 3DView/BGE (BLF)
3) investigate some glitches I see some times
4) support for multiline
5) support for more Blender Font Object options (text aligment, text boxes, ...)
[1] Diego (bdiego) evantually will help on that. For the time being we are using the "default" (ui) font to replace the <builtin>.
[2] but not all of them. I need to cross check who is calculating the size/dpi in/correctly - Blender or BLF. (e.g. fonts that work well - MS Gothic)
[3] I think this may be related to the resolution we are drawing the font
[4] It can't/will not be handled inside BFL. So the way I see it is to implement a mini text library/api that works as a middlelayer between the drawing step and BLF.
So instead of:
BLF_draw(fontid, (char *)text, strlen(text));
We would do:
MAGIC_ROUTINE_IM_NOT_BLF_draw(fontir, (char *)text, styleflag, width, height);
[5] don't hold your breath ... but if someone wants to have fun in the holidays the (4) and (5) are part of the same problem.
Code Explanation:
-----------------
The patch should be simple to read. They are three may parts:
1) BL_BlenderDataConversion.cpp:: converts the OB_FONT object into a KX_FontObject.cpp and store it in the KX_Scene->m_fonts
2) KetsjiEngine.cpp::RenderFonts:: loop through the texts and call their internal drawing routine.
3) KX_FontObject.cpp::
a) constructor: load the font of the object, and store other values.
b) DrawText: calculate the aspect for the given size (sounds hacky but this is how blf works) and call the render routine in RenderTools
4) KX_BlenderGL.cpp (called from rendertools) ::BL_print_game_line:: Draws the text. Using the BLF API
*) In order to handle visibility of the object added with AddObject I'm adding to the m_scene.m_fonts list only the Fonts in a visible layer - unlike Cameras and Lamps where all the objects are added.
Acknowledgements:
----------------
Thanks Benoit for the review and adjustment suggestions.
Thanks Diego for the BFL expertise, patches and support (Latin community ftw)
Thanks my boss for letting me do part of this patch during work time. Good thing we are starting a project in a partnership with a Japanese Foundation and eventual will need unicode in BGE :) for more details on that - www.nereusprogram.org - let's call it the main sponsor of this "bug feature" ;)
In windows this was producing Linking dependence errors because we have BLF_api.h in the /blenfont/ and blf_api.h in /python/generic/. It doesn't produces crash out of the box but I was trying to link both "api" files to the same project (Ketjsi folder). For the linking order was determining what header to use. A workaround is to "include" the file using some ../../ relative folder. But renaming it is less error prone.
Probably Ketsji folder shouldn't link to BLF_api.h anyways, but this is something I will look better later before another commit. In the mean time it's not a good idea to have 2 api files with the same name (for non case-sensitive systems).
from the tracker:
"""The required functionality is provided by the localOrientation property: setting this value will change the dynamic object orientation. This is because dynamic object have no parent and thus the local and world orientation are identical. However, setting worldOrientation will only change the scenegraph node, which has no effect as the physics controller will reset the orientation on next physics synchronization."""
This is a bug as old as the ability to change the actuator values through Python.
For the records: although Blender supports floats as frame values BGE doesn't. It could but it doesn't. So only integers (longs) will be valid start/end frames.
- Exceptions from reading vector values in the game engine where not being caught.
- Also wrote specific KX_GameObject exceptions, without these the errors are quite confusing.
- Object actuator rotation was being scaled by: (1/0.02)*2*PI/360 == 0.872, since revision 2.
- Remove scaling and use do_versions to adjust existing files.
we were using SENSOR_RAY for the radar sensor axis. However the Ray axis is inverted (God knows why) so I created a set of defines only for radar sensor.
Also I thought it was a good idea to replace some hardcoded values in Radar and Ray codes by their defines in DNA_sensor_types.h (similar to what Benoit did for Armature Sensor, so I see no problem on that).
Here is a image of it in action:
http://www.pasteall.org/pic/show.php?id=6351
What it monitors:
* VRAM used by textures created via bf_gpu and BL_Textures
What it does not monitor:
* VRAM used by the Blender ui
* VRAM used by 2d filters
* VRAM allocated by the user via KX_Scene.pre_draw and KX_Scene.pre_draw
- incorrect range check broke ZYX euler rotations, use MIN/MAX constants so this doesn't happen again.
- BGE Armature PyAPI also wasn't using correct min/max with rotation modes.
- clamp on file read rather then when calling the rotation functions, so developers don't use invalid args without realizing it.
- added assert() checks for debug builds so invalid axis constants don't slip through.
* Built-in filters were not being analyzed, which means no depth or luminance textures for them
* Removed an unnecessary if that becomes really hairy when new built-in filters are added (ie, when filters are defined beyond the value used for custom filters)
having the blend file as a part of the __file__ variable is not essential, this is fixed in python 3.2 so add an ifdef and don't use the blend file path for py older then 3.2.
Simple python benchmark shows this to be about 3x faster in the case where an update isn't needed.
This also speeds up rna function argument parsing, since each arg in a function call did 2 string lookups on the context which were never needed.
running a shape actuator on a softbody would crash because it assumed the deformer was a BL_MeshDeformer.
Added TODO note, since it would be nice if softbody would work with shape keys too.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
Both stored the filename of the blend file, but G.sce stored the last opened file.
This will make blender act differently in some cases since a relative path to the last opened file will no longer resolve (which is correct IMHO since that file isnt open and the path might not even be valid anymore).
Tested linking with durian files and rendering to relative paths when no files is loaded however we may need to have some operators give an error if they are used on the default startup.blend.
- omit render code from this warning (cmake only), until render branch is merged.
- moved -Wunused-parameter warning to apply to all C code in blender (not just ./source/blender), (cmake only).
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
- made interface, windowmanager, readfile build without unused warnings.
- re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
First commit to make some structure in doc/ directory.
- moved source/blender/python/doc -> doc/python_api
- moved source/gameengine/PyDoc/*.rst -> doc/python_api/rst
- modified accordingly sphinx_doc_gen.py and sphinx_doc_gen.sh
(later on I'll try alternative/ scripts by neXyon as promised :)
- source/gameengine/PyDoc/ is still there because contains epydoc stuff for the bge, will ask more and look into it later
