Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
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  Game Development / Performance Tuning / Re: C-like contiguous arrays on: 2004-05-12 00:47:52
Could we just say, "we want C# like structs?"

That way, understanding the RFE may be easier for the Sun engineers.

I mean, probably, I would _never_ trust a M$ product for my cross-platform needs.  However, if Sun does it for Java, I think it would be very useful.
2  Game Development / Performance Tuning / Re: C-like contiguous arrays on: 2004-05-10 21:53:49
Quote


I read almost all comments regarding this RFE.  I'm not sure where there is more discussion.

I'd appreciate clarification of this point:

1.  Do "child" structures point to the Buffer Object; or only the top parent structure (instances) point back to the BufferObject?

2.  Are all of these structures garbage collected?

3.  Are all structures "passed by reference?"

It seems that the answers are yes.  If so, then is this still compact enough in memory, when we consider the overhead of really small structures?  Or, is the point of the RFE, just to avoid (per structure) new() overhead?  (I can see the RFE achieving this point.)

If auto-garbage-collected, then what happens to the empty memory slot?

I'm a bit rusty on the details.

Thank you.
3  Game Development / Performance Tuning / Re: C-like contiguous arrays on: 2004-05-08 20:25:47
Arrrrgg!  I don't know what happened, but for some reason I've stopped being notified for activity on this thread.

I'm really glad I checked manually.

Quote
Out of interest, why? It almost sounds like
you're trying to directly port a C memory pool, when a proper OO
object pool would work just as well (if not better). Unless you really
are doing something freaky that is.


Dear Orangy Tang,

The issue is RAM blowup (and cache discontinuity??)

My algorithms may certainly be improvable.  However, I don't think
that what I'm doing, would be unreasonable in C(resource-wise.)

Our last discussion(another thread,) surely helps a lot.

(I'm not trying to port a C program, quite the contrary: I'm
considering porting existing (and so-so working) Java code into
JNI/C.)

If you like to know, it's a terrain rendering algorithm.  I got the idea from:

http://www.flipcode.com/tutorials/geomipmaps.pdf

(Just glanced at it;  no patience to read the details fully.)


The quad tree, is probably a major cause of the RAM blowup.
-----------------------------------------------


The general question about Java (in the long run, and my specific
problem aside) is this:

Suppose you have many nested objects:

class Quad {
     short [] x_range = new short[2]; // small array; overhead
     short [] y_range = new short[2]; // small array; overhead
     QuadNode [][] children;          // small array(s); overhead

     // more small stuff; overhead
};

Moreover, you must new() everything. In C, I use large array;
malloc overhead =~ 0.

So, what is the right way to do this in Java?

If I'm being freaky, let me know please.

Regards, Reza.


PS:  

I _will_ look at the canyon demo's source code.  Ken pointed that out,
on the JOGL thread, and the demo runs fast :-)

Looking forward to it.
4  Game Development / Performance Tuning / Re: C-like contiguous arrays on: 2004-05-08 10:22:39
Thanks Tom.  This is very useful.

Is there any way to do:

1  
arbitrary_object.set_to(nio_buffer, index);


In C we can just say

1  
s = malloc(sizeof(s) * 10);


and that way, it is very easy to give structure to the buffer, and work with it.

What is the best solution for this in Java?

Really appreciate your help.
5  Game Development / Performance Tuning / C-like contiguous arrays on: 2004-05-07 22:35:01
Hi everyone,

I need C-like, RAM/Cache-contiguous, arrays, as in:

malloc(sizeof(struct s)  *  <very_big_number>);

Is it correct that for this, I must go to JNI?  Is there any other way, that is relatively clean?  I suppose using a StringBuffer might be hackish and slow?

Thanks so much for any insight.
6  Java Game APIs & Engines / JOGL Development / Re: JOGL too slow on: 2004-05-07 22:13:05
Quote

Check out the Wiki for a breif overview, and grab yourself a copy of the Red book which covers them somewhere in there.


/me needs to find something to do other than crappy MPI work  Cry


You guys have been a great help.  
Thanks everyone.  
Thanks Orangy Tang.  Please don't cry :-)

Now I just have to ask the Java performance forum if there is a good way to do

malloc(sizeof(struct s)  *  <very_big_number>)

that is as efficient as C(in RAM and CPU cache.)

For now this is the last burning question in my mind; I suppose :-)
7  Java Game APIs & Engines / JOGL Development / Re: JOGL too slow on: 2004-05-07 19:41:43
Quote

Vertex arrays (or their bigger brothers, VBO's) are perfectly capable of including vertex colour, normal, etc. data as well as positions.


Hmm...  That is not clear from the OpenGL reference page:
http://www.mevis.de/~uwe/opengl/glVertex.html

It only says the current color is applied, so I must still set it when it changes.  That is, using an independent glColor3f() call through JNI.

What am I missing?  Is this reference page too old?  Or am I misreading it?
8  Java Game APIs & Engines / JOGL Development / Re: JOGL too slow on: 2004-05-07 19:26:08
I suppose I could arange things to sort vertices by color.  

But what if I have blending requirements down the line.  Things would have to be sorted, in the frustum back-to-front order, as _well_ as by color.  That might get anywhere from complicated, to inefficient(again), given the data set.
9  Java Game APIs & Engines / JOGL Development / Re: JOGL too slow on: 2004-05-07 19:05:54
Thanks for replying.

I know things about my data that display lists don't.  So I can store the data much more efficiently, than a display list probably could.

The tip about vertex arrays is useful to my code, but very limited: vertices are regularly interrupted by glColor().

Triangle strips or fans are also on the menu, where appropriate.

However, I don't really think any of these improvements are going to make JNI overhead fully negligible.  Because of the limitations I described.

Any other tips about OpenGL efficiency might be news to me, and useful.

Thanks again.
10  Game Development / Performance Tuning / JOGL too slow on: 2004-05-07 18:00:11
Sorry, I already posted this in several places.  

Would you please look at it also?

http://
http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=lNCmc.372223%24Pk3.90020%40pd7tw1no


http://
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1083955987


Thanks so much.
11  Java Game APIs & Engines / JOGL Development / Re: camera transformation matrix on: 2004-05-07 17:44:36
This has been tested and works.

Remember, a "black" screen could mean you got your coloring parameters wrong.  That has bit me. Don't let it bite you!

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  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
152  
153  
154  
155  
156  
157  
158  
159  
160  
161  
162  
163  
164  
165  
166  
167  
168  
169  
class Camera {
    public _3dpointd x,y,z,p; // orientation & position
   float shutter_angle;
   
    public Camera() {
      x=new _3dpointd(1,0,0);
      y=new _3dpointd(0,1,0);
      z=new _3dpointd(0,0,1);
      p=new _3dpointd(0,0,0);
      shutter_angle = 45;
    }

    Camera(Camera c) {
      x = new _3dpointd(c.x);
      y = new _3dpointd(c.y);
      z = new _3dpointd(c.z);
      p = new _3dpointd(c.p);
      shutter_angle = c.shutter_angle;
    }

    void print() {
      System.out.print("camera position: ");
      System.out.print(shutter_angle + " ");
      x.print();
      System.out.print("  ");
      y.print();
      System.out.print("  ");
      z.print();
      System.out.print("  ");
      p.print();
      System.out.println("");
    }
   
    void start_viewing(GL gl, GLU glu, Viewport v) {
      if(false) {
          gl.glViewport( 0, 0, v.w, v.h);
          gl.glMatrixMode( GL.GL_PROJECTION );  
          gl.glLoadIdentity();
          glu.gluPerspective(45.0f, (float)v.w / (float)v.h, 10f, 10000.0f);
          gl.glTranslatef(0,0,-400);
          gl.glMatrixMode(GL.GL_MODELVIEW);
          return;
      }
     
      gl.glViewport( 0, 0, v.w, v.h );
      gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glLoadIdentity();
      glu.gluPerspective(shutter_angle, (float)v.w / (float)v.h, 0.1f, 1000.0f);
      GLUtil.print_errors("pers", gl, glu);
      gl.glRotatef(180, 0, 1, 0);
      double [] orientation = {x.x,x.y,x.z,0,
                         y.x,y.y,y.z,0,
                         z.x,z.y,z.z,0,
                         0,0,0,1};
      Matrix o = new Matrix(orientation, 4);
      Matrix oi = o.inverse();
      double [] dd = new double[16];
      int k = 0;
      for(int j=0; j < 4; ++j) //notice j is first: we want the columns
         for(int i=0; i < 4; ++i) {
            dd[k++] = oi.getArray()[i][j];
            //System.out.println(k+" "+i+" "+j+" "+dd[k-1]);
         }
      if(k != 16)
          throw new RuntimeException("bad camera");
      gl.glMultMatrixd(dd);
      //System.out.println(p.x+" "+p.y+" "+p.z);
     gl.glTranslatef(-(float)p.x,-(float)p.y,-(float)p.z);
      gl.glMatrixMode( GL.GL_MODELVIEW );  
      GLUtil.print_errors("start_viewing",gl,glu);
    }

    float distance(float x, float y, float z) {
      double
          x2 = (x-p.x),
          y2 = (y-p.y),
          z2 = (z-p.z);
      x2 *= x2;
      y2 *= y2;
      z2 *= z2;
      return (float)Math.sqrt(x2 + y2 + z2);
    }

    void rotatex(float angle) {
      rotate(y,z,(double)angle);
    }
    void rotate_absolute_z(float degrees) {
      double angle = Math.toRadians(degrees);
      _3dpointd [] p = {x,y,z};
      double [] d = {Math.cos(angle), Math.sin(angle), 0,
                   - Math.sin(angle), Math.cos(angle), 0,
                   0, 0, 1};
      Matrix rot = new Matrix(d, 3);
      for(int i=0;i<3;++i) {
          double [] parray = {p[i].x, p[i].y, p[i].z};
          Matrix pm = new Matrix(parray, 3);
          Matrix prot = rot.times(pm);
          double [] protvalues = prot.getColumnPackedCopy();
          p[i].set(new _3dpointd(protvalues[0], protvalues[1], protvalues[2]));
      }
    }
   
    void rotatey(float angle) {
      rotate(z,x,(double)angle);
    }
    void rotatez(float angle) {
      rotate(x,y,(double)angle);
    }
    void rotate(_3dpointd s, _3dpointd t, double angle) {
      double a = Math.toRadians(angle);
      _3dpointd ss = s.mul(Math.cos(a)).add(t.mul(Math.sin(a)));
      _3dpointd tt = t.mul(Math.cos(a)).add(s.mul(-Math.sin(a)));
      s.set(ss);
      t.set(tt);
    }
    void orientzy(_3dpointf zimage, _3dpointf yimage) {
      _3dpointf zz = zimage.normalized();
      _3dpointf yy = yimage.normalized();
      _3dpointf xx = yy.unoriented_cross(zz).normalized();
      z= new _3dpointd(zz.x, zz.y, zz.z);
      y= new _3dpointd(yy.x, yy.y, yy.z);
      x= new _3dpointd(xx.x, xx.y, xx.z);
    }

    void move2(_3dpointf _p) {
      p = new _3dpointd(_p);
    }
    void move_horizontal(float d) {
      _3dpointd move = x.unoriented_cross(new _3dpointd(0,0,1)).normalized();
      if(Math.abs(move.z) > 0.1) {
          System.out.println("bad z for horizontal move");
          System.exit(1);
      }
      p = p.add(move.mul(d));
    }
    void movex(float d) {
      p = p.add(x.mul(d));
    }
    void movey(float d) {
      p = p.add(y.mul(d));
    }
    void movez(float d) {
      p = p.add(z.mul(d));
    }
    void move_absolute_z(float d) {
      p = p.add(new _3dpointd(0,0,1).mul(d));
    }
    void set_shutter(float angle) {
      shutter_angle = angle;
    }
    void change_shutter(float angle) {
      shutter_angle += angle;
      if(shutter_angle > 45)
          shutter_angle = 45;
      if(shutter_angle < 1)
          shutter_angle = 1;
    }
};

class Viewport {
    int x,y,w,h, size;
    Viewport(int xx, int yy, int ww, int hh) {
      x=xx;
      y=yy;
      w=ww;
      h=hh;
      size = Math.max(w, h);
    }
}
12  Java Game APIs & Engines / JOGL Development / Re: camera transformation matrix on: 2004-05-07 17:28:00
That can get real messy, right??

I will add my code.  Feel free to modify and use :-)

It uses the Jama matrix package.

Camera is represented by 4 vectors: x,y,z,p.

x,y,z give orientation of camera inside world.  All unit length and perpendicular.  determinant(x,y,z) == 1.

p : position inside the world.
z :  always points away from your eyes; (you look that way)
y : points out of your head.
x : well, that's the only one left!

orientzy() is used to set z, and y.  Just point z at the thing you must look at.  Set p separately.

Code follows.
13  Java Game APIs & Engines / JOGL Development / JOGL too slow on: 2004-05-07 16:53:07
On this thread:
http:// http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=lNCmc.372223%24Pk3.90020%40pd7tw1no

Someone suggested that I post my message to this forum.

So, here it is:
--------------------------------------------------------------------

Hi guys,

I've written an application that makes many OpenGL calls for rendering a scene.  (The calls are glColor3f and glVertex3f, mostly.)

when my loops make about 1,400,000 additional calls to glColor3f, render time goes from 50 Milliseconds to 300 Milliseconds!

Straight c (gcc/linux) can do 1,400,000 glColor3f's, 20 times as fast (same hardware.)

This suggests the jogl->OpenGL bridge is very slow.

I could be wrong, but I think not.
------------------------------------------------

My question is not JOGL specific:

Can you briefly explain how the Java->native bridge is implemented?

How that explains the JOGL slowness?

And if it can be made faster?


I chose Java for it's seamless platform independence, and fairly decent JIT, but Java->OpenGL speed is crucial.

I am presently looking into wxWindows and wxGLCanvas as a potential alternative.

I really appreciate any help that makes my decision easier.


PS:

I won't shy away from reading the JOGL source code, if you tell me how it works, and what to do.
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.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (20 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!