Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Xith3D for SWT  (Read 6974 times)
0 Members and 1 Guest are viewing this topic.
Offline tgeorge

Senior Newbie




Java games rock!


« Posted 2004-02-08 20:11:28 »

I have a question.  I am in the process of porting the
Xith3D engine to SWT, (as well as implementing the
3D texturing correctly Angry , but that's not the subject of
this post).  Half of the work is done.  That is, since I
noticed that Xith3D sits on top of JoGL, I ported the
JoGL binding to SWT.  Now I can use JoGL in a SWT
GLCanvas.  To test that all of the functionality of JoGL
was correctly exposed a volumetric shadow test was
implemented.  This tested everything from shaders to
pbuffers, all at once.  It works fine Grin .  Step 2 is to
implement a Canvas- and Render-  Peer in SWT.  Also
a fairly simple task, however, this is not all that has to
be done.

This brings me to the heart of the post, event handling.
Right now, all of the events throughout the Xith3D code
base are AWT events, that leaves SWT events out in the
cold.  So even though there is a SWT-based GLCanvas
that is acting as the CanvasPeer, there are no events
coming out of it and into the rest of the system.  This
is because the rest of the system is listening for AWT
events, which they will never receive.  My planned course
is to write abstractions for all of the events, and then
listen for those in the code base instead.

I am writing to ask if the actual Xith3D developers think
that this is a reasonable course of action.  There are a
lot of surprises throughout the code base that I have been
coming across.  Like the need to do event handling correctly
in the UIWindow as well as in the general system.  It would
be great to know whether or not there are other gotchas in
the code base, or if you guys planned on implementing
SWT integration in a different way.

Holla Back . . .

                                                          -T
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #1 - Posted 2004-02-08 23:28:07 »

If Xith3D is to be truly independant of the rendering layer (which it will need to be if it is ever to be used with LWJGL as well) then we will need these abstractions.  Most of the event handling stuff is really just a temporary hack I believe.  Abstracting these events could also mean seemless JInput integration too.

Another important one is the concept of the Window - so that it will be possible to change for example the title and size of the window in an implementation independant way (currently one has to get the JFrame which isn't so great).  This shouldn't be a large task - a simple interface would hopefully suffice but still it needs to be done.

If you do write an event input interface for Xith3d - would you consider adding in Joystick (and GamePad) support along with mouse, keyboard and window events?

+1 for the abstraction of events from me Smiley

Please keep us posted on your progress.

Will.

Offline Java Cool Dude

Senior Member




Java forever


« Reply #2 - Posted 2004-02-09 00:57:54 »

A bit off topic but I noticed when creating a LWJGL demo that the frame is created and displayed onto the screen in less than half second which is pretty amazing.
Using the regular Jstuff, a frame could take up to 2-3 seconds to show anything on the screen...
I wonder if SWT is any better than AWT or Swing
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #3 - Posted 2004-02-09 01:08:57 »

Quote
I wonder if SWT is any better than AWT or Swing


I wounder that too, especially with the enhancements in Java1.5.

On the topic of portability - I assume that the user inferface library of Xith3d will always require Swing to be installed yes?  I guess it too could be abstracted but that wouldn't be trivial and I'm sure we'd lose some functionality.

Will.

Offline tgeorge

Senior Newbie




Java games rock!


« Reply #4 - Posted 2004-02-09 01:26:09 »

Regarding speed, the short answer is that bringing up
a SWT Shell, (equivalent of a JFrame), is SIGNIFICANTLY
faster than bringing up a JFrame in Swing.

The real reason my company uses SWT, is because of a
bug in JoGL on Windows.  If you bring up a Frame or
Window with multiple GLCanvases in it, draw
to them, and then remove all of them and create new
GLCanvases in the same Window or Frame to replace
them, you will get a crash.  Perhaps not the first time,
perhaps not the second, but sooner or later if you
replace GLCanvases enough, a crash will ensue.

This bug was pretty annoying actually.  Haven't tried it
on 1.5, but we shipped our product last year, so we
HAD to go with SWT, or not use OpenGL.  I am revisiting
the situation now to see if there has been any progress.
I think that Xith3D is the only thing out there that we
would have use for, so I am porting it to SWT so that
we can use it in the future, like the next release.

One thing I will say though, our product has really been
kickin' the s#!t out of a competing product also written
in Java, but using AWT and Swing.  Why that is I don't
know, as I have not used this competitor's product, but
there it is.

                                                      -T
Offline Java Cool Dude

Senior Member




Java forever


« Reply #5 - Posted 2004-02-09 01:32:17 »

Well if you need any help regarding the port, I'm right here making myself your first volunteer Grin
Offline tgeorge

Senior Newbie




Java games rock!


« Reply #6 - Posted 2004-02-09 01:48:23 »

Thanx JCD . . .

THAT is EXACTLY what I was hoping for . . .

Right now I am still inventorying the code base.

I just got a look at it in depth for the first time
yesterday.  Tomorrow I will have a better
idea of what I think the abstractions should look
like.  More importantly, I will be able to back up
my assertions with data.  Right now you guys are
WAY ahead of me in your understanding of the
code base.  I have to catch up in order to facilitate
a productive interchange.

I WILL be running some ideas by you tomorrow
though, if you are available.

                                                 -T
Offline Java Cool Dude

Senior Member




Java forever


« Reply #7 - Posted 2004-02-09 02:11:20 »

Quick question:
Say we successfully switch Xith3D's current AWT/SWING dependencies to SWT, does that mean that JET could finally .exe a Xith3D demo?
/me day dreams
Offline Jens

Senior Member




Java for games!


« Reply #8 - Posted 2004-02-09 06:51:23 »

Without Swing it is maybe possible to use gcj (or kaffe). This means:
  • Xith3D can run with a free version of Java and can make it in the Linux toolchains one day (wow, just the thought of this is amazing). That's the way eclipse conquered the Linux developers desktop.
  • Xith3D programs can be compiled to native code on every relevant platform, which is a very good thing, because it depends on native libraries anyway.

What a pain that I have exams now and not much time to investigate further on the two points above, which would take Xith3D's strength to a new level.  I'll certainly do what time permits. If anyone knows a reason why the above is not possible at all, please tell me.

Regarding the event abstraction: I'm all for it and I already mentioned this weakness of Xith3D several times.

Of course we have to take care of existing Xith3D projects (especially Magicosm). The changes above almost certainly break Xith3D, but if it helps to make it more powerful, it's worth it. I would like very much, if Yuri or David could join this discussion, because they have the best overview of the structure of Xith3D.

Btw. I'm very pleased to see new people interested in supporting Xith3D here.

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

Senior Newbie




Java games rock!


« Reply #9 - Posted 2004-02-09 13:18:24 »

JCD,

Yes it could, with a few caveats regarding UIWindow
that I'm not sure about yet . . .

I will be soon.

Jens,

Yeah, I agree there are some real cool opportunities
here.  I myself will probably start with an Eclipse shader
program editor, but others can integrate into other
tools, as Xith3D is open source.  As I said, my principle
thrust is to get a shader programming framework that
is useable by MY company, but others are free to do
what pleases them.

Now my REAL question,

Who are Yuri and David ? ? ?

And would they be of help here ? ? ?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2004-02-10 03:26:17 »

Quote

Now my REAL question,

Who are Yuri and David ? ? ?

And would they be of help here ? ? ?


David started and runs the Xith3D project, Yuri has added many great features (check the http://xith.org/demo/com.xith3d.test.php page) Smiley

Will.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #11 - Posted 2004-02-10 15:46:01 »

Hi,

Quote
Who are Yuri and David ? ? ?


OK, say, my name is Yuri Smiley . If you'd like to see my profile - you are welcome to http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=announcements;action=display;num=1074215610;start=15#15 thread, but this is off-topic here.

Now as of SWT port for JOGL and Xith3D.

For me, SWT is nothing different that AWT and Swing - this is just another GUI library with nice features, but also with its own open topics.

Xith3D is first of all scenegraph-based rendering engine. Of course, there is a need, a very big need, to add support for event handling and behavior processing.

Time ago I was implementing support for OpenGL-based picking in Xith3D, and came to the issues of handling UI events associated with 3D rendering components.

As of now, UI event processing (except of UIWindow) is completely up to the application that uses Xith3D. CanvasPeer has a method for obtaining a Component that acts as 3D rendering component, and then application can attach any event handlers to it. I see this approach very reasonable, because of it allows to keep Xith3D core aware of any of UI-library-specific event processing issues (again, except of UIWindow).

The visible problem with SWT integration is that [maybe - I don't know] SWT version of GLCanvas extends something other than java.awt.Component, so it may make it incompatible with current CanvasPeer API. This can be easily changed by adding, say,

 public Object get3DRenderingUIComponent()

that will return something other than Component.

I even don't see any reason of changing Canvas- and Render Peer in order to support SWT, just because of this may be a part of JOGL - it already contains factory method of creating GLCanvas:

 GLDrawableFactory.getFactory().createGLCanvas(gc);

So we can keep the same peer classes for all of the JOGL-based UI components.

As of event handling in general, I see the following structure of application that uses Xith3D:

1. Application creates CanvasPeerImpl of interest, maybe providing some peer-implementation flags indicating details of canvas creation.

2. Application attaches event handlers to created CanvasPeerImpl in implementation-specific way.

3. Application attaches View to Canvas and runs rendering loop (either built-in or custom).

4. Upon UI events received, application modifies Xith3D scenegraph accordingly, which results in visible dynamic changes.

If we speat about JInput and other related things, then I would say that there should be separate scenegraph modification subsystem, that may/will run in rendering thread context and will react to different external events. This will bring us to known concept of Java3d Behaviors, which is currently not implemented in Xith3D [OK, I have partially implemented some parts of it for my projects, but this is not 100% compatible and has only part of core Java3D behaviors implemented (interpolator and base mouse behaviors)].

Comparing to Java3D, Xith3D can be really flexible on supported behavior types, so we can make set of behaviors that react on different types of input - say. we can have set of AWT-based mouse behaviors, as well as SWT-based, as well as more generic JInput-based.

But, at the end, I see this as a separate Xith3D subsystem, Scenegraph Manipulation API, so we can still keep Scenegraph Rendering API independent on the underlying UI library, platform and rendering subsystem.

I would prefer to break Xith3D project to subsystems, so it will not become a non-maintenable monster, but a set of optional subcomponents. We see excellent example of this with XML serialization - this is a part of xith-tk project, and interoperates with Xith3D core very well. If we need to make some changes in Xith3D core in order to suppoer SWT, there is absolutely no problems.

Yuri

P.S. This is not a "final decision of Xith3D team", but my personal opinion [that I see very reasonable], so I am open for discussion anyway.

Yuri Vl. Gushchin
JProof Group
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #12 - Posted 2004-02-11 01:50:45 »

Quote

But, at the end, I see this as a separate Xith3D subsystem, Scenegraph Manipulation API, so we can still keep Scenegraph Rendering API independent on the underlying UI library, platform and rendering subsystem.

I would prefer to break Xith3D project to subsystems, so it will not become a non-maintenable monster, but a set of optional subcomponents. We see excellent example of this with XML serialization - this is a part of xith-tk project, and interoperates with Xith3D core very well. If we need to make some changes in Xith3D core in order to suppoer SWT, there is absolutely no problems.


This would be a very good idea indeed.  Other examples of potential sub systems are the collider code, Swing UI, Ase Loader, and terrain generation.  It's certianly important that these packages stay "optional" in the sense that Xith3D doesn't depend on them.  Reasons include as you said, maintainability and also preventing download size bloat and letting the developer easily use an alternative api (for example Odejava instead of the collider code).

Will.

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2004-02-11 07:57:17 »

Here I was talking to someone about abstracting away the basic context management for GL applications using an interface. I believe that the most sensible way forward for everyone in this space is to make a concerted effort on this interface.

Because, ultimately, all GL bindings actually co-operate together and work the same way, it should not matter beyond the context management exactly what the GL binding looks like.

If we could just convince JOGL to branch out into JOGL and JOGL-Context we could all implement the same interface (eg. LWJGL's Window would implement it, SWT could have an SWT canvas that implemented it, and AWT could have a GLCanvase that implemented it). This code only needs to be done once and maintained in one place.

Cas Smiley

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #14 - Posted 2004-02-11 09:10:04 »

well that would help LWJGL support Smiley

a good idea, but, do you think they'll go for it?

Will.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #15 - Posted 2004-02-11 09:24:43 »

Cas,

So, if I understand you right, your suggesting is to isolate OpenGL bindings from UI components that display OpenGL-rendered content via common GLContext/GLCanvas/GL*** interface?

In this case we should think about complete Binding <-> UI Element interaction API, which will be a good idea.

With complete API I mean that we should have in mind also something like GLDrawable callbacks for JOGL.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2004-02-11 10:52:58 »

Yes, I think you're saying what I'm saying. Basically, OpenGL rendering in Java is split into 3 layers: context creation, context management, and GL API calls.

Context creation is the preserve of the underlying windowing system. So LWJGL, SWT, and AWT all have their own ways of creating a context.

GL API calls are all being done in slightly different ways depending on your tastes/requirements - but the crucial thing is that it doesn't matter what API you call or when you call it or even if you mix them: the same native functions get called. (As I pointed out recently in the JOGL forum, you can freely mix and match calls to both APIs).

So that leaves the bit in the middle which has only one thing to do: it must be the common interface between context creation, management, and GL API calls.

If your context creation system is effectively a factory that creates concrete implementations of the interface, you have abstracted away the fact that LWJGL, AWT, and SWT use very, very different methods to set up a context. In LWJGL our Windows and Pbuffers are contexts. SWT uses some SWTGLCanvas and JOGL uses whatever JOGL uses.

The management of the context is then down to the actual implementation but there's really very little it has to do. In fact the only thing it has to do is make itself current for the current thread, and provide rudimentary information about itself such as its size and buffer depths.

Where does this get everyone?

Well, it means that I could write a model renderer in LWJGL that could be told to render on to a JOGL canvas. Or a Xith3D scene could be rendered into a LWJGL window and then I could paint my GL rendered GUIs on top with LWJGL. (Forget, for now, the fact that you'd have two native libraries - that's under-the-hood). Or I could have Swing components in my LWJGL window manipulating a Xith3D scene. In short we could concentrate on writing software components that render stuff without worrying about what's underneath so much.

I'm quite excited by the prospect of making this possible without hurting anyone's APIs or philosophies.

Cas Smiley

Offline tgeorge

Senior Newbie




Java games rock!


« Reply #17 - Posted 2004-02-11 12:52:45 »

OK, I'm back and armed with data.

Princec,

An abstraction of GLContext handling will be a little more
tricky than it seems.  Firstly, AWT and Swing both have the
concept of locking and freeing.  These are things you don't
have to worry about in LWJGL Window or with SWT.  That's
why people use those, because they are more simple.
That's also why JoGL on AWT or Swing freaks out if you
try to do any complicated context handling, like removing
and creating Canvases in an AWT or Swing container on
the fly.  This is also the reason for all of the rendering
thread management calls in JoGL, and that's a whole other
mess that AWT and Swing oblige you to deal with.

I think it is instructive here to consider what the people
at JoGL have done to help us in this regard.  They knew
about the assanine nature of AWT and Swing when they
started reworking the GL4Java code, so they hid the
GLContext altogether.  You can't get to it from the public
APIs.  The only HACKish part of the interface to the
GLCanvas is all of the render thread crap and the auto
redraw handling.  However, in as much as there is a
disagreement with those APIs being there, it could almost
be called philosophical.  The fact is you can use JoGL in
a semi-sane manner with what they've given you.

I think this is the model to follow.  Take a close look at it,
and see what you think.


                                                           -T
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #18 - Posted 2004-02-11 13:05:38 »

Cas, you are 100% right about the context management. And perspective of having binding-independent API for higher-level systems such as Xith3D sounds quite interesting.

Now coming to practical point: in Xith3D, this is relatively easy to add one more indirection level to isolate CanvasPeer/RenderingPeer from binding-specific context management. But what we should do with GL calls? I assume that both LWJGL and JOGL can be used to call native-level OpenGL functions, but how we are going to handle differences in their APIs, and especially differencies in parameter passing (if any, but I can imagine there are differences)?

[OK, I understand that this is a beginning of longer discussion that (I hope) will result in creation of LWJGL renderer for Xith3D, so lets continue]

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Jens

Senior Member




Java for games!


« Reply #19 - Posted 2004-02-11 13:27:25 »

Charlie Dobbie is already working on an LWJGL renderer for Xith3D. I invited him to join the discussion. LWJGL support would be very nice to have.  Grin

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

Senior Newbie




Java games rock!


« Reply #20 - Posted 2004-02-11 13:28:23 »

Yuri,

OK, now I know who you are . . .
I did not mean to offend.

The proposal that you have put forward, I believe will
work.  However, I think there it will require more effort
than you're aware of.  Unless I'm missing something,
and I could be, a View requires a Canvas3D, which is
assumed to be an AWT component.  Right there you're
not off to a good start.  Throw in event handling and all
that stuff, and you've got a pretty big job on your hands.

Now I have to go back and ask my bosses for the time
to make the changes to Xith3D necessary for it to run
over SWT, because it will take more of my private time
than I have.  This is bad for two reasons, the first being
that other worthwhile development will stop for a couple
of weeks.  The second being that it is an open question
as to whether they would be inclined to donate my
changes back to your project.  So I'm in a bit of a bind
right now, as I don't want to have to support Xith3D
going forward.  "Support" meaning to integrate any
changes you guys are making into our system.

At any rate, I am now certain beyond a shadow of a
doubt that any current software written to Xith3D will
not work on the cross-toolkit version.  On the upside
the little hacking I've done so far works on SWT, AWT,
Swing and with LWJGL Windows.  At least, the rotating
cube test I wrote does.  This is cool, since it means that
I can implement princec's dream of a cross toolkit Xith3D.
BTW, princec, you can already mix and match calls to the
different GL instances of LWJGL and JoGL for SWT, just
make certain that you have called 'makeCurrent' in the
binding that you are using and either GL's calls will work.
Will not for JoGL AWT because of the lock and free issues
that I was talking about in an earlier post.

All told I'm VERY impressed that open sourcers made this
engine.  You guys should give yourselves a collective pat
on the back, this is TIGHT.  A few mistakes were made
integrating too closely with AWT, but I think that came
from following the Java3D spec too closely.  There was
probably little thinking about SWT, or the multi-canvas
crashing problems with AWT.

We're less than a month away though,

THANX GUYS ! ! !

                                         -T
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #21 - Posted 2004-02-12 09:19:59 »

tgeorge,

Quote
View requires a Canvas3D, which is
assumed to be an AWT component.


This assumption, as you mentioned later in your post, is made to make Xith3D scenegraph classes compatible with Java3D. From the other side, the way of using Canvas3D in Xith3D is quite different than in Java3D, so it is easy to factor this inheritance out of Xith3D core. But, as I already mentioned before, Xith3D Rendering Subsystem does not depend on AWT at all (UIWindow depends on Swing, but there are other reasons for that).

If you have some patches that make Xith3D more compatible, it would be interesting to take a look on that.

Quote
The second being that it is an open question
as to whether they would be inclined to donate my
changes back to your project.


Well, this is again matter of your personal opinion about that.

Quote
A few mistakes were made integrating too closely with AWT, but I think that came from following the Java3D spec too closely.  There was probably little thinking about SWT, or the multi-canvas crashing problems with AWT.


As of AWT integration, I don't think that Xith3D is too closely integrated with AWT. Java3D compatibility was a clear design decision, but AWT dependencies can be factored out if this is really necessary. As of crashes and other problems, they are just a bugs and nothing else, and they have to be found and fixed. If we speak about another UI libraries, each of them has its own issues and no one is perfect... ...everything is matter of joint efforts we put to make it usable.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline tgeorge

Senior Newbie




Java games rock!


« Reply #22 - Posted 2004-02-12 11:08:38 »

Yuri,

I guess that's what I mean, I can make Xith3D not depend
on AWT fairly easily.  However, this breaks ANY demo that
has been written to the current API.  What I'm wondering
is how people feel about that.
Is the design decision to
maintain Java3D compatibility set in stone and non-
negotiable?  If this is something I want open source, should
I start another project or would you guys be willing to put
these changes into Xith3D?  Again, all of the demos would
break if you do.

These are questions that have to be thought on.  Maybe
I should send you the source and you can decide whether
this is an enhancement to Xith3D, or really another
software package.  As you said, its the rendering that's
important.  I tend to agree with that, but people who
have written applications to the current API may not.
Maybe this is just me thinking like a commercial
engineer instead of an open source one, but there are
still 'customers' to satisfy here.  They just don't pay
any money.  So how is it that they are satisfied?  Normally
this is done through backwards compatibility, which is not
easily attained here.

I think we need a lot of people to
chime in on this issue, because I want to get my changes
out as soon as possible, so others can help through
testing or code changes.  I don't think there's a need for
a long discussion, just tell me whether or not a plurality
of the people would mind changes that break current
applications.  I can then fork something if I need to.

What do you guys think?

                                            -T
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #23 - Posted 2004-02-12 12:13:19 »

I thought it was made pretty clear up front that until Xith reaches a major version number things are open to change? (same as most OS projects I suppose).

Kev

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #24 - Posted 2004-02-12 17:07:30 »

Hi,

Quote
However, this breaks ANY demo that
has been written to the current API.  What I'm wondering is how people feel about that.


Let's try to find a way for minimum possible changes in code that uses Xith3D - I believe that this is possible.

Quote
Is the design decision to maintain Java3D compatibility set in stone and non-negotiable?


Xith3D is not 100% Java3D-compatible anyway, and exactly AWT dependencies are first candidates to become incompatible without seriously hurting developers.

Quote
If this is something I want open source, should
I start another project or would you guys be willing to put these changes into Xith3D?  Again, all of the demos would break if you do.


Lets check. We anyway can create a branch before we'll get confirmation from people that use Xith3D that it works. Xith3D already survived several incompatible changes, and [I hope] nobody died.

Quote
Maybe I should send you the source and you can decide whether this is an enhancement to Xith3D, or really another software package.


Would be great, because of I also have thoughts about factoring out AWT dependencies of Xith3D. You can submit patches to IssueZilla.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #25 - Posted 2004-02-12 21:36:53 »

Quote
I thought it was made pretty clear up front that until Xith reaches a major version number things are open to change? (same as most OS projects I suppose).

Kev


It was and I strongly believe this should be the case as we don't want to be restricted from the start.


Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #26 - Posted 2004-02-13 21:57:11 »

Some good news:

An abstract input library (BSD Licensed) is being created as we speak which could be very useful for Xith3D.  I especially like the fact JInput's in there becasue joystick support would be very nice indeed Smiley

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=GameDesign;action=display;num=1076380063;start=0

Will.

Offline tgeorge

Senior Newbie




Java games rock!


« Reply #27 - Posted 2004-02-13 22:39:33 »

Thanx,

I could use some help in that department.  Currently the
abstraction is only for key and mouse events, and is a
real hack.  For example, mousewheel won't work under
AWT and joysticks don't work at all.  Not that I've tested
them.

                                              -T
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #28 - Posted 2004-02-20 12:45:09 »

Quote
well that would help LWJGL support Smiley


The important point is that it wouldn't actually help it, rather make it irrelevant.  To mix Xith3D rendering into your LWJGL context would require both the JoGL and the LWJGL libraries to be present - Xith3D would still be using the JoGL library, it's just that the output would reach the LWJGL's context instead.

If Xith3D wants to be independant of JoGL, this doesn't help - you'd need a whole GL abstraction layer added into the mix.  Currently there's a lot of unnecessarily repeated code between the LWJGL and JoGL bindings, and another abstraction would alleviate this.  However, it's not a trivial task to implement, and if the JoGL context management is split away from the rendering code and the size of just the rendering portion of JoGL isn't too big, there's no reason to go through it.

However, Xith3D's real dependance on AWT comes not in the library itself, but in people's use of it.  Converting a demo written for Xith3D-JoGL to work with Xith3D-LWJGL basically amounts to removing nasty hacks (canvasPeer.getWindow().setLocation(100, 100);) and porting the input code to use LWJGL's Keyboard instead of AWT keyboard listeners.  The mentioned input abstraction may be exactly what you need!

Hellomynameis Charlie Dobbie.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #29 - Posted 2004-02-23 04:15:22 »

1  
 However, Xith3D's real dependance on AWT comes not in the library itself, but in people's use of it.  Converting a demo written for Xith3D-JoGL to work with Xith3D-LWJGL basically amounts to removing nasty hacks (canvasPeer.getWindow().setLocation(100, 100);) and porting the input code to use LWJGL's Keyboard instead of AWT keyboard listeners.  The mentioned input abstraction may be exactly what you need! 


Iagree with you there - in fact I think it's high time I write an abstract Window object.

It's hardly difficult, all you really need is the title, size, location...

Will.

Pages: [1] 2
  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.

Dwinin (23 views)
2014-09-12 09:08:26

Norakomi (56 views)
2014-09-10 13:57:51

TehJavaDev (69 views)
2014-09-10 06:39:09

Tekkerue (34 views)
2014-09-09 02:24:56

mitcheeb (56 views)
2014-09-08 06:06:29

BurntPizza (40 views)
2014-09-07 01:13:42

Longarmx (25 views)
2014-09-07 01:12:14

Longarmx (31 views)
2014-09-07 01:11:22

Longarmx (31 views)
2014-09-07 01:10:19

mitcheeb (38 views)
2014-09-04 23:08:59
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!