Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Loading stuff...when should it be done?  (Read 4538 times)
0 Members and 1 Guest are viewing this topic.
Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Posted 2012-07-18 21:27:27 »

I'm about to have to generalize loading of resources for my 2D sidescroller (both a regular PC-game and an applet-version). I am fortunate enough to have 2 artists making backgrounds and animations for me, and this will result in many images. I've done some calculating, and for the basic game with a few different tilesets and about 60 monsters, I'll be hitting 50-60mb of image-data. I'm wondering which would be the least irritating way of loading these images, while still having a sane memory-footprint, and I was thinking of doing one of 3 things:

1. Load everything into objects at launch (easy way out)
Pros: No loading times at all once you've started it up
Cons: High memory usage

2. Load just the menus at start-up, and then loading level-specific images when starting the level (semi-easy way out)
Pros: Lower memory usage
Cons: Load times each time you enter a level

3. Procedural loading, which loads images in a separate thread, while you're progressing through the level (hard way)
Pros: Very low memory usage, and no (visible) load-times
Cons: Hard to implement; prone for errors; what if the image takes longer to load than we want it to (player is shot through a cannon or something, and moves so fast through the level, that the loading of new things can't keep up

From a gamer's viewpoint, obviously the first one would be preferable, and 50-60mb isn't really that much, but with game-objects and sounds and everything, it might end up being 200mb of memory usage. Is this acceptable?

- Jonas
Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #1 - Posted 2012-07-18 21:35:04 »

I really think 200mb is okey. But this wouldn't really be the proper way Cheesy

The proper way to do this, would be point 2 from your list Smiley
EDIT: IMO Grin

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline ra4king

JGO Kernel


Medals: 341
Projects: 2
Exp: 5 years


I'm the King!


« Reply #2 - Posted 2012-07-18 21:41:13 »

I disagree, option 1 is the best option, also since if you are using OpenGL, textures are stored in VRAM anyway. If the rest of the 200MB is audio....then you have different problems Wink

Stay well away from Option 3 Grin

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

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #3 - Posted 2012-07-18 21:51:45 »

I disagree, option 1 is the best option, alask since if you are using OpenGL, textures are stored in VRAM anyway. If the rest of the 200MB is audio....then you have different problems Wink

Stay well away from Option 3 Grin
You're very kind to assume I'm using OpenGL, but I'm actually still using Java2D Wink I don't find it so slow at all, for my needs. As long as you code with performance in mind from the beginning, it really performs well.
I'm definitely going to try working with lwjgl and libgdx, and possibly some other libraries, before doing any coding on the sequel ^^
I'm trying to do a big project with Java2D, as to really feel why I should have a need for OpenGL. So far I don't see it, but I hope I will. You could say I'm already seeing it, since I realize none of what I'm doing is taking advantage of the GPU or VRAM, but for my little 2D worlds, I'm havng a hard time seeing why I should change before I hit 3D.

Would number 1 still be a viable option if I'm not using Java2D?

And thanks for the warning about option 3. I was really fearing that one.

- Jonas
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #4 - Posted 2012-07-18 21:53:07 »

Well, different games different methods. You decide really. For relatively small games, I'd just load it in at once. Your audio don't have to be massive too - look into vorbis (I don't work a lot with audio, but I'm fairly sure that's what it's called). If you end up having too much, and it takes too long you might want to rethink.

Think about how many and how long loading screens you want to offer your players. Program your game without hotswap a few hours, and you'll notice if the load is unbearable.

Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #5 - Posted 2012-07-18 21:59:04 »

Thanks. For now it seems to take about 1 second to load 1 tileset, 1 player and 1 monster. I'm thinking that, as long as I make a loading screen, with info which is about as funny as The Sims, it shouldn't bother players too much. Personally, I find it much more frustrating to wait each time I enter a map, than to wait a bit when I start the game.

- Jonas
Offline davedes
« Reply #6 - Posted 2012-07-18 22:04:15 »

Ideally you should pick option 3, but it would be a challenge to implement and may not be worth the effort for a simple game.

Option 1 is the "worst" choice IMO -- having long wait times at the beginning of an online game is a sure way to lose players. Who wants to wait more than a minute just to load a casual web game?

Another idea would be to load only the bare minimum when the game first boots up -- so that the user can immediately see the main menu -- and then load all of the assets once the user decides to hit "Play."

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #7 - Posted 2012-07-18 22:25:46 »

Nah... I totally disagree with Option 3.

But that's only for Level-based systems. I'd propably decide Option 3, if I had only 1 big world map for example, so something like a open-world, when It would actually make sense to limit the stuff loaded, and where there are no seperated "levels".

If you have Levels, I'd totally go with Option 2, (as already said). That's because you usually have to load the level itself, I'd just go with loading the assets at the same time. This is what Portal [2], Team Fortress, many other FPS and whatnot does.

But I agree with Mads about Option 1. In case you only have a bit of data to load, it wouldn't be too bad to just load everything at startup (propably with loading-screen), but since you have 2 artists, and think they would produce a lot of artwork, I think that option could not be the best.

Also, you said you would need 1 second for 1 tileset 1 player and 1 monster. Is that true? Is it really a second, or just a couple of milliseconds? How many pixels are there? What Image format? Cause I'm wondering. This shouldn't actually take that long.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #8 - Posted 2012-07-18 22:30:54 »

Ideally you should pick option 3, but it would be a challenge to implement and may not be worth the effort for a simple game.

Option 1 is the "worst" choice IMO -- having long wait times at the beginning of an online game is a sure way to lose players. Who wants to wait more than a minute just to load a casual web game?

Another idea would be to load only the bare minimum when the game first boots up -- so that the user can immediately see the main menu -- and then load all of the assets once the user decides to hit "Play."

I like your last remark. You can definitely load something like the main menu, and then let the player set up characters while a different thread loads. This applies to any game, but one might want to ask oneself how much of a necessity fast loading for the particular game is.

Your other lines are making an assumption that I don't feel is fair. You assume that there is tons and tons of data. In 99% of the games here on JGO, this is not the case. If that is the case, you cant even load all of it because of RAM restriction, and there would be a lot of unnecessary loading.

For one second, you barely even need to inform the player what he is waiting for. If you make a loading screen, you can definitely make people wait ten seconds (enormous amounts of data can be read), and if you make it the sligtest bit interesting (reading, tips, or interactive), you can get away with a lot more loading time!

Offline StumpyStrust
« Reply #9 - Posted 2012-07-18 23:30:26 »

Like most have said, for smaller games option 1 is much better as you will not be loading gigs worth of textures and 3D models. I use to play a crap load of flash games on kongregate and some games had rather long load times (5-10mins) and thats not including DL time but what I hated most was having to go through a loading screen every time the game changed rooms or something. A one time loading screen with maybe a few sec delay between room transfers would be *kiss* magnificent.

Option 2 is typical for games and option 3 is like....boy oh boy I don't think I could ever do that.

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

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #10 - Posted 2012-07-18 23:47:43 »

Thanks for all the great replies. For now, I don't know exactly how much data I'm going to end up with, so I'll go ahead with Option 1, while still considering I have to be able to smoothly go to Option 2 whilst coding. Shouldn't be too hard with a tilemap and a few backgrounds.

About the 1 second load-time, while merely a quick assumption, it holds true. It's just 27 images so far, racking up a staggering 41kb. When I added my new backgrounds (240kb), it jumped to 4300ms.
That's a LOT!

I'm loading them all from my jar-file using something similar to this (placing it in a HashMap for easy reference):
monsterImages.put("MonsterWalking1", ImageIO.read(getClass().getResource("/resources/monsterImages/MonsterWalking1.png")));

Is that bad? I thought ImageIO was the way to go. I AM on a crippled laptop, but it does have a dual-core. I don't get it.

- Jonas
Offline Cero
« Reply #11 - Posted 2012-07-18 23:48:32 »

We are making a big 2D sidescroller and were obviously using Option 2
because if that we weren't really worried about mapchange time
it now is way to long and we have to cut some things and optimize

my point is option 1 is simply not possible, the game would load for an insane amount of time
option 3 is really advanced and hard to do, without lags n stuff.

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #12 - Posted 2012-07-18 23:50:21 »

Thanks for all the great replies. For now, I don't know exactly how much data I'm going to end up with, so I'll go ahead with Option 1, while still considering I have to be able to smoothly go to Option 2 whilst coding. Shouldn't be too hard with a tilemap and a few backgrounds.

About the 1 second load-time, while merely a quick assumption, it holds true. It's just 27 images so far, racking up a staggering 41kb. When I added my new backgrounds (240kb), it jumped to 4300ms.
That's a LOT!

I'm loading them all from my jar-file using something similar to this (placing it in a HashMap for easy reference):
monsterImages.put("MonsterWalking1", ImageIO.read(getClass().getResource("/resources/monsterImages/MonsterWalking1.png")));

Is that bad? I thought ImageIO was the way to go. I AM on a crippled laptop, but it does have a dual-core. I don't get it.

If you're not using a sprite atlas.. Something about having a bad time.

Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #13 - Posted 2012-07-18 23:55:51 »

If you're not using a sprite atlas.. Something about having a bad time.

Yeah, I guess I should get around to that, huh? Smiley
Thing is, I only have a few test-images implemented so far, and I haven't made sprite-atlases for them.

I must admit I wasn't really sure why they were so loved and sought after, but I guess this is the reason. Insane load-times with multiple image-loads. I didn't think it was that big a deal...

But then how can it take 3000ms to load 2 backgroundImages worth 100-140kb each? They're 1366x768, but gosh darn it that's a lot of time!

EDIT: I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it's a low-compression jpg or a huge bmp. Silly Catface

- Jonas
Offline davedes
« Reply #14 - Posted 2012-07-19 00:08:11 »

They are mostly useful for OpenGL games that aren't using multi-texturing, texture arrays, or other modern techniques. For these games (e.g. Slick2D games) you can only have one texture bound by OpenGL at a time. Binding a new texture is not free -- and binding many textures per frame will cost you. Also, if you're batching sprites (like in LibGDX or Slick's VertexArrayRenderer), switching to a new texture requires "flushing" the batch.

For these reasons, at least for an OpenGL game, sprite sheets should really be the first thing you do when optimizing performance, as they can greatly reduce texture binds. A software renderer (Java2D) won't benefit much from sprite sheets, but since Java2D may take advantage of hardware acceleration under the hood (depending on the platform), it seems like a good idea to use them anyways.

1366x768 is insanely huge and probably unnecessary. Have you thought about using tiles? Or vector graphics? And what do you mean by this:
Quote
I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it's a low-compression jpg or a huge bmp. Silly Catface

Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #15 - Posted 2012-07-19 00:20:20 »

1366x768 is insanely huge and probably unnecessary. Have you thought about using tiles? Or vector graphics? And what do you mean by this:
Quote
I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it's a low-compression jpg or a huge bmp. Silly Catface

Well, for the background I was just thinking of having 2-3 such backgrounds per level side-by-side, that scroll a tiny bit with the player, so you start off the level just viewing the first image, and then veeery slowly you scroll into the second image when moving right. I'm doing parallax-scrolling, so other than that background, there'll be a layer of clouds and such represented by small images placed around the map in various positions, which move a little faster than the background, also relative to the player.

What I meant, was that if I load an image, whether it's a bmp of 4mb or the same image compressed as a jpg, it'll have just as many pixels representing it when loaded to memory, right?

- Jonas
Offline StumpyStrust
« Reply #16 - Posted 2012-07-19 00:35:39 »

Not sure if this would work but maybe lower the resolution of your background images keeping the aspect ratio of your game in check as well. Then scale them when you render. This would cost more cpu I guess (although I never see a performance hit) but it would lower your loading time and overall memory foot print.

I think the class loader is slower then just getting from a file path that is not part of a class. ImageIO.read(new File(path)); I have no proof and have not tested it but since I switched to loading from a class, I feel like things are slower.

Also, under the hood, java does a great deal on hardware. If it was all soft-ware rendering we could not get 1/10 the performance we do. The problem is, we have no control over how it is "trying" to get hardware accelerated.

 


Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-07-19 00:48:53 »

(Small confession - haven't read thread beyond OP)

I load everything at startup. But then I've only got assets that number in the tens of megabytes.

Cas Smiley

Offline xsvenson
« Reply #18 - Posted 2012-07-19 01:17:43 »

I have just this suggestion:

Take the easiest path. Once it's clear, the easiest path is not sufficient, take the next step.

On one hand, it's nice to have the resources to do a deep analysis of the problem and know everything in advance, like the amount of resources that will be needed.
On the other hand, I presonally, don't belive in this kind of system.
It is just not possible for the specifications and for the numbers *not* to change while building the system. Just not possible... maybe in NASA...
The software evolves and some parts need to be refactored or rewritten anyway.

So take the easier path, it just might be enough.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #19 - Posted 2012-07-19 06:04:13 »

Fixed by weirdness!

Not sure if this would work but maybe lower the resolution of your background images keeping the aspect ratio of your game in check as well. Then scale them when you render. This would cost more cpu I guess (although I never see a performance hit) but it would lower your loading time and overall memory foot print.
Well, I tried what you said about resizing the images and scaling them once loaded (not every render! I hope that was a brainfart ^^). This cut the load-time to 1/10!! Which made me very suspicious... I opened the image my artist sent me, saved it as a new jpg with the original resolution, and ended up with a file almost the same size as the original.
This new file, however, loads 8 times faster than with the original background!!! There must be some extra information hiding in the version he sent me. Perhaps he hasn't flattened the image, so all the layer-data was still in it. I'll ask him.
WTF?!

I think the class loader is slower then just getting from a file path that is not part of a class. ImageIO.read(new File(path)); I have no proof and have not tested it but since I switched to loading from a class, I feel like things are slower.
When I port from applet to fullscreen application, putting all my resources in folders next to the .exe instead of in the jar-file, I'll see if it changes the load-time. The original plan was to launch it as an applet, but since then we've decided to do a regular full-screen game.

- Jonas
Offline davedes
« Reply #20 - Posted 2012-07-19 06:30:10 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.

Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #21 - Posted 2012-07-19 06:51:46 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.

Yeah, I usually only use PNG for that reason. I guess he forgot to save them as PNG.
I'll take a look at that texture-loader. Thanks Smiley

EDIT: Since I'm using Java2D for all of this, I'll hold on to that link until I start work on the sequel using lwjgl

- Jonas
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #22 - Posted 2012-07-19 09:36:28 »

They are mostly useful for OpenGL games that aren't using multi-texturing, texture arrays, or other modern techniques. For these games (e.g. Slick2D games) you can only have one texture bound by OpenGL at a time. Binding a new texture is not free -- and binding many textures per frame will cost you. Also, if you're batching sprites (like in LibGDX or Slick's VertexArrayRenderer), switching to a new texture requires "flushing" the batch.

For these reasons, at least for an OpenGL game, sprite sheets should really be the first thing you do when optimizing performance, as they can greatly reduce texture binds. A software renderer (Java2D) won't benefit much from sprite sheets, but since Java2D may take advantage of hardware acceleration under the hood (depending on the platform), it seems like a good idea to use them anyways.

1366x768 is insanely huge and probably unnecessary. Have you thought about using tiles? Or vector graphics? And what do you mean by this:
Quote
I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it's a low-compression jpg or a huge bmp. Silly Catface

I believe it is faster to load one big image than ten small, even if its not because of texture binding.

Offline Grunnt

JGO Wizard


Medals: 66
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #23 - Posted 2012-07-19 15:19:39 »

As long as you show a nice loading screen (maybe even with a progress bar), some loading time is just fine. With such a small amount of resources (anything < 100MB on 1GB+ machines should hardly be a problem) loading everything at the start (option 1) gives by far the best user experience IMHO.

Overall option 2 just multiplies the total loading time for the user (because you'd have to load the same resources over and over again), and option 3 is frickin hard to get right (usually will result in stuttering and other horrors or just crash the game due to some complex bug).

So option 1 has my vote Grin I find this relatively easy to implement using game states: make loading resources a separate game state that runs before everything else. I think you may also need some resource manager that can load and hold all resources at the start and make them available to game components when needed (e.g. something like http://slick.cokeandcode.com/wiki/doku.php?id=resource_manager_tutorial).

P.s. consider using Slick (http://slick.cokeandcode.com/) if you find that the game runs too slow after all. It's quite easy to get started with and gives good performance.

Good luck!

Offline StumpyStrust
« Reply #24 - Posted 2012-07-19 16:06:36 »

Quote
Well, I tried what you said about resizing the images and scaling them once loaded (not every render! I hope that was a brainfart ^^). This cut the load-time to 1/10!! Which made me very suspicious... I opened the image my artist sent me, saved it as a new jpg with the original resolution, and ended up with a file almost the same size as the original.
This new file, however, loads 8 times faster than with the original background!!! There must be some extra information hiding in the version he sent me. Perhaps he hasn't flattened the image, so all the layer-data was still in it. I'll ask him.
WTF?!

Yeah I meant after you load them and yes, you can save things at very high quality (especially with photoshop) which really bloats the files.
I dont think you can save layer information in jpg. I would also try using png and saving things at a lightly lower quality. It is what I do and you lose very little detail if you do it right.

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #25 - Posted 2012-07-19 18:58:15 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
I totally agree. For me JPG is a no-go. I've never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.

Also, better try out a lower compression for (in case you use them) your PNG's. I've heard it around the TMW (The mana world) wikis, that saving PNG's with commpression grade "6".
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade "6" (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #26 - Posted 2012-07-19 19:04:41 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
I totally agree. For me JPG is a no-go. I've never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.

Also, better try out a lower compression for (in case you use them) your PNG's. I've heard it around the TMW (The mana world) wikis, that saving PNG's with commpression grade "6".
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade "6" (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.

I thought PNG was supposed to be lossless.

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #27 - Posted 2012-07-19 19:06:23 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
I totally agree. For me JPG is a no-go. I've never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.

Also, better try out a lower compression for (in case you use them) your PNG's. I've heard it around the TMW (The mana world) wikis, that saving PNG's with commpression grade "6".
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade "6" (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.

I thought PNG was supposed to be lossless.

Eh. yes it is... You can still compress something, even if it should be lossless.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #28 - Posted 2012-07-19 19:11:24 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
I totally agree. For me JPG is a no-go. I've never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.

Also, better try out a lower compression for (in case you use them) your PNG's. I've heard it around the TMW (The mana world) wikis, that saving PNG's with commpression grade "6".
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade "6" (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.

I thought PNG was supposed to be lossless.

Eh. yes it is... You can still compress something, even if it should be lossless.

Oh.. well.. That's peculiar. Photoshop doesn't let you choose.

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #29 - Posted 2012-07-19 19:17:26 »

You can also try using Matthias' pure java decoders to see if those improve load times.

Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more "lossy" i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
I totally agree. For me JPG is a no-go. I've never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.

Also, better try out a lower compression for (in case you use them) your PNG's. I've heard it around the TMW (The mana world) wikis, that saving PNG's with commpression grade "6".
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade "6" (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.

I thought PNG was supposed to be lossless.

Eh. yes it is... You can still compress something, even if it should be lossless.

Oh.. well.. That's peculiar. Photoshop doesn't let you choose.

Really? omg... I just googled it and it seems to be true :O

I just found this forum question on google: http://newsgroup.xnview.com/viewtopic.php?t=4101
Just another guy confirming, that compression level 6 would be the best.
Oh, and I always thought such compression levels only apply on gimp...
And finally, if your artists are using Photoshop it looks like photoshop automatically saves png's with compression level 6 by default, so my suggestion wouldn't help you...

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Pages: [1] 2
  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.

CogWheelz (13 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!