TextOut y value

[afanofosc]

There is already support for this in NXC with the exception that the font height cannot exceed 8 pixels tall. The firmware does not come with any additional built-in fonts but you can create your own fonts (not RIC-based fonts) and use them within your program.

Or you can use RIC-based fonts along with all the different drawing options that the provide that let you do things you cannot do (to my knowledge) in RobotC (unless RobotC has copied the RIC-based font support from the enhanced NBC/NXC firmware).

Last I heard there were only two fonts in RobotC: a fixed width 6x8 (same as standard/enhanced firmwares) and a double size fixed width 12x16 font and that the only way to switch from one to the other was with a different API function (i.e., nxtDisplayStringAt vs nxtDisplayBigStringAt). I haven't kept up on all the latest improvements to RobotC so I could be totally wrong about how many fonts the RobotC firmware now supports.

John Hansen

[HaWe]

maybe I'm wrong since it's a few years since I used it the last time but I think I remember of at least 3 sizes like small, standard, and big.
But anyway what RobotC may have or not - what I mean is, it sounds of a big effort to implement this x,y thing. And in case we once will have it then there will be a lack of different (big) sizes, and smaller ones will still have to be created.
- But why bother if we have much more options using ric fonts where we have different sizes and styles as well as much as we want? )There also will be normally no speed issue for this.)
Usually printing standard chars at any y is finally not that important if we have workarounds like ric fonts which are much more powerful in case we need it if it makes such a big effort for implmentation.

If one would like improve one thing concerning ric fonts: it would be nice to link them (or other grafics) directly into the compiled code (easier for distribution).

[afanofosc]

Doc,

I really do not understand your comments. It was really pretty trivial (i.e., NOT a big effort) to add support for drawing text at any Y value. You already can design any size font you want so long as it is 8 pixels or less tall. There is built-in support for using as many of those fonts as you want with any design that you want. Plus you can always use RIC-based fonts instead if you want to and you aren't worried about the slower speed.

It would be possible to further modify the DrawString function to work with fonts with more than 8 vertical bits of data per character. I'll need to think about it when my head is not filled with cold medicine.

Also, it has long been possible to link RIC-fonts and all RIC graphics, in fact, into an application for easy distribution.

John Hansen

[HaWe]

it was because of one of theses posts that make me assume it's rather complicated...

This should be possible improve this code, but things are much more complicated because bytes are in lines in sprites, but columns on the screen! May be with a lot of scratch registe

...

Also, it has long been possible to link RIC-fonts and all RIC graphics, in fact, into an application for easy distribution.

how can this be done?

[spillerrec]

Also, it has long been possible to link RIC-fonts and all RIC graphics, in fact, into an application for easy distribution.

I know you can use GraphicArrayOut() and convert the RIC file into an array, however I can only find RIC-font functions which takes a filename as parameter, not an array. Is there another way of doing this I haven't heard of?

Btw, I updated RICcreator so that the number opcode behaves like in the new version of the firmware. Not going to release a build until I have some more updates ready, unless anyone wants it.

[afanofosc]

Yeah, I guess I changed the behavior of the NumBox opcode when I added support for drawing text to any Y value. I think it's used rarely enough that it's not likely to cause people too much trouble.

While there is not a DrawFontArray system call like there is a DrawPictureArray system call (which I'd forgotten) a clever person probably could figure out a way around that problem. I think.

I can't test this right at this moment but I think you can CreateFileLinear with the SizeOf the RICfont array variable then a single Write of the font variable followed by a CloseFile on the handle and (maybe) you'll be good to go. You can ArraySize the font variable back to zero if you want to free its memory.

Someone should try that.

John Hansen

[HaWe]

OT: how can this be done? (Maybe I didn't understand the answer if there had been already given one)

...to link RIC-fonts and all RIC graphics ... into an application

what I meant is: without having to have seperate files in the flash (like *.ric), just 1 executable?

[spillerrec]

Yeah, I guess I changed the behavior of the NumBox opcode when I added support for drawing text to any Y value. I think it's used rarely enough that it's not likely to cause people too much trouble.

Yeah, if anything is going to cause trouble it is the fact that TextOut() changed and people had of some reason not used a multiple of 8 as the Y coordinate. ; )

I can't test this right at this moment but I think you can CreateFileLinear with the SizeOf the RICfont array variable then a single Write of the font variable followed by a CloseFile on the handle and (maybe) you'll be good to go.

I tried it out, works fine. It is a bit of a workaround though if you ask me, so it would be more nice to be able to just pass the array.
I guess you could actually just use the same FontTextOut() call and pass the array instead. It is pretty easy to tell whether it is a filename or an array, a RIC-font cannot be smaller than 50 bytes and a filename certainly can't get that long. Or you could look at the first two bytes, the first will always be a non-printable character followed by 0.

what I meant is: without having to have seperate files in the flash (like *.ric), just 1 executable?

This is what John suggested:

Code: Select all

byte fontarr[] =  { 0x48, 0x02, 0x01, 0x00, 0x01, 0x00, 0x08, 0x00, 0x48, 0x00, 0x00, 0x8D, 0x80, 0x43, 0x20, 0x18, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x70, 0x87, 0x1C, 0x13, 0xE3, 0x3E, 0x71, 0xC0, 0x00, 0x10, 0x04, 0x1C, 0x71, 0xCF, 0x1C, 0xF3, 0xEF, 0x9C, 0x89, 0xC0, 0xA2, 0x82, 0x28, 0x9C, 0xF1, 0xCF, 0x1C, 0xFA, 0x28, 0xA2, 0x8A, 0x2F, 0x1C, 0x01, 0xC2, 0x00, 0x20, 0x08, 0x00, 0x08, 0x03, 0x00, 0x80, 0x81, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0C, 0x21, 0x85, 0x02, 0x01, 0xCD, 0x94, 0x73, 0x23, 0x18, 0x40, 0x85, 0x08, 0x00, 0x00, 0x02, 0x89, 0x88, 0xA2, 0x32, 0x04, 0x02, 0x8A, 0x20, 0x00, 0x20, 0x02, 0x22, 0x8A, 0x28, 0xA2, 0x8A, 0x08, 0x22, 0x88, 0x80, 0xA4, 0x83, 0x6C, 0xA2, 0x8A, 0x28, 0xA2, 0x22, 0x28, 0xA2, 0x8A, 0x21, 0x10, 0x80, 0x45, 0x00, 0x50, 0x08, 0x00, 0x08, 0x04, 0x00, 0x80, 0x00, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x10, 0x20, 0x4A, 0x02, 0x01, 0xC9, 0x3E, 0x80, 0x44, 0x10, 0x40, 0x87, 0x08, 0x00, 0x00, 0x04, 0x98, 0x80, 0x82, 0x52, 0x08, 0x04, 0x8A, 0x26, 0x18, 0x43, 0xE1, 0x02, 0xBA, 0x28, 0xA0, 0x8A, 0x08, 0x20, 0x88, 0x80, 0xA8, 0x82, 0xAA, 0xA2, 0x8A, 0x28, 0xA0, 0x22, 0x28, 0xAA, 0x52, 0x22, 0x10, 0x40, 0x48, 0x80, 0x21, 0xCF, 0x1C, 0x79, 0xC4, 0x1E, 0xE0, 0x83, 0x24, 0x23, 0x4E, 0x1C, 0xF1, 0xEB, 0x1C, 0xF2, 0x48, 0xA2, 0x92, 0x4F, 0x10, 0x20, 0x40, 0x02, 0x00, 0x80, 0x14, 0x60, 0x84, 0x00, 0x40, 0x8F, 0xBE, 0x03, 0xE0, 0x08, 0xA8, 0x83, 0x1C, 0x93, 0xCF, 0x08, 0x71, 0xE6, 0x18, 0x80, 0x00, 0x8C, 0xAA, 0x2F, 0x20, 0x8B, 0xCF, 0x2E, 0xF8, 0x80, 0xB0, 0x82, 0x29, 0xA2, 0xF2, 0x2F, 0x1C, 0x22, 0x28, 0xAA, 0x21, 0x44, 0x10, 0x20, 0x40, 0x00, 0x00, 0x28, 0xA2, 0x8A, 0x2F, 0x22, 0x90, 0x81, 0x28, 0x22, 0xA9, 0x20, 0x8A, 0x24, 0xA0, 0x42, 0x48, 0xA2, 0x92, 0x41, 0x30, 0x00, 0x60, 0x04, 0x00, 0x80, 0x14, 0x11, 0x0A, 0x80, 0x40, 0x87, 0x08, 0x00, 0x00, 0x10, 0xC8, 0x84, 0x02, 0xF8, 0x28, 0x90, 0x88, 0x20, 0x00, 0x40, 0x01, 0x08, 0xBB, 0xE8, 0xA0, 0x8A, 0x08, 0x22, 0x88, 0x88, 0xA8, 0x82, 0x28, 0xA2, 0x82, 0xA9, 0x02, 0x22, 0x28, 0xAA, 0x50, 0x88, 0x10, 0x10, 0x40, 0x00, 0x01, 0xE8, 0xA0, 0x8B, 0xC4, 0x22, 0x90, 0x81, 0x30, 0x22, 0xA9, 0x22, 0x8A, 0x24, 0x1C, 0x42, 0x48, 0xAA, 0x62, 0x46, 0x10, 0x20, 0x40, 0x24, 0x00, 0x00, 0x3E, 0xE2, 0x69, 0x00, 0x40, 0x85, 0x08, 0x60, 0x06, 0x20, 0x88, 0x88, 0x22, 0x12, 0x28, 0x90, 0x88, 0x46, 0x18, 0x23, 0xE2, 0x00, 0x82, 0x28, 0xA2, 0x8A, 0x08, 0x22, 0x88, 0x88, 0xA4, 0x82, 0x28, 0xA2, 0x82, 0x48, 0xA2, 0x22, 0x25, 0x2A, 0x88, 0x88, 0x10, 0x08, 0x40, 0x00, 0x02, 0x28, 0xA2, 0x8A, 0x04, 0x1E, 0x90, 0x81, 0x28, 0x22, 0x29, 0x22, 0x8A, 0x24, 0x02, 0x52, 0xC5, 0x3E, 0x91, 0xC8, 0x10, 0x20, 0x40, 0x14, 0x00, 0x80, 0x14, 0x22, 0x66, 0x80, 0x21, 0x00, 0x00, 0x60, 0x06, 0x00, 0x71, 0xCF, 0x9C, 0x11, 0xC7, 0x10, 0x71, 0x86, 0x18, 0x10, 0x04, 0x08, 0x72, 0x2F, 0x1C, 0xF3, 0xE8, 0x1E, 0x89, 0xC7, 0x22, 0xFA, 0x28, 0x9C, 0x81, 0xA8, 0x9C, 0x21, 0xC2, 0x14, 0x88, 0x8F, 0x1C, 0x01, 0xC0, 0x3E, 0x01, 0xEF, 0x1C, 0x79, 0xC4, 0x02, 0x90, 0xC9, 0x24, 0x32, 0x29, 0x1E, 0xF1, 0xEE, 0x1C, 0x21, 0x42, 0x14, 0x90, 0x8F, 0x0C, 0x21, 0x80, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x80, 0x20, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x02, 0x00, 0x02, 0x00, 0x02, 0x00, 0x20, 0x00, 0x00, 0x00, 0x7F, 0x00, 0x3A, 0x02, 0x0E, 0x00, 0x02, 0x00, 0x03, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x63, 0x00, 0x00, 0x00, 0x12, 0x00, 0x02, 0x00, 0x04, 0x00, 0x03, 0x00, 0x1F, 0x00, 0x00, 0x00, 0x20, 0x00, 0x06, 0x00, 0x63, 0x00, 0x06, 0x00, 0x0E, 0x00, 0x02, 0x00, 0x05, 0x00, 0x02, 0x00, 0x20, 0x00, 0x08, 0x00, 0x63, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x01, 0x80, 0x06, 0x00, 0x08, 0x00, 0x12, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x12, 0x00, 0x13, 0x00, 0x14, 0x00, 0x15, 0x00, 0x00, 0x00, 0x00 };

#define FONTNAME "tempfont.ric"

unsigned int LoadFont( byte &arr[], string filename ){
   byte handle;
   unsigned int size = ArrayLen( arr );
   unsigned int result = CreateFileLinear( FONTNAME, size, handle );
   if( result == LDR_SUCCESS ){
      result = Write( handle, arr );
      CloseFile( handle );
   }
   ArrayInit( arr, 0, 0 );
   return result;
}

unsigned int UnloadFont( string filename ){
  return DeleteFile( filename );
}

task main(){
   LoadFont( fontarr, FONTNAME );
   FontTextOut( 0,LCD_LINE1, FONTNAME, "Testing-font", DRAW_OPT_FONT_DIR_T2BL | DRAW_OPT_FONT_WRAP );
   Wait( SEC_5 );
   UnloadFont( FONTNAME );
}

[HaWe]

ok, thank you!
Nevertheless I think I have been misunderstood.

If one would like improve one thing concerning ric fonts: it would be nice to link them (or other grafics) directly into the compiled code (easier for distribution).

I see there's an array which seems to represent a font. But this is extra code inside my code, this is not a linked font file.
But my question was: how to link all font files together with the code to 1 executable?

As I wrote I want to use the *.ric font files I already have (extra files) and which are used by my code (tiny4.ric, tiny5.ric, fixed6ric, sans10.ric).
I now want to link these ric files together with the source code so that I won't need to have overall 5 files for my code to work (1 rxe + 4 ric):
just the way any header files are linked to the main program (by #include) now also the ric files should be linked to the main program (e.g., also by
#include "tiny4.ric"
#include "tiny5.ric"
#include "fixed6ric"
#include "sans10.ric"
or sth similar).
I don't see how this should be already possible as John wrote (at least it wasn't as I tried it the last time for my NN).

But as a workaround (actually not my original question about a ric file linker):
How can one generate of each single .ric file an extra .h header file (containing a specific array) which can be #included?

[spillerrec]

Instead of including a header file you can use the #import directive which converts a file into a byte array. I could have written my code like this:

Code: Select all

#import "ricfile.ric" fontarr

However this would require you to have that RIC file in the same directory as the code file, so I entered it manually so it would be easy to copy into BCC and run it. (I used RICcreator for this, but any decent hex editor has this functionality too. You can use the command line interface in RICcreator to automatize this if you want.)

The example shows that you can use this to only ship one .rxe file which automatically expands itself when you run it and if you want to keep the flash clean you can simply delete them when the program exits. If you clear the arrays after saving them to the flash this should have minimal memory impact on your program.
Does this not solve your problem? If so, what is it exactly you want to achieve and why?