Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (468)
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 ... 5
1  Java Game APIs & Engines / JOGL Development / Re: contribution - maven deploy: some pom and a shell script on: 2009-04-03 00:30:06
Sorry for resurrecting this thread from its grave, but the part where the jars with native libraries are "exploded" is still missing. Did anyone ever find out how to solve that?

I did find something similar for the GWT maven plugin: http://gwt-maven.googlecode.com/svn/docs/maven-googlewebtoolkit2-plugin/setup.html but I haven't been able to adjust it to the JOGL situation (yet).

Any suggestions/help would be welcome  Grin
2  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.1 Released! on: 2008-09-12 12:15:05
I would like to find JOGL packaged in a RPM because it would allow games using JOGL to be packaged in RPM too and then to be added in some Linux distributions.

You might want to get in touch with the JPackage (http://www.jpackage.org/) people and see if they want to help out.
3  Java Game APIs & Engines / JOGL Development / Re: Two ways to load a texture. on: 2008-08-06 10:07:49
The Texture class is "just" a utility class, so whatever it can do you can do. So if it's faster or not than your custom class depends completely on the implementation used, but in the end I imagine it won't matter.
4  Java Game APIs & Engines / JOGL Development / Re: JOGL on Linux (Fedora 9) very very slow??? on: 2008-05-25 22:54:53
I wish I was able to help, but so far I haven't been able to install the (fglrx) ATI driver on Fedora 9 *sigh*
5  Java Game APIs & Engines / JOGL Development / Re: BlendInspect on: 2007-09-12 10:48:08
Show us the code and we might be able to help  Smiley
6  Java Game APIs & Engines / JOGL Development / Re: Dutch speaking people here? on: 2007-09-12 10:45:31
I agree with erikd, you should really advise people to use:

1  
java -cp .;c:\jogl\lib\gluegen-rt.jar;c:\jogl\lib\jogl.jar -Djava.library.path=c:\jogl\lib MyJoglAppMainClass


or since Java 6:

1  
java -cp .;c:\jogl\lib\* -Djava.library.path=c:\jogl\lib MyJoglAppMainClass


instead of globally changing PATH and CLASSPATH.

IDEs like Eclipse or Netbeans and Batch files/shell scripts make that easy enough and will make sure that you won't have any strange version conflicts to solve (these version conflicts might occur for example when trying to run a WebStart application that uses a different JOGL version and the bad thing is that the errors that you will get won't give you any hints as to why things are not working, there's no "Incompatible JOGL libs found on system classpath" exception).

If you're developing and you really want to use PATH and CLASSPATH I would advise to make a seperate batch file/shell script, let's call it initjogl.bat, and start that manually each time you're going to work on your code.

[edit]
- modified the -cp argument to include the current directory, I had forgotten it the first time around
- for Linux and Java6 you need to escape the wildcard: -cp .:/path/to/libs/\* or use single quotes: -cp '.:/path/to/libs/*'
7  Java Game APIs & Engines / JOGL Development / Re: FPS Timer ? on: 2007-08-31 10:48:01
I'm not sure if there is a solution for systems that use speed-step or throttling, you can read this blog for a lot more detail about the use of clocks and timers in the Java VM: http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks. But _if_ there is a solution it would be better to ask Sun to fix the implementation of System.nanoTime() than adding yet another implementation IMHO.

Another interesting source of information is this bug report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6440250
8  Java Game APIs & Engines / JOGL Development / Re: BlendInspect on: 2007-08-11 21:13:32
Doesn't seem to work right on Linux (Fedora 7, JDK 1.6.0_01), I just get this tiny window which I can't resize. No errors in the console.
9  Java Game APIs & Engines / JOGL Development / Re: JOGL Project Template available for NetBeans 5 on: 2007-07-25 09:46:34
Any news yet when the NB6 template will be available? :-)
10  Java Game APIs & Engines / JOGL Development / Re: JOGL in applet on: 2007-06-18 18:09:24
Even though I'm the JOGL project lead, I continue to resist bundling it in to the core JRE, as doing so introduces problems and we need to solve the extension deployment problem more generally (and we are working on this)

Just curious, what's exactly the reason why you are against putting JOGL in the core?

I imagine that flexibility is one of the reasons? You wouldn't be able to keep on improving JOGL at he same rate as you are doing now. But what are the other reasons? Because personally I would love the idea that 3D graphics come with "the package".

Of course if JAMs and the whole OSGi-like system becomes a reality all of this might stop to be relevant.
11  Java Game APIs & Engines / JOGL Development / Re: how does the 3d model (for emample .3ds) load in JOGL? on: 2007-06-18 18:00:23
Quote
meaning people want you to do a little more research before asking

meaning: just use the forum's search function (or google of course)

 Wink
12  Java Game APIs & Engines / JOGL Development / Re: mouse dragging on: 2007-06-04 12:59:04
I think it's because you're continuously adding the difference between the original mouse position and the new one. So if the mouse started at x=5 and is now at x=8 you add 3 but if in the next event is has moved to x=10 you add 5 even though it has only moved 2 units.

This is because I didn't explain very well my original idea. Instead of directly changing scrollX from within the mouseDragged() method I would introduce a new variable, let's say dragX which you initialize to 0.

In the display() method you do: gl.glTranslated((scrollX + dragX)/zoomW, scrollY*zoomH, 0);

while in the mouseDragged() method you say: dragX = distX;
(not using += here!)

and finally in the mouseReleased() you add: scrollX += dragX; dragX = 0;

why do it like this? and not just calculate the distance the mouse travelled between each mouseDragged-event? Because this tends to become very imprecise when the user makes wild movements.

Hope this helps.
13  Java Game APIs & Engines / JOGL Development / Re: scrolling or something like that on: 2007-05-24 15:35:06
Well for your main problem you really need to give a bit more information how you implemented things. Posting your code will give you more answers I think.

With regards to the scrolling, this can be done easily by adding a MouseListener: you just store the current mouse coordinates on MousePressed and in the MouseMove you first check if the mouse button is being held down, if so you calculate the difference between the current mouse coordinate and the one stored in MousePressed and you scroll the scene/image by the amount that the mouse was moved.
14  Java Game APIs & Engines / JOGL Development / Re: OpenGL pipeline on a linux platform bombs out when enabled. on: 2007-05-23 21:10:05
Hi, for me it worked after I downloaded the .jnlp file and commented out the following line:

   <property name="sun.java2d.opengl" value="true" />

without that it would crash in libGL.so.1 (crash dump attached).
15  Java Game APIs & Engines / JOGL Development / Re: JOGL in JavaFX? on: 2007-05-22 17:31:25
Quote
Yes, but what you really want is to browse the javadoc.

Ehm, no, what I really want is documentation. But failing that I prefer to see the sourcecode, the javadocs are in there as well  Wink

Just to explain: normally I want some docs or tutorial to explain the basic structure and functionality of the project. Knowing that the javadocs are enough for the details about how to call which methods using what arguments. But IMHO looking at the javadocs to figure out how everything works just plain sucks, looking directly at the source will teach me much more.

But I'd still like to see some kind of paper describing the ideas behind MCG and some hints how to use it  Smiley
16  Java Game APIs & Engines / JOGL Development / Re: Argh, having trouble with transparency in with Overlay's Graphics2D on: 2007-05-22 17:23:24
I'm not sure, are you doing a markDirty() somewhere on the Overlay? Because I imagine that you need to let the system know you are making changes to the image you are displaying.
17  Java Game APIs & Engines / JOGL Development / Re: JOGL in JavaFX? on: 2007-05-18 12:09:36
For the lazy (like me): https://joglutils.dev.java.net/source/browse/joglutils/trunk/src/net/java/joglutils/msg/
18  Java Game APIs & Engines / JOGL Development / Re: How to include JOGL in a released product? on: 2007-05-08 11:14:33
We're using JWS to deploy software to emergency call center operators (112, the european 911) in the south of Spain. Currently this is for a couple of dozen systems but this will finally run in most hospitals, police stations and fire brigades. So far we haven't had any problems in production. We did have problems during development but like Ken said they were always related to wrong information in the JNLP or badly configured/functioning servers. (I'm not syaing there are no bugs in JWS, I'm sure there are, just that in our controlled environment we haven't run into any problems)

For another application for the same client we tried the All-on-one-EXE solution but this gave us so many headaches we gave up after trying several products that are supposed to be able to do this. It seems to work okay for simple cases but for products with many dependent JARs and native libraries it was just classpath-hell (we were even unpacking all the JARs and putting them into one directory, this worked but we still had problems with the native libs).

In the end we're just using a Windows installer which works in this case because all target systems will run Windows. Never figured out why they didn't decide to use JWS for that application too.

NB: I talked about the classpath-hell for the All-in-one-EXE solution but I must admit that getting JWS to work for non-simple applications can cause headaches too. We never spent as much time on the All-in-one case as on JWS because there wasn't a fixed requirement for that particular application, so we went with what was easiest to get working. But once you get JWS working it really easy for the user and you don't have to worry about updates to the software because they'll get installed automatically (well, in our case at least because the software does not run off-line).
19  Java Game APIs & Engines / JOGL Development / Re: Installation woes!! on: 2007-05-03 14:57:03
I don't mind helping, but that means you've got to start by detailing your setup. That means all the details about which version of Java you got installed (don't guess, but run "java -version"), where did you install which JOGL files, where did you save the demos, show a list of all those files so we can be sure all files are accounted for. A dump of any environment variables. Anything that you think might help and then some.
20  Java Game APIs & Engines / JOGL Development / Re: Trouble running outside of eclipse on: 2007-04-04 10:10:37
Besides the option that Ken mentions in his reply I think you will also need to add the jogl.jar to your class path, eg:

-cp /absolute/or/relative/path/to/jogl.jar
21  Java Game APIs & Engines / JOGL Development / Re: Problem Loading Installable Client Driver (ICD) - Getting Microsoft's Generi on: 2007-03-14 12:41:21
Ken is right that the IDE itself should not have any effect on the application, however, the differences between the environments might have. See my experiences here: http://www.java-gaming.org/forums/index.php?topic=15610.msg124300#msg124300 for an example where running the application from Eclipse resulted in much worse performance.
22  Java Game APIs & Engines / JOGL Development / Re: TextureIO Flipping Out?? on: 2007-03-02 14:37:22
I can't speak for Ken of course, but I can tell you that what you want goes against the advise given by various very knowledgeable people like to author of Effective Java.

Chapter 13 of Effective Java "Favor immutability" for example tells you to use value-objects wherever possible. It gives a bunch of advantages for using them, besides the most obvious disadvantages of course: the need to make a copy each time you need a different value.

The TextureCoords class does not adhere completely to the rules though because it's methods are not final, to be a true immutable objects they should be. So somebody should probably decide which way to go: either go for full immutability or make it easily mutable by default.
23  Java Game APIs & Engines / JOGL Development / Re: JOGL-1_0_0 installation problems on: 2007-02-27 15:39:08
Well I don't know if it will be this easy, but did you literally use CLASS_PATH? Because it should be CLASSPATH without the underscore.

But even so I personally never use the CLASSPATH variable and especially not as a global setting. These days I just use the -classpath (or -cp) option for both java and javac if I need/want to compile manually.

NB: Don't forget to add the current directory "." to the classpath otherwise it won't find the files in the current directory.
So use something like:
   javac -cp .;C:\Java\jogl-1_0_0-windows-i586\lib\jogl.jar *.java
24  Java Game APIs & Engines / JOGL Development / Re: how to do premultiplied alpha on: 2007-02-27 13:59:55
Use a BufferedImage format with premultiplied alpha; TYPE_INT_ARGB_PRE is a good choice. If your source BufferedImages aren't in this format, convert them by manually creating a BufferedImage of the correct type, width and height, and use Graphics.drawImage() to put the initial image into the premultiplied one. Then use the TextureIO classes to convert the BufferedImage into a Texture.

Quote
the Texture class will automatically convert non-premultiplied image data into premultiplied data when storing it into an OpenGL texture

Ken, given the above two quotes (one from you and one from the Texture javadocs) I'm confused as what to do. Your remark seems to suggest that you need to do the pre-multiplying yourself while the javadocs seem to suggest it happens automatically?
25  Java Game APIs & Engines / JOGL Development / Re: Doing my first Parallax scroll with JOGL.. on: 2007-02-19 16:58:40
Very nicely done! Reminds me a lot of XPilot. Luckily you can't die yet or I would have been splattered over those walls countless times already ;-)
26  Java Game APIs & Engines / JOGL Development / Re: JOGL very slow in Linux on: 2007-01-09 16:46:27
Haven't had time yet to look at the versions you mention but I did get a response to my mail to the JPackage.org mailing list. I'll repeat it here to see what you think (I have to little experience with these things to be able to determine if what he says is reasonable or not):

Quote
> I haven't figured out why but I did find what was causing the
> slowdown: the symbolic link from /usr/java/jdk1.6.0/lib/i386 to
> /usr/lib
>
> Isn't this link necessary? It seems a bit too much to include all
> libraries from /usr/lib to the Java native library path

I disagree about this - IMO system libraries should be available to Java just
like all other languages.  The alternative without the symlink is to play
$LD_LIBRARY_PATH tricks which are even worse, and would most likely lead to
the same plus possibly other problems.  And they possibly need to be made on
per application basis (which sucks when we're dealing with a jar-only thing
that requires those native libs - there's no way to do the equivalent of
$LD_LIBRARY_PATH eg. in jar manifests).

This is an area which has some room for standardization, and I hope the
GPL'ing of Java will let vendors to ship VM's sanely configured with regards
to native system libs.  I believe some (GCJ, IBM, Blackdown) already are
though - the symlink added in the -compat package brings the Sun VM up to par
with the mentioned others.

> although I
> must admit I don't see why it causes problems in this particular case
> because the JOGL libraries cannot be found there. It must be some
> other library that causes a problem.

Just a guess, but perhaps there's a vendor specific hardware accelerated
OpenGL library somewhere else than /usr/lib (but still in the runtime
linker's default path, maybe through /etc/ld.so.conf*), and the symlink above
causes the JVM load an unaccelerated software implementation from /usr/lib.
If this is the case, I suppose adding the dir where the hardware accelerated
one is to $LD_LIBRARY_PATH could help.
27  Java Game APIs & Engines / JOGL Development / Re: JOGL very slow in Linux on: 2007-01-06 20:27:22
Hi Ken,

just to let you know that the problem is back if I install the latest nightly build.

Made sure that I removed any other builds before using the nightly but fps was down to ~40 again while just putting back the jars and .so from the release version made the fps jump back to 800+ fps.

Any idea what could be causing this?
28  Java Game APIs & Engines / JOGL Development / Re: JOGL very slow in Linux on: 2007-01-02 21:09:14
Ah yes, sorry, I had noticed that as well but forgot to mention it.

Absolutely no response from my question on the JPackage list though (it seems very low-traffic anyhow) so I'm not sure if I'll ever get an answer.
29  Java Game APIs & Engines / JOGL Development / Re: JOGL very slow in Linux on: 2006-12-31 14:52:51
Ok! I haven't figured out why yet, but at least I know where to look for the cause of the slowdown:

I was using the java-1.5.0-sun-compat package from JPackage (www.jpackage.org) which basically adds a lot of links to make the Sun version of the JDK compatible with the Fedora Core file system layout.

I just switched to the java-1.6.0-sun-compat package .... and now it's Java 6 that is the slow one and Java 5 is fast!

So somewhere in that bunch of links is something that is "off", I'll try to figure out what it is.

...

Ok, found it. The compatibility package adds a link from /usr/java/jdk1.6.0/lib/i386 to /usr/lib, if I remove that link everything works just fine (even from Eclipse!).

I'll contact the JPackage people to tell them about this and see what they have to say.
30  Java Game APIs & Engines / JOGL Development / Re: JOGL very slow in Linux on: 2006-12-30 22:52:26
I'll try a new driver ASAP, I'll let you know what the verdict is.

I've been looking into any runtime differences that might exist between running an application from the shell when compared to running from Eclipse. First with jps it's obvious a new VM gets started, then with jconsole I started looking for differences. But both VM version, VM args, classpath and bootclasspath are exactly the same for both cases.

I imagine Eclipse does keep some links to the application (the console get's redirected to Eclipse for example, but my test app doesn't print anything to the console), but attaching jconsole to the app hardly makes a difference, you can see a drop in FPS each time the info in jconsole gets updated, but the app quickly recovers.

(Just tried running the app from Eclipse telling it not to redirect the console but it doesn't make a difference so there must be something else still)

Anyway, thanks for the help so far  Smiley
Pages: [1] 2 3 ... 5
 

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

The first screenshot will be displayed as a thumbnail.

theagentd (6 views)
2014-04-24 23:00:44

xsi3rr4x (83 views)
2014-04-15 18:08:23

BurntPizza (75 views)
2014-04-15 03:46:01

UprightPath (86 views)
2014-04-14 17:39:50

UprightPath (69 views)
2014-04-14 17:35:47

Porlus (86 views)
2014-04-14 15:48:38

tom_mai78101 (109 views)
2014-04-10 04:04:31

BurntPizza (169 views)
2014-04-08 23:06:04

tom_mai78101 (265 views)
2014-04-05 13:34:39

trollwarrior1 (217 views)
2014-04-04 12:06:45
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!