Very nice Lukas...
I see you have info about LBGUI on your web site...
I look forward to seeing more of your web site completed.
You obviously have control of C-Lite as your GBUI project shows.
Thanks for sharing and best of luck with the contest...

Hi,
based on this cool lbgui i've started GSTGUI with only one skinfile instead of 120 files to show the usage of SpriteSheetPacker2LiteC.
Look here

So you made a tool to puts all skins into one file and added some functions to LBGUI?
Nice.

But you lost the alpha channel of the window borders.

And you just took my demo and changed it, leaving many things like they were, making the texts confusing, lol.

And why does a MessageBox need to be resizable?

Btw, your demo freezes when I try to close it.

Hi Lukas,
Your Gui System is great. At the moment I am creating a small addition to your header with procedural rendered graphics, because I hate to copy/create Bitmaps every time I need a gui in a small test project.
Until now it is only a plain Win98 style, because that's enough for prototypes and small tools.

My problem is:
My window borders are very small bitmaps (6 x 16 pix).
I have seen that you have used bmap_blitt to resize your windows.
The problem is, that my small graphics get "washed out" through the blitting/resizing. I hope you understand my problem
My graphics are exact fitting on eachothers edges, but blurred horizontaly. I don't completly understand the algorithm of the bmap_blitt function. I checked your function and saw that you use the original hight of the middle Titlebar. But it is blurred out as if it would have been scaled in y direction.

My suggestion:
What do you think? Is it usefull to rewrite the scaling function and use the panel element "window". Of course you need a long bitmap with the length of the maximum resolution, but it would be an enorm gain of speed when it comes to resizing.

Yeah, I know bmap_blit doesn't work like I would want it. If you look carefully at the (in the examples) black area of a window, you see some kind of lines, which are also artefacts of the bmap_blit scaling.

Your idea with the windows might work, but this would require creating a bitmap that is big enough so it's always bigger than the window. As it would seem senseless to create such big bitmaps in files, I guess it would make sense to create them procedurally with many bmap_blit commands. But I think this would be much slower than one bmap_blit command, although it normally could be faster if bmap_blit had an option for "nearest neighbour" interpolation. That's why I would hate using workarounds like this. I would prefer an option to scale bitmaps fast without getting them blurred.
Also, this would destroy the possibility to have a border bitmap with a width of more than 1 pixel, which is then scaled.

But if you think it would be useful for your project, you could rewrite this part of LBGUI yourself. I currently don't have the time for an update like this anyway.

If your window doesn't need to be resized, you could also create a bitmap for the whole window and then assign window->panel->bmap to that bmap each time your window is updated.

So, I tried it and it worked well.
the "window" element of the PANEL struct has a nice habbit.
If you use a bitmap that has the power of 2 it will be repeatet, when you exceed the borders of the given bitmap in dx or dy.
With this method you can use very small bitmaps, without interpolated pixels.
I removed every blitting operation in your header (concering the Windows) and I removed the bmap_createblack command ind the window_update function.
The update function only sets the window elements positions new and scales the borders and the content.

The speed gain is huge.
When I cleaned up the code tomorrow (or weekend) I will upload it.

I don't now If I am boring you with this posts I hope not.

Nice, I didn't know about this behaviour of window elements. In this case, window elements are a nice and much more efficient solution for resizable windows.

When I finally get the time to make an update for LBGUI, I'll propably include your solution and add a flag for this, so you could still use the old method for backwards compatibility. I was going to make an update for LBGUI anyway, as I'm currently adding some small features for one of my projects, and I need to do some bugfixes. But as I said, I currently don't have the time...

I'm looking forward to trying your code.

"I don't now If I am boring you with this posts I hope not."
Yaaaawn... what?
No, seriously, you are not boring me, always like to see better solutions for my problems.

Hi,
Here is my Project.
I had not the time to clean the code. It is a bit unclean here and there.
To test my modifications you have to run the "render.c".
I used your split scripts, because SED realy sucks when you open big files.
Until now I only modified "lbgui_windowfunc.h":
I copied "LBG_window_border_bitmap" function to(LBG_window_border_bitmap_n)
and
"LBG_window_content_bitmap" function to(LBG_window_content_bitmap_n)
you will see.
The panels (content and panel) still have the bitmaps attached. With the window elements, you could delete them completly, of yourse with backward compatibility in mind you should not.

Link: Project

I have a small problem with your gui system.
- My mouse Mode is 4
- I am in fullscreen mode
- A mouse_map is attached
Problem: The mouse flickers when I am on top of the titlebar

MfG,
Me

Nice, the window is resized without any lag.
But the Windows 98 style isn't quite nice for a game or even a tool.

I haven't looked much in the code other than the changes in LBGUI, but I don't think LBGUI is responsible for the mouse flickering because it doesn't change the mouse directly. So it must be something in your own code.

I know Win98 is not very nice. And it is a bit too small for big HD resolution.
I am working on a tool to create your own procedural rendered graphics (with alpha channel). It is like a paint programm with the typical brushes. The generated code will be loaded and parsed by my lite-c header. So you start the generator with the filename as parameter and then LBGUI.

At the moment I am trying to find the flickering problem.
It only appears consequent, when a window is maximized.