Slick Forums

There are some really nice "power" GUI libraries for Slick\Lwjgl (Nifty, TWL), but, unfortunately, it seems that there are no good, up-to-date, supported simple GUI solutions for Slick2D.

Thus I've finally decided to step up and attempt to fix the situation .

Current effort can be seen here (now at R2):
https://sourceforge.net/projects/preui/

It strives to minimize the writing part of game creation as much as possible, probably violating some of the good coding conventions - but I suppose it doesn't matter that much for most simplier game projects.

And it doesn't bring any noticeable overhead: I've tried placing 300 elements on screen at the same time, and haven't lost a single FPS .


Here is a complete example of how the Main Menu could be defined (quoted from the included Examples package):







Comments, criticism and RFE's would be more than welcome .


N. B. It is still incomplete, as it lacks more complicated UI elements like Sliders and CheckBoxes - toDo... toDo... If there's demand, I'll do them faster.

There definitivly is a high demand

I am looking for a good UI framework for quite a while, as a temporary solution, i work with keypresses and render text onscreen -.-

Welcome!

At first read I've found very difficult to read your code because you don't follow Java naming conventions:
- using underscore in class name (A_Starter),
- uppercase for variable name (int MainMenuStateID),
- underscore in variable name (Menu1_Steel_400_400),
- uppercase for package name (PreUI.vaults.FontVault),
- uppercase for method name (AddButton ..),
- static resource loading (for example in ImageVault),
- lot of depedencies (http://sourceforge.net/p/preui/code/11/ ... endencies/): what are exactly PreUI dependencies?
- using lowercase in class name (node.java)
- log on systemoutput, better if you can put under slick Log on right error level (info, debug, error)

Because this is on all code, I think that is your style and this is okay, but my suggestion is to use Java naming conventions if you want to build a library or better, follow same style of Slick Api because PreUI aim to be a slick ui api

About SlickStateTemplate, I have another library (MarteEngine) build on top of slick that already extends BasicGameState, do you have in mind to extend it or do you think is possible to encapsulate logic in my code without extend anything?

Can you explain "processClickedMarker" way to retrieve click on buttons? Seems to be something unusual for Java, where this kind of thing is handled usign Listeners

my 2 cents

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

/ i work with keypresses and render text onscreen -.-/

Text rendering is implemented quite extensively in current PreUI . Keypresses are not processed internally yet, though, as I mostly work with mouse. Priority increased.



/At first read I've found very difficult to read your code because you don't follow Java naming conventions/

My bad. Since it's public now, I have to clean it up.

What would be the good naming choice that would allow to separate sorting-IDs (A, B, C) from the class name itself? I use such sorters only in examples, to make the order in which sources are to be read more self-explanatory.

Uppercases will be fixed in R3, thanks.

Static resource loading is done consciously. Apart from being "bad practice", what harm does it bring? IMHO, having a predefined set of basic resources is good. If they trouble you, I can make them non-loaded by default and require an explicit call from programmer.

I probably should add some integration with Slick ResourceManager, but it's a question that needs further investigation -whether any sort of additional integration is actually needed, or if it would Just Work (TM) already.


Dependencies: most of them actually are Slick ones, PreUI generally depends on itself and on Slick. Complete pack is included to simplify the checkout process - I provide the pack I work with personally so that ""Which version?" question would not arise.

Logging: once again, my bad. I hope I'll migrate to proper logger by R3.


/About SlickStateTemplate, I have another library (MarteEngine) build on top of slick that already extends BasicGameState, do you have in mind to extend it or do you think is possible to encapsulate logic in my code without extend anything?/

I'll have a look at it, I don't know how much they overlap. Probably one of us could extend from the other. Or I could externalize most of the UI construction logic to non-State module, but you'll lose some of the briefness then, as you'll have to write "someModule.addButton" rather than simply "addButton". It's minor, but can be annoying .

What is your extended BasicGameState? "World" class or something else?


/Can you explain "processClickedMarker" way to retrieve click on buttons? Seems to be something unusual for Java, where this kind of thing is handled usign Listeners/

Listeners are fat . In order to implement one, you need to define one additional method per button (or per group of buttons if we take Nifty - overhead coding anyway). I use a simpler (prehistoric) way: check if mousebutton is clicked, then check coords from the list of stored State elements to find out which element is under the mouse now (unclickable elements like menus are ignored). It's not as expensive as it sounds: as I've mentioned above, both redraw and click processing for state with 300 element stayed at constant 100 FPS, so that shouldn't be a problem.

What good do the listeners bring to the table? I suppose system could be taugth to silently catch button listener signals and redirect them to something like processClickedMarker for further processing - but is it actually worth doing?..


Thanks for the valuable advice... And sorry for the mess: even though I've been leisurely coding for about half of my life (not in Java, though), I'm not a properly educated programmer, and I guess it shows .