Not really having done anything on my NXT-RPG game in a half year, I have now finally fixed some bugs in the word-wrapping code.

Word wrapping.nxc – version 0.5

Summery: Draws a text string on the NXT display, but will continue on the next line if the string is too long. This is done without breaking a word into two halves, it only breaks the string at spaces, preventing awkward looking text. Tabs are also handled correctly.
A custom made ricfont with variable width is used. The font is 8 pixels high (7px above the baseline, 1px beneath) and have a default width of 5 pixels.

Requirements: Enhanced firmware 1.28 (because of FontTextOut()) and the file “ASCII_7px.ric” present on the NXT.

Changes in this version

I had left a rather serious bug in the previous version which caused it to frequently break the string at wrong places.

The most significant change is the speed. I have optimized it in a few places which results the example string (in the screenshot) now only takes 76 msec to compile and render where it preciously took 109 msec. An improvement of about ~30% and the method to archive this was nothing special. I manually converted to if and one for statements at crucial places to NBC code instead of letting the NXC compiler do it. It is not an assembler optimization, I just do want the compiler should have done but fails to do properly (in terms of efficiency).
30% slower because of bad compilation… -__-

“All LDraw files are plain text based. A specific character set encoding (UTF-8, ISO-LATIN1, US-ASCII7, etc) is not defined and software authors are free to use whatever encoding is appropriate for their target platform(s).”

I really don’t think it is a good idea not to specify any restrains on the character encoding. Just imagine a parser expecting ISO-LATIN1 getting a file encoding in UTF-16… But a file encoded in UTF-8 with BOM can be enough to cause parsing errors. My suggestion would be to enforce ASCII (8-bit) compatible character encodings and recommend UTF-8 (without BOM) if ASCII isn’t sufficient. What about newlines? For better “cross-platform portability” it should be defined which ways of defining newlines are allowed (in order to make sure parsers support them). Because if the parser doesn’t detect the newlines properly, it can’t read the file at all…

The whitespace characters allowed for keyword and parameter separation include spaces and tabs.

“0 // <comment>”, whitespace is required between “//” and the comment? (I guess I’m just not used to having whitespace there…) “<META command> is any string in all caps”, may there appear whitespace in the command? In an example in “Adding New META Commands” there is: “0 !LDPARSER EXAMPLE”, however I prefer that whitespace is not allowed as it makes separating the command from the parameters easier.

Many of the original commands are described by how they affect the original LDraw program and in my opinion this doesn’t belong in a spec for the file format. It should focus on the intended purpose instead of describing an implementation. The “LDraw.org Official Library Header Specification” seems to describe how to describe a file with meta-commands in order to include it in the official library, it doesn’t really specify the commands. Yet this document is the only documentation for several commands… On a side note, “0 Name: Filename.dat” and “0 Author: RealName [UserName]” are both not written in uppercase entirely and include a ‘:’ before the whitespace though this isn’t included in “List of Official META Commands”? According to the spec it can surely not be a META command since it isn’t in uppercase, but the LDraw team apparently treats it like that anyway?