LVL-format corrections & extensions
There is a couple of typos in the PDF file describing LVL format, namely, underscore character '_' is missing of:
• Keyword "Shape" Option "TexTfmID" => "TexTfmID_"
• Keyword "TexTfm" Option "TexTfmID" => "TexTfmID_"
All option-tokens have the character '_' as a terminating symbol (terminal). We can use this fact to extract them from the parsed line (although I would prefer to see the space character as a terminal). This also allows us to use another algorithm to extract option-tokens. Marek uses "find" approach, which means "multipass" algorithm, - one should scan the parsing line N times, where N is the quantity of options for given Keyword. E.g., "Box" has 4 options: "Dep_", "GeoID_", "Hei_" and "Wid_". Thus "multipass" algo scans the line 4 times. Another way to parse the line - "single-pass", when one extracts the tokens from the input stream one by one, and then determines token's type by context and/or using look-up keyword-table. ("Single-pass" approach is usually more efficient etc.)
Note: each of proposed extension is implemented in my version of compiler; therefore they are realizable in principle.
First of all, I reckon that all extensions should be backward compatible, e.g. the parser should be able to read the files in both formats - original and extended.
Another important issue relates to the main property of text-format, namely, it is meant to be human readable and human friendly. Most of my extensions make the LVL format more tolerant towards human errors.
Let's make the LVL-format be more tolerant towards WHITE SPACES (space and tab characters). One can put white-space character to separate any keyword, option-keyword and parameters. Leading spaces should be acceptable as well. For instance, following line should be considered as being correct:
Box GeoID_ 2009 Wid_ 1 Hei_ 2 Dep_ 3
To relieve the task I suggest to add the function SkipWhiteSpaces().
Full fledged C++ style comments support. Yes, it is a good exercise to implement full support of the commenting in your text file:
full support of single-line comment. For example, following lines should be considered as equivalent:
Box GeoID_ 2009 Wid_ 1 Hei_ 2 // Dep_ 3
Box GeoID_ 2009 Wid_ 1 Hei_ 2
full support of multiline C-style comments. A hint - the internal comments of the parsed line could be replaced with spaces, then if you implemented 1) (white-space tolerance) those white spaces will be skipped by the parser.
Box GeoID_ /* 2009 */ 2010 Wid_ 1 /* Hei_ 2 */ Dep_ 3 Hei_ 0.5
could be treated as:
Box GeoID_ 2010 Wid_ 1 Dep_ 3 Hei_ 0.5
Some of the ideas how to handle multi-line comments you can borrow from here
. However, multiline commenting also means that you can start the comment in the middle of some line and then close it in the middle of one of the next lines. Remember also about comment's priority, i.e.:
Box GeoID_ /* 2009 */ 2010 Wid_ 1 /* Hei_ 2 Dep_ 3 Hei_ 0.5
Box GeoID_ /* 2009 2010 Wid_ 1 Hei_ 2 Dep_ 3 Hei_ 0.5
// Grid GeoID_ 2011 */ Box GeoID_ /* 2009 */ 2012 Wid_ 1 Hei_ 2 // Dep_ 3 Hei_ 0.5
Should be treated as:
Box GeoID_ 2010 Wid_ 1
Box GeoID_ 2012 Wid_ 1 Hei_ 2
IOW try to implement all properties of the comments you can find in C++ commenting style.
Add support of the strings with internal spaces. To allow space char in the name, i.e. in option Shape Name_
or Texture File_
, put the name in double quotation marks, like this:
Texture File_ "textures/Spaceship Cafeteria.tga"
For backward compatibility the old format (without quotation marks) should be supported as it had done before.
Multiline strings. If the line is terminated by '\' (back slash) character, then is is considered as multiline and the content of the next line should be concatinated to the current line. Example:
+++ Shape \
GeoID_ 766 \
MatID_ 667 \
Name_ "man of war" \
TexID_ 321 \
This line is convertible to
+++ Shape GeoID_ 555 MatID_ 667 Name_ "man of war" TexID_ 321 TexTfmID_ 123
Add the option Vis_
(visibility) to the Shape
(shape node), similar to Transform Vis_
type = int value, meaning: 0 = invisible, 1 = visible. Default value = 1
See the discussion here
Parsing structure: try to separate the host code (the Parser) and the client part (SceneBuilder). Let the parser passes the parsed lines (in some internal format) one by one to the SceneBuilder. An advantage of this approach is that if you manage to implement this you can later on seamlessly add more and more formats (host parsers), i.e. XML, binary, and any compatible proprietary formats without the necessity to rewrite the code, which creates the scene.
Add rollback feature
The last but not least feature I would propose is the MUTATOR, or the extension applicable to the options' parameters describing some simple linear fluctuations. LVL-code might look like this:
+ Transform Trans_ 0, (0.0 1.0 0.0 0.01), (0.0 -1.0 0 0.03) Axis_ 0 1 0 Angle_ (-90.0 +90.0 0 1)
The format of MUTATOR is (MIN, MAX, CUR, STEP, ID). ID is optional.
As could be seen if one of the parameters of some option is enclosed by round brackets then this parameter has special meaning. This parameter is not just the constant any more, but a value, which fluctuates between MIN and MAX. STEP is the value which is added to CUR value periodically (say each 10 ms). Almost any float point parameters could be mutated by MUTATOR. I used Wink class
as a good helper.
More complete explanation of MUTATORS (with working exe) needs a separate article that I am going to write as soon as possible.