Main Site Documentation

Fez touch spiral


#1

Panda II Fez Touch using Skeworks Spiral

As i move a button further down the screen, the touch zone moves further and further below the button.
Also the touch zone moves further to the right the further down and to the right the control is placed.

This problem is only in Spiral. When using FEZ_Touch_UIControls, this problem does not exist.

Have tried the below calibration, with no change in this problem.

I downloaded Spiral about a week ago. Has any one else had this problem??



using System;
using System.Threading;
using Skewworks.Spiral;
using Skewworks.Spiral.Controls;
namespace ProvidiaSpiral_1
{
    class Program
    {
        private static Font fnt = new Font(Resources.GetBytes(Resources.BinaryResources.small));

        public static void Main()
        {
            Graphics.Initialize();
            point[] calPoints = new point[5];
            calPoints = Graphics.Calibrate();
            Graphics.SetCalibration(calPoints);           
            Form frmMain = new Form(Colors.LightGray);
            CommandButton map_btn = new CommandButton("M", fnt, 180, 200, 28, 20);
            map_btn.tapEvent += new OnTap(map_btn_Pressed);
            frmMain.AddChild(map_btn);            
            Graphics.ActiveForm = frmMain;
            Thread.Sleep(Timeout.Infinite);
        }

        static void map_btn_Pressed(object sender, point e)
        {

        }       
    }
}

Read some where else on forum that Spiral may be one version behind GHI. Am running GHI version 4.1.6.0. Spiral version is 1.0.3.0 would this be related to the problem?


#2

Like I said on the Skewworks forum I am on it and will have something soon. New calibration is already set to go but I’d hate to blast out an update to everyone only to do it again 2 days later; because there will be some more updates and additions to Spiral in the next update.

Just bare with the calibration being a bit off for the next few days and I promise you’ll be happy with the results. :slight_smile:


#3

Final Upgrade Teaser:

Main DLL
We’ve fixed the Touch Calibration
Improved render speeds on several controls
Fixed and Updated the Listbox

Image DLL
Added a Picturebox
And a TinyBitmap class; enjoy many of the features you would with the regular Bitmap class finally on the Panda II.

Input DLL
Textbox control
Virtual Keyboard
New Input Dialogs

;D


#4

All of these sound great, particularly the virtual keyboard!


#5

There may be another surprise or two, space permitting.

I’d [italic]love[/italic] to make the radio buttons use TinyBitmaps for their GUI making them (significantly) render faster and look cleaner.

Plus some Pyxis style App Launching. :wink:


#6

Another Wish?

Command button interrupts.

I have 8 command buttons to switch between 8 possible pages to display. I have 7 labels to describe each of 7 lines on the page. These labels text are changed when its associated command button is clicked. There are 7 more labels that contain the actual data for each line too. These labels text are updated once every second (could be a bit longer). Works like a tab control.

What I see is that when a command button is clicked it is not flashed, to indicate a press, until after the labels have been redrawn, possibly 2 or more seconds. This makes it look like the command button was not clicked.

Assume this is done so that flashing the button doesnt stomp on the labels being redrawn, out in the lcd graphics functions. Is there some way that the interrupt delegate could be run before the button is flashed, so that in the delegate I can stop refreshing the data in the labels. That way there would be less time between button click and its flash. This would work for me since changing pages means all the labels will be redrawn after the command button interrupt.

Also be sparse on your ram usage, I am on the edge of running out.

RD


#7

It’s just the order of operations; I can update it for what you need.

I’ll see what I can do RAM wise.


#8

@ RD I’ve looked into the RAM issue and unfortunately there’s not much fat to trim. I do keep a 1K buffer for doing fills quickly. I can either cut that down or make it allocate dynamically. Either way it would be a speed cost.

I think the real thing that’s chewing through your RAM is just the shear number of controls. Each control derives from a base class which has a minimum requirement of 60bytes * 15 controls (8 buttons & 7 labels) = 900bytes just for the base. Being command buttons and labels you’re also chewing up for the strings.

If I add a TabControl I can probably save you ~420bytes. If I move the colors class into it’s own library and you don’t include it that’s another 240bytes.

The biggest hogs here really would be # of controls & size of font.


#9

I am doing some other stuff that eats ram. Running a gps (serial port), that has to split the gps sentence, parse to double, and update the RTC. I also read in gps coords from a .kml file on the SD, scale the points to screen pixels and plot it on the LCD.

This a field data recorder, so, I read in specs for one of several Jobs from SD and these are placed on one of the 8 pages. I also log all of the data to the SD at an interval of about 10 seconds (less if I can).

One trick I played when using the GHI UI controls was to not allow the fills to occur on the labels. I added a short piece of code to be sure the label text length was always exactly the same length, adding spaces if too short, cutting off chars if too long. Set the text background color to screen color. All the old chars are there fore over written. If I just used the write text method in Spiral instead of labels, the same thing should be possible. That way I would minimize the ram used by the back fill???

I have gone thru the program and made all vars as small as possible, made as many things const as possible. Bring many things off the SD when needed. I get out of memory errors running in debug, but not when I deploy. Imagine the SD buffer also eats a lot of ram.

If you could change the execution order of the Command Buttons it would be helpful. Assume it would execute the delegate, wait for other graphics to cease, then flash the buttons.

Thanks for the insight!
RD


#10

You can definitely do Font.DrawText calls and that will save you overhead for the base class and the stings if you dispose after drawing.

SD buffer is dynamic so you don’t have to worry about it unless you call it. You can also not include that lib if it’s not used.

Sounds like you’ve got a really cool project going on; I’d love to see a video of it after I release the new firmware this weekend!


#11

TinyBitmap.SaveToBMP() and Graphics.SaveToBMP() coming this release; save TinyBitmaps and full screen shots to SD as standard 24bpp bitmaps. 8)