next »

['n ddrylliog]

Xith3DLogo is a small class in the org.xith3d.utility.general package which has one static public method, play(Canvas3D), which, when you call it, play a little "video" on this canvas with the Xith3D logo and some funky music. (There's also a kind of motto, but I think it should be replaced). The video exists when the user press a key or click on the canvas. The load time is very fast, and the needed resources are now in media.jar

Use it whenever you want to give credits to Xith3D in your game/app.

Enjoy !

[Dori]

There is one bug in it.

After Marvin update today the keybord and mouse input needs updating.

Code:

    public void onKeyPressed(int key) {
        end();   
    }
   
    public void onMouseButtonReleased(int x, int y, int button) {
        end();
    }

to

Code:

    public void onKeyPressed(KeyboardDevice keyboard, int key) {
        end();   
    }
   
    public void onMouseButtonReleased(MouseDevice mouse, int x, int y, int button) {
        end();
    }

['n ddrylliog]

Fixed.
Thanks for the hint.

[Marvin Fröhlich]

I had a look at it yesterday. This one is really great work . But I had some issues running it. I expected it to be runnable from the main render thread.

Amos, could you maybe modify it to not extend RenderLoop (expeacially not InputAdapterRenderLoop) and give it two play() methods. One, that starts a new RenderLoop and notifies a listener when finished. And one that takes an OperationScheduler parameter and schedules itself, so that it is usable in the main scheduler.

This way, the logo doesn't interfere with the existing RenderLoop and behaves as at least I would expect. And you will get rid of all threading related issues.

If you want, I could do that.

Marvin

['n ddrylliog]

I had a look at it yesterday. This one is really great work . But I had some issues running it. I expected it to be runnable from the main render thread.

Well, I also expect it to.

Amos, could you maybe modify it to not extend RenderLoop (expeacially not InputAdapterRenderLoop) and give it two play() methods. One, that starts a new RenderLoop and notifies a listener when finished. And one that takes an OperationScheduler parameter and schedules itself, so that it is usable in the main scheduler.

This way, the logo doesn't interfere with the existing RenderLoop and behaves as at least I would expect. And you will get rid of all threading related issues.

If you want, I could do that.

Certainly not. Either you or me hasn't understood something. I made the Xith3DLogo so that it could be launched anywhere, it blocks everything till the user clicks or press a key. I don't want to interfere with the already scheduled operations and additionnally I don't know what's the running mode of the user's RenderLoop (if any). This way causes much more problems than we have now, IMHO. For me, there are bugs in the implementation of some Xith3D classes. If there aren't, please explain me what exactly I'm doing wrong..

['n ddrylliog]

Just to mention it here: Make sure, that you own RenderLoop is not running when the logo is playing.

Ah, I see what you mean here. But what you suggest in the previous post, I don't see how to implement it. It's way too complicated. What I need is a mean to block every RenderLoop running

[Marvin Fröhlich]

Every RenderLoop? I don't think, there should be more than one RenderLoop running at a time. And the one RenderLoop is blocked, if you initiate the logo rendering from a ScheduledOperation and render it synchronously. This way the RL is blocked no matter which RunMode you use.

Marvin

['n ddrylliog]

Every RenderLoop? I don't think, there should be more than one RenderLoop running at a time. And the one RenderLoop is blocked, if you initiate the logo rendering from a ScheduledOperation and render it synchronously. This way the RL is blocked no matter which RunMode you use.

AH ! I think I see what you mean (I don't read again the previous-to-the-previous messages but try to reformulate it if that's one you meant).
You mean that the play() method should accept a RenderLoop and scheduled an operation which would then launch the Xith3DLogo own RenderLoop ? (In RUN_IN_SAME_THREAD RunMode ?).

[Marvin Fröhlich]

AH ! I think I see what you mean (I don't read again the previous-to-the-previous messages but try to reformulate it if that's one you meant).
You mean that the play() method should accept a RenderLoop and scheduled an operation which would then launch the Xith3DLogo own RenderLoop ? (In RUN_IN_SAME_THREAD RunMode ?).

No no. Let me try to explain it another way. What I want to be able to, is to use the logo this way:

Code:

public class Game extends RenderLoop
{
    Game()
    {
        super( 128f );
       
        // do bla...
       
        // do blub...
       
        this.begin();
       
        // show and play the logo and block until it ends...
        // use this RL's OpScheder to initiate it.
        new Xith3DLogo( this.getOperationScheduler(), .... ).play();
       
        // proceed with the main game code...
    }
}

I hope, this is clearer.

Marvin

['n ddrylliog]

Yeah, yeah, I see what you mean.

[Marvin Fröhlich]

I have improved the Xith3DLogo to make it handle all overruled stuff correctly and to be more thread safe.

Marvin