Latest posts of: WhiteHexagon

Show Posts
Pages: [1] 2

1	Java Game APIs & Engines / JOGL Development / Re: FullScreen JOGL in dual monitor configuration	on: 2006-08-21 20:45:10
Hi, thanks for the feedback. I tried another system with dual monitors and things seemed to work fine with both a 1.5 JVM and 1.6 JVM. I tried a 1.6 JVM on the original test machine and fullscreen seems to be supported. SO it's just the 1.5 that it doesn't work (on the primary monitor) Maybe by the time I finish this game everyone will be using a 1.6 JVM anyway Thanks Peter

Java Game APIs & Engines / JOGL Development / Re: FullScreen JOGL in dual monitor configuration

on: 2006-08-18 08:20:37

'Code':

1
2
3
4
5
6
7
8
9

package com.whitehexagon.gameclient;

import java.awt.GraphicsEnvironment;

public class TestFullscreen {
    public static void main(String[] args) {
        System.out.println("fullscreen available? "+GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().isFullScreenSupported());
   }
}

Command line: (just the flag value changed)

1
2

%JAVA_HOME%\bin\java -Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true -classpath build\classes com.whitehexagon.gameclient.TestFullscreen
%JAVA_HOME%\bin\java -Dsun.java2d.noddraw=false -Dsun.awt.noerasebackground=true -classpath build\classes com.whitehexagon.gameclient.TestFullscreen

Results

1
2
3
4
5
6
7

W:\prj\WhiteHexagon>F:\jdk1.5.0_06\bin\java -Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true -classpath build\classes com.whitehexagon.gamec
lient.TestFullscreen
fullscreen available? false

W:\prj\WhiteHexagon>F:\jdk1.5.0_06\bin\java -Dsun.java2d.noddraw=false -Dsun.awt.noerasebackground=true -classpath build\classes com.whitehexagon.game
client.TestFullscreen
fullscreen available? true

I don't have a 1.6 here, but maybe I can try that on another machine later today. Although I don't really want to make the spec for the game 1.6 when its still beta.

Thanks for looking into this!

Peter

GL_RENDERER=GeForce 6200/AGP/SSE2
Nvidia driver - 91.31_winxp2kmce_english_whql.exe
W2K SP4
JOGL nightly - 2006-08-16
1.5.0_06-b05

3	Java Game APIs & Engines / JOGL Development / Re: FullScreen JOGL in dual monitor configuration	on: 2006-08-17 22:33:48
Always so fast to respond thanks Ken. Maybe I was a bit fast to post But the problem seems to be related to -Dsun.java2d.noddraw=true If I exclude this flag, then isFullScreenSupported returns true, if I include the flag then isFullScreenSupported returns false. I wasn't sure if this flag is JOGL specific or Java specific. But I know I need the flag to use JOGL Cheers Peter

4	Java Game APIs & Engines / JOGL Development / FullScreen JOGL in dual monitor configuration	on: 2006-08-17 20:24:46
Hi, It seems that my game will not switch into fullscreen mode when two monitors are involved (dual head). defaultGraphicsDevice.isFullScreenSupported(); is returning false. Is this normal? I can understand if I was trying to fill both monitors, but I'm only using the primary display at the same resolution as the desktop. Cheers Peter W2K SP4 JOGL nightly - 2006-08-16 1.5.0_06-b05

5	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-08-12 13:12:02
Tracked it down to my needless recreation and destruction of the pbuffers, I re-use everything now, and the first call is 200ms and the rest around 30ms each Peter

6	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-08-10 22:18:51
I've noticed that now that I'm using this to render around 30 small (128x64) images, it seems quite slow (150ms per image). Although I'm caching the rendered images so it's only a problem on the first generation. But would you expect offscreen PBuffers to be slower than normal screen rendering? Cheers Peter

7	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-08-01 22:24:12
Cool, Haven't tried to TextureIO class before! all that code I did for nothing Anyway, I put a copy of the code up on my site. I can setup a webstart to runit if that helps anyone? http://www.whitehexagon.com/Brix.java Apologies but the code is a mess. It's a cut and paste job from many parts of the engine, so I hope it makes sense. It's normally full screen, but that code isn't the most reliable to I just maxed it to 1280 by 1024 for now. There's a really exciting texture there in case you dont find a nicer one to use http://www.whitehexagon.com/studs256256.png This is the code I tried that was only hitting around 30fps, and stil does... seems strange considering Spasi's results. I guess I'm doing something silly here, but can't spot what. Thanks Peter

8	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-07-31 21:43:42
Thanks joda, I currently used the polygon offset on another part of the engine, but never really understood what it was doing It works okay for most cases but I found a few gcards where I get really nasty result when two polygons intersect, kinda heavy saw tooth effect, if that makes sense. Using the stencil buffer technique looks a bit tricky, but maybe something I will brave once I learn a bit more about OpenGL. -- Anyway regarding the performance issue, I've managed to rip out most of my engine code into a stadalone test now, apart from Texture loading where I use some custom file formats. Does anyone have a simple bit of code to generate a texture ie. doesn't need to load a texture? Thanks Peter

9	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-07-10 20:56:26
Hi Spasi, A big thanks for writing that! And interesting to see others results. Here's what I got on my hardware. (GeForce 6200/AGP/SSE2, Java 1.5.0_06, Pentium M760, Win 2K). I only tried client VM, don't think my machine is quite server spec IM: 74fps DL: 69fps PI: 73fps The CPU was maxed out, but the display was very pretty I have some lighting and textures which might be slowing my stuff down. Plus as you can see the machine spec is quite low. But obviously I'm doing something wrong in my code to be twice as slow, unless it's the way I'm configuring JOGL. I shall try to extract my drawing code into a testable unit which should make it easier to test, currently is quite heavily dependant on a whole bunch of other code. Cheers Peter

Java Game APIs & Engines / JOGL Development / Re: Performance

on: 2006-07-09 00:09:55

Hi Spasi, I appreciate your help with this but I didn't understand your earlier tip at first (see reply #13). But I'm learning slowerly

I was going to split my display list and that's where I got confused. I've now tried your approach of batching the VA data. My data breaks down into 9 chunks quite nicely so thats what I've tried first. I can see though that this is probably still too much data for the 100 or so items you mentioned, but now Im drawing less data and no outlines... so I'm drawing 9x225 bricks parts as below.

1
2
3
4
5
6
7

bind top texture
loop 9x:
    glDrawArrays[i] (225 single textured quads)

bind side texture:
loop 9x:
    glDrawArrays[i]  (225 x 4 brick sides (no base))

So i presume if I take this approach I'm only doing 18 'draw calls'? For the brick tops I presume that quads will be split internally into two triangles, so that would be 450 triangle per call, right? and 1800 triangles for the 4 sides. Which is more than the 1000 you mentioned. So as expected the CPU was still maxing out for the complete scene.

So next I tried to split the side drawing into two batches, east & north, and south & west.

1
2
3
4
5
6
7
8

bind top texture
loop 9x:
    glDrawArrays[i] (225 single textured quads)

bind side texture:
loop 9x:
    glDrawArrays[i]  (225 x 2 brick sides (no base))
    glDrawArrays[i]  (225 x 2 brick sides (no base))

That brings the triangle count down to 900 in each of those array lists. But sadly I'm still seeing a maxed out CPU and 30fps (the same as a single VA). DO you think I need to make these batches even smaller?

To bahuman: I could display all 2025 tops in a single VA at 60fps and 4%CPU. The problem was when I started drawing the bricks sides as well. Then I seemed to reach some switch over point where the CPU started taking load.

Thanks again for everyone thats helping out on this, I hope I can show something nice at the end of it all

Cheers

Peter

Java Game APIs & Engines / JOGL Development / Re: Performance

on: 2006-07-07 23:54:28

Hi All,

I've done some work on this the last couple of days with some interesting results. I tried Niwaks idea of using a vertex array. For code simplicity I split the rendering into two VA. One for the brick tops with a studed texture, and another VA for the brick sides (including the edges drawn into the texture as cylab suggested).

So the results: when displaying just the tops of the bricks the VA run as I would expect, 5% CPU and around 60fps (I presume this is just limited by the vsynch rate of my TFT which is currently also 60). Is there a way to disable that? I remember with GL4Java there used to be a special call to disable the vsynch limit, does JOGL have something similar?

So when I try to display the second VA (the sidess) as well, the CPU jumps upto 100% and the frame rate drops to 30fps (but thats still better than the 20% from using display lists!)

So I took out the rendering of the tops of the bricks for now, and just have the single vertex array for the sides of the bricks to try and optimize that. I found that by adjusting the count parameter on glDrawArrays I could find some switchover point where I start to become CPU bound. I'm drawing 2025 bricks which worked out to about 32,400 vetices.

1
2
3
4
5
6
7
8

vetcices CPU%
10000   6
15000   15
17000   20
20000   25
21000   50
22000   90
23000   98

So it seems I can only draw around half the brick sides I need taking this approach. I was thinking that maybe I could use a QUAD_STRIP for the 4 sides which would reduce the vertex count from 16 down to 10 per brick.

Or I could even try and calculate a quad strip for a complete row of bricks across the whole map. question? Would I still be able to change the color of each face using a quad strip, or will I end up with just a mess of blended colors because the vertices are shared? How would that with textures if I wanted differnet textures per face. I realise I can have both textures in a single 256x256 texture and just cut out the piece I need for each face, but how would I specify this while drawing a quad strip, seems impossible?

Anyway overall things are getting better. I'm just still confused over why the VA rendering starts to impact the CPU performance so drastically, and not even linearly.

Cheers

Peter

12	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-07-05 23:21:51
#2 For those numbers, what do you define as a draw call? is one draw call = one gl.glDoSomething method? or one Begin End block? Would spliting the display list into 5 smaller lists help in anyway? or is it really down to the number of gl.glDoSomething calls inside the display list. Since I guess that is currently 5600 * number of calls in drawQuestTile (35ish?) = 196,000. I think I'm missing something here, so I shall do some more reading on this topic because I think I need somehow to solve having this many bricks on screen, if not for the landscape then for sure once I have all the other scenery and creatures on screen. Maybe I will also try some VertexArrays here, I use them already for another part of the game and they seems quite performant. Since I only need one surface of the brick textured maybe I can also draw those surfaces seperately and render the sides of the bricks untextured. Lots of ideas... But it's been a long day and my head is buzing with all this Thanks to everyone for the feedback. I shall have another read of this over the weekend and hopefully all will be clearer.

13	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-07-05 17:48:17
Thanks for the great feedback! #1 The code I posted also now has two display lists wrapping it, one for the solid bricks and one for the wireframe, that's where I got my first increase from 7fps to 20fps, but still suffer 100% CPU load. Maybe I try array lists instead? or do you think this might be a jogl issue? From my reading I thought Display Lists were compiled on the GPU and then used directly from there, so should't I be getting almost 0 CPU load? #2If I'm using Display Lists or Array Lists I assume this is no longer an issue? I'd like to look more at vertex shaders in the near future, sounds very powerful, but my priority is to get something basically playable and then start to improve it. I didn't want to worry to much about the performance, but the client has gone down from 60fps a few months ago, to yesterdays low of 5fps, so I thought I'd better take a break and find out where the problem was before I go to far down the wrong path. The info here is really helping, thanks. #3 Interesting. Is there another better technique for highlighting the edges of the bricks instead of just drawing a black wireframe over the brick. (it doesn't seem to work very well anyway because of the zbuffer unless I make the line width equal to 2). You can see the effect I have on my front page: http://whitehexagon.com Thanks Peter

Java Game APIs & Engines / JOGL Development / Re: Performance

on: 2006-07-05 13:42:01

Well it's quite a low spec gcard, but I was down to 7fps, back to 20fps now after the changes, but I think I'm CPU bound for some reason.

Thanks for the link.

This is the code for drawing the solid bricks: but I call the same code but use GL_LINES

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

        
        gl.glBindTexture(GL.GL_TEXTURE_2D, textureStud);
        gl.glEnable(GL.GL_TEXTURE_2D);
        gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_FILL);

 loop 5600 times
                        float tx = drawQx + (QUEST_TILE_LENGTH * x);
                        float ty = drawQy + drawY;
                        int height = mapData[qx][qy].height[x][y];
                        float tz = ClientConstants.STD_BRICK_HEIGHT * height;
                        gl.glColor3fv(questColorTable[height+ -CorkConstants.MIN_MAP_HEIGHT], 0); //adjust height to be zero based.

                        // solid brick
                        gl.glTranslatef(tx, ty, tz);
                        gl.glBegin(GL.GL_QUADS);
                        drawQuestTile(gl, false);
                        gl.glEnd();

                        gl.glTranslatef(-tx, -ty, -tz);

And this is for a single brick

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

    
private static final void drawQuestTile(final GL gl, final boolean wireframe) {
        float BASE = 0.0f; // base height...
        float HEIGHT = STD_BRICK_HEIGHT;
        float WIDTH = 4;
        float LENGTH = 4;
        float[] normal;

        // front
        normal = Utils.calcNormal(new float[] { 0, 0, BASE }, new float[] { LENGTH, 0, BASE }, new float[] { LENGTH, 0, HEIGHT });
        gl.glNormal3fv(normal, 0);
        gl.glVertex3f(0, 0, BASE);
        gl.glVertex3f(LENGTH, 0, BASE);
        gl.glVertex3f(LENGTH, 0, HEIGHT);
        gl.glVertex3f(0, 0, HEIGHT);

        // back
        normal = Utils.calcNormal(new float[] { LENGTH, WIDTH, BASE }, new float[] { 0, WIDTH, BASE }, new float[] { 0, WIDTH, HEIGHT });
        gl.glNormal3fv(normal, 0);
        gl.glVertex3f(LENGTH, WIDTH, BASE);
        gl.glVertex3f(0, WIDTH, BASE);
        gl.glVertex3f(0, WIDTH, HEIGHT);
        gl.glVertex3f(LENGTH, WIDTH, HEIGHT);

        // w end
        normal = Utils.calcNormal(new float[] { 0, WIDTH, BASE }, new float[] { 0, 0, BASE }, new float[] { 0, 0, HEIGHT });
        gl.glNormal3fv(normal, 0);
        gl.glVertex3f(0, WIDTH, BASE);
        gl.glVertex3f(0, 0, BASE);
        gl.glVertex3f(0, 0, HEIGHT);
        gl.glVertex3f(0, WIDTH, HEIGHT);

        // e end
        normal = Utils.calcNormal(new float[] { LENGTH, 0, BASE }, new float[] { LENGTH, WIDTH, BASE }, new float[] { LENGTH, WIDTH, HEIGHT });
        gl.glNormal3fv(normal, 0);
        gl.glVertex3f(LENGTH, 0, BASE);
        gl.glVertex3f(LENGTH, WIDTH, BASE);
        gl.glVertex3f(LENGTH, WIDTH, HEIGHT);
        gl.glVertex3f(LENGTH, 0, HEIGHT);

        // bottom
        normal = Utils.calcNormal(new float[] { 0, 0, 0 }, new float[] { LENGTH, 0, 0 }, new float[] { LENGTH, WIDTH, 0 });
        gl.glNormal3fv(normal, 0);
        gl.glVertex3f(0, 0, BASE);
        gl.glVertex3f(LENGTH, 0, BASE);
        gl.glVertex3f(LENGTH, WIDTH, BASE);
        gl.glVertex3f(0, WIDTH, BASE);

        // top
        normal = Utils.calcNormal(new float[] { 0, 0, HEIGHT }, new float[] { LENGTH, 0, HEIGHT }, new float[] { LENGTH, WIDTH, HEIGHT });
        gl.glNormal3fv(normal, 0);
        if(!wireframe)gl.glTexCoord2f(0.0f, 0.0f);
        gl.glVertex3f(0, 0, HEIGHT);
        if(!wireframe)gl.glTexCoord2f(QUEST_TILE_STUD_COUNT, 0.0f);
        gl.glVertex3f(LENGTH, 0, HEIGHT);
        if(!wireframe)gl.glTexCoord2f(QUEST_TILE_STUD_COUNT, QUEST_TILE_STUD_COUNT);
        gl.glVertex3f(LENGTH, WIDTH, HEIGHT);
        if(!wireframe)gl.glTexCoord2f(0.0f, QUEST_TILE_STUD_COUNT);
        gl.glVertex3f(0, WIDTH, HEIGHT);

    }

Java Game APIs & Engines / JOGL Development / Re: Performance

on: 2006-07-05 11:07:24

Thanks Spasi, that would explain why none of the other gl methods show up too

but it makes it kinda hard to know whats slowing things down.

Anyway I got my scene rendering 3x faster already, but maybe someone has some tips for a novice OGL programmer

The specific scene I was having problems with was displaying only around 5600 lego style bricks. Not that much to ask I thought, but It was really killing my fps.

1
2
3
4
5
6
7

loop 5600 times:
    //draw solid brick
    gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_FILL);
    drawSingleBrick using GL_QUADS and textured.
    //draw wireframe to highlight the edges in black
    gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_LINE);
    drawSingleBrick using GL_LINES

I've now split this into two iterations (one for solid drawing, one for wireframe highlight drawing) which each gets compiled into a display list. Then I just call the two display lists. This approach seems to tripple to performance, but I know that some of this is because of the normal calculations and color lookups only being done once during compilation.

But I'm still a bit confused. I would have thought that using a display list that the code is then on the gcard, but my CPU is still maxing out at 98% during rendering. Is JOGL running these lists on the CPU? Should I be using VertexArrays for this type of stuff? or would I have the same problem?

Any tips are really appreciated.

Cheers

Peter

java (build 1.5.0_06-b05)
jogl beta4
Win2k
GL_VENDOR=NVIDIA Corporation
GL_RENDERER=GeForce 6200/AGP/SSE2
DRAWABLE_GL=com.sun.opengl.impl.GLImpl

16	Java Game APIs & Engines / JOGL Development / Re: Performance	on: 2006-07-05 10:28:43
YourKit - its a bit pricey, but they do a 30day evaluation for free

Java Game APIs & Engines / JOGL Development / Performance

on: 2006-07-05 00:31:40

Hi All,

I'm just testing out a profiler to try and get some more performance out of my game. I can already see that I need to add some more Display Lists for parts of the rendering, but one thing that surpised me was the following:

1
2
3
4
5
6
7

method name                                             time(ms)         invocation count
Model.draw(GL, int, int, int, boolean)                   24,687   93 %    426,877 
  com.sun.opengl.impl.GLImpl.glBegin(int)                 4,937   19 %    2,561,262   
  com.sun.opengl.impl.GLImpl.glEnd()                      3,265   12 %    2,561,262   
  MyUtils.calcNormal(float[], float[], float[])           2,812   11 %    2,561,262   
  com.sun.opengl.impl.GLImpl.glNormal3fv(float[], int)    2,453    9 %    2,561,262   
  ...some other calls

Is glBegin and glEnd really so expensive? It seems so, anyway I can fix this issue no problem, I just thought the numbers were quite interesting.

Cheers

Peter

18	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-06-18 15:08:48
problem solved, reshape doesn't get called when using pbuffer, and in here I was calculating the new aspect ratio of the screen. Of course I can calculate this on the dimension of the pbuffer and then it works Cheers Peter

19	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-06-18 13:51:46
thanks. One strange thing I noticed now. To test and debug this functionaility I was using the same GLEventListener twice, once with a standard GLCanvas approach, and secondly with a GLPbuffer. This was working fine as I mentioned, until I remove the GLCanvas rendering, then my pbuffer only has the glClear color. //without these two lines the pbuffer is just background canvas.addGLEventListener(offscreenCanvasListener ); canvas.display(); offscreenCanvas.addGLEventListener(offscreenCanvasListener ); offscreenCanvas.display(); Cheers Peter

20	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-06-18 11:52:51
Great! seems to work fine apart from I had to flip the image at the end. Thanks again. Peter

21	Java Game APIs & Engines / JOGL Development / Re: Tips for rendering directly to Image	on: 2006-06-17 16:02:10
I'm using GLCanvas normally, so this is a bit involved for my level of understading So can I use something like the following to create a pbuffer GLCapabilities offscreenCaps = new GLCapabilities(); offscreenCaps.setDoubleBuffered(false); offscreenCaps.setPbufferRenderToTexture(true); GLPbuffer pbuffer = GLDrawableFactory.getFactory().createGLPbuffer(offscreenCaps, null, 128, 128, shareWith); Then I need a GLContext from somewhere for 'shareWith'. Is there some way I can access the context being used from my other displayed GLCanvases? Currently I only pass the Animator down to this class since originally I just had a few GLCanvases doing this job. I had a look at the demos, and the user guide and the source code for GLJPanel, but i'm really not sure what I should be doing here. I think I need something like the following? GLDrawable drawable = GLDrawableFactory.getFactory().getGLDrawable(this, capabilities, chooser); GLContextImpl context = (GLContextImpl) drawable.createContext(null); but then If i get this far, where's my init and display method come into play? Am I going to end up rewriting GLJPanel? and thats before I try to somehow extract the image from the pbuffer... any more pointers or tips would be really appreciated. I'm happy to work through this, but I'm a bit lost at the moment. Cheers Peter

22	Java Game APIs & Engines / JOGL Development / Tips for rendering directly to Image	on: 2006-06-14 19:35:00
Hi All, I want to take a 'snapshot' of many small 3D sceens as ImageIcon's to use on some buttons. Any tips or ideas where to start? Can Jogl even do this? Or do I need to render to screen and then somehow screen-scape the image? Cheers Peter

23	Java Game APIs & Engines / JOGL Development / Re: anything special about 60 seconds?	on: 2006-06-09 22:43:26
mystery solved! I tried the gears demo with my fps code and saw the same problem. I tried it on a second box and also saw the same slowdown once per 60s, and it was something to do with Java using some cpu resources for a short time. But it turns out it was the eclipse development environment! doh! should have thought of that, just saw java and assumed it was the application sorry to waste you time guys. But it nice to see the gears demo again Cheers Peter

24	Java Game APIs & Engines / JOGL Development / Re: anything special about 60 seconds?	on: 2006-06-08 19:18:57
I'll have a play with the gears stuff at the weekend. swpalmer: thanks, but visualgc show all this info and its clearly nothing to do with gc or hotspot compilations. maybe its just something in windows. cheers Peter

25	Java Game APIs & Engines / JOGL Development / Re: anything special about 60 seconds?	on: 2006-06-07 09:39:48
btw, I tried visualgc, but couldn't see anything unusual with the gc. I get an Eden collection about every 10s, but nothing on the Old Gen. cheers Peter java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)

26	Java Game APIs & Engines / JOGL Development / anything special about 60 seconds?	on: 2006-06-07 09:28:53
I measure my framerate as an avergae over 5s. It seems every 60s I get a framerate average drop of around 5%. I've shut down all my other threads and there is nothing happening on the gui. Any ideas? Could it be one of the garbage collectors kicking in at regular intervals? or the hotspot compiler? or could it be something JOGL based? Cheers Peter

27	Java Game APIs & Engines / JOGL Development / Re: Problem with multiple jogl GLCanvas	on: 2006-06-06 20:36:35
FYI: My black shadow issue was fixed by using the following flag: -Dsun.awt.noerasebackground=true Thanks to Ken for that! Peter ---- whitehexagon.com - one step closer to online LEGO

28	Java Game APIs & Engines / JOGL Development / Re: Problem with multiple jogl GLCanvas	on: 2006-05-31 12:40:03
yes I'm using the noddraw flag. I don't have a simple test case, but I could email you a login for the app? This is the info for the user reporting the 'black hole' in the screen after closing the dialog. GL_VENDOR=S3 Graphics GL_RENDERER=KM400/KN400/MMX/K3D DRAWABLE_GL=com.sun.opengl.impl.GLImpl cheers Peter

29	Java Game APIs & Engines / JOGL Development / Re: Problem with multiple jogl GLCanvas	on: 2006-05-30 20:32:31
The flag doesn't help, but it seems like the CPU is just maxing out when dragging a dialog. That probably explains the slow repaint. In fact its more like a black shadow that follows the dragging rather than the actual dialog not repainting. I'll try and determine the graphics card thet the shadow stays on after dialog close... Thanks Peter java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)

30	Java Game APIs & Engines / JOGL Development / Re: Problem with multiple jogl GLCanvas	on: 2006-05-29 21:43:10
I had a similar problem and using a single Animator made a big improvement. But I still see slow repaints of a dialog when draging around the dialog over the top of a canvas (that is being animated). Also some users have repoted that closing the dialog leaves a black rectangular hole on the underlying canvas, that just doesnt get repainted. Peter

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!