@david.bernard.31 said:
My project is build with jme 3.1.0-SNAPSHOT where I enabled "gamma correction". I have to change JME3-JFX to support it. The change used API not available into 3.0.x
As some dev use JME3-JFX with 3.0, I enclosed the change into a try {} catch and fallback to current cod. So both jme’s version should be supported at runtime, but the code can’t compile with 3.0.
So my question, how to manage the dual version into the project ?
having 2 branches (master for 3.0 and jme_3.1 for 3.1 )
switch jme to a 3.1.0-SNAPSHOT + inserting hack (like I did to support both version at runtime)
others ?
Its a common issue for software development. Basically you will have to maintain two branches, one for 3.0 and one for 3.1
In fact, I request the project lead, to chose (and create the branch if need), then I’ll be able to PR.
As a side effect, there is also the fact to store the jme-xxx.jar. In my local dev, I used a local repository to store all the version and switching/updating/…, is “just” a change in build.gradle.
To the branches I dont expect breaking jme changes very often, as basically the image class is the only necessary one for the interface.
As resizing is not performance critical:
Fix 3.0 as base version for now, limit support to 2 last version. (aka Stable 3.0 and Dev 3.1)
-> So 3.0 can be dropped once 3.2 is the new Dev one and 3.1 is the released stable.
-> Read JMEBaseVersion (JmeVersion.getFullName()
If 3.1 call the new method via reflection
if 3.0 or fail above call alternative code in base version
That way we have a version that can be compiled against both, uses the newer methods if available.
One base version is moved to 3.1, the workaround can be removed savely.
-> Of course properly making a few comment with the version limitations to the workaround is necessary, so it can be easily removed later.
+No branches that need to be supported
+Clearly defined wich version are officially supported
+Ability to compile against base version
-If there are many of those occurences the quality might degrade
-Not possible for performance critical code.
So If i conclude correctly
Ignore everything except current git version (and increase the base version to 3.1)
Do branches for each version
Use Reflection for non base version methods.
I tent for 3 mostly because I think there will rarely be any change that is in performance critical code.
2 is also ok, but I dont want to make the synchronizing work, if someone else will I’m fine with it.
Yes, but I don’t think it will work at all if this image type is not there - it was the reason why I have added it, to get jfx-jme3 working in first place. Maybe it was added to 3.0 in meantime…
@Empire Phoenix said:
To the branches I dont expect breaking jme changes very often, as basically the image class is the only necessary one for the interface.
Every 3.X release will introduce breaking changes and 3.1 isn’t even out yet so there will still be more coming. E.g. the whole SimpleApplication thing is about to get kicked out and cleaned up just for starters.
@normen said:
Every 3.X release will introduce breaking changes and 3.1 isn't even out yet so there will still be more coming. E.g. the whole SimpleApplication thing is about to get kicked out and cleaned up just for starters.
Aside: yeah, man, I hope to get to this soon! Too many things on the list.
The part “jme in jfx” uses more than just Image. I’ll adapt the code.
<OT>
I mainly use SimpleApplication as a provider for services (assetManager, InputManager, AppStateManager …) and a queue for actions to be done in RenderThread (app.enqueue(…) )
</OT>
@david.bernard.31 said:
The part "jme in jfx" uses more than just Image. I'll adapt the code.
<OT>
I mainly use SimpleApplication as a provider for services (assetManager, InputManager, AppStateManager …) and a queue for actions to be done in RenderThread (app.enqueue(…) )
</OT>
Yep, and that’s essentially what the new version will be stripped down to be (and won’t by called SimpleApplication anymore because I’m tired of the “I didn’t use it because my game is not simple…” conversations. :)). Additional features will be added with app states instead of hard-coded into the class. …and finally no more confusing protected fields.
The build happens as a rolling release via my jenkins server,
so either pin a version to develop against, or use latest.release (and be prepared that it might break sometimes the api, when necessary.)
If you find any bugs, please state the version you are using.
Very interested in this JavaFX thing. But I have a few questions. I have Java 1.8 installed.
What do I need to start making JavaFX GUIS in JME? Your code on github? Anything else?
Can someone please explain in very broad strokes what I need to do to get like a Hello World app running? I saw in the test program that you are using GuiManager, FXMHud, and a few other classes, but I could not find any documentation about them. And that program does not seem to have much in common with the documentation that Oracle provides here http://docs.oracle.com/javafx/2/get_started/hello_world.htm
I read some posts in this thread. You talked about some problems with input events, and about trouble determining if an input event has been consumed by the GUI or not. Is there a satisfactory solution to that?
Are there any other major problems with using JavaFX together with JME?
(Modify accordingly for netbeans never done it there)
yes, also helpfull is scenebuilder from oracle to create fxml files.
gradle eclipse
import project in eclipse
-> note the provided jme is not exported by the project, you are supposed to use a real full jme distribution for your own project, it is enough however for the tests
start test
3.As long as you have not 100% transparent stuff that needs input it works. -> It uses the transmitted textures pixel at eventposition to determine if jfx elements are at that location.
4.So far none noticed, be aware however that jfx has a seperate own renderthread, so everything has to be enqueed in both directions.
5. in fact yes, jme3stuff on bintray. jme3stuff - Maven - Bintray
repository http://dl.bintray.com/davidb/jme3stuff/
compile group: ‘com.jme3x’ ,name:‘jfx’, version:jfxVersion
But in question 2, I meant in the code. The equivalent to what I’m looking for, for plain JME GUI, would be: “Create Quads, set their texture, and attach to the guiNode, which you can get with simpleAppliction.getGuiNode.” The very basics of how to do stuff :P. I don’t even use Eclipse or gradle.
For 3: So, if I want to be able to click through something, then what? Like a transparent map overlay, Diablo 2 style.
Re 3:
All the ‘magic’ is hidden in JmeFxContainer.isCovered(x,y). By default it checks alpha value of the pixel, but you can extend it with whatever custom logic you want.
@abies said:
Re 3:
All the 'magic' is hidden in JmeFxContainer.isCovered(x,y). By default it checks alpha value of the pixel, but you can extend it with whatever custom logic you want.
Yeah, I guess I’ll figure it out when I know how everything works.
)
