GUI

Not an alpha channel, but an alpha value on the entire bitmap + black for full transparency, that is what the Walkera firmware does.

I don't recommend using black for full transparency marker though because it is too valuable a color to be used. Though I suspect that the walkera routine actually does use a buffer because the background image renders black (could just be because the canvas is black), however the status bar animation on startup screws up when the background has transparency, this means it is not just drawing the background, then the status bar animation ontop, it is actually combining them together then drawing it, otherwise the status bar would not screw up on transparent parts of the background, it would just draw ontop.

I do not know how much ram we are working with on the device, for a single full screen buffer (which is what I suspect walkera is using).

It is slow though, and you can see the lines draw when it alphas, though it is applying alpha to almost the entire screen since it is the primary panel that gets it.


I am open to suggestions on it, at this moment I am not even going to focus on that so much as I am to get the GUI API in place so we can develop with it, looks can be refined later, but at this stage we do need to know if it is worth it or not to use a buffer since that is something we need to know now .

My goal today is:

Labels (Text holders)
Frames (Window/Canvas for GUI Objects)
Beginnings of a Dialog Box

Do we have the ability to ask the LCD for the color of a pizel at an x,y coordinate? Instead of trying to incrament the pointer address why not just read the current pixel and re-write it IF possible?

Ok it looks a million times better now ROFL, BUT it is doing alpha it seems to the entire graphic... the image is a pearly colored button, but renders as blueish color, still looks good though .

Sorry if I didn't get a clear picture of what you said earlyer.

Ok good, I just got done implamenting labels too. I am converting over main.c any sprintf's to use labels if has_fs is defined. At this point merging any changes to main.c is going to cause me a lot of conflicts .

Would it pose any problems to include string.h in the project on a global space?

Good point on ifdefs...

Well at the moment all gui objects are stored in arrays, each with their own string, at the moment it's not the most effecient but as I go along I am improving it for memory use...

I am removing the ifdefs and only putting them where bmp is drawn...

Only reason I am even bothering with the current main.c is because we don't really have much else going on yet so it provides a good testbed at the moment.

I just pushed some code that is a LOT cleaner, and should work on device (buttons would just render as a text string).

Without a buffer it's quite annoying as everything flashes as it's redrawn which I imagine will only get worse as more elements are on screen.

I am going to ponder over strings for a minute...

Ok seeing as how my programming is generally done for PC's, the concept of worrying about rom vs ram is a concept I am working on trying to figure out...


You say we have a 48k ram limit...

in the fonts file you create arrays of fonts, they are const, does this mean the ptr to them is pointing to a ROM location? Or is all of that allocated in RAM?

So... if defined as const it is rom... but I assume const cannot be changed once set... is there a way to have changable strings stored in rom?

Also what about scope... I assume locally declared variables are gone once the scope is done (I.E. in a function call).

Obviously we are going to need a string table...

48k really is not much...

Yeah I am still trying to think of a better solution then hard arrays... Last night I changed the array sizes and forgot to change some of the loops .

I thought about link lists or dynamic arrays as well...

Certainly a chalange point I am not used to but it's fun to figure it out none the less .

I attempted to enlarge the gui.bmp to a 500x500 image however the program barfed on it and spit out what appeared to be a memory dump, I made it smaller (I think 300x300) which resulted in no error however it was unable to render any piece of the image...