Mindboards

I have started writing a library which goal is to be able to read, edit, visualize and save RIC files. (No specific reason for doing it, I have just gotten an interest in file formats and RIC files are pretty neat.)
So far reading and saving seems to work (i.e. I have fixed the bugs I have found so far), so I'm starting to try to visualize it correctly.

A couple questions based on set limitations in nxtRICeditV2:

• Why only 10 IDs to use for Sprites and VarMaps? I could understand 15, but 10? (But this is really the biggest limitation of RIC files imo.)
• Why are parameters limited to contain numbers from 0 to 255 while you use int as datatype in NXC?
• How does the Options element work? The nxtRICedit documentation says that it only has an effect in NXT-G, but RIC fonts use it and are affected by it.
• Why does VarMap allow Range up to 65535? Being able to affect the VarMap with parameters could be fun. (Though I suspect that linking to other VarMaps would be dangerous.) (Hmm, perhaps you can set a value that uses the VarMap to suddenly use a different parameter or perhaps VarMap?)

On a side note, is QT worth looking into to make GUIs?

spillerrec wrote:

• Why only 10 IDs to use for Sprites and VarMaps? I could understand 15, but 10? (But this is really the biggest limitation of RIC files imo.)

The range of values is limited to 10, but you can reuse the numeric values for a sprite or varmap within the RIC file, so it is entirely possible to have more than 10 entries. A reference to a varmap or sprite will find the most recent definition in the file relative to the current command being decoded.

And, yes, RIC files are pretty neat!

Ron.

spillerrec wrote:

• How does the Options element work? The nxtRICedit documentation says that it only has an effect in NXT-G, but RIC fonts use it and are affected by it.

I'm pretty sure that the options element is used by NXT-G to make the preview block of the RIC file.

If the options element is used by RIC fonts then maybe John (in the enhanced firmware) has made use of these field parameters to define the height and width of the characters in the font?

Ron.

The Description opcode is how you "call" the RIC-based Font drawing routine in an RIC file with the enhanced NBC/NXC firmware. It is a no-op opcode except for within the LEGO MINDSTORMS NXT software for previewing a simple RIC file in the Display block's configuration panel. I believe that the preview uses the Width and Height fields of the Description opcode but not the Options field.

In the enhanced NBC/NXC firmware if the Options field of the Description opcode is equal to DESC_FONTOUT (0x8001) then it calls the cCmdDrawFont function to draw the text using the sprite with ID == 1. The Description opcode's Width and Height fields are used as the font's standard character width and height.

Andreas Dreier is working on a cross platform version of nxtRICeditV2 so I am not sure I see the point to reinventing the wheel for a third time. Nobody understands the format better than Andreas.

I don't understand what you mean by parameters being limited to numbers from 0 to 255. I don't think that is the case (if you mean parameter values that can be passed into RIC files via the GraphicOutEx API function). The type of the image variables array is signed long. You can have 256 entries in the variables array simply because of the way that values in the various opcodes are masked/encoded as parameterized rather than hard-coded values.
So each value (such as the x coordinate of the first point of a line opcode) is decoded to see if it is parameterized or not using these macros. This allows for a hard-coded value of up to 4095. If the value is encoded as a parameterized value then you have the 0xF00 bits used to determine what the VarMap index is (if any) and then you have the 0xFF bits to specify the index into the variables array. The standard firmware uses 0x000F instead of 0x00FF so it can only accept 16 values in the variables array.

The nxtRICedit documentation link you refer to is talking about the Description opcode which it calls the Information element. The reference to "only used by NXT-G" is talking about the entire Information element (aka Description opcode) and not the Options field within that opcode. Technically, if you set the Options field of the Information element to 0x8001 then it is no longer an Information element but a DrawFont element (or opcode) instead (with the enhanced NBC/NXC firmware, anyway).

I don't really understand your questions about VarMaps. You can't parameterize the output of a VarMap (i.e., link or chain multiple VarMaps together). You could have a really big sprite that has data way out at x = 65530 and need to draw that part of the sprite image on the screen so the output or Range of a VarMap is an unsigned word (0..65535). Large VarMap output values would not be so useful when drawing lines, points, rectangles, circles, ellipses, or polygons.

John Hansen

ronmcrae wrote:The range of values is limited to 10, but you can reuse the numeric values for a sprite or varmap within the RIC file, so it is entirely possible to have more than 10 entries. A reference to a varmap or sprite will find the most recent definition in the file relative to the current command being decoded.

I would have never thought about that, thanks for telling.

afanofosc wrote:Andreas Dreier is working on a cross platform version of nxtRICeditV2 so I am not sure I see the point to reinventing the wheel for a third time. Nobody understands the format better than Andreas.

As I said, no specific reason. So it is mostly for the fun of it. It is also a great way of getting to know the format better.
I hadn't heard that a new version of nxtRICedit is in the works though. Hopefully some of the annoying things in the program will be changed now : )
But anyway, I'm on a programming course at school. At the end of the course you will have to make a program of you own choice; I could always just use this project and then only have to use time on the presentation. (Which will also mean that I'm reluctant to release any code for any project that might be used for that for the next 9 months or so...)

afanofosc wrote:I don't understand what you mean by parameters being limited to numbers from 0 to 255. I don't think that is the case ...

I just got some stuff mixed up, I somehow misunderstood the "Parameters (0...255)" label above the parameters to refer to the range of each parameter instead of how many parameters there where... -__-

afanofosc wrote:I don't really understand your questions about VarMaps. You can't parameterize the output of a VarMap (i.e., link or chain multiple VarMaps together). You could have a really big sprite that has data way out at x = 65530 and need to draw that part of the sprite image on the screen so the output or Range of a VarMap is an unsigned word (0..65535). Large VarMap output values would not be so useful when drawing lines, points, rectangles, circles, ellipses, or polygons.

I'm just wondering why VarMaps allow the use of all the 16bits instead of allowing parameters or something like that... As you said yourself, that large output values aren't useful anyway...

Thanks for the info.

spillerrec wrote:I hadn't heard that a new version of nxtRICedit is in the works though. Hopefully some of the annoying things in the program will be changed now : )

I've been waiting for over an year... -_-

spillerrec wrote:But anyway, I'm on a programming course at school. At the end of the course you will have to make a program of you own choice; I could always just use this project and then only have to use time on the presentation. (Which will also mean that I'm reluctant to release any code for any project that might be used for that for the next 9 months or so...)

Will you post the code once you're confident that it will be of no use to any of your programming adversaries? I could use it in SCR_File_Lib. I don't think the GraphicArrayOut[Ex]() would work. (The original GraphicOut() doesn't work.) Maybe if I used popup memory... But would that mean that the display screen would have to temporarily switch to popup memory every time I want to read/write to it (using GraphicArrayOut and other API)?

muntoo wrote:

spillerrec wrote:I hadn't heard that a new version of nxtRICedit is in the works though. Hopefully some of the annoying things in the program will be changed now : )

I've been waiting for over an year... -_-

: \
(I can't make a GUI anyway, at least not anything good...)

muntoo wrote:Will you post the code once you're confident that it will be of no use to any of your programming adversaries? I could use it in SCR_File_Lib. I don't think the GraphicArrayOut[Ex]() would work. (The original GraphicOut() doesn't work.) Maybe if I used popup memory... But would that mean that the display screen would have to temporarily switch to popup memory every time I want to read/write to it (using GraphicArrayOut and other API)?

I will. However keep in mind that it is written in C++ and intended for use on a normal PC. So lots of pointers and classes with a bit of polymorphism, porting it to NXC would be a pain...
However the .ric format is not that hard to figure out. With an hex editor, nxtricEditV2 and the NXC API (section about ric macros) it took me less than a day to get a program that could read a whole .ric file into memory.

On a side note, is QT worth looking into to make GUIs?

(I can't make a GUI anyway, at least not anything good...)

What is QT? I'm making a gui for an OS right now, I would love to help.

- Stryker

stryker001 wrote:What is QT? I'm making a gui for an OS right now, I would love to help.

Check out http://en.wikipedia.org/wiki/Qt_(framework) for loads of info. I've programmed in Qt in the past and it's a lot nicer than GTK, IMHO. Mind you, this was about 6 years ago or so. KDevelop is what I used to make the applications. The KDE libraries are very nice and sit on top of the Qt framework. Think of Qt as the walls and floors of your house and KDE as the hinges, door knobs, kitchen and bathroom decorations, devices and stuff. While it is possible to do everything with Qt, you will find yourself dealing with a lot of low level stuff that is taken care of very nicely by the higher up KDE libraries.

- Xander