spek

Just added the fake draw step (the background image loading and pushing textures one by one was already implemented). Not sure if it's done 100% correctly, I simply binded the texture and drawed a triangle very, very far away from the camera (is it a problem if its outside the view frustum?).

It's still noticable when a texture gets loaded, though its more equal spread all over now. It may also be the hardware though, I get the feeling that this laptop is going to a digital heaven soon... My desktop loads the entire thing way faster, even though that videocard is slowly starting to date as well. Not only the loading goes slow, the entire game runs slow so its add up.

This would bring me to the conclusion that, like Spiro said, truly "smooth" streaming isn't possible. Then again on a more modern card it would most likely be less of a pain.

I still wonder though, old games like GTA on a PS2 did the same thing (I think). Of course those textures were really low-res, but so was that hardware 10 years ago. Though you could clearly see the scene getting loaded step by step when traveling too fast sometimes, it didn't noticably hurt the performance. And more recent games such as GTA IV are doing it with more (and more detailed) textures on "dating" hardware such as the XBox or PS3. Are they doing something really different, am I just fooled by low-res textures, or is their whole memory architecture different anyway? Just curious.

Cheers

Allright, shizzle swizzle

The image loading already happens in a background thread, and one texture per cycle is made. But I didn't do the fake drawing call, so that explains why the program still chokes.

DXT compression is also used, though I found the results often a bit too crappy for normalMaps or specular stored in alpha channels. So there are quite some textures still uncompressed. Maybe I'm not using the right compression settings (using the ATI libraryand compressing to either DXT1, DXT3 or DXT5).

Oh btw, what exactly would be a cheap way to do a fake drawing? Do I really need to draw a quad or something, or is binding enough to trigger the process?

Well, thanks, I know what to do now

Rick

Hmmm, I see.

Then that leads to the following question; how to smoothly stream a scene then? I'm sure that has been done before with OpenGL.

Seems that no matter where and how I load it, the "slap in the face" comes when walking into that room where its textures finally get rendered, right? To spread the workload, would it be a good idea to render new textures, one-by-one, in an invisible background buffer to ensure they have been handled before walking into a new room and freezing?

Second I wonder how big the impact really is. In my case, some of the bigger textures are 1024 x 1024 RGBA8 images, or even bigger ("2048 x 1024") but using DXT compression. I assume that even loading just one of those, already hurts. Or is it so small that, if I spread it out with some time intervals, it wouldn't be very noticable? For the info, I'm working on a 2009 laptop videocard, not the fastest thing in the world anymore hehe.

Thanks for the info!

Ok. Just using the default GL functions sure is easier.

But I would think glGenerate and other functions to copy image data into a buffer, involves reserving memory and such. So the idea is that if I need to load a 512x512 texture for example, it will look for an unused 512x512 buffer. If there is none, it will generate a new texture, but otherwise it uses a buffer that has already been reserved in the memory.

But maybe OpenGL already does this internally somehow?

@mrbastard

Ah, didn't read that yet. That sounds good. Though I still may want to poke for a new version at work and tell it wouldn't work otherwise hehe