Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  SOLVED - LWJGL Rendering Problem  (Read 1122 times)
0 Members and 1 Guest are viewing this topic.
Offline DrHalfway
« Posted 2012-09-12 01:46:36 »

Hello again JGO community. Rather than write tutorials this time i'm here asking for YOUR help. I'm having a rendering issue thats been ongoing for about 3 months now.. We have a Game Engine that can be used to write both Android games via openGL ES 1.0 (or GL10) and as of 3 months ago also launch the same games on PC via LWJGL. I'm having a really hard time with the PC Renderer, i've tried different methods in the past week but i'm running out of options. This may be mainly due to my inexperience with openGL, so I may be doing something wrong.

I'll try to dissect the rendering as much as possible and provide screenshot of what is actually happening.

At the moment - Rendering goes something like this.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
      try {
         PixelFormat pixelFormat = new PixelFormat();
         
         Display.setDisplayMode(new DisplayMode(graphics.getWidth(), graphics.getHeight()));
         Display.setTitle("Halfway Engine");
         Display.setFullscreen(fullScreen);
         Display.create(pixelFormat);
      }
      catch (LWJGLException e) {
         e.printStackTrace();
         System.exit(0);
      }


This is the "loop"

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  
      while (!Display.isCloseRequested()) {
         
         if (state == RUNNING) {
            float deltaTime = (System.nanoTime() - startTime) / 1000000000.0f;
           
            startTime = System.nanoTime();
           
            fixedUpdateCall += deltaTime;
           
            if (fixedUpdateCall >= 100.0f) {
               fixedUpdateCall -= 100.0f;
               screen.fixedUpdate();
            }
           
            // update the screen - the logic code
           screen.update(deltaTime);
           
            // present the screen - rendering
           screen.present(deltaTime);
         }
         
         if (state == PAUSED) {
            screen.pause();
         }

         Display.update();
         Display.sync(120);
      }


As far as rendering goes - this is rendering code for openGL simplified

1  
2  
3  
4  
5  
6  
7  
8  
   public void setGLContext() {
      camera.setViewport();
      graphics.glDisable(Graphics.GL_DEPTH_TEST);
      graphics.glEnable(Graphics.GL_BLEND);
      graphics.glBlendFunc(Graphics.GL_SRC_ALPHA, Graphics.GL_ONE_MINUS_SRC_ALPHA);
      graphics.glEnable(Graphics.GL_TEXTURE_2D);
      graphics.glLoadIdentity();
   }


And at beginning of every new frame - this code is called from the scene (present) method

1  
2  
3  
4  
5  
   public void setNewFrameContext() {
      graphics.glClear(Graphics.GL_COLOR_BUFFER_BIT/* | Graphics.GL_DEPTH_BUFFER_BIT*/);
      graphics.glClearColor(clearColor.getX(), clearColor.getY(), clearColor.getZ(), 1.0f);
      graphics.glLoadIdentity();
   }


The issues i'm having is that Android rendering works fine, all of the openGL ES functions are mapped onto their equivalent LWJGL function calls via the graphics interface so as far as rendering goes, its exact same code for both platforms.

- I use a Sprite Batching technique to draw all sprites at same time
- I use multiple texture atlas
- I may bind multiple textures, but only one at a time. Process is, bind a texture -> Draw the contents of Sprite Batcher -> unbind the texture
- glError returns 0 (no error)

1  
2  
// texture binding code
graphics.glBindTexture(Graphics.GL_TEXTURE_2D, textureID);


1  
2  
// texture unbind code
graphics.glBindTexture(Graphics.GL_TEXTURE_2D, 0);


Below are some screenshots of the rendering artifacts i'm getting.

Error 1 - Note the Artifacts around the letters. The Buttons are from one texture atlas and letters from another



Error 2 - This is a normal scene - you control that rectangular thing, as soon as it passes over the circles, they are
destroyed and removed from the scene.



And this is what happens when I run them over with the paddle



It leaves a trail of the paddle at the paddles location as soon as a ball is destroyed. I've double and tripple checked, as far
as the renderer is concerned, no instance or reference of the ball exists in the renderer. If i destroyed all the balls, only the
paddles reference would remain (only renderable) and the text aswell, but thats not part of the "game" world.

Any and all help would be appreciated, I'm trying to get to the bottom of this so I can move onto implementing other features,
I can post code snippets as requested. Like I mentioned before, all openGL calls are directly mapped from Android to LWJGL and Android rendering works fine.

Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #1 - Posted 2012-09-12 04:18:21 »

1  
2  
3  
4  
5  
   public void setNewFrameContext() {
      graphics.glClear(Graphics.GL_COLOR_BUFFER_BIT/* | Graphics.GL_DEPTH_BUFFER_BIT*/);
      graphics.glClearColor(clearColor.getX(), clearColor.getY(), clearColor.getZ(), 1.0f);
      graphics.glLoadIdentity();
   }

Before anything else: switch the first two lines. You set the color first, then clear. Also, to save a call to OpenGL, you can also choose to set the color in the 'init' method, then only call clear. The state is stored.

It leaves a trail of the paddle at the paddles location as soon as a ball is destroyed. I've double and tripple checked, as far
as the renderer is concerned, no instance or reference of the ball exists in the renderer. If i destroyed all the balls, only the
paddles reference would remain (only renderable) and the text aswell, but thats not part of the "game" world.
A ball being "destroyed" doesn't have anything to do with OpenGL. This is most definitely a logic/code error, not OpenGL.

Unfortunately, you aren't showing any relevant code so I cannot help more than that.

Offline DrHalfway
« Reply #2 - Posted 2012-09-12 07:15:05 »

Thank you for the reply, i switched those two lines but it didn't really change much. Unfortunately as far as logic errors are concerned, i've eliminated them all. The "Logic" that destroys objects is the same on both PC and Android, it doesn't explain why PC is having weird artifacts while Android is fine?

Dissecting the Engine would take forever, I'm thinking it may have something to do with the Sprite Batcher itself, or perhaps an openGL state that behaves differently on openGL ES and LWJGL, or perhaps the error is also evident in openGL ES but Android is smart enough to ignore it?

What i'm more after are thoughts on why those artifacts may be happening, so i can at least eliminate a few potentials and finally get to the source of the problem... Has anyone has a similar experience in either 2D/3D rendering?? I can post some code snippets on the Sprite Batcher (which is a module that's the same for both PC and Android).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DrHalfway
« Reply #3 - Posted 2012-09-12 07:35:31 »

UPDATE - OK, I fixed it, it was something extremly simple, i'll write it down so everyone who has same problem can see.

If using a sprite batcher - depending on your approach it may be a bit different.

What we do is create an upper bound of maximum "sprites" a batcher can render at any time, we default ours to 1000. This way we can create all the indices and cache them and use them for every frame. The problem is that the upper bound of the indices buffer. When using the glDrawElements I noticed that Android takes a "quantity" as the upper limit of the indices. For example, in a buffer that can hold 1000 sprites, there may only be 6 or 7 at a time. Android takes this "quantity" as an argument for its version of glDrawElements, however LWJGL version of the function takes no such argument, so what was happening was LWJGL Renderer was rendering everything, even when there was nothing there!

So to fix it, Say we have a native Short Buffer that stores indices as "Shorts" This line is needed before sending it off via glDrawElements.

indices.limit(upperLimit);

And that fixed both the "paddle" problem discussed above and the "GUI" problem with the letters.

Case closed, took me a week to pinpoint that stinking line.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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 (27 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (193 views)
2014-04-01 02:16:10
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

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!