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] 2
1  Java Game APIs & Engines / JOGL Development / Re: Java 5.0 experiences? on: 2005-04-15 19:39:38
It has been stated on the Java-dev list from Apple that 1.5 will require Tiger.  I do not think they have any intention of making it available on older releases.  There may even be technical reasons for that.  They are probably using Tiger only API calls to support things like the new concurrency package, and accelerated graphics, etc.  I have a select membership, so I am tracking things, but can not say anything.  The Tiger page lists 1.4.2 for Java so I do not believe 1.5 will be in 10.4.0.  Here is hoping for 10.4.1 or 10.4.2.
2  Java Game APIs & Engines / JOGL Development / Java 5.0 experiences? on: 2005-04-15 00:38:38
For those using JOGL with Java 5.0 what is the experience?  I was looking at the concurrency utilities, high-res timer, and generics.  Would you say it is stable enough to not be more pain than value?  Does it play well with JOGL, and Eclipse 3.1?
3  Java Game APIs & Engines / JOGL Development / Re: Monitor deadlock on dual 2.0 G5 on: 2005-04-15 00:36:44
This occurred when doing a setSize on the main thread was processed at the same time as the init method was still executing on the Event/Animator thread.  I normally do not encounter this, but it happened when using a profiler (that slows everything down).  It should occur with setSize() after creating a frame with GLCanvas who's init() method (on the listener) takes a long time to run.

I have addressed this for my app by doing invokeLater in the initMethod for the part that was long running, and could be separated from the drawable.  In my case that was creating the scene geometry and related Java objects.
4  Java Game APIs & Engines / JOGL Development / Monitor deadlock on dual 2.0 G5 on: 2005-04-09 15:56:31
I seem to be having no problem deadlocking JOGL on my DP 2.0 G5.  I have several threads running: Animator, AWT-Event, Main, and some other threads.  I am running without the single thread model.  The rationale for the single thread model is that the issue is with the driver.  My exploration suggests otherwise.  There may be issues in the driver I have not yet encountered, but the issues I am seeing are all in Java.  The deadlock appears to happen over contention between the AWT tree lock, and the OGL Context lock.  It is pretty easy to deadlock them with a long init() method.  It looks like the makeCurrent call or related method is holding onto a lock on the context while the init method is running.  This is very dangerous, as user code can do anything and take any time to run.  Testing on a dual processor system makes these issues much easier to find.  JProfiler seems to do pretty good deadlock and monitor reporting.  I am going to try moving some of the code to the AWT thread that might impact the AWT tree lock, and see how this goes.
5  Java Game APIs & Engines / JOGL Development / Re: Anti-alias too jagged. ┬áIdeas wanted on: 2005-03-31 03:25:15
I have read those sections in the programmer's guide.  I am using scaled 2D drawing.  I render a quad say 1000x10.  As the scale gets smaller the size of the primitive becomes 500x5 then 100x1.  At this point he drawing is almost not being antialiased.  I get primitives appearing and disappearing depending on whether they fall on whole pixels or not.  I have GL_POLYGON_SMOOTH enabled, and 6 point multi-sampling enabled.  For quads that are nearly vertical or horizontal the result is pretty jagged.
6  Java Game APIs & Engines / JOGL Development / Anti-alias too jagged.  Ideas wanted on: 2005-03-30 18:16:59
I am currently using 6 sample FSAA to smooth out the drawing.  This largely works well in more solid shapes like filled elipse or rectangles, but for thin shapes like 1 pixel wide rectangles the output is still very jagged.  All drawing is 2D using an ortho projection.  When examined closely a 2 pixel line will alternate between 2 solid pixels and one solid and 2 gray pixels.  The problem is that the result looks jagged ebcause the alternating is in large bands rather than being continiously variable.  It looks more like non-AA drawing smeared, rather than real AA drawing.  Using Java2D the gray levels would be continuously variable between black and clear to approximate the amount of coverage a theoretical line would cover that pixel.  Is there any way to get this more accurate view of AA using OpenGL for edges?  On 1 pixel lines I have seen the whole line disappear rather than going to gray.  The result is not much better than non-AA drawing.
7  Java Game APIs & Engines / JOGL Development / Re: JOGL and GLSL on: 2005-03-29 20:07:41
I had no problems creating shaders and linking them using JOGL on OS/X 10.3.8.  Of course they do not run yet, but the calls worked.  I even got compile and link errors where appropriate.
8  Java Game APIs & Engines / JOGL Development / Clip Plane help please on: 2005-03-26 16:27:29
I am using an ortho projection and trying to use clip plans for regular 2D clip boxing.  I can clip to left/upper edge of a box with a call like:

gl.glClipPlane(GL.GL_CLIP_PLANE0, new double[] {1.0, 0.0, 0.0, bounds.getMinX()});

I am trying to get the left/bottom edge with:

gl.glClipPlane(GL.GL_CLIP_PLANE0, new double[] {-1.0, 0.0, 0.0, -bounds.getMaxX()});

But, that clips all shapes!  Any pointers would help.  I have only been able to find the first case in examples on the net.

9  Java Game APIs & Engines / JOGL Development / Re: How to use java2D within jogl? on: 2005-03-25 19:54:53
What we are doing is creating a texture out of a BufferedImage and rendering that in JOGL using a textured Quad.  It does not look too bad, but it is still not as good as direct Java2D.  I expect that in our case the pixel boundaries are not eactly lined up, so all the fancy anti-alising and hinting for Java2D fonts is not aligned with the actual display.  The difference in performance however is huge.  Even with the OpenGL pipeline for Java2D there are tradeoffs that Java2D has made for quality and device independence that will be hard to adapt to high performance needs.  I look forward to being able to test the OpenGL pipeline when Apple released JDK 5.0.
10  Java Game APIs & Engines / JOGL Development / JOGL On Tablet PC? on: 2005-03-23 13:24:44
Has anyone tried JOGL on a tablet PC?  The graphics are all integrated graphics from what I can tell, with only about 32MB of VRAM, or shared RAM.  What was the experience?  I am using JOGL for a non-game application and am considering support for pen based input.
11  Java Game APIs & Engines / JOGL Development / Re: What is under the covers? on: 2005-03-23 01:09:51
I call setSize from the code that creates the frame (the main method) and before setVisible(true).  It does not appear to be calling it every frame, just 2 times, the second time after my init methods were trying to set viewport to match the canvas.  I do not mind it managing the viewport, if it set it to 1:1 to the canvas size.

Here is the stack trace:

     at sun.awt.RepaintArea.paint(
     at apple.awt.ComponentModel.handleEvent(
     at java.awt.Component.dispatchEventImpl(
     at java.awt.Component.dispatchEvent(
     at java.awt.EventQueue.dispatchEvent(
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(
     at java.awt.EventDispatchThread.pumpEvents(
     at java.awt.EventDispatchThread.pumpEvents(
12  Java Game APIs & Engines / JOGL Development / Re: What is under the covers? on: 2005-03-22 21:30:45
That is what I would want from a GL binding.  But I am seeing other indications.  Possibly you can point me in the right direction.  The OpenGL profiler shows a large amount of time in CGLFlushDrawable (about 1/2 my GL time).  This appears to be called once per frame, as the call count mathes the calls to glClear.  I also see the viewport being reset for each frame to the canvas size when the window was first opened, rather than matching the size resulting from setSize, that is being used for drawing.  Having the viewport wrong messes up attempts to prune on visible areas.  I am currently having to do my own pruning against the canvas bounds and transforming that to world space, rather than getting the matrices from OGL.
13  Java Game APIs & Engines / JOGL Development / What is under the covers? on: 2005-03-22 19:55:44
Is there a write-up for what JOGL is doing under the covers?  Some of the things are obvious (using Buffers rather than pointers), but some are not (vsync, calling glFlush, etc.)  It would help in locating bottlenecks and relating the OpenGL Profiler output to what calls I am making in the application.
14  Java Game APIs & Engines / JOGL Development / Re: -Djogl.1thread=false fails on: 2005-03-21 01:36:47
This was due to an older jar/jnilib in an extensions directory.  I hate that.
15  Java Game APIs & Engines / JOGL Development / Re: -Djogl.1thread=false fails on: 2005-03-21 00:40:33
I have resigned myself to only one thread for on-screen rendering, but I need to be able to update geometry in the background using an off-screen context (pbuffer).  I have the property set to false and my call-back is still on the event thread.  I will enable verbose and see what it says and post that.
16  Java Game APIs & Engines / JOGL Development / -Djogl.1thread=false fails on: 2005-03-20 23:37:42
Using -Djogl.1thread=false does not disable this option (Mac OS/X Radeon 9000 mobility).  This prevents me from using an off-screen context for manipulating buffers or textures.  The amount of work I can do in the main thread is much more limited than what could be done in a background thread.  On my laptop it would not matter so much, but on multi-cpu desktops this is a real issue.  There is the Auto and true settings for the common case where stability is more important than performance, but since my whole reason for using OpenGL is performance, I would like the option to use all available CPUs on such systems.
17  Java Game APIs & Engines / JOGL Development / Re: Jitter during zoom operation on: 2005-03-20 20:47:43
It does indeed look like it is errors in using floats for transformations.  Is there any way to make OpenGL use doubles for the transformation matrix?  It looks like I need more precission in representing the scale/translation combination.  I can recreate a similar jitter using calculations in the application at about the same time as they appear on-screen.  Would I be able to use doubles if I did all the transformations using a vertex shader?
18  Java Game APIs & Engines / JOGL Development / Re: Jitter during zoom operation on: 2005-03-20 18:39:53
More oddness that may help in locating what is going on.  I had been using a calculation in the application to adjust for scale on the neted shape.  So it wsa jittering when the scale applied by OpenGL did not match the computation including scale in the application.  This looks like the same type of jitter I am getting on the entire view when the zoom computation is done in the application to retain the same steady location in the view.  Is it possible that when I set the zoom to a float/double it is being rounded or limited to a lower resolution than in the CPU?  Can I ask OpenGL to transform a point and return the result rather than doning this in the application without incurring a long dlay for the pipeline to empty?
19  Java Game APIs & Engines / JOGL Development / Re: Jitter during zoom operation on: 2005-03-20 17:33:54
The same jitter happens to geometry in a nested zoom.  It moves relative to geometry in the enclosing space.  A quad drawn before the glTranslatef and glScalef does not retain the same position relative to one drawn after even when the x/y trans values are 0.0f and the zoom is a steady 0.005f.  This seems very odd.  I would expect that two shapes would retain relative positioning with stable transforms.  That seems pretty basic.  Is there something about transformations that I should know about?  This happens when the outermost zoom (glScalef/glTranslatef) has a zoom factor in the ramge of several thousand, but that could be my data.  I will add some geometry to see if it is happening at lower global scale factors.
20  Java Game APIs & Engines / JOGL Development / Jitter during zoom operation on: 2005-03-20 17:00:35
I am working with a basically 2D application that does zoom by scaling X&Y and applying a translate to keep the cursor point steady.  This works at lower scale factors, but as the scale factor gets larger it gets jittery.  The numbers computed on the CPU look fine using float or double.  But when drawn the display can be off by 10s or more pixels.  The idea is when applying a zoom the user space coordinates X,Y should display at the same screen coordinate before and after.  I use the following to apply the zoom and translation:

           gl.glTranslatef(xTran, yTran, 0.0f);
           gl.glScalef(zoom, zoom, 1.0f);

The problem is that from one frame to the next the point that should be stable is moving around.  I presume this is some type of rounding error using floating point numbers, but have yet to find it.  The following is example debug output for complementary (zoom in/out) from the CPU side:

Before.  Zoom: 6687.519 xt: -6.052199E8 yt: -1.27062797E9 xformed x: 512.0 y: 384.0
Zooming by: 1.010025 inverse: 0.99007446 about: 500.0,441.0
After.  Zoom: 6754.5615 xt: -6.1128723E8 yt: -1.28336602E9 xformed x: 512.0 y: 384.0

Before.  Zoom: 6754.5615 xt: -6.1128723E8 yt: -1.28336602E9 xformed x: 512.0 y: 384.0
Zooming by: 0.99007446 inverse: 1.010025 about: 500.0,441.0
After.  Zoom: 6687.519 xt: -6.052199E8 yt: -1.27062797E9 xformed x: 512.0 y: 384.0

21  Java Game APIs & Engines / JOGL Development / Re: Memory Management question on: 2005-03-20 15:26:12
I see that that is for mapping VBO data to client address space.  But how does that help me draw from an offset position in a VBO?  If I pass a mapped pointer to calls like glVertexPointer does it do the right thing and use the server memory rather than passing the data from the client address space?  It also indicates you can only have one mapping in place per VBO so I could not have mixed data in one VBO and use that for multiple pointers at different offsets right?
22  Java Game APIs & Engines / JOGL Development / Re: Memory Management question on: 2005-03-20 13:57:28
I do not get any results when looking for UPPER_MAP_POINTER_ARB or several varriations.  Can you elaborate please?
23  Java Game APIs & Engines / JOGL Development / Re: Memory Management question on: 2005-03-20 02:10:34
I have spent all day on this and it is still not clearing up.  In order to use VBO buffers for glDrawArrays or glMultiDrawArrays the vertex format must be the same, since all I can specify is element position to start for all aspects of the drawing.  If I have some geometry in one format and some in another (color vs. texture coordinates) I need separate buffers for each format.  Since I need to set the pointers for each component at the start of the VBO, I need to use an index (vertex number) to identify each individual geometry to be drawn, or use glMultiDrawArrays to use indices.  I can not really have just one VBO for an arbitrary collection of geometry and just use offsets into that buffer for each call to glXXXPointer (which would be the easier case for me).
24  Java Game APIs & Engines / JOGL Development / Re: Memory Management question on: 2005-03-18 21:52:49
That is type type of input I expected.  In a general case where various types of primitives and states are required (quads, strips, fans, different textures, different texture coordinates, etc) preallocating enough different VBO buffers seems challenging.  You indicated I can place multiple types in one buffer.  Which calls are those?  Right now I allocate VBO buffers for each array call (vertex, color, tex coord), should I be looking at a different way of doing this?  Some comments indicated that interleved was not any faster, and could be slower.  My application is not a game, so some of the uses are differnt.  I originally used arrays and got noticeable speed up by using VBOs for the drawing.  So, knowing which parts are going to change often for a period of time would seem to be an issue.  Also, is the allocation of the buffer the issue, or the bandwidth to update the data in the buffer?  If it is just the allocation, then pre-allocating and reusing buffers would seem to be an easy solution.

25  Java Game APIs & Engines / JOGL Development / Memory Management question on: 2005-03-18 03:16:52
I seem to be able to bring the OpenGL driver to its knees with my test application.  I create/destroy about 6k VBO buffers per second.  The entire machine starts to act unstable.  The mouse gets jumpy and erratic, all applications get unresponsive, etc.  But, during this time the CPU is not pegged, so it is DMA or other bottlenecks.  If there is a high amount of change in geometry what is the recommended approach.  Should I recycle the buffers and look for an older one that is the right size?  Should I be using something other than VBO buffers for this type of application?

This is all on a 1Ghz Powerbook Ti with 1GB of ram and a Radeon 9000 mobility chip.

26  Java Game APIs & Engines / JOGL Development / Graphics Card question about Mac Mini on: 2005-03-18 01:29:01
I have been working with my Ti 1Ghz Powerbook which has a 9000 mobility.  This lacks programmable shader support.  How does JOGL run on the Mac Mini 5200?  Would that let me work with pixel and vertex shaders?  Any JOGL users working on that box? Any advise?

I am running into performance issues and wondering if the only solution is to make beter use of the GPU.  I try to replace a few VBO objects per frame to update geometry that is animated.  The VBOs have about 1200 quads.  One VBO for vertices, and one for colors.  The time to load them into the GPU on each frame is noticeable!  I guess that is what vertex shaders are for.

As usual this could be some other coding issue on my part, but having hardware the lets me try other approaches seems reasonable.

27  Java Game APIs & Engines / JOGL Development / Re: Performance woes, 10x slowdown during mouse ev on: 2005-03-15 02:23:01
It looks like it was generating a ton of GL garbage that it was not cleaning up.  When the scene was stable the set of VBO buffers was stable, but with motion it was generating new buffers each frame and not releasing the old ones.  Now I get 60 fps for the test case with only 75% of the CPU.  Not bad for Java on a 1Ghz Powerbook.  There is still a lot of optimizing to do, but I am on my way.
28  Java Game APIs & Engines / JOGL Development / 35 dyld_stub_mach_host_self on: 2005-03-14 23:54:40
Removing the FSAA did not address the issue.  In looking at the detailed samples from one run I found this sequence just before one of the supervisor level traces that had the problems.  Do these look familar as part of JOGL or Apple's OGL implementation?  I believe the higher numbered entries are deeper in the call stack.

42      __MIG_check__Reply__io_connect_method_structureI_structureO_t
41      io_connect_method_structureI_structureO
40      gldDestroyBuffer
39      gldCompleteVertexBuffer
38      gldCompleteVertexBuffer
37      gldDestroyVertexArray
36      gldUpdateDispatch
35      dyld_stub_mach_host_self
34      dyld_stub_mach_host_self
33      Java_net_java_games_jogl_impl_macosx_MacOSXGLImpl_dispatch_1glMultiDrawArraysEXT__I_3I_3IIJ

I am still not sure what is really going on other than things slowly degrading during this sequence.  The supervisor level samples correlate with the activity that causes the slow down, and consume the CPU.
29  Java Game APIs & Engines / JOGL Development / Re: Performance woes, 10x slowdown during mouse ev on: 2005-03-14 18:03:57
This is not my day job, so I will need to do testing this night.  I will try turning off multi-samples.  It may be doing that in software, which I guess would be using AGP textures, or that call could be named from old code that is now just general memory allocation.  Most of the interesting demos require nVidia hardware, which this machine is not equiped with.  I will see which ones I can get to run, and let them run for a while to see what happens.  I suspect that it is either my code, or something I am doing that is stressing the driver in some way.  Otherwise it would be obvious to others using the Mac (which seems to be pretty well represented for a change).

30  Java Game APIs & Engines / JOGL Development / Re: Performance woes, 10x slowdown during mouse ev on: 2005-03-14 15:20:42
How do I get Shark to show a stack trace?  As I said in the newest post, I have eliminated the use of textures in the drawing that is being done.  I am not using anything but a frame with one GLCanvas in it.  I do have 6 sample FSAA enabled for the context.

Pages: [1] 2
nelsongames (15 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 (392 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 (167 views)
2018-03-02 22:15:33

buddyBro (715 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!