Your bottom line just needs to be moved up and the image can be split up just fine and still be scalable.

In my GUI system, each control can be defined as either Solidstyle or Gridstyle. Solid just stretches the texture across the whole image where as Gridstyle splits it up into 9 sections. The control's style information includes: TopHeight, BottomHeight, LeftWidth, and RightWidth (this limits your controls to having the all of the top grid-nodes being the same height, all of the bottom ones being the same height, all of the left ones being the same width, and all of the right ones being the same width, but it gives enough room to play with in my opinion.)

Anyway, here's where your line needs to be:


However, you can chop the texture up to save space. This is what mine would look like (I've added spaces between each chunk to show how it's separated):

Don't worry, Programmer16's idea will work, just try doing it.

It wouldn't get bad like you think.

I use the same technique as Programmer16 and it works just fine. You have to remember that the only things that get stretched are the four "thin" slices, and they only get stretched in the direction that makes them look the same, ie it goes from being a thin slice to being a thick slice in his second to last image. The curvy parts stay exactly the same and aren't stretched, so there's no problem. You just have to see it in action once to understand it :)

Have you thought about changing your original design to something that's going to be simpler to implement?

I prefer a minimal design myself anyway. This is an old design, but the simplicity of this gui means that it can be coded with vector-like instructions and can scale to any resolution.



You could also move to a completely vector based gui. The cairo graphics library can help there.

There is nothing wrong with having a well coded, but hard-coded gui system for your game. Unless your actual intention is to write a gui library and not a game I think you are over engineering. The windows and widget placements for your game would work well as xml, but it's quite a stretch to think that the file references for the underlying gui rendering need to be dynamic. Unless you want to be able to theme your gui, but then we get back to creating a gui library.

Why write it when you can steal it? I've heard good things about Crazy Eddie's GUI System (try to overlook the name.)

Do you want to write games, or game engines?

Quote:Original post by XTAL256
Yeah, but those thick slices should have a gradient, but they can't if they are compressed to "thin" slices. Don't worry, i like it the way i have now (using 2 vertical divisions). And i can easily change the implementation later to include horizontal divs. btw, what i have now is a little different from my first post.

I'm not sure I understand your concern ^_^; The gradient is not along the scale of compression. You only vary the slice along one dimension, and that has the same pixels uniformly throughout, so the gradient is preserved even if the slice is just one pixel wide. Oh and you do not compress/expand the corner slices obviously, you only vary the length of the edges and stretch the center piece to accomodate. It's really a pretty standard way of handling this, it's used in AWT/Swing and a number of other GUI's as far as I know and I've used it for everything from buttons to windows and progress bars.

Well, even if you stick to your current design (you don't ever need horizontal divisions if you will never stretch the buttons vertically, after all), the recommendations from all the posters above stay valid, that is, you just stretch the center portion and leave the sides always as-is, so a short button might look like
[|==|] and a long one like [|=======|] (pardon my sad excuse for ascii art)

Since it seems that you're stumped on actually coding the draw function, here's some sample code from my Button class:

This method is called once per frame per button to draw a button with the current skin (there are different paint methods for active and for selected buttons, also). Note that it calls private methods getHeight() and getWidth() to scale the button according to the widget size:


What's actually happening there? Well, something like the following. The texture coordinates for the elements in the skin are hard-coded in my case, but of course loading from XML is much better.


Yes, this is all in immediate mode (all of my GUI stuff is), so there might be room for improvement. But this implementation has the major advantage of "it works" :D And as you can see, there's no magic involved. You just calculate where everything has to go and then draw a bunch of quads on the screen.

Oh, and it's not all that hard to write a GUI system, just a bit annoying (For me, dealing with the propagation of focus for mouse and keyboard was probably the most unnerving part, but I didn't plan ahead well enough). Plan ahead with some flow charts for usability and maybe some class hierarchies and it's not that bad. Of course, you COULD always use one off-the-shelf. It's not as easy as sticking a bunch of libraries together and calling it a game, you still have to do all the game data loading / display / game logic / AI and glue code, not to mention spend all that time on assets, like writing, art, modeling, music, and sound effects... there's always enough to do :D