2
\$\begingroup\$

I have seen a lot of tutorials, and they develop games with 2 different ways:

The first one is using a virtual image (BufferedImage) and filling it's pixels. And displaying virtual picture.

private BufferedImage image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB);
private int[] pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();
private int[] colors = new int[6 * 6 * 6];

Second one is using lots of real images. And displaying they.

SpriteSheet sheet = new SpriteSheet(ImageLoader.loadImage("/textures/sheet.png"));

    //PLAYER SPRITES PROVIDED BY: AddFact
    player = sheet.crop(width * 4, 0, width, height);

    dirt = sheet.crop(width, 0, width, height);
    grass = sheet.crop(width * 2, 0, width, height);
    stone = sheet.crop(width * 3, 0, width, height);
    tree = sheet.crop(0, 0, width, height);

First Question: Which one has the best performance ?

Second Question: How should we load maps? With images or with text files ? Which one is good to chose ?

Sorry for my english. I hope I can explain to you :) Thanks for helping, have a nice day ^^

\$\endgroup\$
  • 1
    \$\begingroup\$ Next time please post two separate questions so it fits the StackExchange format better. Sprite sheets have a better performance because you only pass and bind one file to the graphics card. \$\endgroup\$ – Benedikt S. Vogler Nov 1 '15 at 16:56
1
\$\begingroup\$

Both of these methods are utilizing software rendering, not using the GPU. If you were to use LWJGL or LibGDX or something else that uses the GPU for graphics rendering, it would be faster than both of these algorithms (or at least more efficient, most of the time). Anyways, let me discuss the two methods you asked about though:

In method 1 you are manually filling in the pixels of 1 image, then rendering it to the screen. In method 2 you are using a spritesheet, however in Java this way you are really just getting a bunch of individual BufferedImages by using the crop() method (I assume the crop() method really returns a subimage), so loading the image will be faster however you will be rendering multiple images to the screen. That being said, I can't entirely tell you which one is faster, because both utilize a form of software rendering, however I imagine method 2 would be faster, simply because of it's native implementation in Java, but it wouldn't be too much faster (I could be wrong). I can say, for sure, that using a library/framework that supports using the GPU (such as LWJGL, allowing you to use OpenGL) will be faster than these methods.

As for your second question, maps can be stored/loaded in many different ways. You can use an image to store tile data, maybe, or create (or use) a map editor and write it to a text file, then load it in. You may also want to consider another file to store entity data if you are using the image loading of a level.

I hope this helped a little bit, best of luck!

\$\endgroup\$
0
\$\begingroup\$

For images, you should almost always use a sprite sheet - switching between images is extra work for the GPU. You should load your sprite sheet and load VBOs (Vertex Buffer Objects) using that sprite sheet. LibGDX handles all of this for you and has amazing performance, so I suggest that you check it out.

Storage depends on a lot of things. If your map is an extremely simple one, you could use an image. E.g. The red and blue channels could serve as a tile type for the top layer and the green and alpha channels could serve as a tile type for the bottom layer. Where would you store your entities? If you want the image to look remotely related to the map, it's difficult to arrange things properly.

For my game, which consists of regions, entities, inventories and quests, I chucked everything into a binary file in byte form. However, I had to be really organised, as it's difficult to find errors with this method if you're not. E.g. For a single map with under 256 different types of tiles, that is 4 by 4 tiles, the file would look something like: 4 4 23 45 0 91 255 3 1 8 43 90 12 11 33 43 87 12, the first 2 numbers being the width and height and the next 16 numbers representing tiles.

\$\endgroup\$
0
\$\begingroup\$

Weird connection, but consider how Minecraft does it. The block textures are all in one image. Back in classic each texture was in a separate file. This worked fine because the rendering was very elementary. But as the game became more complete, it started to use much more resources, so a sprite sheet was a great optimization. Lesson... Use sprite sheets please. But if you'd rather not, you could always load each image during initialization, then reference back to them when needed.

Glad I can help.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.