Created a test window that hovers on the 'desktop' (currently BASIC prompt) out of sprites and a GFILL box. Window is at -75 depth (Z-index), GFILL at 0. Window uses 12 sprites including buttons + 1 addtnl. for the icon (, set at -25 Z-index.) Much still to do.

So the window outline is text? I suppose it has its benefits. I might suggest allowing users to turn the 3D off, because it can be annoying in some tools. (They may want, for example, 3D in a game, but not on the windows themselves.) Also, the active window is drawn in front of others. This might not be a problem if you draw it last, but it might cause issues with the staggered depths.

I dont know is sprites is a very stable approach, since that means a limited number of windows can be open at once

@Lumage the window border is made up of sprites, not text. As far as 3D, it will be used to draw the active window in front of others, & when the active window changes, the "root" sprite (which all window sprites link to) of each window (active & former) will have the Z index adjusted through SPOFS. Users can also turn 3D off any time via the slider, at which point the effect will render in 2D.

@Simeon It's still a WIP, but i felt that sprites gave me the highest level of control over the window look, feel, and controls. I could be wrong, however. This here is just a test of drawing the window. Basic stuff. I do intend, though, for there to be a window limit; Too many windows can clutter the display and can be confusing to manage. This is running in SmallBASIC after all.

Have you ever heard of a 9-patch image? Something like that could greatly cut down on sprites and make skinning easier.

@Kl'Dck Hul: No I have not actually. Care to explain? If it supports full control over the design, adjustment of the Z-index per window (as opposed to the entire drawing space), resizing of the "window" without compromising elements, and attachment of sprites (Window Controls) then I'm all ears! (These req. are a must!)

Since other programs are running in this, you want to use as few of their resources as possible. GPUTCHR would allow you to draw to the graphic screen instead, but is trickier and may impact performance. Either method can be done with a 9-patch, where you have 9 graphics: 4 corners, 4 sides, and center. Corners are placed normally, but sides(+center) are 1 graphic, stretched to fill the space.

O-o-oh. That makes total sense! I could stretch the sides and top to cut down on graphics AND have a more refined range of window sizes! (Since it'll no longer rely on the width or height if the side sprites {16x16px}) Thanks for the tip!