Dear all,
I've just checked out JME 2.0 and tried it. There're many strange classes that replace for classes in JME 1.0. I would like to know that whether JME 2.0 is ready for using (just testing) because I cannot find some corresponding classes with JME 1.0 for ex: there's no AlphaState in JME 2.0
1.0 2.0
AlphaState BlendState
jme 2.0 is as stable as 1.0 but has a few more features and its api may change still as its in development.
He, I would mention other more radical change like: no triangle batches in 2.0 meshes.
That one is much funnier when migrating.
Dear all,
I'm trying to use JME 2.0 but I cannot find any document about some changes in comparison with JME 1.0. So, I don't know what the predicate classes in JME 2.0 in order to change to the new Class. Up to now, I think JME 2.0 has all functions of JME 1.0. I don't know whether the structure of JME 2.0 is different from structure of JME 1.0 ? Any one can help me what is Class change (and the new Class corresponding with changed class) in JME 2.0. I need the link but I cannot find from Internet
maybe a wiki entry, 'merging guide from jme 1 to jme 2' wouldn't be a bad idea.
if you use eclipse its pretty easy to figure out what classes you need to use.
Because jme 2.0 uses enums now, you cant make much wrong
Dear all,
I'm using Eclipse and I'm facing with numerous errors that I don't know how to solve because there's no any tooltip for predicated classes from JME 1.0 . For example, How about AlphaState in JME 1.0 . I'm trying to figure out what the new class of AlphaState in JME 2.0 but nothing from Internet
moonjava said:
I'm trying to figure out what the new class of AlphaState in JME 2.0 but nothing from Internet
It's BlendState.
Think the point is that we need to split the wiki and docs up for version one and two.
From what I understand is that we will be swamped with new memebers from the java3d camp, they may get very confused on trying to set alpha states if they are using JME2.0 and have educated them selves from the wiki.
Its going to get very confusing as time goes by with new releases, something needs to be done in the build and release procedures to avoid this.
How would a proffessional company do it ??
Copy the entire WiKi into a separate branch and slowly work through the 2.0 branch deleting everything that does not apply?
Maybe… but a whole lot of work… and considering that the code still changes rapidly… perhaps a bit too early? I think it should be just made clear / visible that the WiKi is for jME 1.0 and since jME 2.0 is still in alpha state there is not yet any WiKi for it… except what you can yourself drain from 1.0 version.
This is essentially the truth… It should just be more visible.
Maybe the download page should also state that 1.0 is stable with docs and give a warning that 2.0 is a WIP with no docs…
Just want to avoid making life hard for new developers …
yea, im completely new to java and its kinda confusing. the language isnt actually all that hard, but all the tutorials are based towards 1.0 and its hard to change the classes and all. Any one know of good 2.0 tutorials like FlagRush? Or should i just learn 1.0 and try to transfer later?
jME is a big project and hard for us to keep all the examples and such up to date. It would be nice if more users could lend a hand porting the examples to 2.0 in the wiki.
All the source for flag rush though is in both distros, so at least that has already been ported to 2.0 and it should be an easy thing for someone to fix things up.
thanks for clearing that up.
I think that copying everything to another branch is bad in the sense that there are generic pages that then would need to be maintained twice.
I believe versioning is the way to go, and exporting documentation for both branches. However the documentation is in a Wiki, so I prefer adding links with "jme1" and "jme2" suffixes where appropriate.
I will take the opportunity to propose that the jME team incorporates a documentation manager. Someone that is willing to organise documentation (as opposite to writing anything). This person could also maybe organise efforts towards improving docs and maybe even prepare some scripts to export it to other formats, etc… Also some posts inviting people to fill in documentation gaps. Writing documentation is also a very good way of learning, if one knows where his limits are.
I think the same should be done with internal documentation, in aspects as thread safeness and examples embedded in the Javadocs.
I have thought this too many times. Now I think jME really needs much better, extensive and organised documentation. And probably a book too :D.
While porting stuff to JME2.0 I made a mappings list based on what I've come across so far:
CullState
CullState.CS_BACK = CullState.Face.Back
setCullMode() = setFaceMode()
Game
AbstractGame.properties = AbstractGame.settings
AbstractGame.setDialogBehaviour (2, ImgURL) = AbstractGame.setConfigShowMode (ConfigShowMode.AlwaysShow, imgURL)
Texture
Texture.MM_LINEAR_LINEAR = Texture.MinificationFilter.Trilinear,
Texture.FM_LINEAR = Texture.MagnificationFilter.Bilinear
Texture.AM_COMBINE = Texture.ApplyMode.Combine
Texture.MM_LINEAR = Texture.MinificationFilter.BilinearNearestMipMap,
Texture.FM_LINEAR = Texture.MagnificationFilter.Bilinear
Texture.WM_WRAP_S_WRAP_T = Texture.WrapMode.Repeat
Texture.ACF_MODULATE = Texture.CombinerFunctionRGB.Modulate
Texture.ACS_TEXTURE = Texture.CombinerSource.CurrentTexture
Texture.ACO_SRC_COLOR = Texture.CombinerOperandRGB.SourceColor
Texture.ACS_PRIMARY_COLOR = Texture.CombinerSource.PrimaryColor
Texture.ACO_SRC_COLOR = Texture.CombinerOperandRGB.SourceColor
setCombineScaleRGB(1.0f) = setCombineScaleRGB(CombinerScale.One);
Texture.ACF_ADD_SIGNED = Texture.CombinerFunctionRGB.AddSigned;
Texture.ACS_TEXTURE) = Texture.CombinerSource.CurrentTexture);
Texture.ACO_SRC_COLOR = Texture.CombinerOperandRGB.SourceColor;
Texture.ACS_PREVIOUS) = Texture.CombinerSource.Previous;
Texture.ACO_SRC_COLOR) = Texture.CombinerOperandRGB.SourceColor;
Quad
Quad.getTextures = Quad.getTextureCoords()
ZBufferState
ZBufferState.CF_LEQUAL = ZBufferState.TestFunction.LessThanOrEqualTo
Skybox
Skybox.NORTH = Skybox.Face.North
AlphaState BlendState
AlphaState SB_SRC_ALPHA = BlendState.SourceFunction.SourceAlpha
AlphaSate DB_ONE_MINUS_SRC_ALPHA = BlendState.DestinationFunction.OneMinusSourceAlpha
setSrcFunction = setSourceFunction
setDstFunction = setDestinationFunction
Does anyone think this will be useful to add to the wiki so people and add their JME1.0 to JME2.0 mappings too? Since at the moment there is no official merging guide.
Hi
I went through the same process and had to use other posts on the forums, was a pain, this would be a useful resource somewhere, but being a beta, the API could change still, and it would be important that it's kept up to date. There is nothing worse than documentation on a new API (or version) thats not correct, I've just had the same pain with the new JavaFX preview.
Grrr
Endolf
yunspace said:
Does anyone think this will be useful to add to the wiki
yes :) (one person minimum ;))
yunspace said:
Does anyone think this will be useful to add to the wiki so people and add their JME1.0 to JME2.0 mappings too?
definitely! go ahead!
good move geronimo… thanks