Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
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]
1  Discussions / General Discussions / Re: They're moving to Flash, here's why... on: 2008-11-07 19:08:54
Hi everyone,

We noticed a bit of traffic coming from here and I wanted to take a minute to respond.  First of all, this forum has probably been the most reasonable discussion of this topic that I've seen so far.  I applaud you all for your ability to understand the situation.  

Most of you have touched on this but I can't stress that the biggest problem is the user's experience.  It's true that JOGL contributed to this, but I don't believe JOGL is really the issue.  Ken Russell actually chimed in on our blog and I honestly feel bad because he's given us a lot of support and I really like JOGL.  

As a couple of you have also mentioned, applet's "basically work," but there are lots of unforeseen issues.  The percentage of our users that have Java is actually pretty high.  Unfortunately, so is the percentage of them that have issues with Java.  I mentioned on our blog that it's really hard to get a frustrated user involved in a difficult QA process.  They need to REALLY want to use your product.  With so many people having these problems, you can spend a lot of energy trying to address them.  As a startup, we don't have the resources to do this.  With Flash, most of that just goes away.

It has been really interesting following the community's response to this.  I love seeing the passion people display, regardless of whether or not they agree with our direction.  I've stated before and I'll state it here again: I hope that Java does succeed as a gaming platform.   It's just going to take a while to repair the damage.
2  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-15 18:04:10
Thank you for the response.  If there's anything I can test on my end please let me know.  I am however running through Eclipse and don't have mingw or cygwin installed right now so it would take me some time to build the native libraries and get up to speed on that.


3  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-15 15:20:28
I understand that LWJGL uses jinput.  In looking through their code, it seemed that they are using their own poller for the keyboard though. 

WindowsDisplay.doHandleMessage() calls handleKeyButton() which calls WindowsKeyboard.handleKey().  This stores the key state in their own buffer (key_down_buffer), which is used to populate the ByteBuffer that is passed in when WindowsKeyboard.poll() is called, and is also used in WindowsKeyboard.isKeyDown().

It seems that a LWJGLKeyboard is layered on top of this to provide a Controller interface to their own polling mechanism.  The pollDevice() call here calls into the WindowsKeyboard.poll() method mentioned above through WindowsDisplay.pollKeyboard().

I'm not describing this to try to prove that I'm right.  I admit completely that I could be mistaken.  This thread has taken a step in the negative direction.  I have an honest problem in production code that I'm trying to fix.  The terse comments are dead ends that are not providing any path to a solution.  The lack of support is convincing us that we will have to drop jinput if we can't resolve this soon.
4  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-15 03:15:38
I was looking into LWJGL and from what I can tell they aren't using jinput for keyboard interaction but have their own keyboard poller. 

I'm kind of at a loss for what to do at this point, other than building the native libraries myself and trying to determine if they're getting called.  Is there no test that I can perform that will help me determine if anything is wrong from the Java side?
5  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-14 20:04:06
System.out.println("security manager is null: " + (System.getSecurityManager() == null));

results in:

security manager is null: false

This is also the case with 1.6.0_07, _04, and _02 though.

6  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-13 14:23:26
We do have our own loader, and we're doing exactly what LWJGL is doing when loading the native libraries.  As I mentioned, our applet runs fine in Java versions previous to 1.6 update 10, so it seems that we are doing this correctly.

Has anyone tried building an applet using jinput for keyboard input and running it under update 10?  If I get time I'll try the LWJGL code and see I can build an applet through that.  I don't have much experience with LWJGL so I don't really know what it will take to do so though.

7  Java Game APIs & Engines / JInput / Re: jinput and Java 1.6.0_10 on: 2008-10-03 15:15:08
Thank you for the response.

We are signed, so we don't explicitly ask for any permissions.  We do access the user.home system property as well because we have our own launcher that downloads jars and stores them there.  I would also be surprised that the behavior with respect to system security would be different between versions of Java.

Is there any way to tell how jinput would be failing if it could not access user.home?  It seems as though things are nearly identical between versions of java.  In both cases, during debug I see that we have a RawKeyboard and a RawDevice that are being used.  The only difference I can tell is that addKeyboardEvent in RawInputEventQueue is never getting called.

I'm curious if anyone knows of other applets that utilize jinput so that I could see if they work with this version of Java. 

Thanks again,

8  Java Game APIs & Engines / JInput / jinput and Java 1.6.0_10 on: 2008-10-01 20:55:00
We're having some problems with Java 1.6.0_10-rc and Java 1.6.0_10-rc2.  When running our code through Eclipse everything works fine.  When running through an applet, no events are coming through.  If I switch to running 1.6.0_7 or earlier JVMs, everything works fine.

I've tracked the problem as far as the addKeyboardEvent not getting called from the native libraries.  It seems as though the events just aren't making it into java.

When starting the application, this line is displayed both when running through Eclipse and running through the applet:

There are no exceptions in the console.  My guess is that this is an issue with the release candidates for update 10 but I can't really debug things any further than this.

Has anyone else seen this?  Is there any fix that I can make in the code?

There is a test application we made here:  The 'g' key will work because it is using Java's key listener architecture, but pressing the other keys will not as they are going through jinput.

Thank you,

9  Java Game APIs & Engines / JOGL Development / replacing JNLPAppletLauncher on: 2008-08-18 20:32:34
I'm having a problem launching a JOGL applet in linux.  The error we're getting is the infamous "UnsatisfiedLinkError: no gluegen-rt in java.library.path."  We aren't using the JNLPAppletLauncher, and have replaced that same type of functionality with our own. 

The problem is that even though we have (supposedly) loaded gluegen-rt ourselves, the com.sun.opengl.impl.x11.DRIHack.begin() method is eventually attempting to load it itself using System.load("gluegen-rt"), because gluegen's NativeLibLoader.loadLibraryInternal("gluegen-rt") knows that the JNLP applet launcher wasn't used.

Another peculiarity is that NativeLibLoader.disableLoading() has been called in our own code before launching the applet, but loadLibraryInternal() is still being called from loadGlueGenRT(), which seems to be checking that.  Maybe someone is resetting it?

We also have our own class loader which we can set in the thread but this has no effect, I believe, because a new thread is spawned

Does anyone know how I can reliably disable loading of gluegen-rt?  I'm sure I could figure this out by building JOGL and debugging it myself but I don't have the time at the moment.



10  Java Game APIs & Engines / JOGL Development / Problem running RC8 in 1.4.2_12: Negative Width on: 2008-04-09 19:43:39
I couldn't find anyone else who has encountered this problem in the forums.  I'm seeing some issues when using RC8 in 1.4.2_12.  RC7 works fine, and both work in later versions of the JVM (tested in 1.5.0_08, 1.6.0_02).  This is the exception I get with RC8 and 1.4.2_12:

java.lang.IllegalArgumentException: Negative width
   at com.sun.opengl.impl.packrect.Rect.setSize(
   at com.sun.opengl.impl.packrect.Rect.<init>(
   at com.sun.opengl.util.j2d.TextRenderer$Glyph.upload(
   at com.sun.opengl.util.j2d.TextRenderer$Glyph.draw3D(
   at com.sun.opengl.util.j2d.TextRenderer.internal_draw3D(
   at com.sun.opengl.util.j2d.TextRenderer.draw3D(

 As far as I can tell, this is only happening for strings that have a space in them ( a ' ' character).

11  Java Game APIs & Engines / JOGL Development / Re: NPOT textures on ATI cards on: 2008-01-11 19:17:35
Thank you for the quick reply.  For our purposes, memory isn't an issue so disabling the texture rectangle extension works fine.  However, we're having another issue as a result of it.

We commonly display foreign characters when using the TextRenderer.  Before setting the system property to disable texture rectangles as you described, the characters would just render as squares if you didn't have the font installed.  Now, once a foreign character that is unsupported by fonts on the system is rendered, any other text, whether supported or not displays incorrectly.  It seems as if the texture coordinates are incorrect, but I'm also not sure that the underlying image data is right.

Unfortunately, I tried attaching some files to show what's happening, but got a message saying that the upload folder was full.  If you want to email me at dale.beermann at sharendipity dot com, I can send them to you.

Thanks again,

12  Java Game APIs & Engines / JOGL Development / NPOT textures on ATI cards on: 2008-01-09 21:51:24
I'm having an issue with non-power-of-two textures on ATI cards that I'm hoping someone can help me find a software fix for. 

Using an image that is 21x20 pixels, getImageTexCoords() is returning [0.0, 0.0, 21.0, 20.0].  This is using an updated ATI driver (from 12/4/2007, version 8.442.0.0), and has been replicated on two different machines, one with an X1400 and one with a Radeon XPress.  Before the driver was updated, the image was displaying and these values were being returned correctly; bounded between 0 and 1 (and works correctly on all NVidia cards).

In addition, the Texture object is returning 21 and 20 as the results to calls to getWidth() and getHeight(), respectively.  If this was returning the correct texture size, I could just create the texture coordinates myself, but I don't have access to the actual created texture size, so I couldn't do this correctly for all platforms.

As one last piece of data, if I hack in the correct texture coordinates, it seems that the wrong underlying image data is getting used for this texture, and a different image is actually getting displayed.  The target object stored in the texture is different though, and writing the image being used out to disk does result in the correct image, so I don't know how that would be happening.

We don't have the option of asking our users to install a different driver so I need to determine a fix that I can deploy to our applet.

We're using Jogl 1.1.1 rc6.

Many thanks,

Dale Beermann
13  Java Game APIs & Engines / JOGL Development / Large heap sizes cause JVM crash when calling glTexImage3D on: 2005-07-12 20:31:39
I'm having a problem where my application is crashing on a glTexImage3D call, but only when the heap size is very large, say 1200MB.  I'm trying to allocate a 3D texture that is 512x512x287 using short data.  I've got a Quadro 4400 so the memory on the card isn't an issue.  I also have 2GB of memory in my machine, so that shouldn't be the problem either.  Furthermore, this call will succeed for lower heap sizes, such as 800MB. 

It seems like there's only so much memory that can be shared between the java heap and what can be allocated for OpenGL, but I don't know what that limit is and how to determine if I've reached it.  If anyone has any information about why this might be happening and how I could prevent it, that would be greatly appreciated.  Thanks for your time.

The top portion of the dump that happens from the crash follows:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x69714D88

Current Java thread:
   at Method)
Pages: [1]
nelsongames (16 views)
2018-04-24 18:15:36

nelsongames (12 views)
2018-04-24 18:14:32

ivj94 (587 views)
2018-03-24 14:47:39

ivj94 (49 views)
2018-03-24 14:46:31

ivj94 (400 views)
2018-03-24 14:43:53

Solater (64 views)
2018-03-17 05:04:08

nelsongames (110 views)
2018-03-05 17:56:34

Gornova (175 views)
2018-03-02 22:15:33

buddyBro (723 views)
2018-02-28 16:59:18

buddyBro (93 views)
2018-02-28 16:45:17
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!