I’ve a silly question. Why are you guys using batch files? Why aren’t you just making your jars executable?
I’ve never found someone else’s batch file to be compatible with my runtime environment on Win32. And they’re useless on other platforms.
Just curious…
Good point. I simply hadn’t thought of packaging them that way. I’ll see if I can repackage the lessons quickly.
http://pepijn.fab4.be/nehe/nehe-demos-execjars.zip
Here’s a zip containing each lesson as a self contained executable jar. I repackaged them manually for now. I’ll look into a proper ant script tommorrow.
I think the MANIFEST is wrong, it now says something like Main-Class: demos/nehe/lesson04/Lesson04 while I think it should be Main-Class: demos.nehe.lesson04.Lesson04 (I’m getting class not found errors while unpacking the jar and executing manually does work).
The other thing is that the jars all refer to Class-Path: data-lessonNN.jar, are these necessary? (although I don’t think they’re doinig any harm either)
The class-path item is indeed wrong. That’s what you get when doing late night updates ;). I’m not sure about the main-class item though. The manifest spec says
[quote]Main-Class :
The value of this attribute defines the relative path of the main application class which the launcher will load at startup time. The value must not have the .class extension appended to the class name.
[/quote]
I interpreted ‘path’ as meaning ‘use slashes as separator’. I tested this on my Powerbook and it ran fine there. I didn’t test on windows or linux though. I’ll give the dot separator approach a try when I get home from work.
You use the dot separator. For example:
Main-Class: com.myco.game.MyGame
Class-Path: dependency.jar
dependency.jar would then have to be in the same directory as the executing jar or in the current classpath.
My guess is specifying the path with slashes worked because you had those classes in that directory structure on your drive. It read the drive rather than the contents of the jar.
Maybe that’s Java implementation dependent because doing “java some/path/to/a/Class” does not work on my Windows system (j2sdk 1.4.2) regardless if the directories exist or if it’s a jar. Only “java some.path.to.a.Class” works.
I’ve got some time now to work on the next tutorial, but I’m a big confused now.
Are we going with a common framework?
If not, is pepijnve going to continue to port work to the framework for the jogl demos?
Are we going to have to maintain two versions? One for nehe.gamedev.net and one for jogl-demos.java.net? Updating code between two sites is going to be a bear without CVS write access. And nehe updates his site by hand.
Ouch, the GLDisplay class is not working on this machine for fullscreen.
C:\Development\Projects\jogl\nehe-demos\src>java demos.nehe.lesson01.Lesson01
Exception in thread "main" java.lang.InternalError: Could not get display mode
at sun.awt.Win32GraphicsDevice.getCurrentDisplayMode(Native Method)
at sun.awt.Win32GraphicsDevice.getDisplayMode(Win32GraphicsDevice.java:330)
at java.awt.GraphicsDevice.setFullScreenWindow(GraphicsDevice.java:195)
at sun.awt.Win32GraphicsDevice.setFullScreenWindow(Win32GraphicsDevice.java:262)
at demos.nehe.common.GLDisplay.start(GLDisplay.java:74)
at demos.nehe.lesson01.Lesson01.main(Lesson01.java:9)
[quote]Maybe that’s Java implementation dependent because doing “java some/path/to/a/Class” does not work on my Windows system (j2sdk 1.4.2) regardless if the directories exist or if it’s a jar. Only “java some.path.to.a.Class” works.
[/quote]
I’m running Sun’s JRE and JDK.
C:>java -version
java version “1.4.1_03”
Java™ 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02)
Java HotSpot™ Client VM (build 1.4.1_03-b02, mixed mode)
Either slashes or dots work fine for me as long as I’m executing from the top of the package tree. I also run without a CLASSPATH if I can avoid it.
Ok, I hope everything works ok this time. I’ve tested each demo on windows in a separate directory, and they work for me now. I’ve also added a build script that generates the executable jars.
Source
Binaries
Another silly question. Why’s jogl.jar included in the source tree? I don’t think that’s something we should be distributing. A link or docs on how to get jogl would be better. Is it actually needed? It seems to me that if it is, it’d cause version conflicts. It’s also adding 500k to the size of your zip.
It’s needed to compile the the demos of course. I’ll replace it with a text file explaining where to get it. I’m going to finish lesson 36 first though. I seem to have fogotten to port it.
Edit:
@pepijnve: Damn, there’s got to be something else wrong on my system then because the new demos still won’t run using the jars (keep getting class not found errors for GLEventListener) 
You need to make sure jogl.jar is somewhere in the classpath. On my test system I put it in lib/ext in the jre install directory, so that it’s available system wide.
I could also put it in the manifest in the classpath entry so that it is automatically used if you put it in the same directory as the lesson jar files. Anybody have a suggestion on how this problem canbest be solved?
Hi,
Please add the following “xml lines” to the “build.xml” file to be
able to run all the demo lessors.
<!--
Please download and put jogl.jar under the lib directory.
For Win32:
copy these two "dll"s file at the same location as this buildfile.
For Linux:
copy these two "so"s files under jre/lib/i386
-->
<target name="run-jars" depends="prepare,compile">
<antcall target="run-lesson-jar"><param name="lesson.number" value="01"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="02"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="03"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="04"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="05"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="06"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="07"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="08"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="09"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="11"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="12"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="14"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="17"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="18"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="20"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="22"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="23"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="24"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="26"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="27"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="29"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="30"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="33"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="34"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="36"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="37"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="39"/></antcall>
<antcall target="run-lesson-jar"><param name="lesson.number" value="42"/></antcall>
</target>
<target name="run-lesson-jar">
<property name="main.class" value="demos.nehe.lesson${lesson.number}.Lesson${lesson.number}"/>
<java fork="yes"
classname="${main.class}"
taskname="${lesson.number}"
failonerror="true">
<!-- put build, data and jogl.jar into classpath -->
<classpath>
<pathelement location="build" />
<pathelement location="data" />
<fileset dir="lib">
<include name="**/*.jar"/>
</fileset>
</classpath>
</java>
</target>Java Webstart and the extensions to load external dlls.
This is an old article, but we might be able to adapt it for JoGL.
http://www.j3d.org/tutorials/quick_fix/auto_install.html
Both JoGL and Java3D suffer from the same problem. There’s no easy installation path for the external libs. At least JoGL doesn’t seem to have export restrictions as Java3D did.
These beginner tutorials seem to be getting more and more complicated.
[quote]I’ve got some time now to work on the next tutorial, but I’m a big confused now.
Are we going with a common framework?
If not, is pepijnve going to continue to port work to the framework for the jogl demos?
Are we going to have to maintain two versions? One for nehe.gamedev.net and one for jogl-demos.java.net? Updating code between two sites is going to be a bear without CVS write access. And nehe updates his site by hand.
[/quote]
I’m adopting a hybrid frame that’s basically the best of mine and pepi mixed up together.
We also use the same bitmap loader and some other classes (Math 
).
Back to pepi, dude throw in a cap “c” button where the frame rate is controlled by the user rather by a defined static limit.(think of it as capped to xx fps, or simply uncapped)
I had to modify your code to get decent speeds and draw a comparaison performance wise between the code in C++ and Java.
Caoimhin: nobody formally agreed on using a common framework. I spent some time merging all the existing code together using the ‘framework’ I made to get a more uniform feel.
JavaCoolDude: I’m not sure I understand 100% what you mean with the ‘c’ button. Right now the frame rate is capped to 60fps in a rather crude way. Should pressing ‘c’ just toggle this limit on/off? If you have any enhancements to the code in demos/nehe/common feel free to send them to me. I guess we really should start using cvs to avoid any mixups in the future.
Scott_Y._Hong: Is it useful to have ‘run’ targets in a build script? The lesson jars are executable and contain the data files they depend on, so personally I don’t see a need for this. What do the other guys think about this?
@pepijnve: it is somewhere in the classpath otherwise doing “java demos.nehe.lesson01.Lesson01” wouldn’t work either. No, it’s just the jars that won’t work. Even ones that I made myself for some personal projects, so it definitely is something that changed for the worse on my system