Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
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  
  JOODE: COLLISIONS  (Read 5655 times)
0 Members and 1 Guest are viewing this topic.
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Posted 2006-02-17 22:36:47 »

Just I thought I would give an update to my convex collision code. I have now finished writing code, but I have a massive backlog of debugging to do. The code does not work as yet, but its promising. At the moment my test  convex cubes accelerate away from each other,  as they are under the influence of a bogus constant collision. I am hoping it won't take too much longer to get it working. Unfortunatly uni is sucking my time again, so it may tkae longer than it should do.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline kylix999

Junior Devvie





« Reply #1 - Posted 2006-02-18 13:58:12 »


t_larkworthy  i would not like to interupt your job with joode but i have some short questions, please answer them if you can:

1) When will some oficial joode release be available (in 2,3, 6 months  time) ?

2) Will joode be made in one self package/jar, becouse in sourceforge cvs section there are many other libs that you are using probably for testing like vecmath and other, so i am asking will joode require external jars etc... or will be made in one jar?

3) What wiil be final size of joode implementation in jar that we will add to our apps (what final size could be in your opinion) ?

again than you t_larkworthy, arne and all other who makes grate job with that project
Offline Amos Wenger

Senior Devvie




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


« Reply #2 - Posted 2006-02-18 14:27:26 »

Quickly inexact answer :

1) When will some oficial joode release be available (in 2,3, 6 months  time) ?

It'll be released when it's ready ! As far as I know, there's no release plan.

Quote
2) Will joode be made in one self package/jar, becouse in sourceforge cvs section there are many other libs that you are using probably for testing like vecmath and other, so i am asking will joode require external jars etc... or will be made in one jar?
Dependances are : Vecmath, probably JAMA (=Matrix Math), maybe JUnit, but we could move test classes to other packages..

Quote
3) What wiil be final size of joode implementation in jar that we will add to our apps (what final size could be in your opinion) ?
I have no idea.. but it should be pretty small (compared to AGEIA, that is 175Mb big ! (with demos))

Quote
again than you t_larkworthy, arne and all other who makes grate job with that project
t_larkworthy : I want to participate more to JOODE, but I don't really know which part is TODO actually... you seems to carry on well with your collision detection code...
Note : I have made a Java port of Chris Hecker 3D physic demo (http://www.d6.com/users/checker/dynamics.htm#samples) but I still have a big debug session to do. It needs Xith3D to work. If someone is interested, I'll release it. (Maybe on Chris's website)

For JOODE, I think we should separate the Collision Detection stuff from the CollisionResponse / Integration stuff. It makes more sense to me. We could just define two standards (using java interfaces) and provide a base implementation. If someone makes a better one, then users can flawlessly switch. Seems more modular.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #3 - Posted 2006-02-18 17:27:44 »

Quote
1) When will some oficial joode release be available (in 2,3, 6 months  time) ?
I am hoping within a month.  That version will have unpowered, unlimited joints. And a convex polygon collision system.
 
Quote
2) Will joode be made in one self package/jar, becouse in sourceforge cvs section there are many other libs that you are using probably for testing like vecmath and other, so i am asking will joode require external jars etc... or will be made in one jar?
At the moment the only real dependancy that is used is the Vecmath package, and for testing the Xith package. I would like to clean the system so that the Xith bindings are seperatly packaged. There is a dependancy for JAMA matrix library, but that is only used when the sys is configured a certain way. You could easily not use the JAMA package without breaking the system. So the code we have written will be in one package and you will have to include external libs such as Vecmath to get it working. Hopefully the bindings will be in seperate packages so you will be able to only include what you need.

Quote
3) What wiil be final size of joode implementation in jar that we will add to our apps (what final size could be in your opinion) ?
At the moment the jar is 250kb, and I don't expect it to grow much. If we did a bit of tidying it will probably get smaller.

Quote
For JOODE, I think we should separate the Collision Detection stuff from the CollisionResponse / Integration stuff. It makes more sense to me. We could just define two standards (using java interfaces) and provide a base implementation. If someone makes a better one, then users can flawlessly switch. Seems more modular.

Yeah in essence it is allready done like that. The collision system needs to be explicitly setup and connected the the rigid body system for collisions to work. So it is a fairly easy operation to create your own collision system and plug it in. I actually didn't like the fact that users had to do this, so I have written a class called SimpleWorld that connects the collision system up for the user. 

Quote
t_larkworthy : I want to participate more to JOODE, but I don't really know which part is TODO actually... you seems to carry on well with your collision detection code...
Note : I have made a Java port of Chris Hecker 3D physic demo (http://www.d6.com/users/checker/dynamics.htm#samples) but I still have a big debug session to do. It needs Xith3D to work. If someone is interested, I'll release it. (Maybe on Chris's website)

Porting the different spaces is still open (HashSpace, QuadSpace). I think arne is trying to create his own OctTree implementation rather than port the existing codebase so there should be no overlap of effort.
Testing! Haha, boring but I have never tested whether a body can be removed from simulation, that will need to be tested before version 1, there is probably about a 50% chance it won't work  Undecided.
There will be a mass of refactoring work to be done, just renaming all the method names and suchlike becuase alot of them are ODE names (like dJointAttach). I think that should be the last thing to be done though before release.
Also kitfox wrote a great bit of code for reading a properties file for setting up the simulation environment, but that has not been leveraged yet. I would liike the properties file to be consulted (only once) for determining the options such as what physics intergration stratergy to be used (i.e. step_world_x1 or x2, Cholesky decomposition or LCP or JAMA etc.). Again I don't think this should be worried about until last though.

So if you want a job I suggest porting HashSpace, then QuadSpace. 

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #4 - Posted 2006-02-18 18:00:47 »

Maybe I should say about the long term l plan as I see it at the moment as well.
The next focus after release one will be
getting joints powered and limited.
Getting spaces other than SimpleSpace implemented (if they are not done in this release).

but the main focus will be architecture!
This will invlove:-
An interceptor pattern for basically everything. Similar to:-  http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
So I would like to have a pre and post step world interceptor stack. An pre and post interceptor stack for body step events. Another set for body creation and deletion ( for global creation and deletion as well as stacks per individual body). I have decided the interceptor pattern acheives basically the same thing as an event model, only without the ambiguities of the delivery ordering (i.e. you explicity know what order everything happens).
This archetecture will be really cool for bolting in functionality to the system.  If you want graphical bindings then implement them as a pair of interceptors that listen to bodies being created and destroyed. When a body is created the binding will get to look at it and create a graphical version, and when the body is detroyed the graphical version can be removed.
The collision system should also be abstracted out as an interceptor.
It will also be ideal for adding custom behaviours to subsets of bodies becuase the behaviours can be notified of the body being removed. Any kind of dependancies between objects will be able to be enforced with the pattern (just think of it as an event model). 

I want a really good implementation of the interceptor pattern model. I am thinking that maybe we could use annotations to mark which methods will have interceptor stacks asociated.

Once that system is in place we can start doing the really cool stuff. like adding scripting language support.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #5 - Posted 2006-02-18 22:39:43 »

Quote
I have no idea.. but it should be pretty small (compared to AGEIA, that is 175Mb big ! (with demos))

Errr, no where near that big, infact, NxFoundation (math libs) is 72Kb, and the actua PhyXCore.dll is 1.23Mb. You have the multiplatform SDK and multiplatform demos there, and the models/textures probably take up alot...

As for Quadspace, i dont think thats a good solution to such a dynamic environment. IIRC, you had to constrain the boundries of the quadspace, so for pure dynamic environments, it isn't a nice solution.

During my "metaball" phase of my programming life (yes! I go through phases  Roll Eyes), i found this article that produces a dynamic tree of boxes that expand and relax according to where the metaballs are (meta balls are pure 3d volumetric rendering), it was pretty quick too, so that might be a good solution to the problem.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #6 - Posted 2006-02-19 01:36:20 »

Quote
As for Quadspace, i dont think thats a good solution to such a dynamic environment.
Its not my favourite either, which is why it should be the last of the spaces to be ported, but it does not take long to port code, and it has its uses (like real time stratergy maps). HashSpace is better. But even so the quad space is a tree space I think. It then shares similarities to OctTrees and they was good enough for unreal.

Anyway its all very well coming up with better ways of doing things, like the argument we had whether to port ODE or start from scratch, but if there is useful stuff you can port its way quicker and actually delivers results.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




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


« Reply #7 - Posted 2006-02-23 17:38:17 »

thomas, can I refactor all ODE methods ? Say, change dJointAttach to jointAttach, and so on. Or do it another way ?

"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 Amos Wenger

Senior Devvie




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


« Reply #8 - Posted 2006-02-23 18:18:24 »

Okay, refactoring done. Thanks Eclipse  Tongue

"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 t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #9 - Posted 2006-03-01 11:26:46 »

ARGH!!!!!!!!!!!!!!! These matrix mathmatics are driving me insane. I have the collision code working for the case when they are not rotated. But as soon as you rotate the things it all goes crazy. I have checked, double checked, trial and errored, triple checked and it all comes down to being impossible to visualise the calculations as they go along. I think I may need to develop a graphical debugging suite so I can draw the plane-vertex checks as they are performed and also visualise the gauss representations as they are checked. Its a massive pain though becuase the graphics engine is decoupled from the bit of code I am working on. I am running out of free time this week I can do it as well Sad Grrrrrrrr. Its so close to working its infuriating....

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Raghar

Junior Devvie




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #10 - Posted 2006-03-01 23:28:17 »

Do you have these matrices orthonormalized? No gimbal locks? No round off errors?
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #11 - Posted 2006-03-02 20:43:20 »

Nah that shouldn't be the problem. I dunno what is. Its just a stupid bug somewhere. I have put the wrong matrix in or something. Anyway I have added some graphic support for collision detections now, so you can see the normals as they appear. Hopefully I will be able to trace what is going on through them. Its a bit of a set back though. I really thought I was gonna get it all working soon. I am off for the weekend ...

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Tropper

Junior Newbie





« Reply #12 - Posted 2006-03-15 18:40:32 »

Hmm, AFAIK you guys doing a 1:1 port.

Maybe the easiest way to find the bug is to build the same test case with the original ODE C/C++ code. And then step with debugger thru the Java test case and at the same time thru the C/C++ test case (both line by line). So you see when the values in the java test case different from the orginal ODE.

But i'm not familier with your work (i'm just waiting till it's done ;-)) - so maybe my suggested way is impossible.

Tropper
Offline arne

Senior Devvie




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


« Reply #13 - Posted 2006-03-15 20:48:04 »

nah -  it's the convex-hull collision code, and ODE doesn't have s.th. like that.
A 1:1 port would have been a bad idea, because ODE is written in C, thus not OO, but
JOODE = Java Object Oriented Dynamics Engine, so we really want to have it OO Wink

It's nice that there are so many people interested in our work Smiley

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #14 - Posted 2006-03-16 11:50:21 »

Bah humbug. Gimmie more time.... There are flaws with the DEEP algorithm, but I am fixing them....

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




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


« Reply #15 - Posted 2006-03-16 17:22:57 »

Bah humbug.
Quote from "Mickey's Christmas Carol", words of Uncle Scrooge.

Gimmie more time.... There are flaws with the DEEP algorithm, but I am fixing them....
You have as much time as you want. Well the DEEP algorithm hasn't been tested ?
I'm waiting for this work to end, too, but I don't want to put pressure, cause till it work I focus myself on improving 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 arne

Senior Devvie




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


« Reply #16 - Posted 2006-03-17 16:19:59 »

OctTreeSpace is implemented now.
I also fixed some bugs in SphereCollisionTest, it didn't work anymore, because key gloabal variables were redefined and it used those instead of the ones defined in the super-classes.
I copied most of this test case and made a new one for testing the OctTreeSpace. (OctTreeSpaceTest).
I've also made a new package for it, so all Space-Testcases can go there. (net.java.dev.joode.test.space)

what next? - mmh maybe I'll do some dokumenting on this stuff.

ohh and s.th. else: It printed loads of "null" messages to stderr. Both using SimpleSpace and my OctTreeSpace. Is this correct?

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Devvie




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


« Reply #17 - Posted 2006-03-17 17:01:22 »

ok - that null thingi resolved (those were some old debug-statements of mine) It'll not be there anymore, when I'm finished documenting and have commited the commented code.

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

Senior Devvie




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


« Reply #18 - Posted 2006-03-17 17:21:52 »

Good job !
Have you made a bench ? Does it makes really a big performance optimization ?

"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 Devvie




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


« Reply #19 - Posted 2006-03-17 18:03:15 »

nope haven't made a benchmark yet, but it's javadoc-ed now.
I also found two bugs when removing Geoms, the more serious one I was able to fix quickly, but I don't know how to tackle the other one.
I'll describe the problem:
I find the Geoms in my OctTree by their bounds. So, if I change the bounds, I won't be able to find my Geom anymore. Luckily the bounds only get recomputed shortly before I test for collisions, so after removing the Geom. But if the bounds also get updated somewhere else, this bug would mean a memory leak (I would deposit references in my tree, without ever finding them to delete again)

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Devvie




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


« Reply #20 - Posted 2006-03-17 18:21:26 »

how can we make best benchmarks with joode?
I think we should add an fps counter directly to TestingWorld. And then, where should we show the current fps?
I think we could also log the fps and then print some statistics.

As I see now, we're printing loads of debug-messages, which decrease speed a lot. Maybe we should wait a bit with the benchmarking until we don't need these messages anymore?

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #21 - Posted 2006-03-18 19:44:06 »

Oh brilliant Arne! Nice one.

Yeah the printing stuff really slows the whole thing down.

Quote
I think we should add an fps counter directly to TestingWorld. And then, where should we show the current fps?

Yes, I was going on about a proper gaming loop for TestingWorld a while back. If we did the looping properly we could get the FPS out of the timing.

Quote
I find the Geoms in my OctTree by their bounds. So, if I change the bounds, I won't be able to find my Geom anymore. Luckily the bounds only get recomputed shortly before I test for collisions, so after removing the Geom. But if the bounds also get updated somewhere else, this bug would mean a memory leak (I would deposit references in my tree, without ever finding them to delete again)

OK well remember that one. We will come back to it...

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Devvie




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


« Reply #22 - Posted 2006-03-19 13:13:28 »

Quote
I think we should add an fps counter directly to TestingWorld. And then, where should we show the current fps?

Yes, I was going on about a proper gaming loop for TestingWorld a while back. If we did the looping properly we could get the FPS out of the timing.


Why do we need a proper game loop to calculate the fps? I believe step() in TestingWorld gets executed exactly once per frame, right? So we could simply save the old time when it got executed in a global var. in TestingWorld and compute the time difference, when we step() is called again.
Then we'll simply have to add a method s.th. like getFps() to TestingWorld and then the gaming loop can be anywhere.
Ohh and we would have to remove that Thread.sleep(), we use now to control the speed in for example SphereCollisionTest.

Give me an OK and it's there Wink

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

Senior Devvie




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


« Reply #23 - Posted 2006-03-20 17:26:08 »

OK.
But I read System.timeMillis() wasn't precise, so beware !

"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 Devvie




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


« Reply #24 - Posted 2006-03-20 18:23:51 »

we're 1.5 remember? So System.nanos is the way to go!

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #25 - Posted 2006-03-21 12:18:46 »

Yeah that would be fine in step().

Sorry I am not about much at the moment. It is the end of term and I have numerous peices of work in Sad I will be back in full swing in about a month.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Devvie




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


« Reply #26 - Posted 2006-03-21 18:19:35 »

mmh I think we've got a problem...
At the beginning we've got an fps of around 0.3 (because of all those collisions) this, because of the small fps leads to a big step -> many new collisions -> a new low fps, grater forces (because of the grater intersectionDepth) so the beginning progresses now faster than before (nah ok ... dunno if this is a problem)
Here's the fps sequence:
0.29836214 3.9929085 18.948008 11.978774 6.87271 9.793552 9.774406 16.952888 12.979427 16.268627 49.73145 28.118322 47.127575 47.094284 18.933657 17.28967 33.475044 26.359491 51.816154 50.175613 46.715874 32.58709 60.31363 21.247663 30.44696 50.208366 53.850296 24.87624 30.246204 9.998401 27.145145 94.08223 97.05911 86.79802 32.187458 121.99585 104.54783 122.219505 101.32739 44.984257 36.39805 106.59844 37.20515 106.64391 119.70313 101.90563 108.049706 50.188206 94.24182 127.40476 107.13521 123.517784 33.2823 125.32899 109.48106 128.15584 91.911766 52.134926 104.635345 85.20791 106.53031 125.26619 34.568584 91.7347 74.15097 136.64935 53.376034 133.70772 111.50758 133.15579 137.64626 115.43346 42.468254 94.51796 136.29549 135.483 110.509445 69.032166 108.68384 138.10248 114.10315 127.975426 80.899605 55.23336 104.59157 113.48161 138.23611 111.91942 64.12723 129.65125 116.57729 135.318 95.46539 136.76149 50.0025 109.18223 103.34849 112.29646 135.88803 59.44243
Average: 77.0327

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

Senior Devvie




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


« Reply #27 - Posted 2006-03-22 13:13:30 »

we're 1.5 remember? So System.nanos is the way to go!
OK.

"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 Devvie




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


« Reply #28 - Posted 2006-03-22 18:15:32 »

I've found a good quick algorithm for logging the fps history. It consumes only a constant amount on memory and adding of new frames runs in true constant time.
I've also coded a graphical output of it.
I've added a screenshot. I also print an average fps and the number of frames on the console.
If you want that output when quitting your application, you'll simply have to call FPSCounter.exit instead of System.exit.
I'll do some commenting and then I will commit it.

EDIT: mmh I've just seen, that the measurement on the fps axis is wrong - I get MUCH higher fps!
Ok .. a thing to fix

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

Senior Devvie




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


« Reply #29 - Posted 2006-03-23 17:29:28 »

Nice !
You could do that as an external mini-profiler that every program could call ! And add some features and make a java.net project for that and make a website and provide IRC support and... ok i'm joking but the external lib idea is good IMHO.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (48 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!