Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  Add detach() method to Group and deprecates BranchGroup ?  (Read 2453 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Devvie




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


« Posted 2006-09-15 15:38:34 »

What do you think ? Here's the code in BranchGroup ?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
public class BranchGroup extends Group {
    /**
     * Constructs a new BranchGroup object.
     */

    public BranchGroup() {
        super();
    }
   
    /**
     * Detaches the BranchGroup node from its parent. Sets
     * the node to not live.
     */

    public final void detach() {
       
        if (View.CHECK_FOR_ILLEGAL_MODIFICATION) View.checkForIllegalModification(this);
       
        Node p = getParent();
        if(p!=null)
        {
            if(p instanceof Group)
                ((Group)p).removeChild(this);
            else
            {
                throw new SceneGraphRuntimeException("BranchGroup.detach(): An unknown node type is the parent.");
            }
        }
    }
}


I think it would simplify the code a bit.

"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 #1 - Posted 2006-09-15 15:39:06 »

And also methods in the Xith3D API (even in the tk) should take/return Groups in argument, not BranchGroups.

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




May the 4th, be with you...


« Reply #2 - Posted 2006-09-15 15:51:02 »

I'm absolutely for it. It is a little confusing, if a BranchGroup is used anywhere inside the scene branch.

But for Java3D compatiblity we should leave the BranchGroup non-deprecated and use it as a brach-root-group. And I'll use BrachGroup for the new multipass code.

So as far as I am concerned, please refactor the detach() method to Group and shrink BrachGroup usage to a minimum (all points except Locale.addBrachGraph()).

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Devvie




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


« Reply #3 - Posted 2006-09-15 15:52:48 »

I'm absolutely for it. It is a little confusing, if a BranchGroup is used anywhere inside the scene branch.

But for Java3D compatiblity we should leave the BranchGroup non-deprecated and use it as a brach-root-group. And I'll use BrachGroup for the new multipass code.

So as far as I am concerned, please refactor the detach() method to Group and shrink BrachGroup usage to a minimum (all points except Locale.addBrachGraph()).

Marvin
Don't really the point of the Java3D compatibility thingy but 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 Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #4 - Posted 2006-09-15 16:03:45 »

Don't really the point of the Java3D compatibility thingy but OK.

Well, BranchGroup is the group type that you use with the Locale.addBrachGraph() method in Java3D. So strictly speaking it would break the Java3D "compatiplity" if we would deprecate it. But I think it's no thing, anyone wouldn't instantly understand. The method takes a specific group type and you'll know what to do. So no problem till this point.

But I find it logic to have a different group type as the root group --> BranchGroup. And it would give us the possibility to be more flexible and do things with the root group than with all the other group... just as I am planning with multipass Wink.
Offline Amos Wenger

Senior Devvie




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


« Reply #5 - Posted 2006-09-15 16:08:26 »

Don't really the point of the Java3D compatibility thingy but OK.

Well, BranchGroup is the group type that you use with the Locale.addBrachGraph() method in Java3D. So strictly speaking it would break the Java3D "compatiplity" if we would deprecate it. But I think it's no thing, anyone would instantly understand. The method takes a specific group type and you'll know what to do. So no problem till this point.

But I find it logic to have a different group type as the root group --> BranchGroup. And it would give us the possibility to be more flexible and do things with the root group than with all the other group... just as I am planning with multipass Wink.
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 Amos Wenger

Senior Devvie




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


« Reply #6 - Posted 2006-09-16 13:27:28 »

Done. Had a great manual merging party today.. thanks Qudus  Grin Grin No just kidding. Putting detach() in node is even better.

But why did you delete the getRenderFrame() method in View ?

"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 #7 - Posted 2006-09-16 13:31:57 »

Hah, I saw you added a Renderer class. Gonna dig that a bit.

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




May the 4th, be with you...


« Reply #8 - Posted 2006-09-16 14:25:37 »

Done. Had a great manual merging party today.. thanks Qudus  Grin Grin No just kidding.

Sorry Grin I thought I was the only one working at this late time (for us Europeans).

But why did you delete the getRenderFrame() method in View ?

Hah, I saw you added a Renderer class. Gonna dig that a bit.

I didn't add this class. It was there before my recent changes. I just moved the rendering code from the View to the Renderer class and the Atom collecting code in the FrameAtomsCollector class which previously was named RenderFrame.

I always wondered what this RenderFrame class did when it didn't actually render. I browsed through the code and found out, that it actually sums up all the Atoms. So I renamed it to FrameAtomsCollector to make it clear to everyone what it actually does and moved the code from Renderer to it, which actually belongs to it. On the other side I moved the rendering code, which was residing in the View class into the Renderer class, since the View only describes a camera or an Eye and doesn't actually render anything.

I think this is much better understandable, isn't it. So we all can better comprehend how the rendering works.

The Renderer actually doen't render itself. It just flatens the scenegraph to Atoms which the actual renderer (OpenGL) can handle better.

I'll proceed this work now and maybe rename some more classes / methods to improve understandability and logical correctness of the code. After all I'll have a quite good understanding of the render process Smiley

Marvin
Offline Amos Wenger

Senior Devvie




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


« Reply #9 - Posted 2006-09-16 14:36:14 »

OK. But be sure to notify us on the forums on our changes.

Seeing a crucial method like getRenderFrame() disappear on CVS without an explanation is... surprising.

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

Senior Devvie




May the 4th, be with you...


« Reply #10 - Posted 2006-09-16 15:12:03 »

OK. But be sure to notify us on the forums on our changes.

Seeing a crucial method like getRenderFrame() disappear on CVS without an explanation is... surprising.

You know I've (most) always reported my changes in the forum. And I would never do such a big change without notifying. But I wanted to wait until I've finished this work. And so far it is not. I think, I'll have finished it this night.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #11 - Posted 2006-09-16 15:17:59 »

For the Background / Foreground .getGeometry() method:

I was always disturbed of this method, since it doesn't return a Geometry or Shape and always wanted to rename it. But It has this name in Java3D. So I din't do it so far. I just stumbled over it again last night Smiley

Anyway, I really like it renamed, since it is a failure we don't need to imitate from Java3D and it's one more point we are better in than Java3D, since it is better understandable. So it's good, that you renamed it, Amos.
Offline Amos Wenger

Senior Devvie




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


« Reply #12 - Posted 2006-09-18 16:47:03 »

For the Background / Foreground .getGeometry() method:

I was always disturbed of this method, since it doesn't return a Geometry or Shape and always wanted to rename it. But It has this name in Java3D. So I din't do it so far. I just stumbled over it again last night Smiley

Anyway, I really like it renamed, since it is a failure we don't need to imitate from Java3D and it's one more point we are better in than Java3D, since it is better understandable. So it's good, that you renamed it, Amos.
Well it just disturbed me that a method named getGeometry() returned a Group.  Grin (probably it was a geometry in the ancient times).

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

Mr.CodeIt (23 views)
2014-12-23 03:34:11

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

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

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

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

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

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

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

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

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
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!