• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

144 Neutral

About misterX

  • Rank
  1. [java] Outline text

    ...just my two cents: if you're using a very thin font (what i supose. I bet you're using the default one.) you should simply draw the background string in the 9 directions insteand of 4! :P
  2. [java] Initializing java3D

    i tested the code above (modifying some tiny details) and it worked fine here. I'm using the openGL version of J3D and also have a bitdepth of 24 for every configuration, however it works fine. Maybe your drivers aren't up to date, is it possible? ...else, i've no clue.
  3. [java] Location in Java3D universe

    yes, the view, starts at 0,0 for your problem, i see several solutions: either the one explained before: myViewPlatform.getLocalToVworld(myTransform3D); myTransform3D.invert(); or, if you're using a ViewingPlatform (the default in a SimpleUniverse): myViewingPlatform.getMultiTransformGroup() or: extend the OrbitBehavior to know the transform. I beleive it is placed in: OrbitBehavior#targetTG for information, to get the pos from a Transform3D: myTransform3D.get(myVector3fORd); => myVector3fORd.x & myVector3fORd.y is it enough or would you want more explanations?
  4. to AP: I just wanted to mention i don't agree with your post. Quote:Original post by Anonymous Poster If you were smart, you might have listened, and then be asking a much more intelligent question, such as: "How come Swing is often slower than AWT despite being lighter in all ways?" That's as stupid. It is shown to be false in the previous posts. Moreover, I've never seen problems of slowdowns because of the number of components a GUI used and i suspect nobody else had, even with hundreds of components. The last thing is that people have the unfounded belief that AWT is *faster* because it's more *basic*. The thing is AWT was "left on the side" after JDK 1.1 because swing is better. Quote: The answer to which is quite simple, and obvious from what the others have said: with a LW component, the developer has to do ALL the work - and that includes interfacing nicely to things like HW acceleration of rendering. The fact that Sun took a very long time to get even partial HW acceleration of Swing and the many bugs and inefficiencies in Sun's own versions of stuff the OS does much better because it's been tested more extensively and had more developers combine to make Swing slow. Maybe it was like this long ago at the time of the first JDKs, but now it's definitely not like this. Swing's component painting is based on java2D so it takes automatically advantage of hardware acceleration if possible. There is not a single line to add (or you made something wrong). LW components are used exactly the same way as HW ones. So I really wonder what you meant with all your extra work. Quote: This is, of course, completely ignoring the other reason Swing is often slow: the people writing Swing code are often crap programmers, or lazy Sun staff who write shit like JTable and JTree. If you find a slow Swing widget it's usually because it's implemented compeltely wrong, and you can easily write your own, in java, no special hacks or anything, that is ultra-fast and responsive. Even for crap programmers, the slowdown issues will surely not be because of their GUI. But, ok, that could maybe be possible in some rare cases. On the other side, what i find very **** is your comment about sun's staffs. I personnally find the API very slick, of good quality and you just need to look at it to see the effort put into it. For example: the JTable. It's very easy to use and very powerfull either, so where is the problem? (Or is it that it doesn't work as you thought so you don't like it?) That's all, i just wanted to say it.
  5. ...hmm there seems to be a general misconception. It looks like all of you think:"awt is quick / swing is slow" It's the opposite!!! Swing is quickier, lighter and more responsive than AWT! To be convinced, just run a small test like the one here under for example. This test creates a window and adds randomly placed/sized buttons to it. Run the test with AWT & swing and you'll observe the difference of performances. import java.awt.*; import javax.swing.*; public class Test { final static int NB_BUTTONS = 5000; public static void main(String[] args) { //testSWING(); // - OR - //testAWT(); } static void testAWT() { Frame frame = new Frame(); frame.setSize(800, 600); frame.setLayout(null); for (int i=0; i<NB_BUTTONS; i++) { int x = (int) (Math.random()*frame.getWidth()); int y = (int) (Math.random()*frame.getHeight()); int w = (int) (Math.random()*(frame.getWidth()-x)); int h = (int) (Math.random()*(frame.getHeight()-y)); Button b = new Button("AWT!"); b.setBounds(x,y,w,h); frame.add(b); } frame.setVisible(true); } static void testSWING() { JFrame frame = new JFrame(); frame.setSize(800, 600); frame.getContentPane().setLayout(null); for (int i=0; i<NB_BUTTONS; i++) { int x = (int) (Math.random()*frame.getWidth()); int y = (int) (Math.random()*frame.getHeight()); int w = (int) (Math.random()*(frame.getWidth()-x)); int h = (int) (Math.random()*(frame.getHeight()-y)); JButton b = new JButton("SWING"); b.setBounds(x,y,w,h); frame.getContentPane().add(b); } frame.setVisible(true); } }
  6. [java] Location in Java3D universe

    1) what has time to do with this? 2) where is the problem to compute the positions?! If you have a very complex scenegraph and are unable to keep track of your objects position, this could maybe help: myObject3D.getLocalToVworld(myTransform3D); myTransform3D.invert(); so that you can get the pos. But usually, you know where your objects are and you transform the scene in consequence, not the opposite!
  7. i never used LWJGL but i think it would be a good choice since puppygames focused mainly on "2D in 3D" games. So my vote goes also for LWJGL. On the opposite, i wouldn't advise J3d for this. It could do it as well, that's not the issue. But i think it would be simplier and easier to make with a more direct api like LWJGL.
  8. Quote: Shouldn't it be called heavyweight, rather than AWT, meaning it's less efficient and bogs down the system more than AWT does? Why the heck did they choose to use that terminology?? I don't know where you got this, it's the opposite. Here is an interesting article: http://java.sun.com/products/jfc/tsc/articles/mixing/index.html and here some parts of it: Quote: A lightweight component is one that "borrows" the screen resource of an ancestor (which means it has no native resource of its own -- so it's "lighter"). ... Some of the benefits of using Swing components are: -More efficient use of resources: Lightweight components are really "lighter" than heavyweight components. -More consistency across platforms because Swing is written entirely in Java. -Cleaner look-and-feel integration: You can give a set of components a matching look-and-feel by implementing them using Swing. ... There are some significant differences between lightweight and heavyweight components. And, since all AWT components are heavyweight and all Swing components are lightweight (except for the top-level ones: JWindow, JFrame, JDialog, and JApplet), these differences become painfully apparent when you start mixing Swing components with AWT components. ... The differences boil down to the following: -A lightweight component can have transparent pixels; a heavyweight is always opaque. -A lightweight component can appear to be non-rectangular because of its ability to set transparent areas; a heavyweight can only be rectangular. -Mouse events on a lightweight component fall through to its parent; mouse events on a heavyweight component do not fall through to its parent. -When a lightweight component overlaps a heavyweight component, the heavyweight component is always on top, regardless of the relative z-order of the two components.
  9. no, there is no "Shadow" object or similar in j3d. No shadowing "ready out of the box" is implemented. The reason is that there are several ways of doing it, and usually one of them is chosen depending on the needs and proprieties of the scene. Realistic dynamic shadows are very complex and very computation heavy. Therefore, simplifications are often used. You can find general articles on shadows here on gamedev: http://www.gamedev.net/reference/list.asp?categoryid=72 I can't help you since i don't know much in this field, maybe you'll have better luck at: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=3D
  10. [java] 3D lib necessary?

    i think java3d (and surely xith3D also) would perfectly fit for doing this. With the scenegraph, it's very easy to build graph/trees with nodes and connections as well as positionning the view at the right places.
  11. [java] J3D and the AWT..

    i've difficulties to understand what you are exactly asking for. What you seem to ask is how to make an AWT UI for a java3D program. => you build AWT UIs for j3D programs like for every other programs. I don't understand what it has to do with j3D. (?!?) => and to know if it's running as applet or as application, why does it have any importance to know that? (It's exactly the same for creating UIs either) So what exactly are you trying to do/searching for?
  12. [java] Java3D and frame updates

    i'll first try to clarify the situation, i'm feeling you're a bit vague yourself. So if you have your working engine, so that you give the input and get the expected output. You could use a single behaviour that wakes up each frame using a WakeupOnElapsedFrames(0). What you had before: update all objects while (timeLeftInFrame) update next AI render Will just be rewritten in such a behavior: public void processStimulus(java.util.Enumeration criteria) { update all objects while (timeLeftInFrame) update next AI } This is strictly equivalent. It'll be exactly the same. This behavior is guaranteed to wakeup every frame, so it'll do everything your engine should and when it's done, the rendering will take place (then it'll be called again...). Therefore, it should be no problems to do that since it's just moving a piece of code into a single, main behavior. This behavior is guaranteed to be waken up before every frame rendering and to be executed completely. Other behaviors run in parrallel to rendering. Besides of this, two details in your post look a bit strange to me. The first one is: while (timeLeftInFrame) update next AI I understand it like this: if there is time, proccess first AI agent. If there is still time, proccess second AI agent... until time went out. This means two things: - some AI agents will be updated and others not - if some AI agents need some amount of time to proccess, the frame could be late or the AI be cancelled in the middle of it's thinking. Ok, these may be details but may be of importance if the AI is time consuming. To show the use behavior, an alternative would be to implement it like this: Every agent has one behavior for it's AI that runs in parrallel to the rendering. This means it'll start to compute things, then in the middle of the computation, the scene will be rendered, then the AI will go on as nothing happened. They just run in parrallel like any behavior do (exept WakeupOnElapsedFrames(0) which is synchronized with the rendering) and therefore cannot accidentally freeze the rendering if they take too long. For your last question, i simply can't answer, i don't know your structure (and you? :P) so i obviously can't answer. cheers
  13. [java] Java3D and Skinning

    hi, your question seems a bit unclear. sun's tutorials explain clearly how to import models (textured or not). And if you want to apply textures on a special way on models, it is also clearly explained in these tutorials. Does it answer your question?
  14. [java] Java3D and frame updates

    i would strongly disadvise to try making an "update then display" cyclic loop in java3D. It is not meant to be used that way. And extending the canvas3D to do such a thing is just trashing the api. Ideally, in j3d, you should forget the "old" main loop of the form: handle input update game elements display graphics Instead, you should now place your elements in the universe and animate them with their own behaviors. Objects will be independant and behave according to their own behaviors and interact with each others and the input. No more main loop, no more loop at all. Maybe it seems strange at first sight or hard to understand or "feel". But wanting to give a better insight of this would need much more lines. Ideally, the best is to merge with java3d's way of doing and using behaviors and so on. If however you wish to keep your engine as it is now, a simple and easy solution would simply be to run the engine from a single behavior waking up each frame (using WakeupOnElapsedFrames). cheers and good luck!
  • Advertisement