Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
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  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-02 23:11:31
Oh wow, I finally managed to solve this...

Turns out that it wasn't even this function that was causing the problem... My UpdateCamera function was based on the matrix transforms that D3DXMatrixLookAtLH does, and it turns out that while for some reason JOGL allows the camera to work fine with these matrix transforms, in C++ this resulted in the geometry being culled out or something about that effect as soon as the CamLocZ variable hit -1.0. I changed up the matrix transforms that UpdateCamera does, and now I have the perfect coordinate system I wanted and it works just great in C++. I applied the same changes to the JOGL version and the camera worked great in there too. I don't know why, but after days of fiddling with this, I just decided to screw around with the UpdateCamera function, and it almost magically just worked afterwards.

As of now, this problem is resolved. In the end, it was my fault for identifying the actual problem incorrectly. I suppose the reason this doesn't occur in java is because all types are 64-bit sized by default so there was higher precision maintained in the matrix values while since the C++ app is a native 32-bit app, that precision was lost and it resulted in premature culling or some other problem to occur which resulted in the geometry disappearing. I might not be 100% correct about that, but what I do know is changing a couple negatives in the UpdateCamera function's matrix generation into positives was essentially what solved this problem.

It turns out the reason I thought it just wasn't working at all was because of the size of the geometry that I was testing with, it was quite large and as the cut-off distance of the camera was a tiny -1.0, I couldn't even notice that the object was actually appearing smaller. That was part of the reason that led to this misconception. As I was approaching this solution, to test my theory, I tried testing with a much smaller piece of geometry and I did indeed notice it appearing smaller, which eventually led me to the final solution.

I appreciate the help of everyone who contributed to this thread, thanks guys.
2  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-02 14:43:44
I did try logging calls to the setDrawMode function and the mode being set, and as the log proved, every frame setting draw mode to 3d first was called once, then setting draw mode to 2d was called once after. No unexpected behavior there. I am also sure that the current draw mode is not set anywhere else, and I did also try removing that check entirely as well. All of this made no difference on the issue at hand. Maybe I should just post the full code I'm using to test?
3  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-02 01:29:18
Yes, in Java with JOGL, I can change the draw mode exactly the same way per frame, and upon drawing the same geometry, what should be 3d is 3d and what should be 2d is 2d.

I have also updated my original post with the C++ port as you requested, as you can see it's very similar and it was really a matter of copy + paste and some minor changes.
4  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-02 00:58:16
Oh, what you said reminds me of another thing I tried. I tried calling only setDrawMode with only DRAWMODE_3D every frame, and depth and all that worked fine. It's only as soon as I added a single call to it with DRAWMODE_2D afterwards to draw some 2d stuff that everything started to only draw in 2d (even the parts before the draw mode should be set to it). In my tests, I only call the function twice per frame, once for 3d at the beginning, draw a quad, then again for 2d and draw another quad, so I know that it's not being called to set 2d somewhere randomly by accident when the drawmode should be 3d. Since the draw mode is being set back to 3d at the beginning of every frame for the geometry that should be drawn in 3d, setting it to 2d later in a frame should still allow the geometry drawn beforehand to be in 3d, but it still appears to be drawn in 2d. Any other ideas?
5  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-01 22:21:33
I've checked it over and my initialization code is exactly the same in terms of opengl calls made in both test code pieces. In terms of how the C++ version fails, geometry is displayed however everything basically takes on a 2d mode and there doesn't seem to be any 3d depth or other transformations going on, everything drawn is 2d (changing the camera's position on the z axis, for example, does not make the geometry change displayed size in C++ like it does in java..). As far as opengl version, as far as I know they should both be using the same version as I have not messed with my opengl to add different versions or anything like that.
6  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-11-01 16:40:41
I made a function to read the matrices in both JOGL and C++ and printed the results out at different states in both JOGL and C++ scenarios. I noticed no differences except for some negative 0 values in the modelview matrix after both a 3d draw mode set and an update camera call (the last result in both sets). UpdateCamera() is just a separate function that I haven't posted, which serves to modify the view in a manner that reflects a set of camera variables like rotation and position. Do these negative 0s affect anything? I'm not really sure, as 0 can't really be negative as far as I know...

Full results in both JOGL and C++ with the camera being in exactly the same position are below.

Java:
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  
Initial state:
GL_PROJECTION
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


After setDrawMode(DRAWMODE_3D);
GL_PROJECTION
1.810661 0.000000 0.000000 0.000000
0.000000 2.414214 0.000000 0.000000
0.000000 0.000000 -1.000200 -1.000000
0.000000 0.000000 -0.200020 0.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


After setDrawMode(DRAWMODE_2D);
GL_PROJECTION
0.002500 0.000000 0.000000 0.000000
-0.000000 -0.003333 -0.000000 -0.000000
-0.000000 -0.000000 -2.000000 -0.000000
-1.000000 1.000000 -1.000000 1.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.375000 0.375000 0.000000 1.000000


After setDrawMode(DRAWMODE_3D); and UpdateCamera();
GL_PROJECTION
1.810661 0.000000 0.000000 0.000000
0.000000 2.414214 0.000000 0.000000
0.000000 0.000000 -1.000200 -1.000000
0.000000 0.000000 -0.200020 0.000000
GL_MODELVIEW
1.000000 -0.000000 -0.000000 0.000000
0.000000 1.000000 -0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


C++:
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  
Initial state:
GL_PROJECTION
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


After setDrawMode(DRAWMODE_3D);
GL_PROJECTION
1.810661 0.000000 0.000000 0.000000
0.000000 2.414214 0.000000 0.000000
0.000000 0.000000 -1.000200 -1.000000
0.000000 0.000000 -0.200020 0.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


After setDrawMode(DRAWMODE_2D);
GL_PROJECTION
0.002500 0.000000 0.000000 0.000000
-0.000000 -0.003333 -0.000000 -0.000000
-0.000000 -0.000000 -2.000000 -0.000000
-1.000000 1.000000 -1.000000 1.000000
GL_MODELVIEW
1.000000 0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
0.000000 0.000000 1.000000 0.000000
0.375000 0.375000 0.000000 1.000000


After setDrawMode(DRAWMODE_3D); and UpdateCamera();
GL_PROJECTION
1.810661 0.000000 0.000000 0.000000
0.000000 2.414214 0.000000 0.000000
0.000000 0.000000 -1.000200 -1.000000
0.000000 0.000000 -0.200020 0.000000
GL_MODELVIEW
1.000000 -0.000000 0.000000 0.000000
0.000000 1.000000 0.000000 0.000000
-0.000000 -0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


Any ideas?
7  Java Game APIs & Engines / JOGL Development / Re: Same matrix transform code doesn't work in C++ on: 2011-10-31 19:08:16
Yes, both the java app as well as the c++ app in question are single threaded. I also know I'm not missing breaks or any other syntax-related differences because I literally copy-pasted this function into the C++ app and just removed the gl. before the API calls to essentially port it over. I also know I'm not modifying the matrices any other way because I tested it in a C++ app that was as small as possible, with just opengl init and this code and drawing a couple quads, still did not match the behavior in java...

I mean, my only guess at this point is that JOGL doesn't directly wrap all these API's and does some additional stuff underneath which causes this discrepancy in behavior when I try to directly port the code...
8  Java Game APIs & Engines / JOGL Development / Same matrix transform code doesn't work in C++ on: 2011-10-31 16:36:45
Well, this is more of a question relating to C++ than to java, however it has to do with java and JOGL and I could think of no other place to post it, so I will post it here.

I have spent quite a long time trying to figure out why this strange behavior is exhibited, however I have not been able to come up with an answer, and perhaps the people here much more experienced with JOGL may be able to provide an explanation.

So basically, I created this small function that allows my app to easily switch to rendering between 2d and 3d objects by changing some values of the matrix stacks, namely in GL_PROJECTION and GL_MODELVIEW. I ported this code exactly as is, as well as my initialization code for opengl to C++ (of which I have more experience in than java), however in C++, this code does not produce the same effect as it's exact counterpart in java does.

Anyways, enough talking, here's the 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  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
   public static void setDrawMode(int DrawMode)
   {
      if (CurrentDrawMode != DrawMode)
      {
         switch (DrawMode)
         {
            case DRAWMODE_2D:
            {
               //glDisable(GL.GL_LIGHTING);
              gl.glMatrixMode(GL.GL_PROJECTION);
               gl.glLoadIdentity();
               gl.glOrtho(0, WindowWidth, WindowHeight, 0, 0, 1);
               gl.glDisable(GL.GL_DEPTH_TEST);
               gl.glMatrixMode(GL.GL_MODELVIEW);
               gl.glLoadIdentity();
               // Displacement trick for exact pixelization
              gl.glTranslatef(0.375f, 0.375f, 0f);
               break;
            }
            case DRAWMODE_3D:
            {
               gl.glEnable(GL.GL_DEPTH_TEST);
               gl.glViewport(0, 0, WindowWidth, WindowHeight);
               gl.glMatrixMode( GL.GL_PROJECTION );
               gl.glLoadIdentity();
               gluPerspective( 45.0f, (float)WindowWidth / (float)WindowHeight, 0.1f, 1000.0f);
               gl.glMatrixMode( GL.GL_MODELVIEW );
               gl.glLoadIdentity();
               break;
            }
            default:
            {
               break;
            }
         }
         CurrentDrawMode = DrawMode;
      }
   }


And here's the version I ported to C++: (uses constants for window sizing for simplicity in tests)
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  
void setDrawMode(int DrawMode)
{
      if (CurrentDrawMode != DrawMode)
      {
         switch (DrawMode)
         {
            case DRAWMODE_2D:
            {
               glMatrixMode(GL_PROJECTION);
               glLoadIdentity();
               glOrtho(0, 800, 600, 0, 0, 1);
               glDisable(GL_DEPTH_TEST);
               glMatrixMode(GL_MODELVIEW);
               glLoadIdentity();
               // Displacement trick for exact pixelization
              glTranslatef(0.375f, 0.375f, 0.0f);
               break;
            }
            case DRAWMODE_3D:
            {
               glEnable(GL_DEPTH_TEST);
               glViewport(0, 0, 800, 600);
               glMatrixMode( GL_PROJECTION );
               glLoadIdentity();
               gluPerspective( 45.0f, (float)800 / (float)600, 0.1f, 1000.0f);
               glMatrixMode( GL_MODELVIEW );
               glLoadIdentity();
               break;
            }
            default:
            {
               break;
            }
         }
         CurrentDrawMode = DrawMode;
      }
}


In the interest of saving people reading, I included only the function to show basically what I'm doing, however if anyone wants the full cpde or whatever, it's not too long and doesn't do much so I'd be willing to share it.

So basically, what I'm trying to ask is: why does this code function as expected in java but not in C++. I examined further strange behavior upon trying to do the same matrix transforms... when i tried to just push/pop matrixes from the matrix stack (in C++) instead of loading identities over and over (like the java code does), it works... this is driving me crazy as to my knowledge, this should result in exactly the same matrixes being formed, but it seems it doesn't function as expected? I'm not sure anymore...

I now resorted to using the push/pop-ing of matrixes in C++ as a solution to achieve the effect I want (seeing is it's probably faster as well), however just for my own knowledge I would really like to know why this doesn't work although it (theoretically?) should... maybe JOGL does something strange here?
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (32 views)
2014-04-15 18:08:23

BurntPizza (29 views)
2014-04-15 03:46:01

UprightPath (44 views)
2014-04-14 17:39:50

UprightPath (27 views)
2014-04-14 17:35:47

Porlus (44 views)
2014-04-14 15:48:38

tom_mai78101 (65 views)
2014-04-10 04:04:31

BurntPizza (125 views)
2014-04-08 23:06:04

tom_mai78101 (225 views)
2014-04-05 13:34:39

trollwarrior1 (190 views)
2014-04-04 12:06:45

CJLetsGame (198 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org 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‑gaming.org
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!