Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Trouble loading textures outside the init() call  (Read 2241 times)
0 Members and 1 Guest are viewing this topic.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Posted 2003-07-08 21:00:30 »

Hello,

I'm attempting to port the client for a game I'm writing from LWJGL to Jogl as it seems like Jogl is better supported and is more of a "pure" gl wrapper than LWJGL.
But I'm having trouble defining textures (and various other things.. I haven't narrowed them down yet, but they seem to involve lists) outside of the init(GLDrawable) call in GLEventListener.
Since the init call is only made once (before the GLCanvas is made visible?), and I want to provide a splash screen in opengl that let's the user know what textures are being loaded and so, I've got a bit of a problem here.

I managed to get around it by turning off autoredrawing and setting the rendering thread to the current thread. That let me define textures and everything from that thread, then call display() on the canvas, and it works.

I felt this was a bit of a hack, so I asked a friend of mine who's running linux to try it... but the game started without any textures and various missing features (like the bitmaps for the fonts), just like it did for me at first.

So now my question is.. what am I doing wrong? Is there any documentation I've missed somewhere that explains this strange behavior?

The current alpha of the game client can be found at http://www.theintraclinic.com/wurm/.

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2003-07-09 05:17:56 »

To do this properly you need to fork off a background thread which performs just the disk I/O and conversion into the appropriate data format (e.g. byte[] or ByteBuffer). Your display() method should then pick up that loaded data from the background thread, call the appropriate OpenGL commands to define the texture objects, and update the progress bar. Once all textures have been loaded the display() method should stop displaying the progress bar and start displaying the main game.

Let me know if this isn't clear enough. For JavaOne I ported the Grand Canyon demo (http://java.sun.com/jfc/tsc/articles/jcanyon/), which does something similar, to Jogl but don't have those ported sources posted anywhere yet.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #2 - Posted 2003-07-09 13:55:14 »

That seems very messy..

If I understand the code correctly, the only proper place to make any opengl calls is in Runnables called from the GLContext (sub)class, and the buffer swapping isn't performed until the Runnable returns.. is that right?

If it is, then I really don't understand the reason for this. Why not just expose the SwapBuffers and/or MakeCurrent calls in GLContext?

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #3 - Posted 2003-07-09 17:31:20 »

Don't get me wrong, I really like and appreciate what you're doing. Smiley

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #4 - Posted 2003-07-10 07:14:44 »

I was an active developer of GL4Java for over a year and most of the errors reported were due to incorrect OpenGL context management, such as forgetting to free() the context at the end of the display() method. This has informed many of the design decisions in Jogl, including (1) making GLCanvas and GLJPanel final, (2) not exposing GLContext in the public API, and (3) not even exposing the makeCurrent/free paradigm to the bulk of the Jogl implementation. In Jogl everything is expressed as a closure that is run with the context made current. This has simplified the implementation considerably and made it much easier to add new functionality.

I used the GLContext.swapBuffers() call manually in one GL4Java application I wrote (for a progress bar), and upon porting it to Jogl found that changing the code to avoid the manual call made it a lot less of a hack.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #5 - Posted 2003-07-10 11:29:21 »

I still think it's strange that the only buffer swap is performed after the only legal place to execute opengl commands returns.

First of all, it's not exactly in line with the very procedural "normal" opengl thinking.
Furthermore, if you want to use a "special" opengllistener just to load a texture, you still have to rerender the entire screen to prevent artifacts. And in the case of the progress bar, that special listener would have to keep track of a lot of state in the instance instead of just in a single linear method.

That, or fork off a thread like you suggested, just to mimic C opengl behavior. :-/


I'll do my best to adapt, but I have to say I don't find this very optimal at all.
Other than that, I still love Jogl. Wink It's exactly what Java needs.

Play Minecraft!
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 (55 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!