Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (549)
Games in Android Showcase (137)
games submitted by our members
Games in WIP (594)
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 3 4
1  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-26 13:28:02
Hi,

I'm not on the "AA" feature (that seems to be another complete topic  persecutioncomplex)
But the discard() is not mandatory if you play with glBlend function by example if you set an equivalent than AlphaComposite.SRC ?

2  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-21 21:10:47
i'm completing the fragment shader from advices.

The result is here :

The shader look's like

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  
#version 330

varying vec2 v_boundingBoxPosition;

void checkFragment() {

   /**
    * Ellipse equation =  (x/a)2 + (y/b)2 = 1
    *     a = horizontal radius
    *     b = vertical   radius
    *
    *
    * Bounding box is a vec2 that correponds to this rectangle coordinate
    *        (-1,-1)            (+1,-1)
    *                  (0,0)
    *        (-1,+1)            (+1,+1)
    *
    *  The varying result in this fragment shader correspond to [ (x/a) , (y/b) ]
    *  We can perform a dot() for doing the pow(2)
    */

    float d  = dot( v_boundingBoxPosition , v_boundingBoxPosition );
    if( d > 1 ) {
       discard;
    }    
}


The fragment result looks much nicer.

But in term of performance, i bench this for 600 ellipses per frame (i use large buffer for prevent implicit flush while pushing datas):
  - Bresenham : 10 ms for pushing datas on the batcher. 6.8 ms for flush it
  - Shader      : 0.1 ms for pushing datas on the batcher. 3.5ms for flush it.

In both of them i take the worst case but in average it's most:
  - Bresenham : 10 ms for pushing datas on the batcher. 6 ms for flush it.
  - Shader      : 0.1 ms for pushing datas on the batcher. 2.8 ms for flush it.

I must check if i have not some performance issues in the push data method. but in all cases, the flush is also faster in the shader version.

So, ATM the shader way seems the way to go...


EDIT: The bresenham algorithm push 6 floats per vertices (color + 2d position) that mean 24 bytes per vertices
The ellipse drawn use 584 vertices that means 14 016 bytes for an ellipse (14 Ko)
When i draw 600 ellipses, it's come up to 8 409 600 bytes (8.02 Mo).
the FloatBuffer.put(...) take me the 50% of total time of the push sequence. It seems strange that it's longer to fill it in RAM than sending it to the GPU...

EDIT : I updated the fragment shader, i don't use anymore an uniform. the varying vec2 is ready to use and minimize computation inside the fragment shader like pitbuller said.
3  Java Game APIs & Engines / Engines, Libraries and Tools / GLFW 3.1 is out on: 2015-01-20 13:09:14
Hi,

I just seen that GLFW 3.1 is now released since 18/01/2015

We can see the changelog http://www.glfw.org/changelog.html
I know LWJGL include an hybrid version but i hope it will include this one soon !! I found GLFW a great library.

Séb.



4  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-18 23:12:35
I implemented the Bresenham algorithm for drawing and filling ellipse : http://www.java-gaming.org/topics/fill-ellipse-from-a-fragment-shader/35411/msg/335293/view.html#msg335293
Il will continue on the fragment shader version with advises of other members.
5  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-18 19:26:16
If you want to do this in a fragment shader, wouldn't you be better using texture coordinates rather than gl_FragCoord and your uniforms?


The easiest way to do this in a fragment shader is to NOT rely on gl_FragCoord. If you rotate the coordinates, the result stays the same. A better idea is to assign "texture" coordinates to each corner and have the shader rely on those instead, since those coordinates will be and interpolated correctly after rotation.

Thanks all, it's the right way with the fragment shader. I don't found it alone.... damn Tongue
It's not yet naturals for me to write shaders and understood all subtles with theses !!!

The most hard things with openGL is the debugging !! .
When it don't work as you wish, it's a reallly a painfull to find the cause.

Thanks all, for your advices, but il will stick with the Bresenham implementation.
6  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-18 16:16:56
I give it a try to the Bresenham algorithm

Some result here (i know there is no reason to be so enthousiast Tongue)

1  
2  
3  
      
g2d.setColor( Color.YELLOW );
g2d.fillOval( 400 ,  50 ,  200 ,  100 );







1  
2  
3  
4  
5  
      
g2d.setColor( Color.YELLOW );
g2d.transform( AffineTransform.identity().rotate( 0.2f , 400 + 100 , 50 + 50 ) );
g2d.fillOval( 400 ,  50 ,  200 ,  100 );
g2d.setTransform( null );






 
1  
2  
3  
4  
5  
      
g2d.setColor( Color.YELLOW );
g2d.transform( AffineTransform.identity().rotate( 0.2f , 400 + 100 , 50 + 50 ) );
g2d.drawOval( 400 ,  50 ,  200 ,  100 );
g2d.setTransform( null );






1  
2  
3  
4  
g2d.setPaint( texture ); // set a Texture instead of a color to fill it
g2d.transform( AffineTransform.identity().rotate( 0.2f , 400 + 100 , 50 + 50 ) );
g2d.fillOval( 400 ,  50 ,  200 ,  100 );
g2d.setTransform( null );




Here the implementation using Breshenham.
I just have a difficulty to pre check buffers size of my batcher. So ATM i must check a BufferOverFlowException that is not quite fun...

I don't do any benchmarks for now but i find this solution much functionnal than the fragment shader (but less fun ^^)

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  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
/**
     *  https://sites.google.com/site/ruslancray/lab/projects/bresenhamscircleellipsedrawingalgorithm/bresenham-s-circle-ellipse-drawing-algorithm
     */

    private void paintOvalBresenham(float x0, float y0, float rx, float ry , boolean fill , Graphics2DAttributes g2dAttributes , boolean overflowed ) {
       /**
        * Basics primitives perform pre check on all buffers of this batcher before pushing datas like:
        *      // 1 primitive 4 vertices and 6 indices.
        *      checkBufferSize( 1 , 4 , 6 );  
        *    
        * This implementation is quite more complicated and i can't determine how much vertices and indices i will use.
        * So, i don't do any pre check but if i have a buffer overflow, i discard this primitive, flush() and restart this paint process
        *
        * I can assume at least to have 1 primitive enought
        */

       checkBufferSize( 1  , 0 , 0 );
       
       /**
        * Get the primitive
        */

       Primitive p = getPrimitive( ( fill ? GL11.GL_TRIANGLE_FAN : GL11.GL_LINE_LOOP ) , g2dAttributes );
       
      float a2  = rx * rx;
       float b2  = ry * ry;
       float fa2 = 4 * a2, fb2 = 4 * b2;
       
       /** Bresenham algorithm compute 2 octants and determine 6 others by symetric computations
        *    - Theses 2 first octants are done without the use of cos/sin operations but use (* +)
        *    - Theses 6 others octants are done only with translation ( + or - operations)
        *
        *  The difficulty is able to order vertices in the "indices buffer" sinces points are not computed sequentially...
        *  
        *  Which is the order of points computation:
        *    - Each octant is numbered from 1 to 8. We compute octants 1,2,3,4 (multiplexed) and after we compute octants 5,6,7,8 (multiplexed)
        *    - Some octants as computed in a clockwise and some others in counterclockwise
        *    - The drawing process draw octants in this order 1 , 5 , 7 , 3 , 4 , 8 , 6 , 2 in the counterclockwise.
        *    - Some octant are clockwise and some others in counterclockwise by nature of symetric computation used.
        *               - Octant 1 : counterclockwise
        *               - Octant 5 : clockwise
        *               - Octant 7 : counterclockwise
        *               - Octant 3 : clockwise
        *               - Octant 4 : counterclockwise
        *               - Octant 8 : clockwise
        *               - Octant 6 : counterclockwise
        *               - Octant 2 : clockwise
        *                
        *  
        *   - Octants topology:
        *  
        *                   ***************
        *              *****   \ 4 | 3  /  *****
        *            **    8     \ |  /    7    **
        *          **             \|/             **
        *          *---------------X---------------*
        *          **      6     / | \     5      **
        *            **         /  |  \         **
        *              *****  /  2 | 1  \  *****
        *                   ***************
        */

       int sizeOctants1234 = 0;
       int sizeOctants5678 = 0;
       
       try {
          /* first half */
          float x, y, sigma;  
          for (x = 0, y = ry, sigma = 2*b2+a2*(1-2*ry); b2*x <= a2*y; x++)
          {
             p.pushVertex( x0 + x , y0 + y ); // Octant 1
             p.pushVertex( x0 - x , y0 + y ); // Octant 2
             p.pushVertex( x0 + x , y0 - y ); // Octant 3
             p.pushVertex( x0 - x , y0 - y ); // Octant 4
             sizeOctants1234++;
             
              if (sigma >= 0)
              {
                  sigma += fa2 * (1 - y);
                  y--;
              }
              sigma += b2 * ((4 * x) + 6);
          }
   
          /* second half */
          for (x = rx, y = 0, sigma = 2*a2+b2*(1-2*rx); a2*y <= b2*x; y++)
          {
             p.pushVertex( x0 + x , y0 + y ); // Octant 5
             p.pushVertex( x0 - x , y0 + y ); // Octant 6
             p.pushVertex( x0 + x , y0 - y ); // Octant 7
             p.pushVertex( x0 - x , y0 - y ); // OCtant 8
             sizeOctants5678++;
   
             if (sigma >= 0)
              {
                  sigma += fb2 * (1 - x);
                  x--;
              }
              sigma += a2 * ((4 * y) + 6);
          }
       }
       catch( BufferOverflowException e ) {
          /** Ouch, we have not enough place for put all vertices, we flush this batcher without the primitive
           */

          if( overflowed ) throw new IllegalStateException("OpenGLSupport with too small buffer size for this method");
          primitiveCount--; // discard this primitive
          flush();
          paintOvalBresenham(x0, y0, rx, ry, fill, g2dAttributes , true);
          return;
       }
       
       /** Now we put all vertices, we know how many indices we must have
        *  We can do a pre check in order to avoid the BufferOverflowException...
        */

       if( ! checkBufferSize( 0 , 0 , ( 4 * sizeOctants1234 ) + ( 4 * sizeOctants5678 )  , false ) ) {
          if( overflowed ) throw new IllegalStateException("OpenGLSupport with too small buffer size for this method");
          primitiveCount--; // discard this primitive
          flush();
          paintOvalBresenham(x0, y0, rx, ry, fill, g2dAttributes , true);
          return;
       }
       
       /** Push indices
        */

       IntBuffer buffer = indicesBuffer.getBuffer();
       
       final int strideOctants1234 = 4 * sizeOctants1234;
       final int strideOctants5678 = 4 * sizeOctants5678;
       
       /**
        * Computing where start each octants
        */

       final int offsetOctant1 = 0;                                                      // forward
       final int offsetOctant4 = 3;                                                 // forward
       final int offsetOctant6 = strideOctants1234 + 1;                              // forward
       final int offsetOctant7 = strideOctants1234 + 2;                              // forward
       final int offsetOctant5 = strideOctants1234 + strideOctants5678 - 4;              // backward
       final int offsetOctant3 = strideOctants1234 - 2;                             // backward
       final int offsetOctant8 = strideOctants1234 + strideOctants5678 - 1;             // backward
       final int offsetOctant2 = strideOctants1234 - 3;                          // backward
       
       // octant 1
       int offset = offsetOctant1;
       int stride = 4;
       for(int i = 0 ; i < strideOctants1234 ; i += stride ) {
          buffer.put( offset + i );
       }
       // octant 5
       offset = offsetOctant5;
       for(int i = 0 ; i < strideOctants5678 ; i += stride ) {
          buffer.put( offset - i );
       }
       // octant 7
       offset = offsetOctant7;
       for(int i = 0 ; i < strideOctants5678 ; i += stride ) {
          buffer.put( offset + i );
       }
       // octant 3
       offset = offsetOctant3;
       for(int i = 0 ; i < strideOctants1234 ; i += stride ) {
          buffer.put( offset - i );
       }
       // octant 4
       offset = offsetOctant4;
       for(int i = 0 ; i < strideOctants1234 ; i += stride ) {
          buffer.put( offset + i );
       }
       // octant 8
       offset = offsetOctant8;
       for(int i = 0 ; i < strideOctants5678 ; i += stride ) {
          buffer.put( offset - i );
       }
       // octant 6
       offset = offsetOctant6;
       for(int i = 0 ; i < strideOctants5678 ; i += stride ) {
          buffer.put( offset + i );
       }
       // octant 2
       offset = offsetOctant2;
       for(int i = 0 ; i < strideOctants1234 ; i += stride ) {
          buffer.put( offset - i );
       }
       p.end();
   }


Sébastien.
7  Java Game APIs & Engines / OpenGL Development / Re: Fill Ellipse from a fragment shader on: 2015-01-18 13:55:36
When using the "vertices" solution, the main problem is to determine how many vertices we should use (depending on the resolution and size of the ellipse).
Using the fragment technics, it's openGL that determine the "size" of the fragment and you haven't to worry about.

Another technic is to use by example the Bresenham's algorithm and you don't have to worry about determining how many vertices you need. but:
   -  when you push only points, it's quite ok, when you want lines, you need to set vertices in the correct order that is a pain with such algorithm.
   -  using the plain old trigo algo is enough but i don't like to compute cos/sin for every points.

i give a try to the bresenham's and will make some benchs
8  Java Game APIs & Engines / OpenGL Development / Fill Ellipse from a fragment shader on: 2015-01-18 12:40:09
I always rewriting some old 2D stuffs using old OpenGL glBegin/glEnd for use modern openGL statements.

I'm writing a fillOval implementation using a fragment shader instead of pushing a lot of vertices for drawing my ellipse.

The idea is to paint a classic rectangle (2 triangles composition) and use a fragment shader that discard all fragment that is not inside the ellipse.

As is, i push on OpenGL in order to draw my ellipse :
  - 4 vertices
  - 6 indices 
  - 2 "vec2" uniforms
       - the center of the ellipse
       - the radius of the ellipse

my fragment shader (responsible to discard fragments) looks like this one:

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

uniform vec2 u_centerOval;
uniform vec2 u_radiusOval;

layout(origin_upper_left) in vec4 gl_FragCoord;

out vec4 outputColor;

void checkFragment() {
   /**
    * Ellipse equation =  (x/a)2 + (y/b)2 = 1
    *     a = horizontal radius
    *     b = vertical   radius
    */

   
    float e1 =  ( gl_FragCoord.x - u_centerOval.x ) / ( u_radiusOval.x );
    float e2 =  ( gl_FragCoord.y - u_centerOval.y ) / ( u_radiusOval.y );
   
    float d  = (e1 * e1) + (e2 * e2);
    if( d > 1 ) {
       outputColor = vec4(1.0 , 0.0 , 0.0 , 1.0 ); // discard;
    }    
}



So, it works not so bad. I have an "aliasing" issue, but i will see this later.

But now, if i paint with this statement:
1  
2  
  g2d.setColor( Color.YELLOW );
  g2d.fillOval( 400 ,  50 ,  200 ,  100 );


i obtain this

But if i apply an affine transformation like this:

1  
2  
3  
4  
 g2d.transform( AffineTransform.identity().rotate( 0.2f , 400 + 100 , 50 + 50 ) );
 g2d.setColor( Color.YELLOW );
 g2d.fillOval( 400 ,  50 ,  200 ,  100 );
g2d.setTransform( null );


i obtain this

That's quite normal since my fragment shader don't take in account my affine transform.
It's only my vertex shader that use it (and it rotate the rectangle as well).

i should inverse my transformation on gl_FragCoord in order to compute the ellipse equation ?
It's a pain, all matrices are not invertible. I can pass it as an uniform.

Have you a better idea ?
At this point, maybe this technical approach is completely crazy but at first  thinking i found it quite fun.

Best regards,
Sébastien.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-17 23:11:17
What i did:
 - Removed deprecated openGL functions like glMatrix, glOrtho.... and use instead a vertex shader.

What i got:
 - A black screen instead of what i would to render  Huh

So it's time to go bed  Angry

I won over the black screen and retrieve what i would to render  Grin
I had 2 problems:
  - My orthographic matrix was badly computed and i provided to the vertex shader a completely crazy matrix.
  - I used the asFloatBuffer() from a ByteBuffer but i don't seen that position() and limit() was independant from theses both buffers.. so i pass to attribPointer completely wrong datas.

With theses 2 mistakes, yesterday, i was far to see somethings to my screen  Roll Eyes
10  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-16 23:32:51
What i did:
 - Removed deprecated openGL functions like glMatrix, glOrtho.... and use instead a vertex shader.

What i got:
 - A black screen instead of what i would to render  Huh

So it's time to go bed  Angry
11  Discussions / General Discussions / Re: New rules regarding Game Engine topics on: 2015-01-14 16:25:03
I'd even say that, if someone really wants to make something more generic/flexible, it'd probably be better to develop a game with modding capabilities, rather than a general use engine.

I think we can't provide theses statements with this simplicity when most of amateur dev works in their free time in stuff they "like" whatever it will be usefull or not.
So if your goal is to built a game and won money with it, maybe you should'nt go into the way of writing an engine (or equivalent).
But as opposed, if you want learn, have fun and that's fun come with such tasks !! why not !!

I know that peoples here don't really like or approve guys that work on theses own stuffs but for me it's not a bad things if it has not a negative impact (by exemple on a team or budget, ...)
Personnaly, i can work on a library even if i have no plan to use it because it's fun for me !!!

Now, i agree that we can have some variable "quality level" of theses homemade engines.
But if a day i post what i done as framework (2d only), it will not for providing the "next level tools" but mainly for have feedback about it and improve it.
I assume that this forum is for such purpose !!!

Séb.





12  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-13 22:02:37
I'm a newbie in shader since i just start to play with theses, but i'm a little surprised from what we read here !!

I bieleved we can attach more than one shaders from the same type on a program !!!


We can read on the glAttach this documentation:

All operations that can be performed on a shader object are valid whether or not the shader object is attached to a program object. It is permissible to
attach a shader object to a program object before source code has been loaded into the shader object or before the shader object has been compiled. It
is permissible to attach multiple shader objects of the same type because each may contain a portion of the complete shader
. It is also permissible to
attach a shader object to more than one program object. If a shader object is deleted while it is attached to a program object, it will be flagged for
deletion, and deletion will not occur until glDetachShader is called to detach it from all program objects to which it is attached.


After some research, we can have more than one shaders of the same type but only one "main" method ? is it right ?



13  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-11 13:15:52
So, i reply here for giving feedback of theses 3 past days.

I rewrote my batcher with vertex array instead of VBO.

I used IntBuffer for indices (since it's more simple than ByteBuffer) for glDrawElements but LWJGL don't have method facilities for use an IntBuffer and providing the number of vertices to fetch except by consumming all datas from the buffer. But my indices buffer is filled with all primitives that i had to draw by multiple calls.

I had to call the unchecked version :
1  
   GL11.nglDrawElements( p.type , p.indicesCount , GL11.GL_UNSIGNED_INT, MemoryUtil.memAddress( indicesBuffer ) );


Now, i have perform a 2d texturing from an atlas texture. I had done all shader/program stuff in order to activate the fragment shader that will do the texturing from an atlas texture.

I have two technical approachs for handling shaders
  - only one program but i attach/detach shaders when needed
  - One program for each shaders topology.

Both of them can be achieve with the same kind of API where i just enable/disable shaders and back-end choose/generate the appropriate program or alter it (depends of the solution).

What is the best practice ?

At this time, i will have 2 shaders (one for texturing from atlas and a second for multiples stop gradiant paint)

Best regards,
Sébastien.






14  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-07 21:03:02
Hi,

Thanks for your detailed answer.

So, ok, fixed pipeline and deferred rendering are two differents things. i deep into deferred rendering with VBO. but for dynamic pipeline it's the use of shaders (vertex, fragment, geometry).

while  reading you, you are seems to say that VBO and shaders are not suitable together and you must go to VAs if i want to use shaders (that i will soon for doing repeated atlases subregion) ?

Anothers small questions

You say than glTranslatef(), glRotatef() are fixed pipeline stuff, so that means we should avoid theses ? At this time i don't use theses but i use some matrix mode when i need to apply an affine transform (that remains the same than glTranslatef() or glRotatef() but provide more flexibilty).

When reading your example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
//With VAs
//Init
FloatBuffer fb = BufferUtils.createFloatBuffer(3 * (2 + 3)); //3 vertices with 2 position floats and 3 colour floats.
fb.put(new float[] {...}); Imagine this is the data for a triangle with XYRGB interleaving.
//And then we DON'T create a VBO for the data.

...
//Render (Assuming you've enabled all the relevant stuff)
fb.position(0); //Move the buffer's position to the vertex offset.
glVertexPointer(2, 20 /*(2+3)*4*/, fb); //Notice that we don't pass the "type" parameter in LWJGL becuase it will infer that these are floats since it is a FloatBuffer
fb.position(2); //Then we move the buffer's position to the colour offset.
glColorPointer(2,20 /*(2+3)*4*/, fb);
glDrawElements(...); //You know this bit



How work the buffer "fb" communication between the cpu and the gpu. You pass it to 2 calls (glVertexPointer and glColorPointer). It have 2 copy into the GPU or the OpenGL API retains that is the same buffer instance and communicate it only on time to the GPU at the end ?

I will try to adapt my code to VAs instead of VBO.

Sébastien.
15  Discussions / General Discussions / Re: New rules regarding Game Engine topics on: 2015-01-05 19:00:02
For continue on the kpars response.

A big difference in the picture between a "game post" and a "game engine post" is the lifetime of the project.

A game even if it will jave few updates and patch should change slowly over the time and not so actively while it is published. A static topic page that describe a such project fit well.
A game engine has a lifecycle more dynamic and must have more frequent maintainance since feedbacks and evolution are mades. You can't so efficiently maintain a static forum topic as well for such projects.

All "game engine" topic without any activity from a while could be moved on the "Archive" forum as Riven do.
In the counterparts, active ones (if it's still have one ?) should remains or moved somewhere else ?

So, all that for said, that a better approach for theses projects is to build an index-directory page that list all of theses projects and provide url to point on the official project's site like a "resources page" could do.
It could give a better visibility for such projects and a better resource finder for thoses need it.

it's my 2 cent's that worth what it worth since i push on this forum 0 game and 0 game engine Tongue

Sébastien.
16  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-04 21:27:12
I forgot GL11.glEnable( GL11.GL_TEXTURE_2D ); and searched for 2 hours why my texture was so white....

So, i continued today to review some personnal stuff using old fixed pipeline openGL with more modern version... i have to work on it for some times :-/
17  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-04 20:36:50
So,

I wrote today the drawImage primitive in the same way than drawRect, fillRect and drawLine

I have few remarks or questions:

 1. When drawing the image (2 triangles with texCoords), i must do GL11.glEnable( GL11.GL_TEXTURE_2D ); each time ? i tried to put it as a global intialization but it seems to have side effects on others drawing ops. I tried the global flag since i thinked that the GL11.glEnableClientState( GL11.GL_TEXTURE_COORD_ARRAY ); would be sufficient for enabling/disabling it


 2. For drawing the image with a transparency, i must use a blend "SRC_OVER" function like it:
1  
2  
  GL11.glEnable(GL11.GL_BLEND);
  GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);

    I must call it before drawing my image. It seems to returns onto the old fixed pipeline mechanism ?  Can i improve theses statements ?


 3. It's a generalization of the 2) statements, if i must do a affine transformation, a blend or other similar things, i must call theses glXXXX just before the the glDrawElements() like before ?
     For the affine transformation, what is the best, letting OpenGl do it by calling glLoadMatrix or applying it by software when i push vertices on the buffer ?


 4. i read some stuff about VAs and specifically on the use of glEnableVertexAttribArray and similar stuff but it remains obscur...

I don't updated the code with the "image" supports since it's always a dirty code, i would clean up before posting here for dicuss about it.

Best regards,
Sébastien.
 
18  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-04 09:09:27
Thanks for all replies.

I'm dealing with this snippet code that works for now with samples cases. ( i put the new code as a basis for further discussions )

So, i don't really understood how works glEnableVertexAttribArray and how i can replace glEnableClientState with it...

I'm not really understood your discussions about VBO vs VAs (in fact i not know what is a VA)...

Code updated on the first topic
19  Java Game APIs & Engines / OpenGL Development / modern OpenGL discussion on: 2015-01-03 20:20:00
Hi,

I just reviewed some of my classes using the last LWJGL that now use GLFW instead of it's internal Display class.

Now, i'm review some of my 2D drawing stuff that used the old OpenGL stuff using glBegin / glEnd by a more modern version using VBO, IBO, etc...

But i have some design questions and i must admit that i have some pain to go on the flexible pipeline...


For some test i done this small classe (i skip all window initialization and openGL configuration like modelview, ortho, ....)

i update the code above with the result of discussions on this topic for have the code only 1 time
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  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
181  
182  
183  
184  
185  
186  
187  
188  
189  
190  
191  
192  
193  
194  
195  
196  
197  
198  
199  
200  
201  
202  
203  
204  
205  
206  
207  
208  
209  
210  
211  
212  
213  
214  
215  
216  
217  
218  
219  
220  
221  
222  
223  
224  
225  
226  
227  
228  
229  
230  
231  
232  
233  
234  
235  
236  
237  
238  
239  
240  
241  
242  
243  
244  
245  
246  
247  
248  
249  
250  
251  
252  
253  
254  
255  
256  
257  
258  
259  
260  
261  
262  
263  
264  
265  
266  
267  
268  
269  
270  
271  
272  
273  
274  
275  
276  
277  
278  
279  
280  
281  
282  
283  
284  
285  
286  
287  
288  
289  
290  
291  
292  
293  
294  
295  
296  
297  
298  
299  
300  
301  
302  
303  
304  
305  
306  
307  
308  
309  
310  
311  
312  
313  
314  
315  
316  
317  
318  
319  
320  
321  
322  
323  
324  
325  
326  
327  
328  
329  
330  
331  
332  
333  
334  
335  
/** Draft
 */

public class OpenGLSupport {
   
   /**
    * Maximum bufferized primitives count
    */

   private static final int     PRIMITIVES_SIZE = 512;
   
   /** FLOAT size in bytes (for stride and offset computes)
    */

   private static final int     FLOAT_SIZE      = Float.SIZE / 8;
   
   /** INTEGER size in bytes (for stride and offset computes)
    */

   private static final int     INTEGER_SIZE    = Integer.SIZE / 8;
   
   /**
    * VERTEX Position size in bytes (for stride and offset computes)
    */

   private static final int     VERTEX_SIZE     = FLOAT_SIZE * 2;
   
   /** COLOR size in bytes (for stride and offset computes)
    */

   private static final int     COLOR_SIZE      = FLOAT_SIZE * 4;
   
   /**
    * Maximum vertices buffer size
    */

   private static final int     VERTICES_SIZE   = powerOfTwo( PRIMITIVES_SIZE * ( VERTEX_SIZE + COLOR_SIZE ) * 4 );
   
   /**
    * Maximum indices buffer size
    */

   private static final int     INDICES_SIZE    = powerOfTwo( PRIMITIVES_SIZE * 8  );

   /** OpenGL bind optimizer
    */

   private OpenGLBinder         glBinder        = null;
   
   private Primitive[]          primitives      = new Primitive[ PRIMITIVES_SIZE ];
   private FloatBuffer          verticesBuffer  = BufferUtils.createFloatBuffer( VERTICES_SIZE );
   private IntBuffer            indicesBuffer   = BufferUtils.createIntBuffer( INDICES_SIZE );
                                               
   private int                  primitiveCount  = 0;
                                   
   /** Our VBO and IBOI handles
    */

   private int                  iVBO            = 0;
   private int                  iIBO            = 0;
                               
   /** Color to use
    */

   private Color                color           = Color.WHITE;
   
   public OpenGLSupport( OpenGLBinder binder ) {
      System.out.println("GraphicsOpenGL (primitivesSize=" + PRIMITIVES_SIZE + ", verticesSize=" + VERTICES_SIZE + ", indicesSize=" + INDICES_SIZE );
      this.glBinder = binder;
   }
   
   public void setColor( Color color ) {
      this.color = color;
   }
   
   public void drawRect(float x, float y, float width, float height) {
      // 1 primitive , 4 vertices, 8 indices
      checkBufferSize( 1 , 4 , 8 );
     
      // Get the primitive to draw
      Primitive p = getPrimitive( GL11.GL_LINES );
     
      // push vertices and colors
      p.pushVertex( x         , y          );
      p.pushVertex( x + width , y          );
      p.pushVertex( x + width , y + height );
      p.pushVertex( x         , y + height );
     
      // push indices
      indicesBuffer.put( 0 );
      indicesBuffer.put( 1 );
      indicesBuffer.put( 1 );
      indicesBuffer.put( 2 );
      indicesBuffer.put( 2 );
      indicesBuffer.put( 3 );
      indicesBuffer.put( 3 );
      indicesBuffer.put( 0 );
      p.end();
   }

   public void drawLine(float x1, float y1, float x2, float y2) {
      // 1 primitive , 2 vertices, 2 indices
      checkBufferSize( 1 , 2 , 2 );
     
      // Get the primitive to draw
      Primitive p = getPrimitive( GL11.GL_LINES );
     
      // push vertices and colors
      p.pushVertex( x1 , y1 );
      p.pushVertex( x2 , y2 );
     
      // push indices
      indicesBuffer.put( 0 );
      indicesBuffer.put( 1 );
      p.end();
   }

   public void fillRect(float x, float y, float width, float height) {
      // 1 primitive , 4 vertices, 6 indices
      checkBufferSize( 1 , 4 , 6 );

      // Get the primitive to draw
      Primitive p = getPrimitive( GL11.GL_TRIANGLES );
     
      // push vertices and colors
      p.pushVertex( x          , y          );
      p.pushVertex( x + width  , y          );
      p.pushVertex( x + width  , y + height );
      p.pushVertex( x          , y + height );
     
      // push indices
      indicesBuffer.put( 0 );
      indicesBuffer.put( 1 );
      indicesBuffer.put( 2 );
      indicesBuffer.put( 0 );
      indicesBuffer.put( 2 );
      indicesBuffer.put( 3 );
      p.end();
   }
   
   /** Peek a Primitive object in the primitives buffer and reinit it.
    *  This methode reuse {@link Primitive} instances in order to limit instanciations under the rendering process.
    */

   private Primitive getPrimitive( int primitiveType ) {
      Primitive p = primitives[ primitiveCount ];
      if( p == null ) {
         p = new Primitive();
         primitives[ primitiveCount ] = p;
      }
      primitiveCount++;
     
      p.begin( primitiveType );
      return p;
   }

   public void flush() {
      // flush our buffers
      verticesBuffer.flip();
      indicesBuffer.flip();
     
      // VBO binding
      boolean gen = ( iVBO == 0 );
      {
         if( gen ) {
            iVBO = GL15.glGenBuffers();
         }

         // Bind VBO (only if it's not already the case)
         glBinder.bindVBO( iVBO );
         
         // make a full buffer for be able to perform dynamic size buffer
         if( gen ) {
            FloatBuffer empty = BufferUtils.createFloatBuffer( verticesBuffer.capacity() );
            for(int i = 0 ; i < empty.capacity() ; i++ ) {
               empty.put( 0f );
            }
            empty.flip();
            GL15.glBufferData( GL15.GL_ARRAY_BUFFER, empty , GL15.GL_DYNAMIC_DRAW );
         }
         GL15.glBufferSubData( GL15.GL_ARRAY_BUFFER, 0 , verticesBuffer );
      }
         
       // IBO binding
       gen =  ( iIBO == 0 );
       {
          if( gen ) {
             iIBO = GL15.glGenBuffers();
          }
         
          // Bind IBO (only if it's not already the case)
          glBinder.bindIBO( iIBO );
         
          // make a full buffer for be able to perform dynamic size buffer
          if( gen ) {
             IntBuffer empty = BufferUtils.createIntBuffer( indicesBuffer.capacity() );
             for(int i = 0 ; i < empty.capacity() ; i++ ) {
                empty.put( 0 );
             }
             empty.flip();
             GL15.glBufferData( GL15.GL_ELEMENT_ARRAY_BUFFER, empty , GL15.GL_DYNAMIC_DRAW );
          }
         GL15.glBufferSubData( GL15.GL_ELEMENT_ARRAY_BUFFER, 0 , indicesBuffer );
       }
       
       // Painting
       GL11.glEnableClientState( GL11.GL_VERTEX_ARRAY );
       
       Primitive p = null;
       for(int i = 0 ; i < primitiveCount ; i++ ) {
          p = primitives[i];
         
          if( p.glColorOffset >= 0 ) {
             GL11.glEnableClientState( GL11.GL_COLOR_ARRAY );
             GL11.glColorPointer( 4 , GL11.GL_FLOAT , p.stride , p.glColorOffset );
          }
          GL11.glVertexPointer( 2, GL11.GL_FLOAT, p.stride , p.glVertexOffset );
          GL11.glDrawElements( p.type , p.indicesCount , GL11.GL_UNSIGNED_INT , p.indicesOffset );
         
          if( p.glColorOffset >= 0 ) {
             GL11.glDisableClientState( GL11.GL_COLOR_ARRAY );  
          }
       }
       
       //Disable vertex arrays
       GL11.glDisableClientState( GL11.GL_VERTEX_ARRAY );
       
       // clear the buffer
       verticesBuffer.clear();
       indicesBuffer.clear();
       primitiveCount = 0;
   }
   
   public void dispose() {
      if( iVBO > 0 ) {
         glBinder.unbindVBO( iVBO );
         
         GL15.glDeleteBuffers( iVBO );
         iVBO = 0;
      }
      if( iIBO > 0 ) {
         glBinder.unbindIBO( iIBO );
         
         GL15.glDeleteBuffers( iIBO );
         iIBO = 0;
      }
     
      verticesBuffer.clear();
      indicesBuffer.clear();
      primitiveCount = 0;
   }
   
   /** Check if the need to flush all pending statements before continuing.
    */

   private void checkBufferSize( int primitiveCount , int verticesCount , int indicesCount ) {
      if( this.primitiveCount + primitiveCount >=  PRIMITIVES_SIZE ) {
         flush();
         return;
      }
     
      if( verticesBuffer.position() +  ( verticesCount * ( VERTEX_SIZE + COLOR_SIZE ) ) >= VERTICES_SIZE ) {
         flush();
         return;
      }
     
      if( indicesBuffer.position() + ( indicesCount * INTEGER_SIZE ) >= INDICES_SIZE ) {
         flush();
      }
   }
   
   private class Primitive {
      private int     type;
     
      private int     glVertexOffset;
      private int     glColorOffset;
      private int     stride;
     
      private int     indicesOffset;
      private int     indicesCount;
     
      private void begin( int type ) {
         // init it
         this.type            = type;
         this.glVertexOffset  = -1;
         this.glColorOffset   = -1;
         this.stride          = -1;
         
         this.indicesOffset   = indicesBuffer.position() * INTEGER_SIZE;
         this.indicesCount    = 0;
      }
      private void pushVertex( float x , float y ) {
         int strideStart = verticesBuffer.position() * FLOAT_SIZE;
         
         pushPaintContext();
         
         if( glVertexOffset < 0 ) glVertexOffset = verticesBuffer.position() * FLOAT_SIZE;
         verticesBuffer.put( x );
         verticesBuffer.put( y );
         
         if( stride < 0 ) stride =  ( verticesBuffer.position() * FLOAT_SIZE ) - strideStart;
      }
     
      private void pushPaintContext() {
         if( color != null ) {
            if( glColorOffset < 0 )  glColorOffset  = verticesBuffer.position() * FLOAT_SIZE;
            pushColor( color );
         }
         else {
            // TODO : texture impl
         }
      }
     
      private void pushColor( Color color ) {
         float[] rgb = color.getRGBComponents();
         
         for(int i = 0 ; i < 4 ; i++ ) {
            if( i < rgb.length ) {
               verticesBuffer.put( rgb[i] );
            }
            else {
               verticesBuffer.put( 1f ); // for alpha if missing
            }
         }
      }

      private void end() {
         indicesCount =  ( (indicesBuffer.position() * INTEGER_SIZE) - indicesOffset ) / INTEGER_SIZE;
      }
   }

   /**
     * Get the closest greater power of 2 to the fold number.
     */

    private static int powerOfTwo(int num) {
        if( num != 0 ) {
           num--;
           num |= (num >> 1);  // Or first 2 bits
           num |= (num >> 2);  // Or next 2 bits
           num |= (num >> 4);  // Or next 4 bits
           num |= (num >> 8);  // Or next 8 bits
           num |= (num >> 16); // Or next 16 bits
           num++;
       }
       return num;
    }    
   
}


and the binder :

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  
public class OpenGLBinder {

   private int bindedVBO;
   private int bindedIBO;
   private int bindedTexure;
   
   
   public void bindIBO( int ibo ) {
      if( bindedIBO == ibo ) return;
      GL15.glBindBuffer( GL15.GL_ELEMENT_ARRAY_BUFFER, ibo );
      bindedIBO = ibo;
   }
   
   public void unbindIBO( int ibo ) {
      if( bindedIBO == ibo ) {
         GL15.glBindBuffer( GL15.GL_ELEMENT_ARRAY_BUFFER, 0 );
         bindedIBO = 0;
      }
   }
   
   public void bindVBO( int vbo ) {
      if( bindedVBO == vbo ) return;
      GL15.glBindBuffer( GL15.GL_ARRAY_BUFFER, vbo );
      bindedVBO = vbo;
   }

   public void unbindVBO( int vbo ) {
      if( bindedVBO == vbo ) {
         GL15.glBindBuffer( GL15.GL_ARRAY_BUFFER, 0 );
         bindedVBO = 0;
      }
   }

}


As is, if i call a fillRect + flush, this code work. (ughh ^^)

So now, i have some reflextion about how to design an efficient drawing back-end if i call by example 2 fillRect and 1 drawLine !!

What i think :
-------------
  - Fill all vertices for theses 2 rects  and the line when i call fillRect and drawLine methods

when flush():

  - bind the IBO, VBO
  - send all vertices to VBO (for 2 rects and 1 line)
  - send all indices to IBO (for 2 rects and 1 line)

  - glVertex (with buffer offset)
  - drawElement for the first rect  (with indice offset)

  - glVertex (with buffer offset)
  - drawElement for the first rect  (with indice offset)

  - glVertex (with buffer offset)
  - drawElement for the second rect  (with indice offset)

  - glVertex (with buffer offset)
  - drawElement for the line  (with indice offset)


The advantage with this design, it's i can merge relatively easily "textcoord" or "colors" in the VBO and use stride concepts for each "entity" since i make a separate drawElement for each one.

I don't know if i can do a drawElement for all of theses ? i think no because we can have the first fillRect with a color and the second one with a texture. so i must configure the call to the drawElement.

The second things, is the size of the buffer, i could imagine to have a limited size (ie 1024k) and flush() automatically if i call a draw() methods that will overflow the buffer.

PS: i would admit, all was simpler with glBegin and glEnd ^^ but it's really fun to discover new things.

Some advise is welcome ^^



20  Discussions / General Discussions / Re: 2015 Game Development Goals on: 2015-01-01 12:02:50
Huhh,  

For me 2014 was a black-hole in term of games developpement  (2013 was a good year).
My professionnal work was too immersive and i let down all personnal projects.
But i played in 2014 to "X-Com Enemy Within" and found it as a really good game and loved it !! it's such game that i'm jalous to not made it even if i know i'm not able to do...

So, since 1 month, i restarted old projects, review theses and started to unify 3 of them inside a single one.
I would achieve in 2015:
   - Finished 2 games started in 2013 (one is playable but i want to polish it a bit)
   - Learn most of things about OpenGL (some stuff are always a mystery for me... and i want to work on theses aspects)
   - Finish my ui framework

But i hope i will be able to get some times for personnal projects over the complete 2015 year.

Happy new Year to everybody !!!
Séb.

21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-30 00:44:11
I think what you're looking for is glfwGeyKeyName, which has not been added to 3.1 yet, see issue #117.

this
1  
glfwGetKeyName 
will be an option for performing local keyboard mapping ( at least for printable keys )
But won't help for not printable keys.

Thanks a lot,
Best regards,
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-29 23:03:38
I understood the concept behind their choices,

But If you let the player to choose a key and click on "A" from my AZERTY keyboard. I have to use 2 callbacks (the unicode version + keycode version) in order to be able to show him the "A" (render text) but retains internally the keycode "Q" for catch events accordingly.
In this simple case, i don't found anything that let you to provide a "display name" from a keyCode (that is near the unicode codepoint but maybe i miss it).

In other way, if you have a game (or an application) that don't let the user to configure keys and have an action of the logical key "A" (since it show the user "you can press A for doing you magical stuff"). You must register a char-callback that can return you so many codepoint for the same key (minuscule, majuscule, accents,...) but in this case it would be easier to have a virtual keycode instead of a physical keycode.

In a naive reflection, when they talk about "physical" keys, when we press the real physical key "A" (i see a "A" in my hardware keyboard), we can be able to think about receiving a "A" keycode instead of the "Q"

So, i'm confident with the WSAD common problem, but it don't help me to much :-/

LWJGL 3 uses a custom GLFW build with all features/fixes added in 3.1. Which means it includes the fix for #114.

With that said, you should never have to map keys between keyboard layouts. There are two separate ways to handle keyboard input:

a) Physical keys. For example, you want the default keys for moving around to be WASD (as they appear on a QWERTY keyboard, which is how GLFW understands it). You use GLFW_KEY_W/A/S/D. Now, lets say a user with an AZERTY keyboards tries your application. When they press ZQSD, you'll still get GLFW_KEY_W/A/S/D in the key callback. The mapping is automatic, you don't have to do anything. The only thing to worry about is writing your app so that it works with the physical layout of a US keyboard.

b) Text input. You have to use GLFWCharCallback or GLFWCharModsCallback. These are keyboard layout and locale dependent, and again, you don't have to worry about specific layouts or mappings.
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-29 22:35:40
Yes, but i don't know how to convert a scancode in a keycode that depends of the current keyboard layout.
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [GLFW] keyboard layout on: 2014-12-29 22:34:47
I checked the version of GLFW used by my LWJGL version and it's:
  
1  
3.1.0 Win32 WGL VisualC


So, if we read the https://github.com/glfw/glfw/issues/114 , we can see that they fix the behaviour in order to provide only the keycode in the US-Layout whatever you have in your OS.

It seems, that before they fix it, it worked like i would want it work for me :-/

25  Java Game APIs & Engines / Engines, Libraries and Tools / [GLFW] keyboard layout on: 2014-12-29 21:44:13
Hi,

I'm playing with GLFW since it is now the window system for LWJGL.

I intercept key events from a GLFWKeyCallback (i'm not using the unicode char version because i want handle special keys like CAPS_LOCKS...)

I'm french and have an AZERTY keyboard and GLFW don't do any keyboard layout mapping and provide always keycode in the US-Layout (So it's QWERTY).
That mean, if i press "A" on my keyboard i receive the event "Q" from GLFW.

I'm starting to perform the mapping manually regarding the country of the swing method :
1  
InputContext.getInstance().getLocale();

But it's a pain, dirty and i'm not sure to achieve this with a robust solution.

So, have you other alternatives ?

At this time what tried to consider ?
  - using scancode instead of keycode on a way that i can convert it to an awt key code by example (but i don't find anything on it)
  - Be able to change GLFW configration in order that it do the keyboard layout itself (but, it seems that their standard behaviour is to map to US-Keyboard only)
  - using a third-party that will do that better than me Tongue (but at this time i don't find it)

Best regards,

Here my local mapping that i use but it's not cool:

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  
   private enum KeyboardLayout {
      Qwerty,
      Qwertz,
      Azerty;
   }
   
   private static String         country = null;
   private static KeyboardLayout layout  = null;  


   private static int mapKeyboardLayout( int glfwKeyCode ) {
      if( country == null ) {
         Locale locale = InputContext.getInstance().getLocale();
         if( locale == null ) locale = Locale.getDefault();
         country = locale.getCountry().toLowerCase();
         layout  = getKeyboardLayout(country);
      }
      switch( layout ) {
         case Qwerty : return toQwertyLayout( glfwKeyCode , country );
         case Qwertz : return toQwertzLayout( glfwKeyCode , country );
         case Azerty : return toAzertyLayout( glfwKeyCode , country );
      }
      return glfwKeyCode;
   }
   
   private static KeyboardLayout getKeyboardLayout( String country ) {
      if( country.equals("fr") ) return KeyboardLayout.Azerty;   // FRANCE                                          
      if( country.equals("hr") ) return KeyboardLayout.Qwertz;   // CROATIA
      if( country.equals("si") ) return KeyboardLayout.Qwertz;   // SLOVENIA
      if( country.equals("cz") ) return KeyboardLayout.Qwertz;   // CZECH REPUBLIC
      if( country.equals("hu") ) return KeyboardLayout.Qwertz;   // HUNGARY
      if( country.equals("pl") ) return KeyboardLayout.Qwertz;   // POLAND
      if( country.equals("sk") ) return KeyboardLayout.Qwertz;   // SLOVAKIA (Slovak Republic)
      if( country.equals("DE") ) return KeyboardLayout.Qwertz;   // GERMANY
      return KeyboardLayout.Qwerty;
   }

   private static int toQwertyLayout( int glfwKeyCode , String country ) {
      return glfwKeyCode;
   }
   
   private static int toQwertzLayout( int glfwKeyCode , String country ) {
      switch( glfwKeyCode ) {
         case GLFW.GLFW_KEY_Z             : return GLFW.GLFW_KEY_Y;
         case GLFW.GLFW_KEY_Y             : return GLFW.GLFW_KEY_Z;
         default                          : return glfwKeyCode;
      }
   }
   
   private static int toAzertyLayout( int glfwKeyCode , String country ) {
      switch( glfwKeyCode ) {
         case GLFW.GLFW_KEY_A             : return GLFW.GLFW_KEY_Q;
         case GLFW.GLFW_KEY_Q             : return GLFW.GLFW_KEY_A;
         case GLFW.GLFW_KEY_W             : return GLFW.GLFW_KEY_Z;
         case GLFW.GLFW_KEY_Z             : return GLFW.GLFW_KEY_W;
         // ....... and so one
         default                          : return glfwKeyCode;
      }
   }



26  Discussions / General Discussions / Re: Geometry classes on: 2013-01-26 20:12:36
Immutable objects absolutely easier to reason about, no question.  And on the average desktop app, you're not likely to notice the difference if you create them by the millions.  But if you're creating them every frame on an Android machine, then you end up having to compromise and use mutable objects.

Seems to me modern platforms are pushing us backward Sad


I agree with you, the immutable approches is the more straightforward but not the most efficient in mobile platform.
I don't like primitives for storing theses kind of coordinates. when i saw a method like xxx(int x1,int y1, int x2 , int y2 , int x3 , int y3, int x4 , int y4 , ...) i have a headhache...
27  Discussions / General Discussions / Geometry classes on: 2013-01-26 15:47:04
I would discuss about a small geometry implementation:

Consider having all basic classes like Point, Dimension, Rectangle, Circle.

By example, you will find on a Circle a method like :
1  
public Point getCenter();


What would be your options ?:
  - Having "Point" immutable that let you the liberty to return the Point from the Circle object without any risk that somebody change it.
  - Having "Point" mutable that you must enforce in a some way any modifications (like with listeners). But even if you are able to intercept changes, theses changes may corrupt some objects states. (exemple changing corners of a rectangle that do not give a rectangle anymore).
  

At this time, my own geometry approche it to use immutable object for all objects. But it's not the best approche for reduce objects allocations. Each time i want to translate, rotate, ... a geometry objects, i must instanciate a new one...

The mutable approches is fine when you perform an animation and translate a series of geometry objects each update() or render() depending of what you do.

Sébastien.
28  Games Center / WIP games, tools & toy projects / Re: Particle Editor Tool on: 2013-01-24 20:25:31
looks cool.
29  Discussions / General Discussions / Re: Coding Standards on: 2013-01-24 11:48:11
If you have a getter and a setter that get and set the fields directly, your field *is* public; you might as well declare it public then and skip de getter/setter.
If you have a getter that returns the field directly, your field is basically public and read-only. You might as well declare your field public final then and skip the getter.

The field is an implementation details, the getter is the API.
If you let the caller to use directly the field you can't rely on an implementation changes without to refactor all usages.

I take by example, if you want to change your implementation for a precise field that you want to set it lazy. You want only to read and instanciate it only when it is accessed.
If you done a getter at the start point, you can reimplement the getter in order to get your lazy function without any impact of the usage.

My position is this
   - You can never have issues to encalupsate a field with getter and setter. (at least no new issue than the direct access version)
   - You can have various issues when letting direct access to your field (that become a API part your class)

So, with this reflexion, i create "get" for all fields if they needs to be publicly accessed outside.


30  Discussions / General Discussions / Re: Coding Standards on: 2013-01-23 07:24:25
I'm working from 10 years in software industry and my standards are very far far of yours.

 - fields are always private, if you need access, a get/set is intended for. if you want to optimize (a very little), you can force the getter to be final (that can be a good contract in lot of cases). With the final, the .class may not use an invokevirtual that can increase performance.
 - Around the reference immutability, for me it's not a standard point but more a contract point of what you are doing. you can't set it as a global state.
 - For methods that instanciate objects that must cache references results,  it depends of the aspect of this returned type. if the returned object is immutable itself (like String), it's a good approach. it's the hell if differents  caller can modify your cached instances concurrently. Theses cases can always be handled by the "mind aware" of the developper but they are very dangerous since you are in a team and works on big projects.

Pages: [1] 2 3 4
 

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

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (14 views)
2015-01-26 04:47:56

Olo (14 views)
2015-01-25 21:26:00

Olo (16 views)
2015-01-25 18:44:22

Robo11 (28 views)
2015-01-25 06:14:26

basil_ (26 views)
2015-01-17 22:29:32

wxwsk8er (26 views)
2015-01-16 21:42:21

wxwsk8er (21 views)
2015-01-16 20:44:20

basil_ (25 views)
2015-01-14 09:46:59

basil_ (21 views)
2015-01-14 09:46:52

wxwsk8er (37 views)
2015-01-13 20:42:16
2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!