Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Minor whine....  (Read 4147 times)
0 Members and 1 Guest are viewing this topic.
Offline hawkwind

Junior Member




Java games rock!


« Posted 2006-10-08 02:30:12 »

Just grabbed the latest and see that Group_Base is gone...I was uncertain of its purpose but converted to using it.  Now it is gone so I guess I use GroupNode??  Also many places I used Vector3f are barfing saying they expected a Tuple3f.

If possible when API/scenegraph  breaking pushes are made, perhaps a quick post with what needs to be converted to make things work would be nice.

I appreciate the work that is being done...just finsihed converting things 2 days ago and now I have red X's again...YOICKS!!  And then my laptop battery died...dang...I am of course hoping that is wasn't the API changes that drained my batteries...Smiley
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-10-08 02:37:59 »

Just grabbed the latest and see that Group_Base is gone...I was uncertain of its purpose but converted to using it.  Now it is gone so I guess I use GroupNode??  Also many places I used Vector3f are barfing saying they expected a Tuple3f.

If possible when API/scenegraph  breaking pushes are made, perhaps a quick post with what needs to be converted to make things work would be nice.

Sorry. I forgot to mention this change Embarrassed.

GroupBase -> GroupNode is correct.

Tuple3f is a super type of Vector3f so you can easily proceed using Vector3f and everything should be fine. Or am I misunderstanding you? Please quote the method call.

Marvin

Edit: but it should nearly never be necessary to use GroupNode. What you you using it for?
Offline hawkwind

Junior Member




Java games rock!


« Reply #2 - Posted 2006-10-08 03:13:21 »

Trying to remember, I guess the BranchGroup is a Group API was changed recently (yes I saw the posts).  When reading OBJ's I was adding them to Branchgroups but using Group as a receiving variable...something like that, so I dropped down to GroupBase instead.  Cannot remember exactly and can't reference my code right now.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-10-08 03:23:42 »

Trying to remember, I guess the BranchGroup is a Group API was changed recently (yes I saw the posts).  When reading OBJ's I was adding them to Branchgroups but using Group as a receiving variable...something like that, so I dropped down to GroupBase instead.  Cannot remember exactly and can't reference my code right now.

When you're loading models, you'll certainly want to move / rotate / scale them. So you won't want to add them to a BranchGroup, since BranchGroup is only allowed to be used as very root group in the scenegraph (due to recent changes). So using Group as receiving variable is ok.

btw. I've created a new Loader base in org.xith3d.loaders.base, which I would like to see as the new base for all loaders instead of org.xith3d.loaders.scene. The Scene and Model classes in this new package extend BranchGroup respectively TransformGroup, which is quite handy to put them into your scene (or make them be the scene in case of a whole loaded scene).

Marvin
Offline hawkwind

Junior Member




Java games rock!


« Reply #4 - Posted 2006-10-08 03:27:40 »

Sounds good...I got in the habit of adding stuff to BG's and then adding BG's to TG's..which is pretty stupid on my part.  One of the reason I reanimated the scene tree graph J3DTree was to find and reduce the empty/redundent  groups I was creating.  I will look at your suggestion.
Offline hawkwind

Junior Member




Java games rock!


« Reply #5 - Posted 2006-10-08 17:54:00 »

more info...Eclipse barfs saying...

Quote
Exception in thread "main" java.lang.NoSuchMethodError: com.xith3d.datatypes.MatrixExt4f.setTranslation(Ljavax/vecmath/Tuple3f;)V
   at com.xith3d.scenegraph.Transform3D.setTranslation(Transform3D.java:445)

1  
2  
Transform3D t3d = new Transform3D();
      t3d.setTranslation((Vector3f) some-hash-table.get(soem-string-index));


T

Resetting vecmath vecmath-kh.jar seems to have helped...

Offline Amos Wenger

Senior Member




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


« Reply #6 - Posted 2006-10-09 18:32:34 »

Qudus, could you please include vecmath-kh.jar sources somewhere in CVS so we can fix it as we want ?

"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 Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2006-10-09 18:36:03 »

Qudus, could you please include vecmath-kh.jar sources somewhere in CVS so we can fix it as we want ?

I'm planning to start a sourceforge project for it.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #8 - Posted 2006-10-20 16:57:00 »

Hi,

Take care of Sun license/copyright for javax.vecmath - I was mentioning this time (a year or so) ago on this forum, and it was the stopper for me to publish it.

I believe we (you) shall get explicit permit of Sun to create a sofrceforge project for vecmath... or maybe I am wrong...

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #9 - Posted 2006-10-20 17:33:47 »

Take care of Sun license/copyright for javax.vecmath - I was mentioning this time (a year or so) ago on this forum, and it was the stopper for me to publish it.

I believe we (you) shall get explicit permit of Sun to create a sofrceforge project for vecmath... or maybe I am wrong...

I don't know, why we should be forced to get the permission of Sun. It is a complete rewritten and different code. It's only based on the vecmath interface. And I don't believe an interface can be protected by a license. And we don't need to write on the project's page, that the lib is compatible to Sun's vecmath (even if it is). So it is just a piece of software, that Sun doesn't have to do anything with. Do you agree?

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #10 - Posted 2006-10-20 18:02:14 »

Hi,

Quote
D. Java Technology Restrictions.  You may not create, modify, or change
the behavior of, or authorize your licensees to create, modify, or
change the behavior of, classes, interfaces, or subpackages that are
in any way identified as "java", "javax", "sun" or similar convention
as specified by Sun in any naming convention designation.

This is from Sun BCL, and similar statements exist (were existing when I checked that - read: a year ago) in other licenses.

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...

Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).

This is anyway very tricky aspect (I mean copyright law and all these licenses).

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #11 - Posted 2006-10-20 18:21:25 »

Hi,

Quote
D. Java Technology Restrictions.  You may not create, modify, or change
the behavior of, or authorize your licensees to create, modify, or
change the behavior of, classes, interfaces, or subpackages that are
in any way identified as "java", "javax", "sun" or similar convention
as specified by Sun in any naming convention designation.

This is from Sun BCL, and similar statements exist (were existing when I checked that - read: a year ago) in other licenses.

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...

Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).

This is anyway very tricky aspect (I mean copyright law and all these licenses).

Yuri

Ah. Good to know. Maybe we should consider changind the package names.

You sayd, you're a JOGL contributor. Some days ago croft sayd, that JSR-321 is released. Can you say, if there're any performance boosts in the new release compared to the one, we're corrently using?

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #12 - Posted 2006-10-20 18:52:42 »

Qudus, could you please include vecmath-kh.jar sources somewhere in CVS so we can fix it as we want ?
I'm planning to start a sourceforge project for it.
Great.

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...
Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).
Hmm so lets pretend we are implementing javax.vecmath and make serialization compatible... err is it possible at least ? If it's in an SVN repository I don't mind working on it..
About the agreement, how can you obtain one ? Do you plan to do so ?

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #13 - Posted 2006-10-20 19:05:02 »

Hi,

Quote
Hmm so lets pretend we are implementing javax.vecmath and make serialization compatible... err is it possible at least ?

Yes, it is possible. In most cases it is refactoring of KH vecmath by changing the field names, adding UIDs etc., but for some classes extra routines should be written.

Yuri

P.S. I will try to allocate time to check what is the status of Sun vecmath at the moment and if the implementor agreement (or contribution to it if it is opensourced) is possible.

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #14 - Posted 2006-10-20 19:21:25 »

Hi,

Quote
Hmm so lets pretend we are implementing javax.vecmath and make serialization compatible... err is it possible at least ?

Yes, it is possible. In most cases it is refactoring of KH vecmath by changing the field names, adding UIDs etc., but for some classes extra routines should be written.

Yuri

P.S. I will try to allocate time to check what is the status of Sun vecmath at the moment and if he implementor agreement (or contribution to it if it is opensourced) is possible.
OK-dokey.

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #15 - Posted 2006-10-21 15:30:32 »

Hi,

OK, I have info on vecmath package.

Now it is opensourced as a part of Java3D package: https://vecmath.dev.java.net/

Exacly as I thought, license states limitations on use of javax.vecmath namespace (with Kenji Hiranabe's vecmath we fall under "Compatible Implementation" cathegory):

Quote
3.1.3 A Compatible Implementation may not modify the functional behavior of the "Java Classes" which means the specific class libraries associated with the Technology; and
3.1.4 A Compatible Implementation may not modify, subset, superset or otherwise extend the Licensor Name Space, nor include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required and/or authorized by the Specification. "Licensor Name Space" means the public class or interface declarations whose names begin with "java", "javax", "com.sun" or their equivalents in any subsequent naming convention adopted by Sun through the Java Community Process, or any recognized successors or replacements thereof.

So if we want to have better vecmath OFFICIALLY, we have two options: 1) to contribute changes directy to vecmath CVS (which will need Developer CVS access on vecmath, and, therefore, contributor agreement, similar to one I have for JOGL), or 2) execute JDL with Sun (I think I can do this on behalf of Xith3D Project Group), create compatible implementation, ensure it passes TCK, and distribute it under terms of JDL (then we have to manage JDL agrements with our users).

I believe 1) is more appropriate but on the other hand will be more complicated. As a companion to 2) we may suggest vecmath group to take the changes after we have them passing TCK. But, anyway, to get TCK, we have to execute JDL.

...that's the world of laws and licenses... ...and we also have to deal with this...

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #16 - Posted 2006-10-21 16:39:56 »

...that's the world of laws and licenses... ...and we also have to deal with this...
Alas..

So if we want to have better vecmath OFFICIALLY, we have two options: 1) to contribute changecs directy to vecmath CVS (which will need Developer CVS access on vecmath, and, therefore, contributor agreement, similar to one I have for JOGL), or
This approach has a big flaw : vecmath is meant to be used in single or multi-threaded environments, while we don't need multi-threading *at all*. In order to be thread-safe. Sun's vecmath generates lots of garbage (e.g. 3x3 or 4x4 raw matrices are created with some get() method calls... this is just astonishing ! putting those sames matrices as members take little more memory and generates nearly no garbage (some allocations are unavoidable)). So I don't think Sun's vecmath really goes well with our needs/goals.

2) execute JDL with Sun (I think I can do this on behalf of Xith3D Project Group), create compatible implementation, ensure it passes TCK, and distribute it under terms of JDL (then we have to manage JDL agrements with our users).
Well why not if it's the only solution to do that legally. What exactly do you mean by "manage JDL agreements with our users" ? Be it Sun's vecmath JDL-ed lib or Kenji Hiranabe's vecmath JDL-ed I don't see the difference for users (about licenses).

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #17 - Posted 2006-10-21 17:01:17 »

Hi,

Quote
This approach has a big flaw : vecmath is meant to be used in single or multi-threaded environments, while we don't need multi-threading *at all*. In order to be thread-safe.
Can you please point me to this highlight in the specification? Anyway, this statement does not imply any method to be synchronized (what we are trying to avoid by being "non-multithreaded"), it just assumes that concurrent method calls are thread-safe.

I just checked the Sun vecmath source, and did not find ANY "synchronized" keyword.

Even first-look at Sun vecmath show it is not thread-safe: check Color3f.set(Color) and Color3f.get() - get may return completely wrong color if set(...) is called from another thread concurrently.

So I don't see it as an issue at all.

Quote
putting those sames matrices as members take little more memory and generates nearly no garbage (some allocations are unavoidable)).
If you take a closer look to Kenji Hiranabe's vecmath, you will see that he does not use arrays at all - search for "new" allocation operator and you will be surprized bu ABSENCE of new arrays! He is using parameter passing (i.e. local variables) instead of arrays, and this voids need to make shared matrices, so does not compromize thread safety at all.

Quote
What exactly do you mean by "manage JDL agreements with our users"?
If we distribute vecmath under JDL agreement (as required by Sun JDL), we have to ensure that all of our users ("third parties") accepted the terms, and better in written form (as required by Sun for their JDL). Aletrnative is BCL (Binary Code License).

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #18 - Posted 2006-10-21 17:11:55 »

Well then what is best : to introduce Kenji Hiranabe's changes in official vecmath or to JDL his vecmath ?

Quote
What exactly do you mean by "manage JDL agreements with our users"?
If we distribute vecmath under JDL agreement (as required by Sun JDL), we have to ensure that all of our users ("third parties") accepted the terms, and better in written form (as required by Sun for their JDL). Aletrnative is BCL (Binary Code License).
But currently users have to download vecmath separately but I never reviewed whatever about vecmath license.. it was there, I just used it (I know this is counter-professional).. only enterprises will mind.. but ok I got it.

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #19 - Posted 2006-10-21 17:22:08 »

Hi,

I believe that better is to introduce Kenji Hiranabe's changes in official vecmath.

By making activity there we may also attract some new developers/users to use Xith3D which is good anyway.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




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


« Reply #20 - Posted 2006-10-21 17:31:11 »

I believe that better is to introduce Kenji Hiranabe's changes in official vecmath.

By making activity there we may also attract some new developers/users to use Xith3D which is good anyway.
Agreed, though it's gonne be a lot of work. When/where do we begin ?
You have to apply for something at Sun, IIRC ?

and..
You sayd, you're a JOGL contributor. Some days ago croft sayd, that JSR-321 is released. Can you say, if there're any performance boosts in the new release compared to the one, we're corrently using?

"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 Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #21 - Posted 2006-10-21 18:09:22 »

Hi,

Quote
. Can you say, if there're any performance boosts in the new release compared to the one, we're corrently using?
Not really. If there is one, it is quite minor.

Major point is stability and compatibility. So, in general, I think we should migrate to newest JOGL, and I think it is a minor effort.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #22 - Posted 2006-10-21 18:17:06 »

I'm not very happy with the rocks Sun puts into developer's ways. I think it would be best to change the package names from javax.vecmath to something like org.linalg or so. Then we would be free to choose a license like BSDish and change the API's behaviour if needed.

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #23 - Posted 2006-10-21 18:23:00 »

Hi,

I don't see it is too much problematic... I think that we can even [theoretically] try to push Sun to relax vecmath license to BSD (as it happened with JOGL - it is also project managed by Sun and it is under BSD!)...

I think before making any decisions we should try to speak to Sun people and get their opinion, if possible.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #24 - Posted 2006-10-21 18:29:24 »

I don't see it is too much problematic... I think that we can even [theoretically] try to push Sun to relax vecmath license to BSD (as it happened with JOGL - it is also project managed by Sun and it is under BSD!)...

I think before making any decisions we should try to speak to Sun people and get their opinion, if possible.

That would be great.
Offline Amos Wenger

Senior Member




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


« Reply #25 - Posted 2006-10-21 18:33:14 »

That would be great.
Sure.

"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]
  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.

xsi3rr4x (28 views)
2014-04-15 18:08:23

BurntPizza (25 views)
2014-04-15 03:46:01

UprightPath (40 views)
2014-04-14 17:39:50

UprightPath (22 views)
2014-04-14 17:35:47

Porlus (38 views)
2014-04-14 15:48:38

tom_mai78101 (62 views)
2014-04-10 04:04:31

BurntPizza (121 views)
2014-04-08 23:06:04

tom_mai78101 (221 views)
2014-04-05 13:34:39

trollwarrior1 (188 views)
2014-04-04 12:06:45

CJLetsGame (195 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!