GUI

More
30 Apr 2012 19:49 #114 by MatCat
Replied by MatCat on topic Re: GUI
I just pushed some changes, it SHOULD draw a button image to the screen though it's not... not sure why yet.

Please Log in or Create an account to join the conversation.

More
30 Apr 2012 20:01 #115 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
Looks good so far.
FYI, you can use LCD_DrawImageFromFile instead of LCD_DrawWindowedImageFromFile if you just want to draw a bitmap at the provided coordinates. The Windowed mode works as well, but is more cumbersome if you don't need the extra functionality.

Please Log in or Create an account to join the conversation.

More
30 Apr 2012 20:07 #116 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
You should use gdb. It is the easiest way to find issues like this. Likely your bmp isn't in the right format or in the right location.

Please Log in or Create an account to join the conversation.

More
30 Apr 2012 20:57 #117 by MatCat
Replied by MatCat on topic Re: GUI
We need a display buffer of some sort... preferably layable. There are certain aspects that will always be there:

Absolute background
Status Bar
Current Screen
GUI Objects

Anytime any of these change it all will need to be redrawn.

Until we figure that part out I am going to get this GUI api functional in some way. the actually graphical method can be modified later but I want to get a good framework in place.

Please Log in or Create an account to join the conversation.

More
30 Apr 2012 21:43 #118 by MatCat
Replied by MatCat on topic Re: GUI
Ok I have a basic functional GUI button with callback though coords are a bit off for some reason. Still a LOT to do :).

Please Log in or Create an account to join the conversation.

More
01 May 2012 00:04 #119 by MatCat
Replied by MatCat on topic Re: GUI
Ok I just noticed the touch coords only give 0 to 255, but the width is 320x240? It's throwing off stuff at either rate.

Please Log in or Create an account to join the conversation.

More
01 May 2012 01:25 #120 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
As I mentioned above, we need a mapping function to convert the raw ata to screen coords. I purposefully convert screen coords to 0-255 in the emulator since we can't rely on the raw values returned by the actual touch sensor. We need a calibration routine and then a mapping routine.

I just committed the relevant changes to make coords 16bit, and for the emulator to return actual screen coords. It is just temporary until the calibration routines work, but should let you make progress.

Please Log in or Create an account to join the conversation.

More
01 May 2012 02:06 #122 by MatCat
Replied by MatCat on topic Re: GUI
It made coordinates accurate however it cuts off at 255 and starts from 0 again on the x axis, on the Y since it is 240 it doesnt matter...

Also if you look at my build you will see the draw image function is still not functioning quite right.

Please Log in or Create an account to join the conversation.

More
01 May 2012 04:20 #123 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
did you do a:
make clean TARGET=emu_devo8
When I built your code, the x coord did go from 0 - 320
My Makefile does not notice changes to .h files, which would likely cause the behavior you saw.

I also committed a fix for the screen offset issue. the image will now appear properly, and you should not need to subtract one from the image width/height either.

Please Log in or Create an account to join the conversation.

More
01 May 2012 05:43 #125 by MatCat
Replied by MatCat on topic Re: GUI

PhracturedBlue wrote: did you do a:
make clean TARGET=emu_devo8
When I built your code, the x coord did go from 0 - 320
My Makefile does not notice changes to .h files, which would likely cause the behavior you saw.

I also committed a fix for the screen offset issue. the image will now appear properly, and you should not need to subtract one from the image width/height either.


Yeah that is all working fine now... we need a buffer, I tried to put redrawing into the loop but its silly without atleast 2 page buffer.

Also a transparent support on bmp drawing? I do not recommend black like the stock system though, perhaps standard magenta color?

Please Log in or Create an account to join the conversation.

More
01 May 2012 06:43 #126 by MatCat
Replied by MatCat on topic Re: GUI
Ok I just commited a proof of concept with 3 button objects all with callback functions (just removes the button and lets you know you pushed it).

A list of basic GUI objects I am thinking of:

Label
Frame Box
Checkbox
Dialog Box
Dropdown Box
Radio Button

Obviously there will be more but these seem like the basic foundation items.

Please Log in or Create an account to join the conversation.

More
01 May 2012 07:28 #127 by FDR
Replied by FDR on topic Re: GUI
They use kind of spin button for numeric values. It would be better to provide two different step: small and large. (...and input from a virtual keyboard. They use one too for the model name and the fixed id. ;) )
Scrollbar and scrolling capability come to my mind too...

Please Log in or Create an account to join the conversation.

More
01 May 2012 08:16 #128 by MatCat
Replied by MatCat on topic Re: GUI

FDR wrote: They use kind of spin button for numeric values. It would be better to provide two different step: small and large. (...and input from a virtual keyboard. They use one too for the model name and the fixed id. ;) )
Scrollbar and scrolling capability come to my mind too...


Yeah scrollbar is on the high priority list for sure.

Hey FDR your website most of the time takes 60~ seconds to respond... I have a couple servers in a datacenter if you want a more stable hosting enviroment for the project website.

Please Log in or Create an account to join the conversation.

More
01 May 2012 08:36 #129 by FDR
Replied by FDR on topic Re: GUI
Cool!
I think it is caused by the subdomain...
I'm out for three days now. After that we can port the whole thing.

Please Log in or Create an account to join the conversation.

More
01 May 2012 12:25 #130 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
Note that we can't actually buffer the screen. We don't have enough RAM for a page buffer, so we'll need to be smarter about that.

One possibility is to keep track of what is on each layer and to use windowed mode to re-render each layer on change
Another is just to re-render the entire screen whenever anything changes

Please Log in or Create an account to join the conversation.

More
01 May 2012 12:30 #131 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
About transparency:
it can be done, but it is very expensive. Especially for bitmaps. It is fine if what you are rendering is small, but to use transparency on a large bitmap would likely cause unacceptable performance. I'd strongly recommend designing a system that doesn't need it.

Transparent text background is already supported, but it requires implementing a redraw method, which is why it isn't enabled. You can however change the background for the text. I'm not sure how useful that is though

Please Log in or Create an account to join the conversation.

More
01 May 2012 13:39 #132 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I've now implemented the touch calibration routine. Press '1' in the emulator to activate it.
So you can now use the x/y coordinates from SPITouch_GetCoords as actual screen coordinates

Please Log in or Create an account to join the conversation.

More
01 May 2012 18:31 #133 by MatCat
Replied by MatCat on topic Re: GUI
We don't need full alpha support, but it shouldn't be too hard in the bitmap drawing routine to do something like

if (pixelcolor != transparentcolor) {drawpixel;}

The only images that will need it will be GUI elements such as buttons with rounded corners, shouldn't add much computational expense.

I plan on having labels done today, which should be used for screen text instead of just raw sprintf aswell so that text can be preserved on redraw.

Please Log in or Create an account to join the conversation.

More
01 May 2012 18:47 #134 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
Actually, that is difficult to do.
The reason is because of how the LCD screen driver works.
The way we use it now is to define a viewport (x0,y0) - (x1, y1) and then to just send one pixel at a time which increments the current location pointer automatically. There is no 'skip' function, so you need to write to every single pixel in the window. I had tried reading the pixel and writing the value I read, to tryto increment the internal poiter value, but it didn't work for me.

The only way around this that I know of is to use the DrawPixelXY function. This is much slower as it basically sets a 1-pixel wide viewport, and then writes to it for each pixel. That is fine if the image is small, but you wouldn't want to use it for the full screen.

Please Log in or Create an account to join the conversation.

More
01 May 2012 19:26 #135 by MatCat
Replied by MatCat on topic Re: GUI
We are missing something I think, I do believe the Devo 8 firmware does have true alpha in it currently because when I changed the image on it the icon holder shows alpha to it...

Granted it is a SLOW routine, you can see the line by line draw in that case on the current firmware...

We should just have 2 image drawing routines, one for non-alpha, and one for alpha, and only use alpha bitmap drawing for small images like buttons and things, the actual background doesn't even need transparency.

At minimium we really need transparent backgrounds on fonts, sure we could specify a background color but that means to maintain a good look any object text is on would have to have a solid color background...

Please Log in or Create an account to join the conversation.

Time to create page: 0.121 seconds
Powered by Kunena Forum