Latest posts of: milvich - Java-Gaming.org

Show Posts
Pages: [1] 2

1	Java Game APIs & Engines / JOGL Development / Re: Vertex Buffer Objects	on: 2004-07-14 15:12:52
The NeHe lesson checks to see if VBOs are available, if they are not then they use standard vertex arrays. Your video card probably doesn't support VBOs.

2	Java Game APIs & Engines / JOGL Development / Re: Stereo viewing using quad buffers in JOGL	on: 2004-07-12 14:49:42
I was able to get stereo on a Nvidia Quadro 3000g using the same code that you have. Although I haven't been working on that project much, and it has been several months since I have run it in stereo mode, so something could have broken in the latest releases. This was using redhat 9 linux with a 2.6 kernel.

3	Java Game APIs & Engines / JOGL Development / Re: Losing the backbuffer when resizing	on: 2004-07-06 15:50:57
I just upgraded to the latest nvidia drivers (6106) and that seems to have fixed this problem.

4	Java Game APIs & Engines / JOGL Development / Re: Uncontrolled flicker	on: 2004-07-01 21:32:16
This sounds very similar to a problem that I am having on linux. I seem to lose the back buffer when I resize the GLCanvas, and sometimes it comes back when I resize it again. Mine was triggered when I upgraded my video card to a Nvidia Quadro card, and has persisted between Java 1.4.2_03, 1.4.2_04, 1.5.0 b2. I think there is still some threading issues lurking somewhere...

5	Java Game APIs & Engines / JOGL Development / Re: Good books for jogl?	on: 2004-06-22 15:12:46
You can use any OpenGL book/tutorials, the only parts that might be different is how you set up, and start the program, and jogl has some limitations about when you can call GL functions (you can only call GL functions in the init, reshape and display callbacks). For books, I like: OpenGL SuperBible, by Richard Wright, and Michael Sweet Computer Graphics Using OpenGL, by F.S. Hill For tutorials you can't really beat the NeHe ones (http://nehe.gamedev.net/), and a good number of them have JOGL source code.

6	Java Game APIs & Engines / JOGL Development / Re: compiling jogl on mac os x	on: 2004-06-18 20:34:36
I haven't tried Java 1.4.2_04, but I was able to compile the latest nightly source on Java 1.4.2_03. I would first re-download the source, and make sure that you have new enough versions of ant and antler. Michael Mac OS 10.3.4 Ant 1.6.0 Antler 2.7.2

7	Java Game APIs & Engines / JOGL Development / Re: keyevent question	on: 2004-06-14 20:59:09
If you haven't set up an Animator then all your drawing is done on the swing event thread. So removing the listener when you start displaying, and adding it when you finished doesn't do anything, since the swing event loop will not be processing any events while you are displaying. The way I would fix this problem would be to split the problem into 3 areas/threads. I would create an Animator that will run the display loop. The one that comes with JOGL just tries to draw as fast as possible, but you could modify it to support more of a repaint() style operation, but would still draw on its own thread. This way the swing event thread is free to respond to any events which should keep events from "backing up". The final part would be to set up a Timer that fires x number of microseconds, and start it when the user presses your key, and then stop it when the user releases your key. In that Timer you could do the logic to change all of your points (just be careful not to re arange all the points while you are trying to draw them). Or you could just install JInput and poll for the keys every time through the display method. =)

8	Java Game APIs & Engines / JOGL Development / Re: calling repaint of GLCanvas->Performance pr	on: 2004-06-14 14:56:58
You can't place any light weight components on top of the heavy weight GLCanvas. Well, you can, you just won't ever see them. =)

9	Java Game APIs & Engines / JOGL Development / Re: GLContext from other classes	on: 2004-06-14 14:47:31
A few function calls is not going to slow down your renderer by any measurable amount.

10	Java Game APIs & Engines / JOGL Development / Re: Downsides of Display List?	on: 2004-06-06 16:18:45
You are presuming correctly. When building an display list OpenGL records what you are doing and can pre-compute some stuff, and stores your operations in a more efficient manner. Although the reason for your speed up probably has more to do with the reduction of function calls. This is especially important with JOGL because of the expense in making a JNI call (one method/function call is being expanded into something more like 4 or 5). The only downside that I can think of is if your model changes quickly, then the overhead of rebuilding the display lists might negatively effect you. For most applications the memory cost is probably too trivial to worry about. You might want to try vertex arrays and vertex buffer objects. They are faster then display lists, especially with vertex buffer objects, since they upload the geometry into the video card's memory.

11	Java Game APIs & Engines / JOGL Development / Re: jogl on linux amd64? (EDIT: Partially solved)	on: 2004-05-31 22:00:33
I finally had some free time so I applied the AMD 64 patch from Issue 88 to jogl to see if it worked. Which it sorta did, as long as you used the core of GL. Almost anything that used a dynamically looked up address would cause a crash. I say almost because the GLU functions worked fine, but the GL functions did not. After much detective work I figured out that glXGetProcAddressARB did not always return the same function address. Calling it from the java method resetProcAddressTable(...) would return an invalid pointer (which was cached by jogl and used later, causing a crash). I then modified the native code dispatch_1glTexImage3D function to call glXGetProcAddressARB and print out the result, which was different the cached version and if I used that address to call the function I would not crash. I tried moving when the glProcAddressTable is populated to different times, and it always would get the incorrect values, even if I called it right before my display method was to be called. It confused me for awhile that the GLU functions worked fine, until I looked at X11GLContext.java and saw that you use dlsym to look up the function points for the GLU functions. So rather then using glXGetProcAddressARB, I switched it to use dlsym for all of the symbol look up, and everything worked after that. It looks to me that Nvidia has yet another bug with their driver/gl implementation. Although, C based programs seem to work fine... So in short, to use jogl on a AMD64 with nvidia cards you have to patch dynamicLookupFunction in X11GLContext to use dlsym rather then glXGetProcAddressARB. Michael

12	Java Game APIs & Engines / JOGL Development / Re: Losing the backbuffer when resizing	on: 2004-05-25 14:31:06
Ok, an issue has been submitted. Also, this only started happening to me after I upgraded to a quadro video card (need the stereo capabilities). This did not happen to me when I was using the Nvidia Geforce4 Titanium which probably isn't too far off of your GeforceFX card. Michael

13	Java Game APIs & Engines / JOGL Development / Re: Thread question	on: 2004-05-21 22:18:17
Quote What I was attempting to say was that I am repainting a GLCanvas from 2 seperate threads. I tried to use the synchronized(glcanvas) technique but this failed. My program has never crashed without using the synchronized keyword though which brings me to my question: Well, the repaint method doesn't actually do any painting. It signals java that the next time through the event loop it should paint the Component. So if you call repaint multipule times before the Component is actually painted, it is collapsed down into one call to paint. Repaint is safe to call from any thread without any synchronization, and the Swing event loop will eventually tell the canvas to paint on the main Swing event loop thread. Quote is there some inbuilt mechanism in JOGL to ensure mutual exclusion between 2 or more threads updating a common GLCanvas? Or is it frought with danger? I really don't know if JOGL will pause a thread if another thread is currently in the display method. But if you are signaling that you would like to redraw using the repaint methods, then you don't have to worry about this.

14	Java Game APIs & Engines / JOGL Development / Re: Losing the backbuffer when resizing	on: 2004-05-21 21:45:33
Actually... I spoke to soon. It still loses the backbuffer, it just requires more work. =) I can now usually resize the view a few times before losing the back buffer. I can also lose the back buffer just by just shaking the window for a few seconds. I downloaded the Java 1.5 beta today, and I sometimes lose the back buffer, but not nearly as often as with 1.4.2. Michael

15	Java Game APIs & Engines / JOGL Development / Re: Losing the backbuffer when resizing	on: 2004-05-21 19:11:44
Hey Ken, I implemented that change and it did fix my problem! =) Thanks, Michael

16	Java Game APIs & Engines / JOGL Development / Losing the backbuffer when resizing	on: 2004-05-21 15:01:37
Hello, I recently got a new video (a Nvidia Quadro 4 XGL) and when I resize a JOGL canvas the canvas appears to lose its backbuffer and always draws to the front buffer with nasty flickering results. I have tried it with both my program and several of the JOGL demos with the same results. This only seems to affect JOGL programs, both glxgears and the xscreensavers resize fine without loosing their back buffer. Does anyone know why this is happening? Gentoo linux 2.6.5, Nvidia Quadro 4 XGL, Nvidia 5336 driver. Thanks, Michael glxinfo output: Quote name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample client glx vendor string: NVIDIA Corporation client glx version string: 1.3 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro4 750 XGL/AGP/SSE2/3DNOW! OpenGL version string: 1.4.1 NVIDIA 53.36 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fence, GL_NV_fog_distance, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NVX_ycrcb, GL_SGIS_generate_mipmap, GL_SGIS_multitexture, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r y . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x2a 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 2 1 Ncon 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 2 1 Ncon 0x2c 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 4 1 Ncon 0x2d 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 4 1 Ncon 0x2e 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x2f 24 dc 0 32 0 r . . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x33 24 dc 0 32 0 r . . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x34 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x35 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 2 1 Ncon 0x36 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 2 1 Ncon 0x37 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 4 1 Ncon 0x38 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 4 1 Ncon

17	Java Game APIs & Engines / JOGL Development / Re: Help! Persistent Linux problem	on: 2004-05-12 21:28:11
I ran your kreisel.jnlp on my linux box without a problem. It locked up when I clicked random buttons, but the axies did show up and I could spin them. Gentoo Linux 2.6.5 kernel Michael

18	Java Game APIs & Engines / JOGL Development / Re: jogl on linux amd64? (EDIT: Partially solved)	on: 2004-05-10 14:50:04
Good job! =) I will have to try it again soon. I am going to assume that you are using the Blackdown JDK? Have you tried the Java 1.5 beta for AMD64 from Sun? I tried to use it, but it was extreamly flaky on my system (64bit gentoo). Now I just need to get JAI ported to AMD64... Michael

19 Java Game APIs & Engines / JOGL Development / Re: camera transformation matrix on: 2004-05-08 21:17:41

It looks like you are keeping your orientation and translations separate from each other. You do not need to do this. A 4x4 transformation matrix contains a 3x3 rotation component, and a 3x1 translation part. The matrix is shown below. The Rs are the rotation matrix, and the X,Y,Z is the translation.

[ R R R X ] [ R R R Y ] [ R R R Z ] [ 0 0 0 1 ]

I think the problem you are running into is that when you rotate, you just rotate the rotation matrix, and ignore the translation. Consider the following scenario:

1) Translate 10 down the z axis (out of the screen).
2) Rotate 180 degrees around the Y axis

After doing that our camera should be at (0,0,10) and -z should be pointing out of the screen. Your code translates correctly, but when you rotate, you rotate the orientation and then multiply it by the old translations. Which means you rotated then translated, which is not what we wanted to do, and our camera ends up at (0,0,-10).

What you should do is keep a single unified transformation, and every time you want to rotate or translate, create a new transformation matrix and multiply the unified one with the new transformation.

Here is some totally untested code =)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public void translate(Vector3d translation)
{
    Matrix4d transform = new Matrix4d();
    transform.set(translation);

    this.transformation.mul(transform);
}

// rotates around a vector
public void rotate(double x, double y, double z, double radians)
{
    Matrix4d transform = new Matrix4d();
    transform.set(new AxisAngle4d(x,y,z,radians));

    this.transformation.mul(transform);
}

public void setGLCamera(GL gl)
{
    Matrix4d inverse = new Matrix4d(transformation);
    inverse.invert();

    gl.glLoadMatrix4d(convertToGLMatrix(inverse));
}

20	Java Game APIs & Engines / JOGL Development / Re: camera transformation matrix	on: 2004-05-02 14:56:08
That is the correct way, at least that is how I do it. A couple of things that you might want to check: - OpenGL is column major, ie the indices of the matrix written out by column. `[ 0 4 8 12] [ 1 5 9 13] [ 2 6 10 14] [ 3 7 11 15]` If you did row major then change it to match the OpenGL ordering. - You are setting up the matrix incorrectly. An easy way to check this is to do some transforms using the gl functions, glRotate, glTranslate, and glScale and then ask the OpenGl context for the current matrix (glGetDoublev(GL.GL_MODELVIEW_MATRIX, matrix) and see if doing the same sequence of transforms match up with your transformation matrix.

21	Java Game APIs & Engines / JOGL Development / Re: Creating image/imageicon from canvas	on: 2004-04-25 15:21:32
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1080167202;start=1#1 Thread is about printing a GLCanvas, code is about saving the screenshot to disk. I am sure you can modify it to do what you want.

22	Discussions / General Discussions / Re: Collabnet new look complaints	on: 2004-04-25 15:16:53
I second this suggestions. We have already seen several posts in the forms from people who can't find the files they want to download. It even took me awhile to figure it out and I had to read someone's post twice to understand what they were talking about. Getting rid of the arrows seems like the best way to fix the problem.

23	Java Game APIs & Engines / JOGL Development / Re: ...jogl.GLException: Unable to lock surface	on: 2004-04-25 15:09:02
My guess is that the GL Context hasn't been set up yet. I believe that JOGL delays the actual creation of the context until first display. So the reshape is happening before the context is created. Why don't you try setting the size before adding the GLCanvas?

24	Java Game APIs & Engines / JOGL Development / Re: JOGL 1.1 b02 released	on: 2004-04-24 01:37:47
Quote I navigated to Projects > games > games-core > jogl > Documents & files And I see: Release Builds 2004 Official JOGL release builds There are no files in this folder. The navigation design on the download pages is... well pretty worthless. You have to click on the triangle next to the folders to expand them in the column on the left. Clicking on a folder will only show the files and not any sub folders in the main panel. So click on the triangle next to the Release Builds 2004 folder, then click on the name of the folder you want.

25	Java Game APIs & Engines / JOGL Development / Re: Help: gl call in key listener generates except	on: 2004-04-19 03:24:48
The gl context is only active during the display/init methods. You need to save the information about the events and tell your GLDrawable to redraw. Then during the display callback you can respond to those events and use the gl functions.

26	Java Game APIs & Engines / JOGL Development / Re: OpenGL Commands outside of Display	on: 2004-04-15 22:20:33
How about disposing of textures? When a glCanvas goes away, does all of the textures that you loaded using that gl context also go away?

27	Java Game APIs & Engines / JOGL Development / Re: [compatibility] does jogl demo run on your com	on: 2004-04-15 15:24:30
It works on my linux box at work. Dual Opterons running Gentoo linux with the 2.6.3 kernel. Nvidia Geforce Ti with 128 megs of vram. Lesson6: ~910 Earth Sattelit: ~785 Running both at the same time locks up the program.

28	Java Game APIs & Engines / JOGL Development / Re: [compatibility] does jogl demo run on your com	on: 2004-04-14 22:27:43
The Jogl-Runner app doesn't constantly show all of the "sub apps". It sometimes launches with only "Lesson02", or "Lesson02" and "Lesson06", or "Lesson02" and "Lesson06" and "Earth Sattelit". Here are the FPS from a time when all three showed up: Lesson06 fps: ~350 Earth Sattelit fps: ~350 Running both at once causes it to crash. Computer: PowerBook G4 1Ghz, ATI Radeon 9000 Mobility with 64 megs of VRAM

29	Java Game APIs & Engines / JOGL Development / Re: April 12, 2004 JOGL build	on: 2004-04-13 14:27:23
Might I suggest changing the way the file browser works? I did the same thing Mithrandir did, even after reading your post about the tricky triangles. Why don't you expand the folder if the user clicks on the name? Thats how I expected it to work, and my co-workers also agreed with me.

Java Game APIs & Engines / JOGL Development / Re: Only 65 fps rendering empty world...

on: 2004-04-12 15:37:08

Quote

I was using a technique I found in a book that seemed weird anyway, so I went back to just getting the time at the beginning and end of display() and subtracting them.

This yielded a result of 0 (zero) ms passing between the two points. That still seems a little weird, but that's what I got. Then again, I don't really know jack about OpenGL, so maybe that IS reasonable.

The clock in your computer isn't accurate or fast enough to generate a time delta for one frame of drawing nothing.

What you should do is create a frame counter that you increment everytime you draw and after say .25 seconds compute the FPS using your frame counter with an equation like the following.

1
2
3
4
5
6
7
8

time = getTime()
timeDelta = oldTime - time
if(timeDelta > .25s)
{
  fps = frameCount * (1.0s/timeDelta)
  frameCount = 0
  oldTime = time
}

Pages: [1] 2

Check out our latest community projects!

Play Revenge of the Titans! The situation is critical. We need fancy commanders to defend Earth, the moon, Mars!