Subject:
|
NXT & RIC
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Fri, 29 Jun 2007 17:31:16 GMT
|
Viewed:
|
22074 times
|
| |
|
|
A while back I wrote part 1 of a 2 part description of the RIC file format on
the Nxtasy blog. I still haven't gotten around to writing part 2 (been busy
writing other stuff) but RIC-related things have been hanging around on the
edges of my attention span for quite a while. I started work on integrating
support for editing RIC files in BricxCC a while back as well as working on a
compiler/decompiler for RIC files that would be able to convert from a
text-based RICScript language into a compiled RIC "program" and back again.
Both projects have been on the back burner for a while.
But late last week week while fixing bugs for NBC/NXC beta 31 as a result of
some great bug reports from Andreas Dreier and Dave Slate I had the RIC spark
lit under me again. Andreas was asking me to look into supporting multiple
images per RIC so that you could somehow pass the index to draw into the
GraphicOut or GraphicOutEx API functions in NXC and it would draw only the
specified image. My initial response to Andreas was along the lines of "sorry
that is not supported and would require a custom firmware". For some reason I
got to thinking about it some more on Wednesday and a little light bulb went on.
Inside the light bulb was some really small writing and it said: You dolt, you
can already do exactly what Andreas wants in NBC/NXC using the standard NXT
firmware!
So I used Andreas' nice nxtRICedit utility (which hopefully soon will be built
into BricxCC in an enhanced version of some sort) to create a small RIC file
called letters.ric. In this file I drew 10 small 10x8 letters in a row. Each
letter was actually 6 or 7 pixels wide but the image grid was 10 pixels wide by
8 pixels tall. I edited this RIC file in a nice little Hex editor
(http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm) and modified a
couple of the values that Andreas' utility writes out in the CopyBits opcode
(described in my NXTasy article). I changed the width value from 96 to be 10
(0x0A). Then I parameterized the x value. The source rectangle in the CopyBits
opcode is normally 0, 0, width, height where width is the full RIC Sprite width.
As mentioned I said I only wanted to Copy a 10 pixel wide rectangle. The
normally hard-coded 0 for the source origin x value was changed from 0 to 4096.
I set the 13th bit to 1.
Setting bit 13 (or any higher bits) tells the standard NXT firmware that the
value "uses args", i.e., that it is parameterized. And what is the value of the
parameter? The parameter value is zero since I did not change any bits in the
low order byte. In the Hex editor the 0x00 0x00 bytes became 0x00 0x10 so that
the word value of x was 0x1000. The standard NXT firmware limits the parameter
value to be 0x0 through 0xF (0..15), i.e., the low order nibble. That's a bug.
It masks the parameter value with 0xF when it should mask it with 0xFF since
both nibbles are unused for either the "uses args" flag or the "var map index"
nibble which is masked with 0x0F00 and shifted right 8 bits. But even 16
possible parameter values is not bad.
So now that the X value of the CopyBits source rectangle was parameterized what
does it mean that its parameter value is zero? What can I do with that?
The value zero means "use the value of the first element in the Variables array
instead of what is in the RIC file". The parameter value, then, is an index
into the Variables array. That means you could pass up to 16 values (using the
standard NXT firmware) into the RIC drawing routine and have them replace values
in the opcodes that are executed from the RIC file. If I change the value in my
Variables array and call GraphicOutEx again then something different will be
drawn, depending on which values I parameterize.
By parameterizing the x source origin value and fixing the width at 10 pixels I
can pass in 0, 10, 20, 30, 40, 50, etc... into different calls to the
GraphicOutEx function via the Variables array (in element zero) and each drawing
operation will CopyBits from (0, 0, 10, 8), (10, 0, 10, 8), (20, 0, 10, 8),
etc... Very cool!
You can do all kinds of cool stuff with multiple Sprites in an RIC file or a
single larger tiled Sprite and a parameterized CopyBits opcode. If you use
multiple Sprites you will need to parameterize the DataAddress field in CopyBits
as well as (possibly) the width and height values in the source rectangle while
if you use a single tiled Sprite you can just parameterize the x and y values in
the CopyBits source rectangle and set the width and height values to the correct
tile dimensions. Then call GraphicOutEx and pass in your array of argument
values with the proper values in the proper locations within your array.
Andreas (I think) is planning to develop an enhanced RIC editor (eventually
built into BricxCC) that supports all the possible drawing opcodes, including
support for value parameterization, Sprite tiling, multiple Sprite opcodes,
etc... And my RICScript compiler & decompiler will let you create fancy
parameterized RIC files via a text-based language.
The NXC code and the sample letters.ric file is at
http://bricxcc.sourceforge.net/nbc/ in the NXC sample programs section. A
similar program written in NBC is also available in the NBC sample programs
section.
Parameterized RIC files are totally cool, imho.
John Hansen
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
