Mindboards

~muntoo, thanx.

Another idea. It seems pretty obvious that the NXT screen buffer is much larger than the physical NXT screen. It seems to be at least twice as tall, as well as extra wide. Is there a way you could allow the NXTScreen tool to view the entire buffer? The idea is that I could have screen with at least 4-8 times the area.

If the pixels positions and buffers are setup for full byte values, that's a 256 x 256 buffer, limited to a 100x64 pixel LCD. Imagine the possibilities of such a large virtual screen! At 256 x 256, It would have over 10 times the area!

Obviously this would just be an option for the NXTScreen tool.

Edit: after a little testing, I have reason to believe the buffers contain signed int number of elements (15 bits, plus sign bit). That means the virtual LCD size would could actually be 32767 x 32767 pixels (or twice that with unsigned). Obviously this would be way too much to use realistically, and probably too much bandwidth for USB. If any of this is possible, what about allowing the user to select the size of the virtual screen?

...I can just see it now, you run into a minute bug in the program, so you display the values of every variable, string, array etc. until you find the issue . Staring at the screen waiting for it to update at the 0.02 Hz refresh rate you manage to squeeze out of the USB stream

I am pretty sure all the drawing functions have clipping enabled (for performance reasons; TextOut() and GraphicOut() overdo this, actually), so there isn't much point in being able to view the 'entire buffer'.

muntoo wrote:I am pretty sure all the drawing functions have clipping enabled (for performance reasons; TextOut() and GraphicOut() overdo this, actually), so there isn't much point in being able to view the 'entire buffer'.

Based on my tests with LineOut, it doesn't seem to be clipped. Even if I couldn't use TextOut or GraphicOut, I would still use the extra area for sure.

Pretty sure it is being clipped in the PixelOut() function which, iirc, all other drawing functions are based on. I think the GraphicOut() is clipped too, but I don't quite remember. You could look it up in the firmware source, I think the file was called cmd_draw or something like that.

I don't think it will be difficult to modify the dimensions the clipping is being done on anyway.

Ctrl+F, "clip" on c_cmd_drawing.inc.

Kinda messy, but: I am not sure, but cCmdWrapDrawPoint() is probably used for PointOut(). (The other functions don't use this, though. They use cCmdSetPixel() so I'm not sure if the comments are outdated, or what.)

it would be very nice and convenient if we were able to work with 2, 3, or 4 permanently USB-connected bricks and their related NXC programs simulateously (particularly using specific program download/start and TOOLS-features like NXT screen, NXT Explorer,...) without having to disconnect or to unplug and re-plug any USB-cables (e.g., starting several instances of BCC, with each instance dedicated to 1 specific brick).

~Ford, +1

However, I made myself a workaround using two computers side-by-side with DropBox to keep the files synced and Synergy to share the mouse and keyboard. It's almost a necessity when programming multiple NXTs to work together (e.g. RS485).

I would be keen to see a 'block indent' feature in the editor, i.e the ability to select multiple lines of code and pressing a key, e.g. ctrl-k, and each line within the selection gets indented by a space (i.e. the whole block moves to the right)

This would be useful if you have a block of code and realise subsequently it needs to be within an if statement or a while loop.

And while I'm on my soapbox, another useful feature would be curly-bracket highlights that somehow allows the user, when the cursor is on a curly bracket (open or close), to easily identify its matching close or open (respectively) curly bracket.

I second that :)
+1
+1
maybe also an auto-indent of 1 tab (2 spaces) in the line after {
and one auto -1 tab in the line of }