Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (468)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Small Gui System (SGS for short) for Xith  (Read 7273 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Posted 2006-01-20 17:22:11 »

Okay, so me and jaakko777 have decided to make a GUI system for our own games, but in a common effort.
This is intended to be developed relatively quickly, and (I hope) it don't need to be sophisticated.

Here are the defined concepts :
  • Uses Xith multi-pass render capability (class MultiPassView still to add to Xith core)
  • Uses Textured Quad in PARALLEL_PROJECTION mode
  • Doesn't need picking, (maybe just for calibrating when the application is started or the GUI resized ?)
Other features/ideas need to be discussed.

I think we can start doing a sort of Panel object, that is just a colored quad. Then we can do TexturedPanel, a textured quad. Then we can do TexturedButton, a textured quad with mouse reaction. Then we can do TextLabel, using font -> texture generation. Then we can do TextButton and we will have an "acceptable" GUI system.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline jaakko777

Senior Newbie





« Reply #1 - Posted 2006-01-21 17:31:08 »

@BlueSky: I suggest we start a shared project and set it up in either a cvs or svn repository. I can provide the former, if we want svn i might be able to set it up on friend's server. But before that maybe we should exchange some mails to define the precise targets and the implementation. You got mail...

In the meanwhile others can post here wishlists on features (preferrably accompanied with some sort of implementation suggestions). That doesnt neccessary mean that we will do it, but atleast we'll think it and hopefully we will atleast be able to leave room for implemeting it without hacking it. Wink
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #2 - Posted 2006-01-22 01:40:17 »

Why dont you set the targets out for the project and how its supposed to work out before attempting the fine detail of what projection policy to use ?

This way, more people will understand the uniqueness of the project and what its aimed at instead of saying "yeah, its another GUI tool...great"

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jaakko777

Senior Newbie





« Reply #3 - Posted 2006-01-22 03:11:30 »

Why dont you set the targets out for the project and how its supposed to work out before attempting the fine detail of what projection policy to use ?

This way, more people will understand the uniqueness of the project and what its aimed at instead of saying "yeah, its another GUI tool...great"

DP

 Grin Well, I guess mostly since threads about developing guis seem to draw out very long and we are both in urgent need of a gui. Im sure that as we get rolling this will change. I dont think that we are aiming at a complete solution, instead at forming quickly a extendable base to work from.

But this dont need to mean that we will develop this "in the dark", im sure we will post here our targets so you can see whay we are up to.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2006-01-22 08:25:07 »

Hi,

I'd love to see a GUI library actually get released!

One important widgit that I think should be on the initial list with your other three would be a text input box.

Will you be using the 2D text classes already in the Xith-tk project?

One CVS option would be to use the xith-tk project, this is essentially why the project exists.  That would have several advantages over a private server:
1) It's alrady setup and ready to go
2) When I release a Xith3D build, your API would be included (also the javadocs on xith.org/javadoc)
3) Easy for other people to contribute (with your permission)
4) When the initial development has subsided, it can be easily maintained or further developed.  Especially important if the Xith3D API changes
5) It would increase the visibility of your API

Good luck!

Cheers,

Will.



Offline jaakko777

Senior Newbie





« Reply #5 - Posted 2006-01-22 21:40:05 »

One important widgit that I think should be on the initial list with your other three would be a text input box.

I agree, that would be required.

Will you be using the 2D text classes already in the Xith-tk project?

I dont know. I must say its a pretty way to do the 2d texts. However, one thing disturbed me when i checked it out, that the text was allways evenly aligned like in TrueType even if the font wasnt one. If we could change that im sure that would be a strong candidate. Another option would be to draw entire strings in the same manner. Or maybe support both ways.   Undecided

One CVS option would be to use the xith-tk project, this is essentially why the project exists. That would have several advantages over a private server:

That sounds like a good idea!
How should we proceed to get the xith-tk repository in use?

Good luck!

Thanks  Smiley
Offline jaakko777

Senior Newbie





« Reply #6 - Posted 2006-01-23 00:46:30 »

Ok, here are my toughts on the GUI, how i would do it...

1) Rendering the GUI on top of the Scene
The GUI will be implemented trough multipass rendering, where the GUI will be rendered last in PARALLEL_PROJECTION.

2) Receiving User Input
User input needs to be sent first to the GUI logic. If the GUI is not interested in the input then the scenegraph may have it. The GUI will have its own methods for receiving the input and the game will be responsible for forwarding the input to it. This approach also abstracts the input system and the game may implement whatever input system it likes. I must admit i have little or no experience with any input system exept the AWT Events, please point out any stupidities i may assume...

3) The GUI Structure
The GUI should be structured in components (UIComponent) and containers (UIContainer). Containers extend the component and can hold several other components as well as containers. These are base abstract classes that should be extended. The primary GUI object will be a UIFrame that extends the UIContainer. The frame will be able to receive the user input and will also be responsible for determining if the input has any effect on the GUI and for passing it on to affected component or container. A container upon receiving input will check on what of its components/containers the input has effect and pass it on. A component receiving input will call its attached UIListener if it has one. The UIListener interface is where the game should implement the functionality of the GUI.

4) Positioning of the Components on the Screen
The GUI should be able to position the components automatically to the appropriate Z-depth. This could be determined from the nearClipDistance or it could be set by the game. There should be enough room for the components to be layered on different Z-values. A component (and container) will always be lying on top of its parent container.
The coordinates for the component positions should be abstracted to screen coordinates (pixels). This is one thing that I’m not sure how to accieve… Needs research and helps n' hints would be appreciated.

5) Extensibility of the GUI
The GUI base classes should be designed to be easily extended to create new components and containers.

6) 2D Components
These components are probably just colored/textured quads and should support adding Appearance objects to them.

7) 3D Components
These could most likely be treated as Shape3D’s in all aspects.
Offline hawkwind

Junior Member




Java games rock!


« Reply #7 - Posted 2006-01-23 04:16:28 »

One thing to consider is the "skinning of the GUI" 

In my GUI components, based on the Xith UI, Each UI part has a know set of components, title lable, ui type icon, exit button, filler backgrounds texture etc.   When I create a instance of a dialog for example, I pass in an adaptor structure  (an array of textures)  the dialog box displays based on the textures in each position,  exit button is texture position 6, title background is position 2 for example.  This allows me to reuse the same dialog, a collection of UI elements, but also allows me to override the display of these components by passing in different sets of textures. 

I have a generic 512x512, a 256x256, and a 128x128 versions of the same components, appropriatewly resized.  If the dialog does not require a title the the underlying panel, which is not opaque, is not displayed,   Each GUI component also has a user-content panel allowing me a "add GUI elements" to the generic component.  The added element may be a simple dialog structure or  a tile game.  This lets me reuse, extend and redesign a large set of GUI element using a small core set of classes.  Does this make sense??

A game has a full set of textures, title, exit button, background textures, etc  and a panel containing the actual game which is added to the user content panel.

  A simple info box has almost all of textures undefined so that the associated parts don't display and an alpha texture for the info.  This approach allows me to display a comic type bubble window image with text and the rest of the rectangular dialog is transparent...in a sense allowing tme to displa non-rectangular alpha texture in a rectangular but transparent dialog.


Offline jaakko777

Senior Newbie





« Reply #8 - Posted 2006-01-23 06:57:07 »

Wow! Sounds great.
Thats basically what i had in mind also, although i havent really tought that far yet.
Can you tell if you encountered any problems that should be assessed in design phase?

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #9 - Posted 2006-01-23 10:32:50 »


That sounds like a good idea!
How should we proceed to get the xith-tk repository in use?


Sign up for a dev.java.net account, and apply for "Developer" access to the Xith-TK project. I will approve it within 24 hours, then you are good to commit.  I believe MagicSpark is already a developer of the TK project.

More info about the TK project:
http://xith.org/XithTKGovernance
http://xith.org/XithToolkitContributions

You will need to decide on a package name before committing anything.  org.xith3d.ui.sgs perhaps?  David's unmaintained Xith3D swing UI is there named org.xith3d.ui.swingui.

Up to you really, I do think that the benifits of using the xith-tk project for this sort of undertaking are good though Smiley

Cheers,

Will.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline hawkwind

Junior Member




Java games rock!


« Reply #10 - Posted 2006-01-23 13:31:15 »

The main thing in my setup is handling events.  I use the hial lib to gather and store keystrokes and mouse events.  For my simple purposes at the moment GUI's retain their own events "exit button pressed" and the render loop queries the GUI for their indidvidual events and does the appropriate thing.

Dont overlay Xith UI componetnts GUI A with button B may/does not work if on top of GUI C.  I thinl the Event the Xith GUI elements handle are based on mapping screen space to on event such as a mouse click if N GUI's are on the same block of real estate the system falters...cant decide who got the evednt.
Offline jaakko777

Senior Newbie





« Reply #11 - Posted 2006-01-23 17:37:25 »

Hmm.. I was really intending to do components that can be layedred. Im pretty sure that if you keep record of their Z-value this can be done. But you would have to do it manually. And not only keeping record but updating the Z-values as the focus changes.

A component would allways be closer than its container. And no container should be at the same distance. Actually when this is done in PARALLEL_PROJECTION they can be spread over a huge distance as that has no meaning for their presentation, exept for what gets drawn on top of what - and thats just what we want.

Then you would just keep a record of their "distance" and based on that determine who gets the event if there is a conflict.

Im still considering also the picking since i cant believe that it would be a performance hit since there arent that many shapes in a gui to test for.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #12 - Posted 2006-01-23 18:49:11 »

@jaakko777 I totally agree with you on all you've said in your post with 1), 2)...
Hmm.. I was really intending to do components that can be layedred. Im pretty sure that if you keep record of their Z-value this can be done. But you would have to do it manually. And not only keeping record but updating the Z-values as the focus changes.

A component would allways be closer than its container. And no container should be at the same distance. Actually when this is done in PARALLEL_PROJECTION they can be spread over a huge distance as that has no meaning for their presentation, exept for what gets drawn on top of what - and thats just what we want.

Then you would just keep a record of their "distance" and based on that determine who gets the event if there is a conflict.

Im still considering also the picking since i cant believe that it would be a performance hit since there arent that many shapes in a gui to test for.
I agree. Picking is really practical for me because it permits me to converts easily mouse coordinates into world coordinates. For the Z-value stuff, I think it's not really hard to do. Okay so we can begin soon (CVS stuff).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline jaakko777

Senior Newbie





« Reply #13 - Posted 2006-01-23 21:43:25 »

Ok, now then as Will pointed out we need to choose the package name.
Do we use org.xith3d.ui.sgs or maybe something a bit more descriptive?

Im short of ideas, does anyone want to suggest something that goes with what we are planning?
This is something that cant be changed later so i guess its quite important ---> youll have to live with it when its decided  Tongue.

I took a dictionary/thesaurus to my aid and decided to whip up a few suggestions and here they are:
- We are doing a really basic gui that is intended to be easily extended/modified. ---> org.xith3d.ui.modular or org.xith3d.ui.abstract
- Our gui is based on scenegraphs as opposed to swing. ---> org.xith3d.ui.graph
- It will make the renderer work in multiple passes. ---> org.xith3d.ui.multipass

Dont get me wrong, org.xith3d.ui.sgs is fine by me but honestly I couldnt tell what it is by the package name...
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #14 - Posted 2006-01-24 18:22:53 »

org.xith3d.scenegraph.ui ?
(jaakko777, look at the subject I just started on this board about Xith toolkit and all that stuff).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2006-01-26 08:54:11 »

My 2c:  I think it would make sense (whatever the name) as a subproject of "ui" since it is a GUI related tool and can accompany the others already in there.

Will.

Offline jaakko777

Senior Newbie





« Reply #16 - Posted 2006-01-26 10:17:03 »

I agree it should be there..
I'll think about  the name a few more days.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #17 - Posted 2006-01-26 19:08:25 »

I propose the name "Guild". It stands for "Graphical User Interface Library for Developers". I think it's a funny name that goes well with this project and is pretty explicit because it has "Gui" in it. Note that if you find a better signification for the last "D", you're welcome.
So the package name would be org.xith3d.ui.guild.
I currently have to work a bit on my physic engine (hopefully it won't be long), and then I'll probably do an "implementation draft", cause I need it for my physic test/debugging, and for my level editor too.

Oh and I also work on a triangulation algorithm (using the Two-Ears Theorem). Since my levels' terrains are made of non convex 2D polygons, I need to triangulate them for displaying them and for collision checking. If it works well I'll put it in the toolkit too, although it's pretty more of a geometry library. Then I can put it in Gymli (By the way I have to set up a dev.java.net account for that project soon).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #18 - Posted 2006-01-26 22:02:32 »

Didn't you want to call it sgs? Guild ofcourse is a funnier name Smiley

Quote
(By the way I have to set up a dev.java.net account for that project soon).
I'd hurry if I were you - they might take ages to approve your project Wink

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #19 - Posted 2006-01-27 16:51:04 »

Didn't you want to call it sgs? Guild ofcourse is a funnier name Smiley
Yes but, first Guild is a funnier name, as you said, and second it's much more explicit (because containing the GUI letters in it).
Quote
Quote
(By the way I have to set up a dev.java.net account for that project soon).
I'd hurry if I were you - they might take ages to approve your project Wink
Then they'll wait.. I don't want to mind about making this project available to the other developers until my game is functional. Seems very selfish, but it's really wise to do so, I just don't want to make the same experience as I did with Gamma. (Although my personal libs are really better now than Gamma was... Smiley )

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline jaakko777

Senior Newbie





« Reply #20 - Posted 2006-01-31 14:44:07 »

Whats your progress <MagicSpark.org [ BlueSky ]>?
Communication has been almost zero between us during the project, and as a matter of fact all that there is is on this forum...   Undecided
I have progressed to a good start on my behalf and now i wonder weather to recheck and try to bring up some cooperation or should i just burn more gas and head on out finishing one GUI system by myself.
I dont really mind working alone, infact i prefer now that since i feel that i have formed a good start by myself and feel confident in developing it alone and the way that i want it to be.

Do you have any comments on this before i start my own thread about it?

 Smiley Cheers,
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #21 - Posted 2006-01-31 17:31:26 »

Whats your progress <MagicSpark.org [ BlueSky ]>?

I have not progressed, cause I didn't even started to code Guild.
The reason is I didn't realized physic simulation was a sooo complex topic and I just underestimated the needed time to implement it.. An additional factor is my requested feateures list has been dramatically growing recently...

Quote
Communication has been almost zero between us during the project, and as a matter of fact all that there is is on this forum...   Undecided

That's right, but communication between us can be made on this forum.

Quote
I have progressed to a good start on my behalf and now i wonder weather to recheck and try to bring up some cooperation or should i just burn more gas and head on out finishing one GUI system by myself.
I dont really mind working alone, infact i prefer now that since i feel that i have formed a good start by myself and feel confident in developing it alone and the way that i want it to be.

If you prefer to work alone, I won't put my big bears paws in your work  Cool
However if you don't mind having some help (assuming I wouldn't have the same level of authority over the project than you), just put it directly in the xith-tk CVS, because it's here intended to put the work I wanted to do.

Actually I have to test and tune 2D physic simulations and I have already done a level editor (using Xith) but I don't know wether it's a good idea to use Guild instead. If it was the case I would contribute a lot because I need it for level editing and also for testing/tuning.

Quote
Do you have any comments on this before i start my own thread about it?

 Smiley Cheers,

Why would you start your own thread about it ?
Don't forget to share your work ! (if you make it alone)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #22 - Posted 2006-02-01 18:58:04 »

Hey Boys!

Sorry that I havent posted on this earlier! I really should read the forum more carefully (*bad johannes, bad, bad Johannes*) Smiley

I am working on something quite similar, though for a broader audience. I remember the days when I developed a flight simulator entirely in Xith for a computer graphics grad. course at my Univ. Back then I used Xiths pretty neat Swing-to-Texture mapper to display a simple Swing GUI as an in-game element.

Long story short, maybe you know FengGUI already? If not you can check it out here. And I would like "to sense" the possibilty for us to join forces in order to build a really cool GUI system.  Smiley

Johannes

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #23 - Posted 2006-02-02 18:30:01 »

I think this is really cool, and if I had time I really would join this project.
Unfortunately I'm actually learning about physic simulation and this takes me loads of time.
Anyway this is a really good initiative and I'll probably use it (and why not contribute) when I'll need a GUI system.
But how will it be integrated in Xith ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #24 - Posted 2006-02-03 18:42:09 »

But how will it be integrated in Xith ?

Yepp, that's exactly the problem. I and this is where I am hoping you can help me out.

FengGUI supports currently two rendering peers, namely LWJGL and JOGL (btw, FengGUI stole the concept of rendering peers from Xith, though it is a bit modified). The rendering peers are mainly implementations of this interface (a subset of required gl commands) and this interface (an interface to handle a single texture).

If we could somehow implement this interfaces to run on Xith, the intergration would be piece of cake. However, I can imagine, that this approach pays the simplicity with a rather odd design from an architectual point of view, which I cannot decide since I have no inside in Xith. So what do you think? Smiley

Johannes

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #25 - Posted 2006-02-04 11:21:18 »

It seems possible (I just looked at the interfaces and I don't think there are Options Xith3d doesn't support).

Maybe we could also make it acces directly Xith3d's jogl or lwjgl renderer? Then it really could be a no-brainer Wink
To do this, we could simply let it render in another Render-Pass on top of the scene

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #26 - Posted 2006-02-05 06:47:21 »

Cool! I love no-brainers!

Maybe we could also make it acces directly Xith3d's jogl or lwjgl renderer?

I am afraid I cannot really answer the question because I know zilch about the internal organs of Xith. But it sure sounds good!

Don't you feel like joining FengGUI as a developer? Grin

Johannes

PS: Unfortunately, I leave on vacation today (for two weeks) and I am not sure if I have an Internet access there...


Offline jaakko777

Senior Newbie





« Reply #27 - Posted 2006-02-06 10:51:53 »

Some update from my progress:

I have a very well working system for the basis of any kind of gui. I have made two abstract classes (component and container) that are capable of handling the positioning, sizing, and such. Infact they handle everything exept two things that they require a subclass to implement; first they need to provide a method returning a node that will be used to render the component, second they need to provide a geometryUpdater method that can handle updating the geometries in the node it provided. Both can be left empty, of course you wouldnt want to leave the first one empty, if you leave the latter empty then the component will not be able to for example resize should it be needed.

In addition to those two forming the base of the system i have extended one container (UIPanel) and one component (FPSCounter). In the FPSCounter i used the DText2D class from the toolkit but i had to do a lot of customization so i might have to make a new one (maybe UIText) just for the gui.

Last night i squeezed in one more thing; support for layout managers. I made the interface and implemented a swinglike GridLayout. Im still just beginning to think about the layoutmanagers so ill elaborate on that when i know im doing it the right way (maybe taking a peek at awt sources Cheesy).

Oh, i almost forgot; the gui is interactable by implementing a listener on your topmost gui container and then delivering events from your input layer. The methods return boolen so you can know weather the gui "consumed" the event or was it targeted at the scenegraph. The components are currently draggable and clickable, and some attributes can be defined to them that changes the behaviour they react to these events: they can be draggable or not draggable, they can cross the screen borders or not cross, they can dock to the screen borders or not dock, they can be auto resizing or not.

Lastly, using the multipass rendering the screen scale is set relative to that of the screen pixel size (for a 800x600 window the screen scale is set to 400) in the pass when rendering the gui. This enables to position and size the components in pixel scale. This also enables the gui components to remain of constant pixel size even if the window is resized. I made the first prototype without this feature, it worked fine but i had to do a lot of extra computing to get the locations right and the components were also resized when the window resized. Maybe i will provide both options.

Ill clean up the code, javadoc it and post some screens next.  Wink
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #28 - Posted 2006-02-06 18:34:56 »

Good work !

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline jaakko777

Senior Newbie





« Reply #29 - Posted 2006-02-07 00:20:39 »

Here is a screenshot, although its not intended to be pretty yet, you can see that it actually does work Tongue

There are some more stuff visible since from my last post; the button and a "panel" showing the wireframe of a shape from the scene selected by picking.

[size=8pt]Edit: Dont pay attention to the FPS of 77. That has nothing to do with the gui but with the scene... It's ~750 without the scene and only the gui.[/size]
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

theagentd (6 views)
2014-04-24 23:00:44

xsi3rr4x (83 views)
2014-04-15 18:08:23

BurntPizza (75 views)
2014-04-15 03:46:01

UprightPath (86 views)
2014-04-14 17:39:50

UprightPath (69 views)
2014-04-14 17:35:47

Porlus (86 views)
2014-04-14 15:48:38

tom_mai78101 (109 views)
2014-04-10 04:04:31

BurntPizza (169 views)
2014-04-08 23:06:04

tom_mai78101 (265 views)
2014-04-05 13:34:39

trollwarrior1 (216 views)
2014-04-04 12:06:45
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!