Nov 06 2011

## RICcreator – October update

Category: Lego,Mindstorms,RICcreator,SoftwareSpiller @ 00:34

Focus this time has been mostly on sprite creation/editing, with a few nice additions.

### Polygon enhancements

The last missing piece in the drawing routine was fill_shape in PolyOut(), which has now been implemented. Here is an example:

Originally I planned on just using the code from the firmware however when I did so I noticed that the polygons didn’t look quite as good as I expected. The code which the firmware implementation was based on was both poorly implemented and flawed, so both the firmware and RICcreator ended up having the same issues.

So I spend some time on fixing up on those issues and modifying the algorithm to fix the flaws. This also means that the output isn’t exactly as on the NXT until is fixed there. I will write a full post about this later, when I’m done fixing a XOR issue with unfilled polygons which is also apparent in the firmware.

### Sprite Editor

Sprites are no longer created at 100×64, you start out with an empty sprite like in nxtRICedit now. It is a minor thing but still rather important anyway.

I have also fixed up the scrollbars a bit. Still not perfect, but a lot better than before. A reset button has also been added in the corner.

### Image importing

I have added a third way to convert images to 2 colors, Floyd–Steinberg dithering. While dithering in most cases look quite neat, it is not that useful when used on the NXT screen. The resolution is simply too small in most cases, making it difficult to see what it actually is. It does work well on some images occasionally, so experiment!

Dithering, Global thresholding and Adaptive  thresholding now also takes gamma in account. Almost every image on the web is encoded in sRGB which defines power of a RGB value. 0 means black, 255 means  completely white. The value for 50% black, 50% white however is ~187 and not 127. I might write a full post about this later.

Another enhancement is that adaptive thresholding have been greatly optimized. Actually, I just cache some results, however this meant that the complexity was reduced from O( n^2 ) to O( 2n ) where n is the size parameter. Before a size of 30 would be quite slow, now you can use 99 without even notice any slowdown.

Please delete any settings.xml files from previous versions.

Revision 154 win32: RICcreator rev. 154 – win32.zip

Revision 153 source: RICcreator rev. 153 – src.zip

The source version also includes test and example .ric files. (The reason it is one revision older is that I forgot to add some .dll´s in the Windows build which takes care of image loading.)

Oct 12 2011

## MainWindow vs. Editor

Category: Lego,Mindstorms,RICcreator,SoftwareSpiller @ 21:24

RICcreator is a MDI application which is implemented by using tabs. Because tabs are used, only one document is viewed at a time.

Up to this point it was implemented using QTabWidget which provides tabs and a area on each tab to place widgets in. Using this, a editor (ricfile_widget) was created on each tab which each owned a ricfile.

When a user clicked on an action in the menus or toolbars, this action had to be routed to the editor currently shown. Since there are about 10-15 commands which deals with the ricfile, 10-15 wrapper functions had to exist in the MainWindow with 10-15 actual implantations in the editor. There were mainly two types of actions, open/save/export actions and actions which added a specific object.

The open/save/export actions are useful no matter which editor you are currently using, while the “add polygon” action is pretty useless when using an editor for modifying RIC fonts. (Not implemented) The goal was therefore to keep the implementations for open/save/export in MainWindow while removing all the other actions from MainWindow and keeping them strictly in ricfile_widget.

### Design

Instead of having the QTabWidget manage the editor for us, we make MainWindow keep track of it instead. Secondly we change the ownership of ricfiles to the MainWindow. To do this we make a class which keep track of a ricfile which contains the information needed. The class (openRicfile) contains the following information:

• The ricfile
• The ricfile editor which is used to edit this file.
• The name of the file
• The file edit state, has the file been changed since it was loaded?

Since MainWindow now owns the ricfile and the required information about it to save/export the file, the actions can now be directly implemented here.

To make it possible to create different editors, we create an interface between the MainWindow and editor. As open/save/export is now done by MainWindow and that every other command was editor specific the interface must not contain any of these. To still be able to have editor specific commands in MainWindow we allow the editor to create a Toolbar which the MainWindow will shown.

In return we add a requiriment to the editor, it must be able to change the active ricfile. The interface (ricfileEditor) have the following properties:

• Change the ricfile to be edited by specifying a openRicfile.
• Request a toolbar to be shown
• Signal which tells MainWindow when openRicfile as been edited.

### Implementation

Instead of using a QTabWidget, a QTabBar is used instead. QTabBar only shows the tabs, it does not create a space to hold widgets. However we get slightly more control over the tabs appearance. But now that an editor can change file, we only need one for each type and therefore not a separate space.

In openRicfile we therefore only save the editor type for each file. So openRicfile instead keeps an list of implemented editors. When we request a editor, it will return the editor specified by the openRicfile. (Editors will only be created on request to preserve resources.) But since there is only one editor, we will need to store information about how the file was viewed in the editor, as this is lost when changing file. I still need to implement this, but it will just be an extra field in openRicfile containing the required information.

All the “Add [object]” actions have been implemented as a Toolbar in ricfile_widget, so MainWindow is now completely free of them, it just changes the shown toolbar whenever a new editor is to be shown.

### Results

MainWindow and ricfile_widget is now much cleaner implemented as it doesn’t contain functions which is half implemented in MainWindow and half implemented in ricfile_widget.

Secondly it is now possible add new editors quite easily and there is an way of adding actions to be shown in the MainWindow.

A side effect is that memory use has dropped greatly. ricfile_widget used about 600KB of RAM, so after opening 10 files you had doubled the memory use of the program. Now it only increases with a few KB for each file. (This is an empty file however, haven’t quite tested it with large files, but it shouldn’t be too much nevertheless.)

Another side effect is that since QTabBar is now used, it is possible to specify the text color of each tab individually. So a file which have been edited and not saved yet is highlighted by changing the color to red and adding an asterisk to the end:

RICcreator rev. 133 – win32

Sep 28 2011

## RICcreator – September update

Category: Lego,Mindstorms,RICcreator,SoftwareSpiller @ 17:56

Not much have happened on the SVN repository, this is the pain of not having an Internet connection and not being able to do local commits with SVN…

### Overview:

2. VarMaps and Polygons
3. Command line improvements

A huge update has been made to nxtCanvas which emulates the NXT screen. And offset to the drawing commands have been added, so instead of always assuming the lower left corner to be (0,0) it can be anywhere on the canvas.

It is not intended to be changed manually however. The reason for adding this is because you get some ugly side effects when automatic resizing of the canvas is turned on. If you use PointOut(-1,-1) with automatic resizing turned on, the canvas is expanded and the point is drawn at (0,0). However if you do this a second time, PointOut(-1,-1) will point to another pixel than the previous call which might not be desireable.

However a more serious issue was in the editing GUI for nxtCanvas. If you for example tries to draw a line it shows a preview before actually drawing it. When you move the cursor outside the canvas it automatically resizes. However if you moved the cursor to a negative coordinate it would still keep the canvas in the same place. If you tried to draw a line to (-10,-10) this command might have been issued 5-10 times because of the live preview, causing the canvas to be rapidly expanded. Because of this the live preview has until now had automatic resizing turned off, only turning it on just before the user stopped drawing.

While this is finally working as intended now, adding that offset was a pain since it caused pretty much everything drawing related to break.

### VarMaps and Polygons

VarMaps have been implemented for a long time, however it didn’t have an editable GUI. And since this is one of the most important elements, RICcreator have been pretty much useless so far. The reason that I didn’t add it until now was that I was not satisfied with the way it is implemented in nxtRICeditv2 and wanted to do this differently. However I didn’t get any ideas on how to improve it so in the end I just implemented a similar design.

VarMaps and Polygons have been implemented using the same datatype in RICcreator, so the GUI for them both is the same.

With this done, RICcreator now supports editing every RIC opcode in the enhanced firmware. Only thing lacking now is implementing fill_shape for polygon and the special copy options for RIC fonts.

### Command line improvements

RICcreator supported one parameter, a filepath to a RIC file to open. You can now open several files at a time by specifying more than one filepath.

A completely new addition is converting files through the command line. By using the “-convert” parameter you can convert RIC files to PNG. It is used like this:

RICcreator -convert FROM_FORMAT TO_FORMAT filepath

If you want to convert “circles.ric” to png you use it like this:

RICcreator -convert RIC PNG circles.ric

This will create “circles.ric.png” in the same folder as “circles.ric”.

Formats are:

• RIC: ricfile, can be used for both input and output
• PNG: PNG image, only output
• C: C header file, only output

RICScript will be added when implemented. Currently conversion is done with all RIC parameters set to 0, if anyone have a good idea to how these could written on the command line speak up!

A note on the PNG export using the command line is that the nxtCanvas is set to 0x0 and then every draw command resizes the canvas to fit everything. So the resulting PNG will not be 100×64, it will be sized to contain everything drawn and the (0,0) point.

Thanks to the material Linus from Mindboards gave me I have now implemented adaptive thresholding in the import image dialog. I have written the algorithm myself so it is a bit slow right now.

The improvement with using adaptive thresholding instead of global ranges from almost nothing to quite a bit. However it is more difficult to get good results with it so for now global thresholding is default.

Global thresholding to the left, adaptive thresholding to the right

It is now possible to load a RIC file from an array internally. This makes RIC loading much more flexible. I cover this more deeply in another post though. The most noticeable change this made for RICcreator is that the default RIC font is now embedded into the program and that it is possible to convert the file into a C header.

Pre-Alpha revision 130: RICcreator rev. 130 – win32.zip

Sep 28 2011

Category: Lego,Mindstorms,RICcreator,SoftwareSpiller @ 17:48

riclib have until now read RIC files directly from a file stream. This is done using a distributed approach, each nxtVariable is passed a file stream pointer and loads the data it needs by itself.

Adding a second source to read from would require an extra read command to be added for each nxtVariable which would be a lot of work.

A file can easily be converted into a char array, so I could just drop direct file reading and rewrite every function to read from a char array instead. Actually, I should have done this from the start. (I didn’t because this would require 3 paramters to be passed each time, the char pointer, the current position in the array and the total lenght of the array.)

I decided of some reason to do a more complicated approach. I added a abstract base class nxtIO which is used by nxtVariable to read and write to RIC files. I have then added to classes which inherits nxtIO, nxtFile which implements file IO and nxtStream which implements IO on a char array. The advantages of doing it like this is that I only need to pass one parameter, the nxtIO pointer, and that it is possible to add several other types of IO without redoing the reading functions in nxtVariable. The disadvantage is that it is more work and that I probably will not need to be able to read/write from anything else than char arrays anyway…

### The reason behind using byte streams

One of the key goals with riclib and the reason it is keept seperate from the GUI code is that it should be easy to use it to extend other applications to use RIC files. However since it needed a RIC file containing the font to use with TextOut to be located together with the exe this could complicate matters for the application developer.

So one of the key benifits with reading from a byte stream is that a RIC file can be embedded into the exe. IO to a byte stream can be used in the other direction too, in order to create a C header file containing a RIC file to easily embed the RIC file into C/C++/NXC programs. (quick implementation done)

Another important reason is that when you use riclib in other applications you might not be able to read/write directly from/to a file. Consider that you want to upload and download RIC files to the NXT. The interface functions will undoubtly use byte streams instead of files. (I will add this feature as soon I as can figure out how to do it.)

Another case would be using riclib together with the Windows Shell. Once I figure out how to create a COM module I’m planning to add RIC support into Windows Explorer. While supported, Microsoft discourages using filepaths and suggests accepting and using bytestreams instead.

#### Example

I’m currently creating an image viewer using QT. QT already supports most image formats like JPG, PNG, BMP, SVG and more, but allows you to create plugins to implement special fileformats. So I created a plugin to extend QT to support ricfiles using riclib. This will not just extend my application, but every QT application using QT’s inbuilt image functions. (The application and plugin will be posted in the near future.)

I will not go into depth about how this is done however one of the key aspects is that QT is not using filepaths, but its own QIODevice class which does a similar task as my nxtIO class. I could create a sub-class which inheriths nxtIO and read/writes to a QIODevice, but I took the easy solution and just used the QIODevice to read the whole file in one go and use nxtStream instead.

QByteArray data = device()->readAll(); //Read all bytes in QIODevice into data
nxtStream stream( data.data(), data.size() ); //Create a nxtStream using data
ricfile file;
file.read( &stream ); //Read the RIC file

nxtStream takes a char pointer and a int holding the size of the array. What is left is just drawing the file:

nxtCanvas canvas;
canvas.set_auto_resize( true );
file.Draw( &canvas );

The canvas is created at size 0x0 with auto_resize on. The RIC file then draws on the canvas, expanding it as needed.

The next step is to convert the nxtCanvas into an image format the application supports which is normally rather trivial. One thing to remember is that (0,0) is located in the lower left corner in nxtCanvas where it is most often located in the upper left corner in other formats.

Aug 12 2011

## Planned features for RICcreator

Category: Lego,Mindstorms,RICcreator,SoftwareSpiller @ 22:18

A great trip to Ireland has ended, a trip without my computers, music and anime. However not being completely able to detach myself from everyday life I found some paper and a pen and compiled a list of features I want to add in RICcreator.

So while not complete and subject to change, here is the most important features to be done:

### Features to be done before Alpha release:

• VarMaps must be editable. I cannot drag this out any longer, so I will go with an interface similar to what is found in nxtRICedit. The entries will use the left part of the screen, with the graphical view on the right. (Graphical view will automatically swap x-y axis depending on the available screen area.) Graphical view might first be added in Beta though.
• Polygon will also be added in a similar way as VarMaps, just with a different graphical view.
• RICScript import/export support.
• Export an open file as a C/NXC header file.
• Support parsing a RIC file from a byte stream internally. This will improve Windows Shell integration and will make it easy to include GraphicArrayOut() in nxtCanvas.
• Embed default font in EXE instead of require it to be located in the folder. When the two previous features are added, this will be a piece of cake.
• Improve command-line interface. Support opening several files at once and make it possible to convert files from one format to another.

### Features to be done before Beta release:

• Change preferences dialog (and make preferences global internally).
• Allow graphically editing Point/Line/Rectangle/… objects like in nxtRICedit.
• Visual hints in Copybits object, similar to nxtRICedit.
• Drag-n-drop in the object list widget to move them.
• Copy and paste
• Edit history, undo and redo
• Simple/beginner mode which just shows a nxtCanvasWidget and then manages the Sprite and Copybits element in the background.
• RIC font edit mode to simplify RIC font creation.
• Remember recently opened files.
• Check for updates. (Automatic vs. manually?)
• Remember RIC parameters.

Any suggestions are welcome.

I have added Trac to the SourceForge project page which I intend to use as a bug tracker instead. The reason for this is because in includes a nice Roadmap page where you can add Milestones. I will try to issue tickets for the features which needs to be done and bugs which needs to be fixed and then add them to the Milestones. It should work as a good TODO list if I remember to use it. I will properly close the old bug tracker when I add a few more tickets to Trac.

Jul 10 2011

## Keywriter

Category: Lego,MindstormsSpiller @ 14:18

An old project of mine, from before I got my NXT 2.0 kit. From about 2.5 years ago iirc.

Old description from HDD:

A robot which can write on a computer by pressing the keys on the keyboard.

### My original goals

To become more used to make building instructions.
Making it to work on multiple keyboards so it isn’t specific for a single keyboard/working condition.

Making programs that can be modified easily to perform similar tasks.

Making simple and strong constructions.

Should work on multiple keyboard, but remains untested…

Program works by using coordinates, nothing like the “modifiable” program I wanted…

Most of the construction was simple enough though.

### Program

The program was made in NQC since it would most likely fail in RIS…

By using the rotation sensors, the motors worked like servos changing speed/precision depending on distance.

Keys were found by using manual entered coordinates…

By using some functions in Windows which are normally for people which have trouble using the keyboard, you can activate a function to press keyboard shortcuts one key at a time. This can be done with shift and uppercase letters so caps lock isn’t needed and furthermore it could be used to control many Windows features directly from the keyboard.

Still, I didn’t continue that far…

### Construction

The frame was made simple, long, and strong. The long beams are made of both studded and studless bricks to reinforce each other. So even if the span is over 30 cm, they don’t bend that much.

Wheels are used instead of gearracks on the frame and this works okay…

### Photos:

LDraw file can be found on my brickshelf: Keywriter folder

Photos from while I was constructing it can be found this this folder.

Jun 01 2011

## Improving nxtCanvas

Category: Lego,Mindstorms,Programs,SoftwareSpiller @ 15:56

After a weeks delay (3 exams, playing Little Busters! for three days, and a bit of piano training) I’m finally able to do some more on RICcreator.

Lately I have been working on nxtCanvas, the class which attempts to emulate the drawing functions on the NXT.

First of all, LineOut() and RectOut() have been optimized quite a bit since they weren’t that well written… (For example, when drawing a filled rectangle, it first drew a normal rectangle and then a filled one inside that.)

Not minding the small stuff, I finally fixed the EllipseOut() implementation. After doing a bit of math it just worked much more like I wanted in a much simpler procedure… I also added fill-shape, so this is now working for both circles and ellipses. To avoid it drawing on some pixels several times it has quite a bit of exceptions, so it needs to be cleaned up someday. But well, it works.

## RIC fonts

I have also finally written a simple implementation of RIC fonts. In short, it is just FontTextOut() without any special font copy options. However this much is enough to get a TextOut() and NumOut() working. I made a RIC font which looks like the default font on the NXT and TextOut() simply calls FontTextOut() using this RIC font.

So the Number opcode is now working, meaning only Polygons aren’t fully supported. And I’m not sure when this will be added, because I’m simply unsure on how it should work…

Interestingly, the font I used is different from the one used in nxtRICedit. I based it on the 1.29 standard firmware source and it looks the same when trying it on my NXT. Was the font different in the 1.0x firmwares? For now I’m not planning to emulate how it would look on the standard or older versions of the firmware, but it would be good to know if there is a difference here.

## Editing nxtCanvas

I have also done a bit of work on the GUI side.

You can now edit the copy options settings which opens up the possibility of drawing in white, using fill-shape, and XOR drawing:

There are some performance issues with displaying the canvas. Right now it needs to fully redraw everything each time the nxtCanvas has been changed. It does so by drawing the entire field white and then adds the black pixels. This means the performance decreases the more black pixels there are. (So the performance issues with fill-shape is actually because of the huge black areas.)

There are two solutions to this problem. One is to make nxtCanvas draw directly on the image class QT needs. However since I want to make riclib completely independent on QT for reusability reasons, this is not an option.

The other solution is to only partially redraw the image. It would surely speed up the redrawing but nxtCanvas would need to specify the changes with every drawing operation… I will try to add this some other day.

It might be possible  to take a more low-level approach to this, I will try to look into this and see if it is possible to gain anything by doing that.

EDIT START: Just tried that, made quite a difference… It needs to redraw everything each time this way, so no point in partial redrawing in nxtCanvas. Still slows down with more black pixels, but it should rather be treated as an optimization anyway… EDIT END

Other than features to speed up redrawing, I’m also planning to make it possible to auto expand the canvas when the drawing operation attempts to draw outside the canvas.  The issue here would be performance though… I’m not going to add it right now anyway though…

There are also a few functions that need to be added, like shrinking the canvas size to the area actually used, and filling an random shape with a color.

## VarMaps?

The most important missing feature right now is editing VarMaps. I just can’t come up with a good interface to do this with though. The solution in nxtRICedit works, but I don’t quite like it… There must be some better way to do it, but I’m still on a loss on how this should be…

Well, this is it for now… I will upload a build in a couple of days, I want to add a little bit to the GUI first.

EDIT: it has been uploaded, revision 80.

EDIT2: I forgot to upload the font file together with it, fonts will not draw without it…  Will be fixed in the next release. For now, you can place a ricfont named “font.ric” together with the .exe, it will use that one. If you really want to test it out…

Apr 28 2011

## Toy plane

Category: LDraw,LegoSpiller @ 20:18

I haven’t posted anything for a while since I’m currently busy with finishing my exams projects. So I brought up a little thing from the past. Quite a few years actually (so I’m sorry about the dust ;) ).

Back in the days I loved the platform game  “Toy Story 2: Buzz Lightyear to the Rescue” (from 1999). In the third level (video here) there is this toy plane which I happened to like even though I hated the level of some reason. So I made a small scale model in normal Lego:

LDraw file (with steps) is available from my Brickshelf account. (direct link)

I haven’t really made a lot of small scale models (and therefore certainly don’t have any skills with it yet) however this is the only type of  Lego other than Technics/Mindstorms that still interests me today. For example this model of Suiseiseki from Rozen Maiden is just fascinating. (Well, perhaps I just don’t want to admit that I don’t have enough Lego…)

I just recently got my hands got my hands on a SLR camera however since I’m quite new to this I didn’t manage to get the depth of field correctly.  Well, I will figure it out someday… EDIT: someday was apparently the day after that as I found out how to change the setting by accident…

Mar 05 2011

## Writing NXC code in Notepad++

Category: Lego,Mindstorms,NXC,SoftwareSpiller @ 19:21

When writing programs in NXC I prefer using Notepad++ instead of BricxCC as the text editor. Notepad++ isn’t a IDE though so you can’t compile it directly in the program. However Notepad++ comes with a plug-in called NppExec that can execute other programs and we can use this to start the command line compiler (nbc.exe) directly in Notepad++.

## Compiling files with NppExec

NppExec is a rather powerful plug-in which can do a lot for you. To start it up, simply press F6 (or find it in the menu, Plugins -> NppExec -> Execute…).

The big multi line textedit field will contain all the commands you want to execute. Each line is a separate command which will be executed after each other, starting from the top. To get started, we need to find nbc.exe’s location. It is in the same folder as BrixcCC which is normally:

"C:\Program Files\BricxCC\nbc.exe"

(The quote marks are necessary if  there are spaces in the path, they are NOT optional!)

First of all, as this is a command line compiler (because that is the reason we are using it), we need to know which parameters it takes. To do this, enter the following command in NppExec:

"C:\Program Files\BricxCC\nbc.exe" -help

(To get a command line program’s supported parameters, you often write “-help”, “-h” or “/?”. (To get a list for NppExec, simply write “help”.)) The result should look something like this:

Notice the syntax: nbc.exe options filename options

So after nbc.exe you can place parameters (options), then the filename and after that more parameters. (I prefer having all the parameters together though.) The most important parameters are:
-d, which will compile and transfer (download) the program to the NXT.
-r, the same as -d, but will also start (run) the program when done.
-Z[1|2], this will turn compiler optimizations on, -Z2 is recommended.
-EF, if you are using Enhanced Firmware, remember to add this one.
-v=n, this specifies the version of your firmware. This apparently defaults to NXT 2.0 firmware now, so you most likely doesn’t need to specify it. (Otherwise write -v=128)

(I haven’t tried downloading over Bluetooth so don’t know how this is done. You might need to use the -S=portname parameter…)

"C:\Program Files\BricxCC\nbc.exe" path_to_your_file -d

where “path_to_your_file” is the file path to the NXC file you want to compile. If you want to use Enhanced Firmware and compiler optimizations you can do it like this:

 "C:\Program Files\BricxCC\nbc.exe" path_to_your_file -d -EF -Z2

Everything we have done here is possible to do in the command prompt, if you try to run the commands in the command prompt it will work as you expect. However there isn’t much point of doing it in NppExec if you just use it as if it was a command prompt…

The first thing we want to avoid is to having to change “path_to_your_file” every time you need to compile another file. NppExec contains some macros that can help us with this which take the form: $(NAME_OF_MACRO) where “NAME_OF_MACRO” is the macro you want to use. The one we want to use is FULL_CURRENT_PATH which will be replaced by the file path of the document you are currently viewing. We simply needs to use this instead of “”: "C:\Program Files\BricxCC\nbc.exe" "$(FULL_CURRENT_PATH)" -d

Notice that there are quotes around the macro. These aren’t necessarily needed, however as said before, if there are spaces in the file path you need to have them. Add quotes every time you automatically inserts something that can contain spaces, better safe than worry.

### Saving files

One thing you need to be aware of is that it uses the file saved on the hard disk, so if you have made changes to the document and have not saved it yet, those changes will not be known by the compiler. So you will either have to remember to save or use the NppExec “NPP_SAVE” command which automatically saves the current document. You place this command on its separate line before your call nbc.exe:

NPP_SAVE

### Reducing the shown amount of compile errors

The command window autoscrolls so if you get 50 errors you will have to scroll all the way up again. You can set a limit on how many you want to be displayed with the -ER=n parameter (where n is the maximal amount).

"C:\Program Files\BricxCC\nbc.exe" "$(FULL_CURRENT_PATH)" -d -sm- -ER=5 (It seems it that nbc.exe didn’t output the error messages to the console in some of the older versions, but you can store the error messages to a file with the -E=filename parameter and then display this file in the console.) ### Making the compile errors easily readable and add goto line Right now the compile errors is a bit hard to read, however you can add coloring rules to make it more clear. Go to “Plugins -> NppExec -> Console Output Filters…” and a dialog window with three tabs appear which you can filter some of the lines out or only allow certain ones. You can replace text and the last tab, which we are going to use, highlight lines. Take a closer look at the image to see the changed I made. The column of checkboxes turns the highlight marks on and off, the second column is the rule, the three next ones is the RGB color in hex (which nearly impossible to change, just use “0” and “ff”). The last three colomns with check boxes add Italics, Bold and Underline text decoration. I will not go in dept with how to make rules though, look in the documentation or just read the text at the bottom if you want to learn how to make your own. I will however go through the first line: File "%ABSFILE%" ; line %LINE% The %ABSFILE% part tells that this is an absolute file path and %LINE% tells that it is a line number. The cool thing is that if you double click on that line, it will automatically go the specified line in that document. ### Make Notepad++ automatically add syntax highlighting If you open a .nxc file in Notepad++ it will treat it as a text file. To make it recognize the file extension, go into “Settings -> Style Configurator” and select the language you want to use, most likely C or C++. Then in the “User ext. :” box, add “nxc”. (If you want multiple extension, separate each with a space.) If you want to use a User Defined language instead, go into “View -> User-Defined dialogue…” and add the extension in the “Ext. :” box. ### Function auto-complete and highlighting? I found a User Defined language once that did this, but its C support wasn’t too good as User Defined languages are rather limited in that aspect. (Which is why I’m just using the standard C syntax highlighting.) Autocomplete worked great though. I don’t have the link anymore and I think it was posted on nxtasy.org… (And I will not redistribute it without permission from the author.) Does anyone know of a good alternative? ## Other stuff… ### Saving the compiled .rxe file It can be done with the -O=filename parameter: -O="$(CURRENT_DIRECTORY)\$(NAME_PART).rxe"

Notice the two new macros and how it is used to create a new file path.

### Windows intergration

I have recently studied how to implement your own filetype in the Windows shell, so I’m going to try it out and write it in another post. Adding stuff like being able to compile .nxc files just by right clicking on them in Explorer and such.

It is going to involve manual editing in the Registry using regedit though.

Tags:

Feb 16 2011

## Bezier v2.4.0

Category: Lego,Mindstorms,NXC,Programs,SoftwareSpiller @ 00:31

\Quite some time ago, way back to the time of nxtasy.org, I was writing a Bézier curve implementation in NXC. Muntoo was also writing one at the time, you can check his out on his blog, here. His implementation is generally more feature rich, like several different drawing modes, while mine is geared towards pure speed.

To start it off, here is a screenshot of the current progress:

The process is two-step, a initiation function which calculates some basic stuff which takes 11 msec, and then the drawing functions. In the screenshot there are 10 cubic curves drawn by the general Bézier algorithm which takes 419 msec in total, so ~42 msec per function call in average. (The first draw with a new amount of control points is a bit slower as some of the calculations are reused.)

Right now there is only a general Bézier algorithm, the one I optimized for cubic curves isn’t working correctly…

### Implementation – v1.1.0

The general Bézier formula looks like this:

$B(t)=\sum_{i=0}^n{n\choose i}(1-t)^{n-i}t^iP_i$

So to draw a Bézier curve you would start with t=0, calculate the x and y positions, increment t by 1/”desired precision” and recalculate. This process is repeated until t=1. There is a lot of calculation needed for each t value, yet we might be able to do some of the calculation that doesn’t directly involve t beforehand.
We could for example calculate the binomial for each P and store it in C like this:

$C_i={n\choose i}P_i$

$B(t)=\sum_{i=0}^n(1-t)^{n-i}t^iC_i$

### Implementation v2.+

NXC is compiled into a bytecode format in which math opcodes are polymorphic. If you try to multiply an array with a scalar, the scalar will be multiplied with each of the elements in the array. This is however a lot faster than manually iterating a loop multiplying each element.

So my idea was to take advantage of this by making an array containing each value of t. Instead of iterating a loop, you would simply do the math operations on this array. The array of t values would also only be calculated once in the beginning of the program, instead of each time you need to draw the curve.

So for the Bézier algorithm there would be two arrays, one containing each value of t and another containing each value of 1-t.

However we want to optimize this further. Since we start at i=0, lets consider that case:

$(1-t)^{n-0}t^0=(1-t)^n$

We will only need to calculate $(1-t)^n$, so lets try finding the difference between the first iteration and the next:

$(1-t)^{n-1}t^{0+1}$

$\frac{(1-t)^n}{(1-t)^1}t^0t^1$

We can therefore get to the next iteration by multiplying $\frac{t}{1-t}$ into $(1-t)^n$ and into the next iteration by multiplying again:

This fraction can be calculated without knowing n or i, so we can calculate this at the start of the program and reuse it. We will need to calculate $(1-t)^n$ each time we get a new n value (but we can keep the array, so if the next curve have same n value, we also reuse this (and when done right, even the binomial)).

However a small loop is still needed to calculate the sum since ArraySum() isn’t polymorphic. Currently there is also a little bit of multiplication in the loop, but I’m working on removing that too.

The major downside with this approach is that if you use high resolutions the arrays become rather large (and they are using float to boot) so memory usage rise quite a bit. (Some temporary arrays are also needed, so it quickly becomes a few KB.)