Loading is too slow, especially texture loading

[SaturnV]

Those data is taken from my game log.

Main assembly loading time not included (3.24 seconds)

Obviously, texture loading hurts, anyway to improve that?

[zzz]

[deleted]

I need to shut up

Edited August 30, 2013 by zzz

[Satiagraha]

I agree that the loading is much too slow (especially for experimenting with small changes in your rocket design).

Perhaps at the very least, we can add back in the navigational menu buttons to jump directly to different areas (tracking station, VAB, etc.) so that we don't have to load the damn space center every single time you want to switch between areas?

[Harguinxx]

With a testing area (flat surface with easy twikable atmosphere and gravity) you would need a lot less proper launches as we know right now. Also don't expect a high performance in an alpha please, we can talk about this threat when at least we have a Beta.

[Prophes0r]

Did the performance in 0.21.1 get significantly worse though? Or is it just me? I don't remember it taking 30-40 seconds to load from the VAB to the launchpad with a 3 part rocket in 0.19.

[SpaceHole]

Maybe we could ad an option to enable physics in the Building-Area to test at least if it snot falling apart instantly to save time?

Also one thing i was wondering about - i heard that ingame textures will be used in an uncompressed format. Why cant formats like jpeg etc. not be used ingame?

Edited August 31, 2013 by SpaceHole

[technicalfool]

Also one thing i was wondering about - i heard that ingame textures will be used in an uncompressed format. Why cant formats like jpeg etc. not be used ingame?

JPEG is a lossy file format, which may save some (actually quite a lot of) space on the disk, but would not save any space in RAM, as it would need to be decompressed upon load. It can also look like utter pants if you compress stuff too tightly.

There are texture compression formats that graphics cards use and that will keep the texture in a compressed format in video RAM, however these are separate from the compression used to store the file. The main format that you'll hear about for this is S3TC, which is also a lossy format. Basically, you can have texture compression, but the textures will not look as good.

That said, it would be a nice option to have, for people who have less video RAM in their graphics cards, or who are operating on shared-RAM chipsets, such as laptop machines.

[Tiron]

Most likely it's caused by the fact that it does SOMETHING to massively inflate the size of textures:

ISA Mapsat's maps, for example, end up taking up about 600MB of RAM when loaded. That's 20MB *per Map*. Compressed, they're around 2MB each(Except the Blank, which is 38 kb.) Uncompressed, about 8MB each. Uncompressed with the Mipmaps in VTF format came out to 10.6MB. I have yet to see the memory usage vary substantially based on the number of completed maps, which is a good indicator that it's probably loading even the blanks as uncompressed textures.

This is a pretty good indicator that something really goofy is going on, like it's upscaling them AND uncompressing them, or something similarly stupid. No wonder it takes awhile to process.

Edited August 31, 2013 by Tiron

[Nuke]

this is one of the 50 reasons we need *.dds textures.

There are texture compression formats that graphics cards use and that will keep the texture in a compressed format in video RAM, however these are separate from the compression used to store the file. The main format that you'll hear about for this is S3TC, which is also a lossy format. Basically, you can have texture compression, but the textures will not look as good.

actually textures will be smaller and allow for higher resolutions where needed. it takes 4 bits per pixel to store dxt1, which is 6 times smaller than uncompressed 24-bit rgb, so you can move up to the next power of two and it will still be smaller than the uncompressed version. if you need to do things like normal maps or maps with alpha, you can still double the size and break even. this makes the artifacts a reasonable tradeoff. loading times are improved because you dont have to uncompress a storage format, and convert it to a memory format (this is why loading pngs is slower than loading tgas). its already in the format the video card can read so there is zero processing, it just goes directly from disk to video card.

Edited August 31, 2013 by Rich

[Climberfx]

this is one of the 50 reasons we need *.dds textures.

Hey Man, don't forget DDS is only for PC Windows. Won't open on Mac or Linux without convert.

And KSP is for all of us!

[Nuke]

Hey Man, don't forget DDS is only for PC Windows. Won't open on Mac or Linux without convert.

And KSP is for all of us!

this is completely wrong. while d3d has its own designations for the formats, they are not microsoft formats. they were developed by s3 a long time ago and are supported by almost everything. *.dds is just a texture of one of those formats, saved to disk and given a file extension. there is no reason you cant use that format on linux or macosx, you just need to have software that can read/write to that format. one example of a cross platform game that uses .dds textures is freespace 2 open (which uses opengl), which works on all the platforms that ksp does.

[Captain Sierra]

Warbirds (flight sim) uses .dds.

Personally, I'd like to see some form of dynamic part loading.