Hello,

As some of you may know, I am writing a GUI dll and editor at the moment.
This brought up some question, or let me say problems.

First of all, a speed vs compatibility problem:
Using panels for the GUI-elements would be better, if you want to have to
have the same layer system as in the native GameStudio system. (If you
have any other elements with a layer, they would work as intended) -
but that would be slow... The other method would be using draw_*
commands, that would be faster than panels, but your elements would
always be below the GUI.
Okay, a quick test changed the situation a bit - it seems that
panels are not really slower (maybe even faster D: ) than draw_ calls.


Next problem: Image source
There are some plans for the image source of the elements. The first is
the simple "use a image for every state of the element" which is very
self explaining. The next method is, that all states (of a button e.g.)
are in one picture, that is tiled. Another method is using .fx (shader)
to create those elements procedurally. This prevents ugly scaling and
the like.



There will be many features, that are not available in the standard
GameStudio GUI, an alternative input (way better than inkey/inchar -
tested!), a nice and usable standard image set, the great editor and
easy usage.


Thanks,
Marian

Drawmode single choice
	panels
	draw_*
Votes accepted starting: 10/12/11 08:32
View Results

Image source multiple choice
	Multiply pictures
	Single pictures
	Procedural pictures
	Something else (please post in comment)
Votes accepted starting: 10/12/11 08:41
View Results

That sounds very interesting to me, especially the editor!
Would make creating complex guis much more easier, i suppose!
If you allow procedural pictures, you should also implement at least one other options for developers who are not familiar with procedural generation.

Also it would be interesting to know how much of a speed difference there is between panels and draw_-calls. in general, I would prefer panels, but if they are a lot lot slower then draw would be ok. Depends on if there is any widespread usage for which panels are too slow.

FYI: The editor will have a drag'n'drop interface, like the form editor of Visual
Studio. There will be two options for scripting - user functions and a pattern
based scripting, where you can do simple things by having boxes, that can be
connected.

I don't really get what you mean by having at least one other option, as I am
going to have as many options as possible, but I wanted to see with this poll, if
my ideas are usable.

(Btw, of course there will be example and it will include a default procedural
image shader that will be used, if the user does not select any other source
-> fast prototyping of GUIs)

For the speed thing, well, I only read other users opinions about that (e.g. in
the 2D scrolling game thread by Joozey(?)), so I used it my IsoEngine project
too. I have to admit, that I have never made a real comparison, but a quick
test with 800 non moving 2x2pixel panels/quads showed, that panels were faster
in that case. If that is always the case (I need to think about a better
test...), the first poll is useless.

Hi,
I appreciate your project, Rei - but would like you to think about if this is really necessary: to start/develope a new one.
Don't know if you realized it, but Lukas did make a really good Lite-C header for creating GUI elements called LBGUI. And he continues to improve it - with a great support and eye on user feature requests. (thx!)
Anyway, an editor sounds great. But maybe you can join Lukas and continue with him his great work (he's german as well). Even though it's not dll grounded.
Greetings

Short answer: No.

Long answer: No, I am not going to use LBGUI, because I don't like its style,
its usage and it was slow... It also didn't feel good (the handling) -
especially the text input. My GUI already has more different buttons, less
coding to get them and so on. The editor won't output a script, but a
definition file, that could be (theoretically) read out by any script and
parsed to LBGUI (if you really want to use it).
When it comes to support, well, I get support from Felix Queißner, and you will
get any support I can afford, because I want to sell this editor/dll for
like 5-10$ and support is important to me.

I see. In this case I wish you much luck with that project! I'm curious about the outcome. Submitted vote!

´Bout multiply pictures and usage of panels: Please make sure that dds files are working.

Rei, please support all ways to skin a GUI. I also dislike in the first place the idea of doing draw_ calls, but maybe this comes in handy, too, some time... so why not doing all the possibilities?

@Clemens: Thanks!

@fogman: Okay, I am putting dds on my list.

@HeelX: I am going to support as many ways as I can, I just wanted to see if one of my "ideas" is not liked at all.
Yeah, I think I am going to support both, draw_ and panels, because the poll is not that clear.

When I start to do this for my application, I usually make an image that is scalable, e.g. all parts of the gui have a certain location in the image, which I read out. Corners have a static size, but frame edges can be stretched (and thus are usually 1px in width). Perhaps you can use this idea to make a little (standalone) gui component editor in which you can load an image, select the object you wish to skin (e.g. button) and drag the scalable/static parts of the button like a puzzle in your image. Write output in a separate gui skin coordinate file or so, that can be loaded via your dll.

This way you can neatly have a single image containing the skin for all components, and by "unwrapping" all these gui components into your image create a skin coordinate file. You could obviously colors in the image without the need to create a new coordinate file, but when the scale needs to be different, you'll have to make a new coordinate file.