Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
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   
Pages: [1]
  ignore  |  Print  
  [SOLVED]LWJGL Loading Progress  (Read 1485 times)
0 Members and 1 Guest are viewing this topic.
Offline Vladiedoo
« Posted 2012-12-05 05:23:57 »

Hi, I recently added 402 (256x256pixel) PNG images into my game that are loaded right away. This causes my game to take around 1737ms to load, or 1.737 seconds. I tried to add a loading screen in the begging so the user doesn't just see a black screen for 1.737 seconds (which is bound to get longer in the future). However, upon adding a loading screen it causes the game to take around 7435ms, or 7.435 seconds to load.

I noticed that "Display.update();" is what causes the increase in time spent but without that function I can not draw the display bar. The API states that update() does the following "Update the window. If the window is visible clears the dirty flag and calls swapBuffers() and finally polls the input devices." Getting rid of input only added a few milliseconds and I am not exactly sure what dirty flags and swapBuffers() do, perhaps that is what causes the delay.

Here is the function used.
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  
public void initSkillIconTextures(String path) throws IOException {
      Mouse.destroy();
      Keyboard.destroy();
      Scanner scanner = null;
      try {
         scanner = new Scanner(new FileInputStream(path));
      } catch (FileNotFoundException e) {
         e.printStackTrace();
      }
      try {
         // While the text file still has another image name, continue reading image names, storing the Textures into an ArrayList<Texture>
         while (scanner.hasNextLine()) {
            skillIcons.add(TextureLoader.getTexture(
                  "PNG",
                  ResourceLoader.getResourceAsStream("res" + File.separatorChar + "images" + File.separatorChar + "spell_Icons" + File.separatorChar
                        + scanner.nextLine())));
            // loadingRender() draws the loading bar but removing this method only got rid of a few milliseconds.
            loadingRender();
            Display.update();
         }
      } finally {
         try {
            Mouse.create();
            Keyboard.create();
         } catch (LWJGLException e) {
            e.printStackTrace();
         }
         LOADING = false;
         scanner.close();
      }
   }


Perhaps I should create a JFrame to display the status of loading; or maybe I am approaching the whole situation incorrectly? If someone could point me in the right direction it would be very helpful.

Thank you for your time.
Offline davedes
« Reply #1 - Posted 2012-12-05 16:40:13 »

Why aren't you using sprite sheets? If you are rendering that many different images at once, even if they are small, you will inevitably run into massive performance issues because of the many calls to glBindTexture. Maybe you could post a couple of the images -- there may be plenty of ways of compressing that information in order to reduce load time and distribution filesize.

You should not use FileInputStream unless you are certain the file will not be packed into your executable JAR.

Why are you destroying the mouse and keyboard before loading? You should only destroy these things at the end of your application life-cycle, i.e. when the user is exiting your game.

A loading screen works like this...

1.
Render the loading screen; i.e. progress bar at current position and text that says "Loading."

2.
Load a single resource and move forward in your list of "resourcesToLoad."

3.
Finish the frame and repeat.

The pseudo-code for your whole application will look like this:
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  
Stack<String> imagesToLoad = new Stack<String>();
HashMap<String, Image> images = new HashMap<String, Image>();
int totalImages;

... in game init ...

    imagesToLoad.push("res/skill1.png");
    imagesToLoad.push("res/skill2.png");
    imagesToLoad.push("res/skill3.png");
    ..etc...

    totalImages = imagesToLoad.size();

    while (!Display.isCloseRequested()) {
        render();
        update();
        Display.update();
        Display.sync(60);
    }

... in LoadingScreen render ...
    if (imagesToLoad.size()==0) {
        ... we are done, fade to next game screen ...
    } else {
        progressBar.setValue( (totalImages - imagesToLoad.size()) / (float)totalImages );
        progressBar.render();
    }

... in LoadingScreen update ...
    if (imagesToLoad.size() > 0) {
        String str = imagesToLoad.pop();
        images.put(str, loadTexture(str));
    } else {
        loadScreen(Screens.GAME_SCREEN);
    }

Offline chrisethompson

Senior Newbie


Medals: 1
Exp: 5 years



« Reply #2 - Posted 2012-12-05 16:43:26 »

I think the key might be that you are missing Display.sync(60).  So Display.update() tries to render the screen at as high a frame rate as possible.  Add that just after you Display.update() and see if it reduces the time.

As the post above says, there are probably ways to reduce the 1.7 seconds, but the extra time for drawing the screen should not be there.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Danny02
« Reply #3 - Posted 2012-12-05 17:24:58 »

I think the key might be that you are missing Display.sync(60).  So Display.update() tries to render the screen at as high a frame rate as possible.  Add that just after you Display.update() and see if it reduces the time.
Some time ago Carmack gave the tip on his Twitter feed to deactivate vsync while loading, because this WILL slow things down.
Offline theagentd

« JGO Bitwise Duke »


Medals: 361
Projects: 2
Exp: 8 years



« Reply #4 - Posted 2012-12-05 18:38:43 »

You're drawing the progress bar 400 times. Don't draw it for every image, draw it every Xth millisecond instead. 16<X<100.

Myomyomyo.
Offline Vladiedoo
« Reply #5 - Posted 2012-12-06 02:07:16 »

@davedes
I literally facepalmed at the fact that spriteSheets went over my mind. Thank you so much for the pseudo-code outline, I'm new to Stacks and HashMaps so it will be a good learning experience as well.

@chrisethompson
I originnaly had Display.sync(60) but I found that removing it actually sped up the loading. As an extreme example, setting Display.sync(10) after Display.update() would have the game load very slowly, I would imagine it's because only 10 resources are trying to be loaded every second as apposed to as many as possible.

@Danny02
BINGO!
I disabled it and to my surprise 95% of that extra delay is removed. That would make sense too though because at such a high frame rate the Display would spend a lot of resources making sure that it is synced up with the monitor. What is interesting though is that I kept getting an "GL_INVALID_ENUM" error when I would try to re-enable V_SYNC after loading. I added the line "System.out.println(GL11.glGetError());" after creating the textures and it prints the error # 1280 in the console and no longer causes the game to stop playing. For now it's a temporary solution.

@theagentd
That's a very good point, with a delta timer I could control the update rate.

Thank you everyone for helping out.
Without davedes's or theagentd's optimization yet I am able to reduce the loading time to 1.8s with progress bar loading. It should dramatically lower after combing the images into a spritesheet.

Thanks again guys.

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.

PocketCrafter7 (14 views)
2014-11-28 16:25:35

PocketCrafter7 (10 views)
2014-11-28 16:25:09

PocketCrafter7 (11 views)
2014-11-28 16:24:29

toopeicgaming1999 (76 views)
2014-11-26 15:22:04

toopeicgaming1999 (67 views)
2014-11-26 15:20:36

toopeicgaming1999 (17 views)
2014-11-26 15:20:08

SHC (30 views)
2014-11-25 12:00:59

SHC (28 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (28 views)
2014-11-24 19:59:16
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

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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!