Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / loading hi res image takes very long time (and a couple other texture ?s)

Author
Message
Cigaboo
18
Years of Service
User Offline
Joined: 12th May 2006
Location:
Posted: 16th Jun 2006 08:02
Link
I want to load a 4814 x 3818 jpeg image in my (dbpro) game. It's compressed to 3MB. Problem is, it takes like 40 seconds to load in my compiled exe. I am curious why this occurs, as opening the image (for viewing) in any other windows program takes about 2 seconds. I have tried converting it to a dds, changing the texture to a power of 2, and various other things. It seems like the loading time is entirely dependent on the pixel size of the image.

Also, do textures typically perform better if they are a power of 2? Does dbpro have to convert unconventionally sized textures so that they are a power of 2 and is there an overhead to this?

Lastly, I have a missle in my game that produces a missle trail. The missle trail is composed of flat planes with a "smoke puff" PNG image with an alpha. The smoke puffs all rotate, scale, and change opacity to give the effect of disipating smoke. Also, they face the camera at all times. The problem is, seemingly randomly the alpha either blends properly with what is behind it, or ignores everything behind it except my black backdrop. It looks incorrect, like a solid image, when it blends with my black backdrop and ignores all the other objects in the scene.

Any advice on any of these would make my life easier Thanks.
Back to top
Profile PM
spooky
22
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 16th Jun 2006 09:51
Link
Just tried same test. Big 3.2MB jpgeg 4814*3818

Load image takes 35 seconds

Reason is because DBPro defaults to loading images and automatically creating mipmaps for use in 3D.

You can reduce load time to 2 seconds if you add the optional ,1 on end of load image command to tell it not to create mipmaps

But I would strongly advise you are doing something wrong if you need an image that big and using it in game will be slow as hell. What is the image of?

And yes, keeping images to a power of 2 is always a good idea as lots of graphics cards only allow square textures on 3d objects.

Boo!
Back to top
Profile PM Website
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 16th Jun 2006 11:37
Link
4814 * 3818 * 4 bytes = 73.5 Megabytes, just for one texture. Compressing it to a jpeg is actually worse computationally, because it has to decompress it before it can be used.

Like Spooky says, your issue may be the way you are building your game, rather than the size of your single image.



Back to top
Profile PM Email
Cigaboo
18
Years of Service
User Offline
Joined: 12th May 2006
Location:
Posted: 16th Jun 2006 21:43
Link
Thanks for the responses, guys. The reason this image is so large is because I want to use public domain satellite/arial photography as my terrain texture. I hate to give it up because it looks pretty cool on my terrain, and is consistent with the visual style I am seeking.

Batvink is probably correct in that it maybe becomes significantly larger size when it is decompressed. But I suspect dbpro is inefficient for some reason with large textures - the same texture loaded into Milkshape3D, for example, takes like 5 seconds to load. Also, Worldwind, the 3D satellite photography program from which it was acquired seems to load and display the images much faster on it's mesh (although I did notice it seems to load them in 512x512 dds chunks). Is there something hardware accelerated about 512x512 dds images?

I didn't notice slowdown once the image is loaded, though.
The optional 1 (to prevent mipmap generation) at the end of load image does not seem to affect it's load time.
Back to top
Profile PM
Three Score
20
Years of Service
User Offline
Joined: 18th Jun 2004
Location: behind you
Posted: 16th Jun 2006 21:53
Link
why not just scale it?

JouleOS and friends
great thanks to http://galekus.com for FREE HOSTING!
Back to top
Profile PM Email Website
Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 16th Jun 2006 22:14 Edited at: 16th Jun 2006 22:15
Link
Try knocking it down to 256 colours. Use adaptive palette, no dither.

Back to top
Profile PM Email Website
Cigaboo
18
Years of Service
User Offline
Joined: 12th May 2006
Location:
Posted: 16th Jun 2006 22:23
Link
I will probably reduce the size to half of it's current pixel size now - 2407 x 1909. But the person viewing it will be pretty close, so I can't probably go less than that without significant blurring. It looks like the end result of texture memory consumption depends on pixel size, so I should probably consider an image format other than jpeg to squeeze more more detail for every pixel even if the image takes up more hard drive memory as a result.

Is there a way to calculate the amount of video ram consumed by a texture? Obviously, my game can't require more than 128MB video memory if I want to have a significant market!
Back to top
Profile PM
Crit
18
Years of Service
User Offline
Joined: 24th May 2006
Location:
Posted: 16th Jun 2006 22:32
Link
What about breaking it up into several 512x512 images, applying each one to a different plain or mesh object. Should load faster and keep the quality you're looking for.


WIP Thread:http://forum.thegamecreators.com/?m=forum_view&t=80964&b=8
Back to top
Profile PM
Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 17th Jun 2006 01:52
Link
Knocking it down to 256 colours is the same as halving the size of it, but you loose nothing. It will look exactly the same. I'll bet you that not one pixel will be altered.

Back to top
Profile PM Email Website
Cigaboo
18
Years of Service
User Offline
Joined: 12th May 2006
Location:
Posted: 17th Jun 2006 07:31
Link
Thanks for the responses. Crit- why would breaking it into 512x512 images (on separate meshes) result in faster theoretical loading? Pincho - I think the image is currently at 256 colors (I checked in the GIMP). I'm pretty convinced that the pixel size seems to be the determining factor.
Back to top
Profile PM
Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 17th Jun 2006 13:42
Link
Post the image on here.

Back to top
Profile PM Email Website
Crit
18
Years of Service
User Offline
Joined: 24th May 2006
Location:
Posted: 17th Jun 2006 22:47 Edited at: 17th Jun 2006 22:54
Link
OK, forget what I said about breaking it up. I tried it and it doesn't help. Spooky was totally right about DB creating mipmaps on the fly. Solution: Save your JPG file as a DDS file. I had to change the resolution to 4096x3840 for a DDS export, but here are the results:

JPG - 13.98 seconds to load
DDS - 3.4 seconds to load
[edit]
JPG using Spooky's solution: 1.2 seconds.

[end of edit]



If you have Photoshop, you can find a dds plugin here.
http://www.nvidia.com/object/photoshop_dds_plugins.html

It adds dds to the "save as" list. It also includes a cool normal map filter that I'll have to check out...


WIP Thread:http://forum.thegamecreators.com/?m=forum_view&t=80964&b=8
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-09-25 01:33:35
Your offset time is: 2024-09-25 01:33:35