[SOLVED]LWJGL Loading Progress

Newbie & Debugging Questions
#1

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.

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.

#2

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…

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

Load a single resource and move forward in your list of “resourcesToLoad.”

Finish the frame and repeat.

The pseudo-code for your whole application will look like this:

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);
    }
#3

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.

#4

Some time ago Carmack gave the tip on his Twitter feed to deactivate vsync while loading, because this WILL slow things down.

#5

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

#6

@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.