GUI

More
07 May 2012 19:58 #214 by MatCat
Replied by MatCat on topic Re: GUI

PhracturedBlue wrote: I can't fix it at the moment but just define:

void SOUND_Init() {}
in target/emu_devo8/stubs.c


I don't see a stubs.c

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

More
08 May 2012 00:03 #215 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
You probably need to do a pull then.
You should have:
target/emu_devo8/stubs.c

I just committed the fix though. I also added timer support. If you want to know the time, you can use CLOCK_getms().

If you need to do something on a regular cadence, we can implement a callback system that does stuff on a regular interval, which would be more efficient than polling

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

More
08 May 2012 00:21 #217 by MatCat
Replied by MatCat on topic Re: GUI
Yep was there on pull :).

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

More
09 May 2012 02:12 #233 by MatCat
Replied by MatCat on topic Re: GUI
Deep in working on window redraw... got slowed down by some pointer issues I am still working out...

I tried to create a pointer on the guiObject struct to guiBox inside of gui element struct however it doesn't seem to want to work right :P. But I am gonna figure it out.

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

More
09 May 2012 12:18 #243 by FDR
Replied by FDR on topic Re: GUI
May be we should collect the goals for the GUI too, just like you did for the model data?
I think it would be a good starting point to define what's wrong with the original.

While I think it is not too bad, let me set out my complaints:
- It is not visible enough. That was the cause we started tinkering with the library;
- the voices and alarms are bad: the turn on/off voices are annoying and unnecessary, but the alarms (like the timer and telemetry warnings) are too quiet. Both shoul be configurable, like the buzzer setting is.
- values are slow to set by only small steps allowed. There should be larger steps too, or clicking inside the box it should be entered on a virtual keyboard, like they did with the fixed id and the name;
- model settings are dispersed into the model and function menu. You often have to go out entirely, go into the other menu, change something, go out again, beck to the previous menu, so you can change a thing which was disabled depending of the other setting.

There a a lot more in the "would-be-great" category, for example: shortcuts on the main window should be configurable, but the above ones are really annoying sometime...

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

More
10 May 2012 14:24 #257 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I just committed new code that changes the organization of main() so you probably want to pull. I also added the ability to support proportional fonts to the gui. You probably want to look it over. Lastly, I added a debug window to the GUI which will be used to display channel output as we start work on the real GUI and want to be able to see how curves and mixers are working.

also, it is possible to completely remove tearing in the emulator by switching to an event loop. there is a define in makefile.inc to enable this. I decided to leave it off, as any tearing you see with the current implementation will show up on the actual hardware, only worse, so hiding it in the emulator masks the problem.

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

More
10 May 2012 19:30 #258 by MatCat
Replied by MatCat on topic Re: GUI
Yeah I would ratherthe emulator emulate as best as possible. I am still workig on windowed redraw, bee busy for the last few days though so progress has been a little slow.

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

More
10 May 2012 21:27 #259 by MatCat
Replied by MatCat on topic Re: GUI
Ok I pulled it and I am checking it all out. One thing that has been urking me is that closing the emulator window does not shutdown the program :P.

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

More
10 May 2012 21:37 - 10 May 2012 21:43 #260 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
yeah, that is pretty lame :) I'll fix it.

If you remember, you can press 'x' to exit cleanly though.

Edit: It is fixed now.
Last edit: 10 May 2012 21:43 by PhracturedBlue.

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

More
11 May 2012 06:48 #261 by MatCat
Replied by MatCat on topic Re: GUI
Ok I justed pushed some code that SHOULD atleast redraw the background part of the buttons label when buttons are pushed, however the offsets for windowed bmp's does not seem to be working properly.

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

More
11 May 2012 13:40 #263 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
The bmp offset code is fixed. I keep forgetting that the bmp is drawn from bottom to top which changes the math. I can see the button label is only partially redrawn, but it ooks like your ordering is off, since it overwrites the dialog box.

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

More
11 May 2012 19:34 #268 by MatCat
Replied by MatCat on topic Re: GUI
Yeah I am working on that :)

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

More
11 May 2012 21:25 #272 by MatCat
Replied by MatCat on topic Re: GUI
Ok I am working on a vertical bar indicator (for analog stick display), and I am noticing raw decimal format of throttle info is 65535 for 0, and 61445 for 100% ??

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

More
11 May 2012 21:37 - 11 May 2012 21:37 #273 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
yep. That is how it is (all other sticks work as you'd expect though). Actually the real analog range is much smaller (only ~11 bits) but you can assume we'll provide 16-bit normalized data (0 is smallest, 65535 is largest) to the routine. any reversing or scaling will be done ahead of time.
Last edit: 11 May 2012 21:37 by PhracturedBlue.

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

More
11 May 2012 22:10 #274 by MatCat
Replied by MatCat on topic Re: GUI
I am restructuring the main display to be more like what one would expect, and I am going to start working on an actual menu system now.

Windowed Redraw is partially working, and as I go along I will continue to refine it to work properly.

I am also going to put in a start screen (binding time) too.

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

More
12 May 2012 01:04 #275 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I just committed an xy graphing function. It should be mostly flexible enough to display curves.

Would you mind if I converted all of the guiDialog/guiButton/guiLabel structs into a single union? Overall I think it would use less space (though individually the struct will be a little bigger). but it should make the code a lot easier to read since most of the case statements in gui.c would go away. Alternatively, we could define all the structs to have common variables in a common location, then we could cast each to a base struct and still save most of the code complexity (though not the variable space)

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

More
16 May 2012 14:58 #307 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I've changed how partial redraw is done in the GUI. I assume the following rules:
* Only a dialog object can overlap another object
* When a dialog is open, anything underneath will not be redrawn
* If a dialog image has transparency, the transparency will not be properly honored

With those rules in place, it is much easier to do a partial redraw as there is no need to intersect objects to see if they overlap, and ordering of objects is irrelevant.

There are further efficiencies that can be implemented still, especially with regards to removing objects, but it seems to work pretty well now.

I introduced a new 'dirty' bit which can be set for each object, and then a redraw will only redraw the dirty objects.

I also introduced a new 'transparent' bit which defines whether a GUI object has transparency. If it doesn't, there is no need to redraw the background, and so there is less flicker.

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

More
16 May 2012 22:43 #309 by MatCat
Replied by MatCat on topic Re: GUI
Well, the method I am still working on for windowed redraw should be fairly effecient, as overlap won't be very common but it will happen. For example an image button ontop of a frame which is the menu.

On your post above about restructuring the objects, I am open to any more effecient method, I was considering a way to try to do it more class style like, but I don't see how inheritance or type casting would work very easily in straight C, I also did think about the idea of creating the object there in code where it is needed, instead of the API for GUI handling the data store, but that makes it more complex to keep track of things from the business end of the code... I am open to ideas. I have been busy for a few days, and probably will be for the next few days, hopefully I can put some time into some of the GUI code, but it may be a few days before I can put any real time in it.

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

More
16 May 2012 22:54 #310 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I'm not sure what you mean by 'menu' but it will likely be easier to not draw on top of a frame, and instead to just replace the background image as appropriate. For instance, I can completely eliminate flashing redraw if I know that the bar-graph widget is not drawn on top of any other widget. This is because I can only draw the transparent portions, and not overwrite the static portions. The result is much nicer than drawing the background under the bar and then redrawing the bar. I think the ability for widgets to intelligently redraw is probably worth the limitations of a widget only being allowed to draw on the background or a dialog (or maybe a non-transparent frame)

The performance is now sufficient for me to start work on the Mixer page, though if you can get similar performance without the overlap restriction, that would certainly be better.

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

More
17 May 2012 17:05 #311 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I've been thinking about it a bit, and I think the best solution will be to define all widgets in ROM (via const variables). All of the GUI_Create* functions then become macros which fill in the structure. The Object list still needs to be in RAM. There are 2 downsides to ths approach that I see:
1) It limits the ability to modify the layout of the screens via a theme. We'll basically be hardcoding all of the elements. At most you could reorganize them in a theme, but not change their size
2) You can't store any dynamic data in the widget. That either needs to be stored in the object, in a linked pointer or fetched via a callback.

Still, I think this is the way to go. It should save a lot of RAM.

I've just added a spinner widget. I think I now have enough widgets to design the Mixer page.
I'm trying to decide if this is a good time to try switching to a ROM based implementation, or if I should build the mixer interface 1st.

I added code to significantly improve BMP performance, but we're currently limited by the FAT filessystem implementation as far as redraw speed. I'm not sure what we should do here. I could probably write some routines to short-circuit the FAT system when reading data, which may help, but I'm not sure I really want to go there.

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

Time to create page: 0.069 seconds
Powered by Kunena Forum