Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (515)
Games in Android Showcase (122)
games submitted by our members
Games in WIP (577)
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  
  Handling events  (Read 1688 times)
0 Members and 1 Guest are viewing this topic.
Offline pedro

Junior Duke




Java games rock!


« Posted 2003-11-17 20:16:48 »

I am about to create a 3d application using xith3D, and was wondering what is the best approach to handle events.

After Canvas3D is registered to listen for mouse inputs (for example), do people normally have another a class to further manage events associated with entities in the 3d world? So when there is an event, a loop tries to pick and see which entity is associated with it and process the event accordingly?

If a model consists of different parts, how can one 'listen' for mouse events on the different parts of the model? I am sorry for the newbie question, but it would be cool if someone could direct me to a good way of dealing with this.

cheers.
Pedro Teixeira

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #1 - Posted 2003-11-17 20:42:44 »

I suggest you download/print the Getting Started Guide PDF, and go though some of the examples.

There are two excellent tutorials on getting AWT mouse events and also on Picking (which is I think what you are after) which Jens has authored.  It shows you how to detect "3d scene" events as you call them.

http://xith.org/tutes.php

If you want an example of Picking in action, the one that is explained in the GSG, goto this JWS link:
http://xith.org/jws/jws-org.xith3d.gsg.Picking.jnlp

More fully explained demo's from the GSG here:
http://xith.org/demo/org.xith3d.gsg.php

Will.

Offline pedro

Junior Duke




Java games rock!


« Reply #2 - Posted 2003-11-19 17:28:56 »

Thanks for the directions! But I'm running into apparently silly problems. I am basically try to find a way where I can deal with mouse and key events, and 'tell' the involved objects to act accordinglt. I would appreciate if someone could spot what's wrong with the following?  

I have a main class, with the following methods:

init() {
 start rendering peer, canvas3d, universe,..
 addMouseListener( eventManager --> which is a class that holds a Vector of events to be dealt with)
 call run();
}

run() {
 while(true) {
     view.renderOnce();
     handleEvents();
 }
}

handleEvents() {
  goes through events in the queue, and process it.  
  For example, if mouse was released call pick(x,y)
}

pick(x,y) {
 try to pick some objects:
 PickRenderResult[] results = view.pick(canvas, x, y, 3, 3);

}


The problem is that I get the following:

1  
2  
3  
4  
5  
6  
7  
8  
java.lang.Error: Pick initiated not from rendering thread
        at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:853)
        at com.xith3d.scenegraph.View.pick(View.java:713)
        at Main.pickDebug(Main.java:125)
        at Main.handleEvents(Main.java:92)
        at Main.run(Main.java:116)
        at Main.init(Main.java:74)
        at Main.main(Main.java:149)



What's meant by the rendering thread? It's the thread from where view.renderOnce() is called, right? Can another thread be granted permission to call the View.pick() ?

Is it necessary to have a queue to hold the events? Can't events be processed straight from the EventListener class? (instead of just setting up some flags)


[All this is very interesting.. Smiley]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Duke




Speak Java!


« Reply #3 - Posted 2003-11-19 18:49:36 »

Hi,

The problem is somehow strange, your logic seems to be OK. Anyway, check Xith3DSwitchNodeTest.java - it implements exactly this technique [only event queue is one-level and implemented as locak variables with flag], and it works OK.

Also, you should never mix call to View.renderOnce() and View.startView() because of startView() also starts trivial rendering thread.

Quote
What's meant by the rendering thread? It's the thread from where view.renderOnce() is called, right?


Yes, correct. But you should take care that only one RenderingThread exists per one JOGL-based CanvasPeer.

Quote
Can another thread be granted permission to call the View.pick() ?


With OpenGL renderer - no. JOGL requires that all the OpenGL calls for given context are made from same thread, and pick(...) uses OpenGL to perform picking operation (GL_SELECT mode).

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Jens

Senior Duke




Java for games!


« Reply #4 - Posted 2003-11-20 02:45:55 »

Post the whole source or a simple example here and I'm sure we can help.

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline pedro

Junior Duke




Java games rock!


« Reply #5 - Posted 2003-11-20 08:53:23 »

The problem indeed was that I was a calling view.startView() in the init method.. Thanks for the help!

And.. is there any purpose to call this method at all, since it creates a thread and therefore deny us access to openGL calls?

best regards.
Pedro Teixeira
Offline Jens

Senior Duke




Java for games!


« Reply #6 - Posted 2003-11-20 09:02:24 »

Quote
And.. is there any purpose to call this method at all, since it creates a thread and therefore deny us access to openGL calls?


Currently in my opinion it just makes sense for simple examples. For most applications it is better to have control over the rendering thread. (It might make a bit more sense, when Behaviors are implemented.)

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #7 - Posted 2003-11-20 09:19:49 »

Quote


Currently in my opinion it just makes sense for simple examples. For most applications it is better to have control over the rendering thread. (It might make a bit more sense, when Behaviors are implemented.)


I would agree with this. In java3d you didn't have direct access to the thread but you could still do intermediat or mixed mode rendering, when behaviours go into xith it will be interesting to see how it's handled Smiley

Endolf.

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.

TehJavaDev (31 views)
2014-10-27 03:28:38

TehJavaDev (26 views)
2014-10-27 03:27:51

DarkCart (40 views)
2014-10-26 19:37:11

Luminem (21 views)
2014-10-26 10:17:50

Luminem (25 views)
2014-10-26 10:14:04

theagentd (31 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (57 views)
2014-10-16 15:22:06

Norakomi (46 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!