Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (521)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (589)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 12
1  Game Development / Newbie & Debugging Questions / Re: Bitshift Operators in RGB values? on: 2014-11-10 16:20:33
An excellent tutorial for understanding all things (I joke, if only) bitwise. for future reference and future readers of this post.
2  Java Game APIs & Engines / OpenGL Development / Re: Particle/Billboard rotation issues on: 2014-11-09 11:59:02
So think about it. (Following ignored translation just to be simpler) Your camera rotates your projection matrix by -pitch and -yaw, which simulates a camera rotated by pitch and yaw. Then you have the (rotation part of) the model matrix set to the identity ie not doing anything. So essentially your particle will be rotated by -pitch and -yaw, which obviously works when pitch and yaw = 0 or 180 degrees (180 assuming back face culling isn't enabled) but no other time.

So if you want to get a nice billboard effect, you have to have the model matrix to be rotated by pitch and yaw as well, (or don't have the projection matrix rotated). Now there are better ways to do this computationally speaking but it really isn't necessary.
3  Game Development / Performance Tuning / Re: JNI passing data from Native to Java on: 2014-10-29 13:25:43
To be fair you kind of expect Windows to not allow programs to kill it. Windows is the equivalent of the JVM. It's like the JVM crashing when a Java program doesn't catch an exception. I suspect that Windows did not crash but rather it slowed down trying to find more memory to use and seemed to be non-responsive.
4  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL] Making The Camera Look At A Point on: 2014-10-29 09:27:43
If you are going to roll your own camera implementation straight from the matrices, then you really need to understand the maths. I find the best place to learn this stuff is here: It's not too long and will give you a firm basis in vector and matrix maths as they apply to 3D graphics.

If you don't understand this stuff then I'm afraid you are just clutching at straws and you will run into problem after problem.
5  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-10-24 17:10:49
V nice.

Released alpha footage of Basingstoke today:

Cas Smiley
That's awfully, awfully pretty. Not much else I can say just from the new video.
6  Game Development / Newbie & Debugging Questions / Re: Is using glScalef(...) frowned upon for 2D? on: 2014-10-24 11:37:45
The glScale(), as I stated above, is part of the fixed function pipeline. It can be used with immediate mode or deferred rendering.

There are two different options in OpenGL which everyone gets confused about.

Immediate Mode vs Deferred Rendering
Immediate mode uses commands like glVertex3f(), glTexCoord2f(), glVertexAttrib3f() in between glBegin(), glEnd() blocks. It is called immediate because you send OpenGL the vertex data and the primitives are rendered (pretty much) immediately. Deferred rendering uses VBOs. You send OpenGL the vertex data and it keeps it. You can render primitives with it at any time, hence the rendering is deferred from sending the data.

Fixed Function Pipeline vs Programmable Pipeline
Fixed function uses commands like glTranslatef(), glRotate(), glScalef(), glOrtho(), glMatrixMode() as well as (amongst other things) all of OpenGL's built in lighting support. It is called fixed function because the primitives are modified through set fixed functions, you can modify the parameters of the functions (like the contents of the matrix) but it is quite an inflexible system if you want to to do anything beyond what it is designed for. The programmable pipeline uses shaders to modify the primitives and it is called programmable because, guess what, it is programmable. This means you can do pretty much whatever you want. One important thing to note is that you can still access the fixed function matrices and lighting parameters in earlier versions of OpenGL so if you make use of them, then the above functions will still work.

I hope that clears things up.
7  Game Development / Newbie & Debugging Questions / Re: Is using glScalef(...) frowned upon for 2D? on: 2014-10-23 17:32:56
All of the OpenGL fixed function transformations ie glTranslate(), glRotate(), glScale() etc. perform the transformation the same way. They combine the transformation into the current matrix. Hence using glScale() will have absolutely no effect on performance (other than the actual call to glScale() which is trivial), doing things cpu side by drawing bigger quads would be worse.
8  Game Development / Newbie & Debugging Questions / Re: Collision with inclined plane. on: 2014-10-17 21:15:27
Firstly, that is far too much code to post. You should be posting small sections of relevant code. This code is both long and not relevant and also (and I mean no offence here) but it is in what looks like Spanish and that isn't helping the members of an English speaking forum either.

Now your question. Firstly, are you talking about just the maths of the collision, or the collision response. If you're talking about the collision then a Google search for "plane-sphere collision test" will yield all the results you should need. Come back if you have more specific questions.

If you're talking about the collision response, then you need to think about normal response, the sphere's stretching (and hence bouncing) ability and elasticity of collision.

The normal response is the force the plane exerts on the sphere to stop it falling through and it is called normal response because it acts in the direction of the plane's normal, ie perpendicular to the plane.

Bouncing occurs when the top of the sphere continues to fall whilst the bottom remains at rest, compressing the ball and giving it elastic potential which then converts to kinetic and pushes the ball up. You can cheat this by simply scaling up the normal reaction based on a coefficient of stretchiness (no idea what if any this's name is. Partly Young's modulus but something else as well must be).

Elasticity of a collision determines how much of the energy remains as kinetic and how much dissipates. This will combine with the above so that balls don't bounce infinitely.

To implement sliding properly, you will need to do friction as well.

In terms of answering implementational questions, you will need to post more succinct code. I can deal with the Spanish but English comments would be appreciated.
9  Game Development / Newbie & Debugging Questions / Re: Edge of the island (Release) Android on: 2014-10-15 10:38:27
-Wrong section.
-No description

Add a description and politely ask a mod to move it to the correct section.
10  Discussions / General Discussions / Re: painful maths that will hurt your brain... on: 2014-10-12 10:21:35
So here are my thoughts for what they are worth, bearing in mind I have also never done any algebra with modulos. But I agree with @philfrei about that being the way to solve it and the whole infinite answers of x thing. @moogie I suspect the reason Wolfram told you otherwise is that it either interpreted "log x(28274625)" as "log of (x times 28274625)" rather than "log base x of 28274625" or it misinterpreted the modulo symbol or both.


7 = logx(28274625) % 17

(n * 17) + 7 = logx(28274625)  Where n = 0, 1, 2, 3... (not -ve since log(a) > 0) using @philfrei's equation.

Now it gets a bit hairy.
Take the change of base log formula

logb(a) = logd(a) / logd(b)

logd(b) = logd(a) / logb(a)      Making the original base, b, the subject.

ln(b) = ln(a) / logb(a)        Just for jollies lets make d = e -> logd(a) = ln(a)

b = e^( ln(a) / logb(a) )

Now lets sub the original equation into that. b = x, a = 28274625, logb(a) = (n * 17) + 7

x = e^( ln(28274625) / ( (n * 17) + 7 ) )

Giving some example answers (to 4dp): (n = 0, x = 11.6007), (n = 1, x = 2.0440), (n = 2, x = 1.5196) etc. and you can see the trend.

Also just noticed that final answer can be simplified to:

x = 28275625 * e ^ (1 /  ( (n * 17) + 7 ) )

However this does not use the hint at all or even give nice numbers so I don't think it is right.
11  Game Development / Newbie & Debugging Questions / Re: Box2D Circle works but not pentagon Polygon? on: 2014-10-12 09:45:12
Your way is the way I would do it and I see no problems. Are you sure there isn't an issue with how you are rendering it? As a point of interest, the one thing I can think of different between a box and a pentagon is the pentagon has an odd number of vertices whereas the box has an even number. The same (probably) goes for the circle. So maybe try a hexagon and see what happens there.
12  Game Development / Newbie & Debugging Questions / Re: Netbeans string concatenation wrap on: 2014-10-04 18:11:53
Yes and security vulnerabilities aside, in NetBeans you can set most formatting preferences by going "Tools|Options" then going to the "Editor" tab and then the "Formatting" sub-tab. There all kinds of options in there for all the various languages you have support installed for. I don't know if that is there (and off the top of my head, I thought it did it automatically) but if the option exists I recon that is where it will be.
13  Java Game APIs & Engines / OpenGL Development / Re: [batching] How to transform drawing primitives on: 2014-09-26 19:47:02
The problem with batching is that you can't really batch together meshes with different transforms because you have to modify the modelview matrix between draws, which is not batching. So if you want to do something like that then the best option really depends on what gives the best performance and is easiest to implement.

You can either compute the transforms cpu side as you have said. Or it might give better performance to give up on batching all together. Ultimately batching is a performance improvement and if your requirements mean that it isn't increasing performance then what is the point.
14  Game Development / Newbie & Debugging Questions / Re: Collada format interleaved index buffer? on: 2014-09-26 19:43:53
Ah sorry. Haven't used Blender in a while, turns out it was the Wavefront export that had those options. Well the other thing is that in the asset node in the COLLADA document, you will find an element called <up-axis> which, exporting from Blender, has the value "Z_UP". You can read this element to work out how to transform the data to get it into the y-up format.

And I would recommend transforming the vertices as you parse them. As @basil_ says, best to get it in the format you like and are used to. Otherwise you are just adding another layer of complexity which is wholly unnecessary and can only lead to bad things.
15  Game Development / Newbie & Debugging Questions / Re: LWJGL - 2D Image not rendering right on: 2014-09-26 19:22:28
I've got two issues to be starting you off for.

1) You should be calling glTexCoordf() before the corresponding glVertex() call. When you call glVertex() it sends the currently set tex coords as the ones for the vertex it creates if that makes sense. The same goes for every similar call like glColor, glNormal, glFogCoords everything. And if you are using custom attributes then index 0 takes the place of glVertex() and works the same way.

2) OpenGL used to only work with power of two dimension textures. Nowadays (since OpenGL 3.0 I think) implementations are required to support them but Slick2D still works with pot textures. So it pads out non-pot textures to make them up to pot textures. Fine except it leaves you with black borders like the ones you have.

Fix these two things and see how many of your problems go away.
16  Game Development / Newbie & Debugging Questions / Re: Using a FrameBuffer object on: 2014-09-23 09:44:05
LWJGL specific, good FBO tutorial:

LWJGL example of render to texture:
17  Game Development / Newbie & Debugging Questions / Re: Collada format interleaved index buffer? on: 2014-09-23 09:41:48
Two things to think about.

1) By default, Blender exports with a z-up system whereas chances are you want a y-up system. In the export screen in Blender, look over the options in the bottom right hand corner.

2) With COLLADA you cannot just look at a single isolated element. This <float-array> will be accessed from an <input> (well actually a <vertices> which is referenced from a <polylist> (or similar) inside a <mesh> inside a <geometry> referenced by an <instance-geometry> inside a tree of <node>s inside a <visual-scene> referenced by an <instance-visual-scene> inside the <scene> (That was from memory and some of it might be wrong). And every step along the way there can be stuff that will change the way it works. I expect that one or more of the <node>s of the scenegraph contains a transform which is distorting your quad because you are ignoring it.

So COLLADA isn't that complex but there is a lot of work to do to make a full parser. If you are going to make a fully functional parser, then you have to start in the <scene> node and follow the references all the way down to the actual data collecting all the information along the way. It is no simple matter.

However there is (I believe) another option in the Blender export screen that lets you pre-apply any kind of transform to the geometry before exporting. I believe this will mean that any transforms will be applied to the geometry rather than defined in the scenegraph.

Hope this helps, Quew8
18  Game Development / Newbie & Debugging Questions / Re: Is it Possible to use Java and send sounds through the microphone? on: 2014-09-11 09:33:34
I don't know how but, if there is a way I'd expect you to find it in one of these websites:
19  Game Development / Game Mechanics / Re: Rendering pixel data from array in lwjgl on: 2014-09-02 18:31:49
Textures. You have an array of rgb values, also called an image. So you can wrap up the image in an OpenGL texture and render that. You can update individual pixels in the texture with glTexSubImage2D():

Depending on how much this minimap is being updated, you might get more performance out of using glDrawPixels(): to render those pixels directly. But I would always go with the texture option just for ease of use and simplicity.
20  Discussions / General Discussions / Re: Performance Test for the Voxel Thing on: 2014-08-30 13:18:57
Smooth 60 fps on
Windows 7 32 bit
Intel core i3-2100 @ 3.1 GHz
ATI Radeon HD 2400

So I don't think you have a performance issue.

Also ditto on @PandaMoniumHUN's bug if it matters.
21  Discussions / Miscellaneous Topics / Re: Music in games? on: 2014-08-30 09:51:13
Well I have a friend who is very capable with music production and has made and does make the kind of music I think you are looking for. He would I'm sure be happy to work on the basis of credit given and links provided. If you're interested, pm me and I can get in touch.
22  Java Game APIs & Engines / Android / Re: Hardware survey on: 2014-08-27 09:17:47
I think the point really is in comparing Android to ios. I find that people coming from an IPhone to a comparable Android phone are always complaining about how quickly their apps run. Since the phone's have fairly identical specs and the actual OSs run without a hiccup, I've always concluded that it is because a lot of Android apps cannot be optimized to the same degree as their equivalents on ios.

So yes we can deal with it, doesn't make it the best outcome (purely in terms of final product, I think the pros outweigh the cons in this case).
23  Game Development / Newbie & Debugging Questions / Re: GLSL Lighting a 3D box on: 2014-08-22 10:19:01
OK, here is your problem. Your shader is designed to work for directional lights. A directional light is one considered to be infinitely far away which has two effects: 1) It (can be considered to have) has a uniform intensity. 2) The rays of light (can be considered to be) are parallel. An example of a real world directional light is the sun. So obviously a directional light doesn't really have a position, only a direction.

Now in fixed function pipeline OpenGL lighting, the direction of a directional light was set with the light's position. I don't know why this is, probably to ease the implementation, but whoever wrote your shader has emulated this behaviour, getting the light's direction from it's position. Now you setting the position to (0, 0, 0) essentially kills the light. But that isn't your only problem, hence why setting it to (10E3, 10E3, 10E3) didn't work either. And it is capital 'E' btw. Lower case e is natural logarithm base.

The dot product only works in the way you are using it when both vectors are normalized. (10E3, 10E3, 10E3) is obviously not normalized giving you undefined results. Either normalize it in the shader or better yet normalize it cpu side before setting it.

Two last things. Since you are using your own shaders, enabling GL_LIGHTING and GL_LIGHT0 does absolutely nothing. And if you want to read about how OpenGL used to do these lighting calculations: It is a good read for explaining lighting things.

Hope I've helped.
24  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-21 22:14:45
Specifications are the programmers holy texts. Well if your tutorial explains the maths, I'll sure as hell read it.
25  Game Development / Newbie & Debugging Questions / Re: GLSL Lighting a 3D box on: 2014-08-21 18:58:53
I think this is more of a problem with how you have set up the light rather than the shader.
26  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-21 18:53:23
I'm afraid it is not obvious. I tried to extract the right numbers from a file to test it out and that came out as a no, but I am almost certain that I didn't get it right. Sorry. What you're saying definitely makes a lot of sense in any case.

COLLADA files are XML based and I am told that technically makes them "human readable." But I think that just means text based rather than pure data. It is certainly possible to follow them once you know what they are about but data is essentially split up into several great long lists of numbers and you have to jump to the right index in that list the whole time. The format is also a bit "all over the place" to allow for great flexibility. Fine for a computer, bit confusing for a human. So in short: us humans can read them but, only with experience and then only with difficulty. Quicker to write a program to read them for you frankly even if it's just one or two models.
27  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-20 10:31:31
I'm afraid I cannot be much help here. I create my models in Blender and export them as COLLADA (.dae) files. Parsing through them gives you the bindShapeMatrix and invBindMatrices.

(What follows is guess work)
I've just looked through the COLLADA files for a couple of my models and in all of them the bindShapeMatrix was the identity matrix. Now these are models with a very simple rigging (it was more to test my COLLADA parser than anything else) so perhaps the bindShapeMatrix is only necessary for more complex skeletons? But the invBindMatrices were not identity matrices which leads me to conclude that your original idea which I shot down in flames is probably mostly right. So perhaps the invBindMatrix is the combination of the joint's default transform with the inverse of the bindShapeMatrix and so when the BSM is the identity matrix, the IBM is just the joint's default transform.

Pure speculation, but speculation that makes sense to me.
28  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-19 16:34:25
am I correct in assuming that the mat4 jointMatrices are the current matrices for each joint? (not the default, but their transforms in the current frame?

Yes. The jointMatrix is the joint's transformation in the current frame.

What is the bindShapeMatrix? is this the current joint's default pose(TPose)?
If my assumptions are correct what are the invBindMatrices? are those the default pose matrices as well?

So first off, I don't entirely understand the maths behind skeletal animation (and I don't know what TPose is) but I will share what understanding I do have. Essentially, the joint's transformation is not calculated in object space but in joint space. Joint space is a unique space for each skeleton. The bindShapeMatrix takes the vertex into joint space, where you apply the joint's transform, then the invBindMatrix takes the vertex back into object space. Why the invBindMatrix is unique to each joint, I could not tell you.

That is my understanding - incomplete or flawed as it may be. I am ashamed to say that this is one of the (few) things where I succeeded in implementing something and therefore did not question the maths behind it.

Again, I hope I have been of some help.

29  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-16 09:19:18
Well perhaps I can help with that. I'll post a few pertinent sections of my own skeletal animation code.

The vertex program. Or at least a section of it. Because of my in-app shader build process, I don't have direct access to the entire shader.
attribute vec4 inPos;
attribute vec4 jointWeights;
attribute ivec4 jointIndices;
uniform mat4 bindShapeMatrix;
uniform mat4[~nJointMatrices~] jointMatrices;
uniform mat4[~nJointMatrices~] invBindMatrices;

void main() {
    vec4 vbsm = inPos * bindShapeMatrix;
    outPos =
        ( ( vbsm * invBindMatrices[jointIndices[0]] * jointMatrices[jointIndices[0]] ) * jointWeights[0] ) +
        ( ( vbsm * invBindMatrices[jointIndices[1]] * jointMatrices[jointIndices[1]] ) * jointWeights[1] ) +
        ( ( vbsm * invBindMatrices[jointIndices[2]] * jointMatrices[jointIndices[2]] ) * jointWeights[2] ) +
        ( ( vbsm * invBindMatrices[jointIndices[3]] * jointMatrices[jointIndices[3]] ) * jointWeights[3] );

Where "~nJointMatrices~" should take the value of the maximum number of joints a model of yours has.

The onPreRendering() method from my SkeletalRenderMode which is called before a batch of skeletal renders. (VertexData.vertexAttribPointer()) mirrors the OpenGL function in parameters)
public void onPreRendering(VertexData vd) {
    vd.vertexAttribPointer(0, 3, GL_FLOAT, false, 52, 0); //inPos
    vd.vertexAttribPointer(1, 3, GL_FLOAT, false, 52, 12); //Normal Vector - not shown in shader
    vd.vertexAttribPointer(2, 2, GL_FLOAT, false, 52, 24); //Tex Coords - not shown in shader
    vd.vertexAttribPointer(3, 4, GL_BYTE, false, 52, 36); //jointIndices
    vd.vertexAttribPointer(4, 4, GL_FLOAT, false, 52, 50); //jointWeights

The onPreDraw() from same. This is called before each individual skeletal model's render. (The value of bindShapeMatrixVar, invBindShapeMatrix and jointMatrix in this instance would be "bindShapeMatrix", "invBindMatrices", "jointMatrices". The variable names in the shader)
public void onPreDraw(Skeleton data) {
    data.uploadSkeleton(shaderProgram.getId(), bindShapeMatrixVar, invBindShapeMatrix, jointMatrix);

The uploadSkeleton() method from Skeleton. (matrixBuffer is just a FloatBuffer that is reused for uploading skeletal matrices)
public void uploadSkeleton(int programId, String bsmVar, String ibmVar, String jmVar) {
    ShaderUtils.setUniformMatrix(programId, bsmVar, matrixBuffer);
    for(int i = 0; i < joints.length; i++) {
        joints[i].uploadJoint(programId, ibmVar, jmVar, matrixBuffer);

And the uploadJoint() methods from Joint. (the value of indexString is "[index]" where "index" is the flattened index of this joint)
public void uploadJoint(int programId, String ibmVar, String jmVar, Matrix parentWJM, FloatBuffer matrixBuffer) {
    Matrix.times(tempMatrix, parentWJM, jointMatrix);
    ShaderUtils.setUniformMatrix(programId, jmVar + indexString, matrixBuffer);
    ShaderUtils.setUniformMatrix(programId, ibmVar + indexString, matrixBuffer);
    for(int i = 0; i < children.length; i++) {
        children[i].uploadJoint(programId, ibmVar, jmVar, tempMatrix, matrixBuffer);
public void uploadJoint(int programId, String ibmVar, String jmVar, FloatBuffer matrixBuffer) {
    uploadJoint(programId, ibmVar, jmVar, new Matrix(), matrixBuffer);

The are a couple of caveats to this code. Firstly - there are a maximum of four joints that any vertex can be influenced by. My models are simple so this is fine for me, if you need more then you can move to arrays rather than vec4s.  Secondly - there is a fixed size to the joint matrix arrays. This could be fine, or it could be a waste of space. Variable arrays can be achieved by using textures to send data, or you could be clever and send the matrices of several small models in one go. I'm sure there are more caveats but it has been a while since I wrote this so I forget.

My apologies for the somewhat convoluted nature of this code - I have a framework I have to conform to - but I hope it should serve as a concept example.
30  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2014-08-15 13:00:41
Well firstly, the absolute simplest and best way of doing this as you have described it is (as with most things) to use shaders. You pass a uniform array of joint matrices and attribute joint weights for each vertex. The shader is actually pretty simple.

But doing it your way, also possible. You can transform the vertices cpu side and put them in the cpu pre-transformed. I would counsel against making the matrix in OpenGL and retrieving it to do the transformations. If you are going to do things on the cpu, do it all on the cpu. Or rather better "cpu -> gpu" than "cpu -> gpu -> cpu -> gpu" because in these sort of situations, "->" ie transferring data to (and even more so) from OpenGL is actually the slowest part by quite a bit despite the gpu being able to do processes faster.

Doing matrix calculation cpu side also allows the possibility of caching animation matrices which depending on animation and model size/detail can be the better option.

I don't recognize the library you are using but certainly LWJGL has it's own Vector and Matrix classes which are fully capable of doing these operations and I expect others such as LibGDX and JOGL are similar; so doing the calculations yourself isn't even that complex.
Pages: [1] 2 3 ... 12

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

The first screenshot will be displayed as a thumbnail.

xFryIx (60 views)
2014-11-13 12:34:49

digdugdiggy (39 views)
2014-11-12 21:11:50

digdugdiggy (32 views)
2014-11-12 21:10:15

digdugdiggy (28 views)
2014-11-12 21:09:33

kovacsa (50 views)
2014-11-07 19:57:14

TehJavaDev (54 views)
2014-11-03 22:04:50

BurntPizza (53 views)
2014-11-03 18:54:52

moogie (68 views)
2014-11-03 06:22:04

CopyableCougar4 (67 views)
2014-11-01 23:36:41

DarkCart (153 views)
2014-11-01 14:51:03
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06 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‑
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!