Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (546)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 16
1  Java Game APIs & Engines / JOGL Development / Re: ANNOUNCE: Aviatrix3D 2.0 release on: 2008-10-25 14:17:06
Well, there's nowhere else to post about it apart from OpenGL.org forums  Angry There is a sad lack of any other non-gaming Java forum for 3D graphics, so here is where we post about our occasional updates.

Like all toolkits, it's up to the end users to decide what they want to do with it. Yes, you could develop games with AV3D, but our primary development goals do not optimise for that path. As our company mostly does military, medical and scientific visualisation, as well as commercial applicaitons (see Shapeways), we make sure the toolkit is well suited to handle those tasks.

That said, there is nothing stopping someone from developing a game engine on top of it. It is just a scene graph after all. My current work is making sure that all the existing multipass techniques work. Some deficiencies are being worked on right now, and once those are corrected (for a 2.1 release), then all of the current, and hopefully future, GL coding strategies will be possbile within the AV3D API environment.
2  Java Game APIs & Engines / JOGL Development / Re: (GL)JPanel w/o GLEventListener on: 2008-10-20 01:14:28
Yes, it's a little tricky doing your own context management, particularly working with JOGL's lazy loading. We do this in the core of Aviatrix3D with a fair amount of success. Occasionally it falls over, particularly on OS/X, but it works.
3  Java Game APIs & Engines / JOGL Development / Re: ANNOUNCE: Aviatrix3D 2.0 release on: 2008-10-20 01:10:48
DzzD,

Yes, we're aware of that issue. The Shapeways site is in Beta, and so they have not yet acquired a commercial-grade code-signing certificate. As such, it is using a self-signed certificate from us right now. We expect that this situation will be changed around January 2009.

goussej,

I don't know about the TextRenderer bug. We do our own text management and polygon generation for the shapeways site. What we have internally to AV3D is a couple of simple checks - first to see whether VBO's are available and then a method call and catch for the GLException generated if they don't really exist. The VBO problem is symptomatic of a larger problem within JOGL of the way it does some version checking and capability checking right in the heart of the codebase. We've analysed this in the past and sent the results to Ken, but he disagrees that it is a problem. So, there is really nothing that we can do about it right now - so we just catch the exceptions and fall back to normal vertex arrays. There is significant changes to JOGL coming with the post OGL 2.0 pipeline infrastructure so hopefully that will fix those problems as a byproduct.
4  Java Game APIs & Engines / JOGL Development / Re: ANNOUNCE: Aviatrix3D 2.0 release on: 2008-10-16 20:11:32
They were added about 2 years ago, but it has been 2.5 years since the 1.0 release. These are the change notes of the big things that changed from 1.0 to 2.0.

Because we are being used in a lot of production systems, we're pretty slow going between major versions. We need to be really thorough in our testing to make sure it works across all major platforms.  VBOs are an example of something that, while they look simple, do not actually work nicely in a cross-platform manner. We also have to work around some bugs in JOGL code too to make sure (eg some drivers report that they support it, but when you attempt to access that particular method in the GL class, it throws an exception saying it can't resolve the name). Dealing with that across all different sorts of platforms and driver versions takes a lot of time. 
5  Java Game APIs & Engines / JOGL Development / ANNOUNCE: Aviatrix3D 2.0 release on: 2008-10-16 18:26:29
After two and a half years of serious development, Yumetech/j3d.org is pleased to announce the next major upgrade of the Aviatrix3D toolkit to version 2.0. This release has been a fundamental restructure of the codebase to further improve on it's initial design aims: namely to be a scalable scientific and visualisation-oriented scene graph capable of running on any size platform from a desktop PC and upwards.

A summary of the major changes since the 1.0 release:
  • Reorganised the interfaces to the rendering pipeline to not use most of the user-facing classes. Now uses the separate Cullable/Renderable-derived interfaces.
  • Introduced a lot of customisation capabilities within the pipeline, particularly with the ability to have your own culling and sorting code.
  • Addition of SWT lightweight rendering capabilities (Draw2D and GEF) This is somewhat a work in progress as SWT Image handles are an issue with long running code. Works on SWT 3.2 and later.
  • Introduction of VBO capabilities
  • Many package changes for the renderer/pipeline classes. Now is a little bit more easy to see what belongs where.
  • Ability to create multiple independent windows that share a scene graph and/or render management.
  • Multipass rendering ability. This allows for most multipass rendering techniques to be implemented. The one except we know of right now is shadow volumes due to the need to have a custom, infinite view frustum matrix. This will be fixed in 2.1.
  • Layers (compositing) and viewports within a layer can be created.
  • Point sprite extensions added

Aviatrix3D is used as the core of many commercial and military projects, though you are unlikely to see much marketing blurb about it as they are all back-office styles of applications. Our major public user is Shapeways: http://www.shapeways.com which has approx 10K active users on any one day using our toolkits, of which AV3D is the core technology.

You can look over the toolkit and download it from here:

http://aviatrix3d.j3d.org

(Still cleaning up a few minor things on the site as of this posting, so check back regularly!)
6  Discussions / Jobs and Resumes / Re: Yumetech is seeking an experienced 3D graphics programmer on: 2008-08-30 20:04:54
Yes, sorry. It's in Seattle, WA, USA. We would normally consider remote workers, but in this case, I'm looking at the role involving a reasonable amount of mentoring of junior developers as well, so we'll need you in the office for that.
7  Discussions / Jobs and Resumes / Yumetech is seeking an experienced 3D graphics programmer on: 2008-08-27 16:30:01
Title: 3D Graphics Developer

Yumetech is looking to hire an experienced 3D graphics developer.  We
are looking for a 3D developer with experience in developing shader
programs, ideally in OpenGL's GLSL.  A good understanding of scenegraphs
is key. Typically you will be asked to turn a research paper into
production quality code.

As a company that specializes in Open Source projects, the job tasks are
highly varied and span all levels of the software stack from low-level
OpenGL tweaking to full applications, to building specialized libraries.
As part of the OSS community, you must have excellent communication skills,
ability to work as part of a large distributed team and extremely flexible.
If you are smart, hard working and willing to be tossed into new situations
to learn on a regular basis, we can take care of the rest.

We work mostly in Java, but do have a reasonable amount of programming in other
languages - typically C, perl and shell scripts.
We develop and deploy across all three major platforms - MS Windows, OS/X and Unix.
Our company has a reputation for delivering well engineered solutions, not hacking,
so you should be of similar mindset. As such, we are looking for a software
engineer, not code hacker.

Yumetech is a software services company specializing in Open Standards
and Open Source 3D graphics applications.  We manage over 1.5 million
lines of Open Source code and are key contributors on several standards.
We are looking for employees who enjoy the creation process and value
working on many different challenging projects.

Initial position will be a 4 month contract leading to a full-time job offer.

Responsibilities:

Required:
- 5+ Years 3D Graphics Experience
- 2+ Years Shader Programming, GLSL Prefered
- 3+ Object Oriented software development experience
- BSc in Comp Sci
- Strong analytical and problem solving skills
- Strong self motivation, particularly looking towards a more
  senior role of leading one or more projects
- Excellent communication skills and willingness to participate in
  open source development communities.

Nice to have:
- Java Development Experience
- VRML or X3D Experience
- Experience in developing existing open source applications
- Experience in unix and open-source style development environments,
  including CVS, Make, Shell scripts, Ant etc

Please send your current resume to giles@yumetech.com
8  Java Game APIs & Engines / JOGL Development / Re: WebStart and Method "glBindBuffer" not available on: 2008-01-15 07:25:47
Ken, I know that Alan has sent them test code already for the VBO problems listed here,  but hasn't yet (that I know of) sent code on the other threaded issues yet. I believe the code was sent back in early-mid December.
9  Java Game APIs & Engines / JOGL Development / Re: WebStart and Method "glBindBuffer" not available on: 2008-01-14 18:00:13
We've had a similar problem in the not too distant past with one of our webstart applications that is publically deployed. This is a problem that we've specifically narrowed down to the Intel drivers. They say that they support it, but when you attempt to call any of the buffer methods it crashes saying that it can't find them. Check with all those users about which specific chipset they are using. I'll place good money that it's the Intel 465.
10  Discussions / Jobs and Resumes / Jr. 3D Graphics Developer - Seattle on: 2008-01-14 17:53:23
Yumetech Inc is looking to hire an entry level developer with a strong background in maths or 3D graphics programming (0-2 years commercial experience). As a company that specialises in Open Source projects, the job tasks are highly varied, but almost always have a heavy mathematical component.  We work all levels of the software stack from low-level OpenGL tweaking, to full applications, to building specialised libraries. As part of the OSS community, you must have excellent communication skills, ability to work as part of a large distributed team and extremely flexible. If you are smart, hard working and willing to be tossed into new situations to learn on a regular basis, we can take care of the rest.

We work mostly in Java, but do have a reasonable amount of programming in other languages - typically C, perl and shell scripts. We develop and deploy across all three major platforms - MS Windows, OS/X and Unix. Our company has a reputation for delivering well engineered solutions, not hacking, so you should be of similar mindset. As such, we are looking for a software engineer, not code hacker.

Initial position will be a 3 month contract with a full-time job offer available.

Responsibilities:

Required Skills:
    Very strong math skills (Calculus, Linear Algebra, Matrices/Vectors)
    Unix/cygwin development environments
    Java programming
    Software Engineering skills (eg Design Patterns, Data structures and algorithms)

Desired Skills and Knowledge:

    Open Source development tools (eg CVS/SVN, Bugzilla et al)
    VRML / X3D / Collada
    Applied Physics (eg What are Navier-Stokes Equations used for?)

We prefer college degree in computer science, though not required if you can demonstrate knowledge and use of good software engineering principles.

We are located in Seattle, WA, USA. We would prefer that applicant are in this general area as we have immediate needs and several projects to be worked on. If you are willing to (or are already) relocate to this area, we will also consider your application.

Please send replies to either myself (justin@yumetech.com) or Alan Hudson (giles@yumetech.com).
11  Java Game APIs & Engines / JInput / Re: Full Force feedback support on: 2007-08-15 02:57:54
I'm throwing this out for contemplation because there is now some serious movement at the higher levels of some communities for a generalised haptics description capability. SenseGraphics H3D API has a pretty huge support amongst the haptics-using industry and there's several working groups and open source projects (SOFA being the biggest of those) that are starting to work towards some sort of commonisation of haptics.

An additional feeder to that is the Medical working group of the Web3D consortium is starting working on specifying haptics capabilities as part of the X3D spec.

It would be nice is JInput had more than just "force feedback" capabilities and was capable of more general haptics rendering.
12  Java Game APIs & Engines / JOGL Development / Re: porting JOGL to SWT on: 2007-07-25 19:55:44
One of the major reasons for not extending GLAutoDrawable is the fact that it contains a completely unnecessary and pointless interface that pulls in all the AWT event classes. Simply importing that class and using it on Eclipse on a Mac causes the Mac to lock up the JVM solid. I don't even have to call or make use of them. It's the classloading of them that causes the problem. AWT and SWT are mutually incompatible on OSX. Doesn't matter whether in headless mode or not. Simply firing up the AWT event model causes the lock because SWT uses one toolkit (Carbon) and AWT the other (Cocoa). Apple states flat out time and again on their developer websites that they are mutually incompatible and developers should never mix the two toolkits together.

The other major problem with the bottom of the JOGL source is that it has a very large amount of code that is designed to make the integration between Java2D and JOGL much smoother for JDK 1.6. In the bottom of the implementation the existing JOGL Threading class makes method calls and class references to the AWT event queue. The RI also then makes many many calls to an internal class called Java2D, which also either directly calls the Threading class or makes other calls into the AWT code that tickles the AWT event model, with the inevitable deadlocks on OS/X.

The biggest problem that I ran into was that there are so many layers of internal circular dependencies in the RI that it was not possible to cleanly extend it for SWT usage. I've used large chunks of the RI code, but heavily modified in many ways. I had to strip thousands of lines of code out of it to make it work (ie not deadlock) and also have some amount of long-term maintainability that was not dependent on the RI code. Another contributing factor to the large amount of differences it that SWT and AWT fundamentally act differently. AWT uses a lazy-loading approach to the widgets, SWT does not. The AWT widget can exist for a long time before the underlying operating system resources are allocated, where SWT has the native resource loaded before super() returns in the constructor. This forces many more intracacies on the AWT implementation than was needed for SWT. In fact, as I got through it, I found that many of the threading things that the RI had in it were causing problems for the SWT code. In stripping all that out, it made the code more reliable and conformant to the SWT implementation requirements.  I struggled for months to keep the code in a state where you could run either the SWT or AWT components and still have things somewhat sane. However, it just cannot work given this completely different underlying implementation model, so I discarded the AWT code completely and made something that would actually work reliably with SWT (though I know there are still some timing bugs that I have yet to hunt down).

Quite simply, there is absolutely no way that an SWT version of the JSR 231 APIs can ever be conformant and run on all platforms that Eclipse runs on. The only way it could be is if the JSR group has a fundamental rethink about what an OpenGL API should provide, and what 3rd party widgets should provide. I don't see that happening any time in the near future.
13  Java Game APIs & Engines / JOGL Development / Re: porting JOGL to SWT on: 2007-07-24 16:46:35
I've already done it.

http://opengl.j3d.org/swt/

And, yes, as you're aware, JOGL is, unfortunately, tightly wedded to AWT, which means it is impossible to implement a conformant JSR 231 implementation for SWT.
14  Java Game APIs & Engines / JOGL Development / Re: Errors creating pbuffers with MESA + Xvfb on: 2007-07-23 23:07:13
Well, we have some resolution to the problem. It took a while to fix. I've already been chatting with Ken about this, so this reply is for infomration purposes only for those that also may come across the same problem.

JOGL is triggering a bug in the current releases of MESA. For pbuffers, JOGL would explicitly set the GLX_STEREO flag to GL_FALSE, which is the default value. This would cause MESA to fail and return no matching configs. If you did not pass in the GLX_STEREO flag and let MESA use the default (which is also GL_FALSE) then MESA would correctly return a matching FBConfig. I have posted a bug report to the MESA developers and a fix is already in their codebase and the bug report closed here:

https://bugs.freedesktop.org/show_bug.cgi?id=11705

Note that this will effect every MESA user up to and including development to this date. Both 6.5.1 and 7.0 are effected by this bug.

Of course, this doesn't help those of us that are using the default installs of MESA and are not running from the current GIT version of the code. I am also sending a patch to Ken to remove explicit setting of the default value, which triggers the MESA bug.

A separate and somewhat related bug was that internally JOGL was not correctly fetching the right screen identifier. In several places in the codebase it was using a hard-coded screen ID of 0. This would also cause the GLX methods to fail when you were not using the default display. Instead the code needed to make calls to DefaultScreen(display) and use that returned integer value. A patch for that is also being sent.

Several other bugs relating to timing of JAWT calls were also found in headless mode and ken is working on fixes for those.

With these all in place, you should be able to run JOGL under AWT headless mode with just raw pbuffers, using Xvfb and MESA.
15  Java Game APIs & Engines / JOGL Development / Errors creating pbuffers with MESA + Xvfb on: 2007-07-21 23:25:01
Wondering if anyone has some ideas on other workarounds for the system. The code is currently failing with the infamous glXFBConfig failure error message on the combination of  MESA and Xvfb.  Prior to attempting to create the pbuffer I check with canCreateGLPbuffer, but the actual creation fails.

Some relevant details:

GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 16, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
Exception in thread "main" javax.media.opengl.GLException: javax.media.opengl.GLException: pbuffer creation error: glXChooseFBConfig() failed
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(X11GLDrawableFactory.java:652)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.createGLPbuffer(X11GLDrawableFactory.java:313)
        at org.j3d.aviatrix3d.output.graphics.PbufferSurface.init(PbufferSurface.java:237)
        at org.j3d.aviatrix3d.output.graphics.PbufferSurface.<init>(PbufferSurface.java:154)
        at org.j3d.aviatrix3d.output.graphics.PbufferSurface.<init>(PbufferSurface.java:72)
        at org.xj3d.ui.awt.browser.ogl.OffscreenOGLConstruct.buildGraphicsRenderingDevice(OffscreenOGLConstruct.java:64)
        at org.xj3d.ui.construct.Construct.buildRenderingDevices(Construct.java:387)
        at xj3d.replica.OffscreenSceneRecorderConstruct.buildAll(OffscreenSceneRecorderConstruct.java:62)
        at xj3d.replica.SceneRecorder.<init>(SceneRecorder.java:224)
        at xj3d.replica.SceneRecorder.main(SceneRecorder.java:605)
Caused by: javax.media.opengl.GLException: pbuffer creation error: glXChooseFBConfig() failed
        at com.sun.opengl.impl.x11.X11PbufferGLDrawable.createPbuffer(X11PbufferGLDrawable.java:126)
        at com.sun.opengl.impl.x11.X11PbufferGLDrawable.<init>(X11PbufferGLDrawable.java:73)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory$2.run(X11GLDrawableFactory.java:306)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)


System is Fedora Core 6 with all the latest updates applied.

MESA 6.5.1
Xvfb

Commandline for running Xvfb is

1  
Xvfb :1 -screen 0 1280x1024x24

Daily build of JOGL as of last night (21/7).


I'd like to try out MESA 7.0, but don't have any prebuilt binaries for FC6 to try out, so that's my next plan of attack. Note that this is on a server that doesn't have any form of graphics hardware in it, hence the virtual framebuffer and MESA for JOGL.  I cannot run JOGL headless due to other internal JOGL errors and the latest JDK 1.6 u2 JAWT libraries, so this is about all I have to work on for now.
16  Java Game APIs & Engines / JOGL Development / Re: Ideas for a X3D loader on: 2007-02-07 21:26:41
JAXB is horribly inefficient - particularly the 2.0 codebase. It generates inordinate amounts of garbage. One of our applications had the load times increase 300% in shifting from 1.0 to 2.0 simply due to the extreme amounts of garbage generated. You would be far better off hand rolling it or just making use of the pre-built parsing infrastructure that we have in Xj3D.
17  Java Game APIs & Engines / JOGL Development / Re: SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support on: 2007-01-14 01:34:18
Yes. There is a system property that must be set first to make the sure GLDrawableFactory pulls our factory implementation. If you have a look in the examples, you'll see the name of the property that needs to be set.  In our code, we've kept what we can of the RI, which means it will still work with the AWT panels. However, a lot of the functionality is reduced or removed - such as the Java 6 OpenGL integration work.
18  Java Game APIs & Engines / JOGL Development / Re: SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support on: 2007-01-12 21:23:56
We haven't done any direct playing with FBOs yet so I don't have any direct tests to play with. It could well be a timing issue somewhere with the SWT event model. If you could send me a test case and a bit of info about your hardware and OS I can look into it.
19  Java Game APIs & Engines / JOGL Development / Re: SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support on: 2007-01-10 23:34:32
Simple answer to why you woiuld want to use our code: Try running your JOGL RI code on a Mac. You'll see it lock solid within about 2 seconds. The JOGL RI does a lot of very nasty things with the AWT event loop, which then causes the locks on OSX. It does a lot of them in very unobvious places. The problem is that most if the code somewhere touches the Threading or GLContextShareSet classes either directly or indirectly. Inside those classes there are a heap of references to the Java2D class which then does things like look at the AWTEventQueue or make static references to it. As soon as any of those classes are touched, that's when the OSX version locks solid. Works mostly fine on other platforms, but can't ever work on OSX whilst any of that class code is in there (and it won't be due to all the Java 6 OpenGL integration work).

If you want portable code under SWT, don't use the RI.

20  Java Game APIs & Engines / JOGL Development / Aviatrix3D 2.0 Beta 2 released on: 2007-01-09 23:01:39
Hot on the heels of the SWT/OpenGL v0.7.0 release, we also have a new beta release of Aviatrix3D 2.0.

What is Aviatrix3D? It is a Java scenegraph that is aimed at the high-end 3D graphics market such as scientific and medical visualisation. Multithreaded rendering is supported implicitly, meaning you can easily make use of your dual-core machine's full capability.

Some of the more interesting features:

  • Full layering, compositing and multiviewport capabilities, as well as multipass rendering including all the required
    buffer access such as stencil, accumulation and colour buffers.
  • Both AWT and SWT support, using either lightweight or heavyweight components.
  • Multithreaded rendering internals
  • Highly optimised performance for the target markets (at least twice as fast as Java3D on any given piece of content)
  • Several codepaths that avoid bringing any data in Java at all, which helps for those multi-gigabyte geometry scenes

You can download the latest version at http://aviatrix3d.j3d.org/download.html

21  Java Game APIs & Engines / JOGL Development / SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support on: 2007-01-09 22:54:06
Continuing on our march towards real JOGL support in SWT, we have another release of the SWT OpenGL bindings to the JSR 231 APIs. These are specifically coded to allow you to use JOGL on any SWT performance in almost an identical way to you would use them on an AWT platform. Specifically, we have completely rewritten large parts of the JOGL RI code to remove anything that even remotely tickles the AWT event thread, thus avoiding the lockup problems on OSX that you get using the RI.

In this release, we have fixed all the timing problems that we found in the last on on X11 platforms. In addition, a major new addition is the ability to use a lightweight Draw2D surface now with JOGL. That's right, you can have real 3D graphics in the middle of your GEF panel and have it play nicely with everyone, including proper resizing, compositing and alpha support. If you want to get really funky, you could also pull in Aviatrix3D and have a real scene graph there too (Xj3D won't be too far behind either once we get rid of the AWT image loading that also causes lock ups on a Mac).

Have a look at the new downloads here: http://opengl.j3d.org/swt/download.html

We are currently missing 32bit linux support due to the death of our 32 bit machine, but do have 64bit support for Linux, Solaris/Sparc, OSX universal binaries and Win32.  We hope to have the 32 bit linux support available within the next couple of weeks once the repaired machine is back in our hands.
22  Java Game APIs & Engines / JOGL Development / Re: Example jogl RCP application and plug-in on: 2006-12-04 17:41:46
If you're doing serious Eclipse development, you'll be better off using our native port of JOGL to the SWT environment. In addition to proper SWT support, I've just in the last few days also added Draw2D support so that you can use JOGL as a Figure instance, (eg inside GEF).

More details here:

http://opengl.j3d.org/swt/
23  Java Game APIs & Engines / JOGL Development / SWT JOGL impl v0.6 released on: 2006-10-27 18:01:05
New version of the native SWT bindings to the JOGL APIs is now ready to play with. In this version I now have all the major platforms supported:

Win32
Mac OSX universal
Linux x86 (both 32 and 64bit)
Solaris Sparc

Pbuffers are not currently supported on any platform, but I am, quite literrally, working on that now. A 0.7 version should be out within the month that supports pbuffers.

All libraries are compiled using Java 5  JVMs, though they don't use 1.5 libraries or language structures.

http://opengl.j3d.org/swt/downloads.html

I'm particularly interested in getting some of the linux testing results. I've got it working on several of our boxes here, but one of our clients is getting timing exceptions. Unfortunately, even with their code running on our machines I can't replicate the the problems. Hoping that feedback from others will perhaps help narrow things down.

Since this is the SWT bindings, you may also be interested in a scene graph too. The current beta of Aviatrix3D 2.0 also has native SWT support, so please download and have a play with that.  The links to that are in my sig.
24  Java Game APIs & Engines / JOGL Development / Re: OS X 10.4 linking issues on: 2006-10-23 18:18:46
Thanks for that. Everything is building nicely for us now.
25  Java Game APIs & Engines / JOGL Development / Re: OS X 10.4 linking issues on: 2006-10-23 16:38:07
Sorry, forgot to answer the other question - all machines are running Xcode 2.3.
26  Java Game APIs & Engines / JOGL Development / Re: Shared context initialization problems on: 2006-10-23 16:23:40
The majority of our users, and more importantly, those that are paying us to do work on AV3D, are all using SWT. As such its an absolute no-go on using the Threading class(es) on either platform - we did the same thing for the SWT OpenGL bindings with an OS-dependent Threading class for those that need it.

I did some tests over the weekend and our SWT code handles this situation perfectly on all platforms, so the problem is a bug in the AWT bindings that should be resolved. I recommend you enter it into the bug tracker so that it can be looked at.
27  Java Game APIs & Engines / JOGL Development / Re: OS X 10.4 linking issues on: 2006-10-23 16:18:51
I discovered the difference between the two commands over the weekend too. It seems that somehow inside the ant build scripts that calling "ant macosxfat" is not executing the same buildpath as "ant macosx" with the universal binary flag being set. Confirmed the problem on a 4th machine, so it's definitely an build.xml problem and not the machine setup. Since the property file value is being used, the extra build target is superfluous, so I would recommend removing it.
28  Java Game APIs & Engines / JOGL Development / Re: OS X 10.4 linking issues on: 2006-10-20 21:39:35
Quote
~justin: $ ant macosxfat

{Snipping all the other junk before this point.}

gluegen.cpptasks.configure.compiler:

c.configure:

c.build:
     [echo] Output lib name = gluegen-rt
    [mkdir] Created dir: /Users/develop/j3d.org/gluegen/build/obj
     [echo] Compiling src/native/macosx/*.c
     [echo] user.dir=/Users/develop/j3d.org/jogl_stock/make
       [cc] 1 total files to be compiled.
       [cc] cc1obj: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for ObjC
       [cc] cc1obj: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for ObjC
       [cc] Starting link
       [cc] ld: warning unknown MACOSX_DEPLOYMENT_TARGET environment variable value:  ignored (using 10.4)
       [cc] ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4
       [cc] ld: warning unknown MACOSX_DEPLOYMENT_TARGET environment variable value:  ignored (using 10.1)
       [cc] ld: Undefined symbols:
       [cc] _dlclose
       [cc] _dlerror
       [cc] _dlopen
       [cc] _dlsym
       [cc] /usr/bin/libtool: internal link edit command failed
       [cc] lipo: can't figure out the architecture type of: /var/tmp//cchSRGCQ.out

BUILD FAILED
/Users/develop/j3d.org/jogl_stock/make/build.xml:1507: The following error occurred while executing this line:
/Users/develop/j3d.org/jogl_stock/make/build.xml:1395: The following error occurred while executing this line:
/Users/develop/j3d.org/jogl_stock/make/build.xml:496: The following error occurred while executing this line:
/Users/develop/j3d.org/gluegen/make/build.xml:411: The following error occurred while executing this line:
/Users/develop/j3d.org/gluegen/make/build.xml:356: The following error occurred while executing this line:
/Users/develop/j3d.org/gluegen/make/build.xml:321: gcc failed with return code 1

Total time: 16 seconds

gluegen.properties and jogl.properties have the contents:

antlr.jar=/Users/justin/java/antlr-2.7.6/antlr.jar
macosxfat=true

Nothing else in either file. This is a clean download onto 3 separate machines. There was no jogl, gluegen or anything else out there and they just got updates last week. It's not like the environment is being poluted from something else here, hence my confusion as to what is going on. I had this compiling on another machine about a month ago with no issues.
29  Java Game APIs & Engines / JOGL Development / OS X 10.4 linking issues on: 2006-10-20 20:30:06
The current CVS build is broken for universal binary building on OS X 10.4. We've tried on both PPC and x86 versions of 10.4 and identical errors result. Three different machines all are doing this. If I use the non-universal binary build then it compiles cleanly, so it appears that one ofthe libraries being pulled in is causing the problems.

If I don't set the MACOSX_DEPLOYMENT_TARGET to 10.3, it complains about not being able to prebind and stops. If I set it to 10.3 then it fails to find _dlopen, _dlclose, dl_sym and several other libraries involved in dynamic library loading. This comes from the linking step of gluegen-rt.

Doing a little bit of research around the net, this particular problem started arising with the release of 10.4. One or more system libraries require these APIs beyond what the actually app code needed. The typical solution that worked for others was to add -ldl to the command line, which I've tried but hasn't had any effect. We had this code compiling about a month ago, so I suspect that something in the most recent set of Apple updates on these machines has caused the problem. Wondering if anyone has come across this and some idea of a fix?
30  Java Game APIs & Engines / JOGL Development / Re: Shared context initialization problems on: 2006-10-20 19:56:56
It is not possible for us to use the JOGL threading classes because it introduces more problems than it solves. At a simple level, we no longer can control the framerates that require - an extremely important requirement when you have to guarantee a framerate in an application (eg real flight simulator). In addition, introduction of the RI Threading class, or anything even remotely associated with it causes the entire system to lock solid when using SWT on a Mac.
Pages: [1] 2 3 ... 16
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (21 views)
2014-08-19 09:29:53

Tekkerue (21 views)
2014-08-16 06:45:27

Tekkerue (21 views)
2014-08-16 06:22:17

Tekkerue (12 views)
2014-08-16 06:20:21

Tekkerue (19 views)
2014-08-16 06:12:11

Rayexar (56 views)
2014-08-11 02:49:23

BurntPizza (37 views)
2014-08-09 21:09:32

BurntPizza (29 views)
2014-08-08 02:01:56

Norakomi (35 views)
2014-08-06 19:49:38

BurntPizza (65 views)
2014-08-03 02:57:17
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!