Marvin Fröhlich
Xith Lord
Administrator
Guru
 Offline
Posts: 4337
May the 4th, be with you...
|
 |
« Reply #5 on: 29. October 2010, 11:11:42 PM » |
|
Very nice book. It is certainly a good guide for everyone having to me similar decisions. I just wonder, why you didn't join this board earlier to ask a few questions about the Xith3D project (not XITH). Let me sum up some points, that should be corrected. - LWJGL is certainly not just good for 2D games. It is an OpenGL Java binding. OpenGL is designed for 3D scenes. The ability to render in 2D mode is just a "spin-off product", though very good to use, too. But actually it is very good for 3D games, though hard to use for complete games, since it only provides plain OpenGL, but no scenegraph or extra functionality.
- In the same list you just say, Xith is good for 3D games. At the same time you made your decision for Xith. So there should be a few more pros while the other libraries have more. Some of them would be "very extendable", "very flexible", "good and easy documentation", "loads of examples (testcases, demos)", "free license", "platform independant", "huge support of 3D model formats", "supports 2D rendering", "very high performance", "many advanced features like an intuitive input system, complete HUD support, etc.", "integrated physics engine abstraction", etc; I will leave the list of cons to you
 . - Renderer and RenderPass are not synonymic (as for Xith). A RenderPass keeps and manages a sub graph, which is processed and rendered by the Renderer. It also implicitly defines the rendering order.
- The view needs a third vector to be fully defined, the up vector, plus a screen scale, which is better known as the vertical field of view (FOV).
- Xith doesn't force you to use y-up. It is just the OpenGL default and can be defined anything else. Plus the BSP level is designed with y-up.
- Don't advise your followers to extend InputAdapterRenderLoop, but RenderLoop. The InputAdapterRenderLoop is (as XIN says) just a utility class, that simplifies demo creation. But in your game you will not want to handle input directly in your main class, but externalize it in some separate class. InputAdapterRenderLoop may also serve to demonstrate, how input events are captured. Even if it may look tempting to have just one class to extend and you're through, this is not a good idea for a complete game.
- Consider using an "Updatable" implementation for your game logic instead of overriding the prepareNextFrame() method. This is also good to keep things clean in bigger solutions. Of course intervals are another way to do game logic, that needs to be updated every x time slices as you correctly documented. Just for the record: Another way to use Intervals is to simply extend the onIntervalHit() method in an Interval extension instead of using the listener approach.
- Your using of the Transform class looks strange and should be even wrong. You're applying a fixed translation to the apple using the StaticTransform class. Then you add it to a Transform instance, which defines a scale. This scale applies the whole shape including its fixed translation. Afterwards you "add" additional translations to the Transfrom object. Correct would be to apply a fixed scale through StaticTransform and then adding it to the Transform (I would even use a normal TransformGroup), which defines the position. If you want to make the apple rotate in place, you would need to put it into ann additional TransformGroup, which defines the rotation and which is itself added to the translating TransformGroup.
- Use PickingLibrary for picking instead of the PickScheduler. You are already inside of the xith rendering thread, if picking from within one for the update methods or input listener methods or prepareNextFrame() etc.
- Picking doesn't test, if an object is "within the crosshair". Picking casts a ray, which doesn't have a width and checks for intersection with shapes.
- The way you explain to setup a project for xith is... well, not wrong... but...
Better:
Create a new project called "xith3d".
Create a folder "lib" folders in it.
Copy all the xith jars and natives into it.
Refresh the project in Eclipse (F5).
Open the Project properties and go to "Java Build Path".
Press "Add jars" (not external).
Add all the jars (except for the swt.jar).
Now expand the lwjgl.jar entry and edit the "Native library location". Set it to the "natives" sub folder under the lwjgl folder.
Do the same for the gluegen-rt.jar, joal.jar, logl.jar, swt.jar (if included).
Expand the xith3d.jar entry and edit the "Source attachment". Set it to the xith3d-source.jar.
Switch to the "Order and export" tab and deselect everything, but the openmali.jar, jagatoo.jar, jops.jar, joode.jar and xpal-joode.jar.
Click ok.
Create a second project called "mygame" or something.
Open its project properties and select "Java Build Path" and switch to the "Projects" tab.
Add the "xith3d" project.
Done. Your "mygame" project is now fully bound to Xith and all of its libraries and natives.
I suggest to checkout the xith3d project and xith-tk project from SVN. The xith-tk project has a very similar class path setup (Java Build Path), which you can use as an example.
Don't extract the xith3d-source.jar, but just use it as source attachment as described above.
Exclude the swt.jar from the minimum list, if you don't plan to create Eclipse plugins. On the Mac platform just having the jar in the classpath causes some problems.
I don't quite see, why you decided to use GTGE for 2D games. It seems to be nothing more than a layer on top of AWT/Swing, hence no hardware acceleration. It uses Java's crappy input system without any means to abstract it. I suggest you to have a look at the "twoodee" package in Xith. You should be able to create 2D games with it just as easily as 3D ones. Of course you can mix it with the HUD, but I wouldn't recommend to do it all in the HUD, since it is not designed for that purpose. Ok, I think, that was it. Cheers, Marvin |
Projects
