Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
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  
  jtabbedpane problems (now TileRenderer)  (Read 3957 times)
0 Members and 1 Guest are viewing this topic.
Offline invictus

Senior Newbie





« Posted 2006-03-08 11:14:01 »

Hi

I am trying to use GLCanvas with jtabbedpane and it doesnt work as expected. When I add a tab with a jpanel containing a glcanvas it doesnt draw the canvas. if I add another one and click on the second tab then the second canvas is shown (however it has a small flicker in the graphics). When I then click the first tab again the first canvas is shown.

I am using yesterdays nightly build of jogl.

I made a small example of the problem on the following address:
http://studweb.hig.no/020843/Scene.java
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2006-03-08 17:20:54 »

This appears to be a problem with the JDK. The same thing happens if you add a normal AWT Canvas instead of a JOGL GLCanvas. Also the problem doesn't happen with a recent Mustang weekly build. I would suggest posting on the Swing and AWT forum on javadesktop.org.
Offline invictus

Senior Newbie





« Reply #2 - Posted 2006-03-09 09:05:38 »

The java 6 JDK fixed the issue. Do you know if beta2 is stable enough to keep using instead of version 5?

didnt fix the intel extreme flicker though :p

EDIT:

After a bit of testing using canvas in tabbedpane I have some serious performance issues. I use a shared context for all windows, and the performance is good on the first 5 canvases I created, but every canvas created after that will have lag issues. I have tried having about 10 tabs with canvases sharing context, and the first 5 tabs that is clicked/made visible will have great performance even if I have 10++ tabs, while the rest will lag real bad. Any ideas?

EDIT2:

This seem to be a problem on the intel extreme 2 chip as I just tested it on 2 machines using that card, while on the same crappy SiS card on a machine with less RAM it is going smooth without a problem...this intel extreme graphics 2 issues are really getting on my nerves now as it isnt working and its ruining my project Sad
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #3 - Posted 2006-03-09 22:26:27 »

This seem to be a problem on the intel extreme 2 chip as I just tested it on 2 machines using that card, while on the same crappy SiS card on a machine with less RAM it is going smooth without a problem...this intel extreme graphics 2 issues are really getting on my nerves now as it isnt working and its ruining my project Sad

Spend the 30 bucks or so to get the lowest-end NVidia card on the market that will go into your PC. I guarantee it will work more reliably than the Intel Extreme chipset. Note: I do not work for NVidia.

You may want to look for more up-to-date Intel video drivers for your hardware.
Offline invictus

Senior Newbie





« Reply #4 - Posted 2006-03-09 22:51:30 »

I have the 7800GT card on my other computer and still have some issues.

The problem for us is that we are using JOGL  for the last project at a bachelor education, and the product is suppose to be used by low-end computers. Since intel extreme graphics seem to be one of the most common graphics cards in use we have problems Sad

Here is a more extensive report of the issues we have had with different hardware so far in the project:
--------------------------------------------------------------------------------------------------------

The computers:

Amd64 x2 3800+
2GB DDR memory
WD raptor 74GB
Geforce 7800GT with newest forceware

Most works. PBuffer code (will post below) work even with destroy unlike most other machines, but with multiple tabs it cant redraw the canvas before its clicked EVERYTIME you do something with the window. Also crashes when using repaint() in reshape method saying something about singlethreadworkaround. Have none of these problems when we are not using tabs.

---

Dell inspiron 510m
CeleronM 1.3ghz
512MB DDR memory
intel extreme graphics 2: tried with both default dell drivers and newest intel drivers

When resizing a window it fill the "new" area with random data. Can be "avoided" if forcing a repaint() at the end of reshape() (although it will have a 1-2 seconds delay before it works) method, but will cause problems for the computer above. Was told it could work if we instead of running repaint() just start a thread that run repaint(), but I cant confirm this. Also have insane lag on each tab created with canvas after 5 tabs are clicked (first 5 tabs still work smooth though). PBuffer code works like a dream though as long as the destroy() on the pbuffer present. If the destroy is removed it will crash if the code is run several times.

-

IBM thinkpad r50e
CeleronM 1.4ghz
512MB DDR memory
intel extreme graphics 2: default ibm drivers

Same as above except that the pbuffer code crash on destroy() method. Someone said it would work if we created a whole new thread just to do destroy(), but I cannot confirm this.

-

Acer TravelMate 2310
Celeron M, 1.2ghz I think
256MB DDR memory (192MB because of shared memory)
SiS m661mx card using newest drivers

Will crash bigtime on pbuffer code, but else everything works like a dream (even though this computer has the worst spesifications).

-

amd athlon xp 1800+
1GB memory
nvidia geforce fx 5900 ultra

Everything seem to work ok with this computer. Both canvases in tabs, pbuffer code, and redraw both with and without repaint() in reshape method.

-

Also barly tried another computer that I do not have the specs of, and the pbuffer code crashed bigtime.

----

PBuffer code:

  protected boolean Capture()
  {
      if(GLDrawableFactory.getFactory().canCreateGLPbuffer())
      {
         GLCapabilities caps = new GLCapabilities();
         caps.setDoubleBuffered(false);
         GLPbuffer offScreenCanvas = GLDrawableFactory.getFactory().createGLPbuffer(caps, null, 1024, 768,

canvas.getContext());
         offScreenCanvas.addGLEventListener(this);
         offScreenCanvas.display();
         offScreenCanvas.removeGLEventListener(this);
         offScreenCanvas.destroy();      //will crash here on half of the computers
         return true;
      } else return false;
  }

reshape code:

   //will display random trash on new area until a repaint is forced on half of the computers. on one computer a forced repaint will

crash the application saying something about singlethread. Even if a repaint is forced it will take a second or two for the random trash

disapears and the image is streched.

  public void reshape(GLAutoDrawable glDrawable, int x, int y, int width, int height)
  {
    GL gl = glDrawable.getGL();
    int width_l = width;
    int height_l = height;
    if(height <= 0)
      height = 1;
    final float h = (float)width_l /(float)height_l;
    ratio = h;
      gl.glViewport(0, 0, width, height);
      gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glLoadIdentity();
    glu.gluPerspective(45.0f, h, 0.1f, 200.0);
      gl.glMatrixMode(GL.GL_MODELVIEW);
    canvas.repaint();               //this is causing problems for some machines, but for some not
  }

tabs:

   Not much to say about the tabs. We have a static Context used for keeping track on the context so every canvas get the same

context on "new GLCanvas".

from the panel holding the canvas:

  public static GLContext context = null;


from the contructor of the panel holding the canvas:

    if(context != null)
      canvas = new GLCanvas(caps, null, context, null);
    else
    {
      canvas = new GLCanvas(caps);
      context = canvas.getContext();
    }


The panel holding this data is used with this code:

   tabbedpane.addTab("name", new Scene()); where Scene inherits JPanel and place the canvas as BorderLayout.CENTER

--

The resize/redraw issues are described in the following threads:
http://www.java-gaming.org/forums/index.php?topic=12225.0
http://www.java-gaming.org/forums/index.php?topic=8738.0

The tab issues are described in the following thread:
http://www.java-gaming.org/forums/index.php?topic=12761.0

I hope the fault is ours so its fixable...otherwise we have a hudge problem Sad
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2006-03-09 23:31:28 »

Thanks for posting this information and sorry about the problems you're running into. Unfortunately even with these descriptions it's impossible to guess what could be going on in most cases. Can you provide output and crash logs for the various crashes you're reporting? What output indicates something about the single-threaded workaround?

Do you have a small test case reproducing some of these problems?

Can you do any workarounds like using a GLJPanel or doing the tabbed portion of your GUI using OpenGL rather than the AWT so that you have only one GLCanvas?
Offline invictus

Senior Newbie





« Reply #6 - Posted 2006-03-10 19:16:41 »

Thanks for posting this information and sorry about the problems you're running into. Unfortunately even with these descriptions it's impossible to guess what could be going on in most cases. Can you provide output and crash logs for the various crashes you're reporting? What output indicates something about the single-threaded workaround?
About the tabbing lags I dont have any logs, but I think I will go for another tabbing solution using only one canvas instead so it doesnt really matter anymore.

I will supply you with a log from the pbuffer crash with a working example when I get a hold of the rest of my programming group.

When it comes to the resize issues with intel extreme graphics I dont know more than I (and another guy in that other thread I linked to) already told you since there is no crash, but just a visible bug.

Most of the issues were related to the tabbing and usage of multiple canvases anyway it seems.

But I ask anyway: when forcing a redraw using canvas.repaint() or canvas.display() (dont know wich is better), should it be necessary to put it in a own thread? We have had to do this a couple of places to avoid crashes when forcing redraw (often after an input event that is changing the scene). That is the singlethread-thingy exception I was talking about. I will try to get a groupmember to reproduce this error so you can see for your self.

Do you have a small test case reproducing some of these problems?
I can try making something, but that wont be until beginning of next week

Can you do any workarounds like using a GLJPanel or doing the tabbed portion of your GUI using OpenGL rather than the AWT so that you have only one GLCanvas?
I will create a custom tabbedpane that only use one single canvas instead of multiple. I figured out that this would be better for me anyway.


And last but not least; thank you so much for the support and help here on the forums. It helps against the frustration to get help from someone that know JOGL better Smiley
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #7 - Posted 2006-03-10 20:01:17 »

But I ask anyway: when forcing a redraw using canvas.repaint() or canvas.display() (dont know wich is better), should it be necessary to put it in a own thread? We have had to do this a couple of places to avoid crashes when forcing redraw (often after an input event that is changing the scene). That is the singlethread-thingy exception I was talking about. I will try to get a groupmember to reproduce this error so you can see for your self.

There should be no difference. JOGL moves all of the OpenGL work onto a single thread internally anyway. I assume you aren't calling Threading.disableSingleThreading() or specifying the opengl.1thread system property on the command line.

I did notice recently that there are a couple of OpenGL-related calls that still get made on the current thread instead of the "OpenGL worker thread" and if the drivers are suspect then those could be causing problems. I've made a note to look into these issues.

Quote
I can try making something, but that wont be until beginning of next week

No rush.

Quote
And last but not least; thank you so much for the support and help here on the forums.

You're welcome and sorry for the trouble. We want to make this library as robust as possible.
Quote
Offline invictus

Senior Newbie





« Reply #8 - Posted 2006-03-13 10:28:42 »

Ok here is the PBuffer example:

http://home.online.no/~bj-bakke/hello.java

When running the application press F2 when destroy() isnt commented out in the Capture method.
If the destroy() is commented you need to press F2 as fast as possible 2-5 times.


The results:

dell laptop with intel extreme graphics WITH destroy()
works fine

dell laptop with intel extreme graphics WITHOUT destroy()
crash with the following exception:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: javax.med
ia.opengl.GLException: pbuffer creation error: wglCreatePbufferARB() failed: tri
ed 1 pixel formats, last error was: (Unknown error code 0)
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:268)

        at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThr
eadedWorkaround(WindowsGLDrawableFactory.java:213)
        at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(
WindowsGLDrawableFactory.java:160)
        at hello.Capture(hello.java:139)
        at hello.keyPressed(hello.java:161)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)


Acer laptop with SiS card WITH destroy()
the following exception:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: javax.med
ia.opengl.GLException: Error releasing pbuffer device context: error code 0
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:268)

        at com.sun.opengl.impl.GLPbufferImpl.destroy(GLPbufferImpl.java:177)
        at hello.Capture(hello.java:143)
        at hello.keyPressed(hello.java:161)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: javax.media.opengl.GLException: Error releasing pbuffer device contex
t: error code 0
        at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.destroy(WindowsP
bufferGLDrawable.java:92)
        at com.sun.opengl.impl.GLPbufferImpl$DestroyAction.run(GLPbufferImpl.jav
a:253)
        at com.sun.opengl.impl.GLWorkerThread$WorkerRunnable.run(GLWorkerThread.
java:241)
        at java.lang.Thread.run(Unknown Source)

Acer without destroy()


#
# An unexpected error has been detected by Java Runtime Environment:
#                        +----------------------------+
#  EXCEPTION_ACCESS_VIOLA┬ŽEnter char to copy up to:   ┬Že90c, pid=3724, tid=3272
#                        +----------------------------+
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta-b59g mixed mode, sharing)
# Problematic frame:
# C  [sisgl.dll+0x7e90c]
#
# An error report file with more information is saved as hs_err_pid3724.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

The log is located here:

http://home.online.no/~bj-bakke/hs_err_pid3724.log


The IBM laptop with intel extreme graphics have the same crash as the acer laptop WITH destroy(). without destroy() I dont know.
Offline invictus

Senior Newbie





« Reply #9 - Posted 2006-04-24 09:28:27 »

I am sorry to do this, but I need to bump the last reply in this thread regarding the pbuffer issues. Any new ideas on this problem with pbuffer and destroy?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #10 - Posted 2006-04-24 19:14:16 »

Sorry to say this but you're running into problems with crappy OpenGL drivers. You should file bugs with Intel and SiS. I don't think JOGL is doing anything wrong here. Your test case works fine on my laptop with an NVidia chipset.

Regardless I don't think you should be creating and destroying a pbuffer every time you want to take a screenshot. Even NVidia's drivers don't deal well with rapid creation and destruction of off-screen surfaces like Frame Buffer Objects. You should lazily create the pbuffer the first time the user requests a screenshot and hold on to it for subsequent screenshots, resizing it if necessary. Please try this and see whether it helps.
Offline invictus

Senior Newbie





« Reply #11 - Posted 2006-04-26 10:58:05 »

Ok. So its not needed to do destroy() at all then?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2006-04-26 16:01:26 »

Right, just hold on to the pbuffer and reuse it over and over again.
Offline invictus

Senior Newbie





« Reply #13 - Posted 2006-04-26 17:25:35 »

Ok I now works on more machines than before.

What I did was to remove the .destroy(), replace the offscreencanvas.display() with .repaint(), and finally made sure the pbuffer only got init once.

It works on all except one of the two intel extreme graphics 2 machines. Get the message "Could not find suitable pixelformat..." even tho I am using the lowest possible pixelformat setting: default with doublebuffering off. If I could just find out where to trap that exception I could probably fix it by dumping the framebuffer and scale it as a backup solution. Seem like the exception happens in a event-thread I dont have access to because now I have tried catching GLException both in the triggering code and in init & display. Any idea how I can catch the suitable pixel format exception?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #14 - Posted 2006-04-26 18:38:05 »

First, GLPbuffer.repaint() just calls GLPbuffer.display(), so there should be no difference in behavior between them.

If GLPbuffer.display() causes an exception to be thrown on the AWT event dispatch thread, this exception should be propagated back to your thread as a GLException and you should be able to catch it there. If this doesn't seem to be working, could you please post some code?
Offline invictus

Senior Newbie





« Reply #15 - Posted 2006-04-26 19:18:30 »

The code sample I am working against is at this address:
http://home.online.no/~bj-bakke/hello.java

When run you push F2 to take the screenshot (and get the crash). I suppose it wont crash on your machine, but if you uncomment line 210 you get the same exception as we get on the one computer. The exception is caught in the Capture() method, but it still give us a stacktrace a second later for some reason. What I want is to get rid of that stacktrace.

Line 210 is ONLY for reproducing the exception on other machines that dont get it otherwise!

Btw you were right about repaint() and display() it seem.

You can see I already implemented the backup solution with gluScaleImage (although the images are 3 times as big and 3 times as ugly using that compared to the pbuffer ones). In the Capture() method it just tell the pbuffer to display and save to file if possible or else it should just repaint the canvas, dump the canvas framebuffer, scale it up, and save it to file.
Offline invictus

Senior Newbie





« Reply #16 - Posted 2006-04-27 21:02:49 »

It seem like the exception that create this stacktrace is produced every time display() is run after pbuffer fail and I try using the backup solution. I have no idea how to fix this as that spesific exception cant be caught in neither display() or Capture().
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #17 - Posted 2006-04-27 21:22:16 »

Is this the second exception you were getting?
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Should not reach here
        at javax.media.opengl.glu.GLU.gluScaleImageJava(GLU.java:1486)
        at javax.media.opengl.glu.GLU.gluScaleImage(GLU.java:1608)
        at hello.display(hello.java:140)
        at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
        at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
        at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
        at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:258)
        at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
        at javax.media.opengl.GLCanvas.paint(GLCanvas.java:142)
        at javax.media.opengl.GLCanvas.update(GLCanvas.java:213)
        at sun.awt.RepaintArea.updateComponent(RepaintArea.java:239)
        at sun.awt.RepaintArea.paint(RepaintArea.java:216)
        at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:254)
        at java.awt.Component.dispatchEventImpl(Component.java:4031)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)


If so, this was a bug in the Java gluScaleImage implementation; sorry about that. The fix will be present in the nightly builds dated 4/28 or later.

You should also look into the com.sun.opengl.util.TileRenderer class and demos.misc.TiledRendering demo for producing higher-resolution screen shots.
Offline invictus

Senior Newbie





« Reply #18 - Posted 2006-04-28 17:36:45 »

Ok I will try TileRenderer instead. Any idea on where to get started?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #19 - Posted 2006-04-28 22:02:25 »

As mentioned above, look at the source code for the demos.misc.TiledRendering demo in the jogl-demos workspace.
Offline invictus

Senior Newbie





« Reply #20 - Posted 2006-04-29 10:05:04 »

oh...I just noticed that code also was using pbuffers. I was hoping to not using pbuffer since some of the project machines keep getting these pixel format exceptions when using pbuffers. What I need is a 800x600 screenshot of a variable size canvas...
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #21 - Posted 2006-04-30 10:43:33 »

You don't need to use a pbuffer with the TileRenderer. It can read its results from the back buffer so they don't need to be displayed on-screen. Try changing the test case to use an on-screen GLCanvas.
Offline invictus

Senior Newbie





« Reply #22 - Posted 2006-04-30 21:50:19 »

Really? I did not know that. Any idea how to use/save the backbuffer without displaying it then? Or am I way off here...

I think this might be the solution I have been looking for for a couple of months now if I can just get it working Smiley
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #23 - Posted 2006-05-01 05:27:56 »

Look at the man pages for glReadBuffer and glReadPixels.
Offline invictus

Senior Newbie





« Reply #24 - Posted 2006-05-01 08:58:23 »

Hmm...is there any standard "this is what your doing wrong" if I get the following output using TileRenderer?



Its suppose to render _one_ large triangle.

The code is as usual over at http://home.online.no/~bj-bakke/hello.java

If I can just get this one working I am as good as done with my project Smiley

UPDATE: It works if I run my app in fullscreen. That means if the tilesize is bigger than the image size. If not then I get this weird image.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #25 - Posted 2006-05-01 16:20:22 »

You definitely need to call trPerspective in order to tell the library what the overall view frustum is that you're rendering into. You should also make sure that your rendering routine "disp" produces exactly the same results no matter when you call it in the beginTile / endTile loop. I think you are also not supposed to modify the projection matrix in your rendering routine. You may also want to simply set a boolean flag when the capture key is pressed and do the capturing work in your display() routine instead of doing manual context manipulation. Beyond that I would recommend you just study the TiledRendering demo.
Offline invictus

Senior Newbie





« Reply #26 - Posted 2006-05-01 16:59:43 »

You definitely need to call trPerspective in order to tell the library what the overall view frustum is that you're rendering into.
I tried that without any different results. Perhaps I am doing it wrong.


Quote
You should also make sure that your rendering routine "disp" produces exactly the same results no matter when you call it in the beginTile / endTile loop.

Do you mean the rot += thingy? That is way gone but it didnt matter for the result. was mostly for the animator.

Quote
I think you are also not supposed to modify the projection matrix in your rendering routine.

Where do I do that? Perhaps I dont get what you mean...

Quote
Beyond that I would recommend you just study the TiledRendering demo.

I did...I even tried swapping the drawGears function with my triangle, but then I got the same result. I really dont get what going on.
Offline invictus

Senior Newbie





« Reply #27 - Posted 2006-05-01 17:41:50 »

I managed to get the TiledRendering demo to work with my triangle just as I wanted it so I guess I perhaps will get it working on the canvas also soon. Thanks for the help so far Smiley
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.

Elsealabs (15 views)
2014-12-28 10:39:27

CopyableCougar4 (19 views)
2014-12-28 02:10:29

BurntPizza (24 views)
2014-12-27 22:38:51

Mr.CodeIt (14 views)
2014-12-27 04:03:04

TheDudeFromCI (19 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

rwatson462 (58 views)
2014-12-15 09:26:44

Mr.CodeIt (47 views)
2014-12-14 19:50:38

BurntPizza (96 views)
2014-12-09 22:41:13

BurntPizza (115 views)
2014-12-08 04:46:31
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

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50
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!