> You've just re-implemented the managed memory pool. You might as well
> load it all into managed memory and let the runtime do the streaming.
> It will probably do a better job than you could.
Probably, but it would have the side effect of the texture changing each
frame, as far as I can see.
Currently I define a videotexture object which is mapped unto various
objects. The texture is the same, but the content is different.
If I create a texture for each frame (that is what you are saying, right?)
then I need to swap the used textures every frame.
Ok,after considering itsome more.. in a way that is not a problam. It would
require some redesign, but now I set fill texture1,texture1,render object1,
fill texture2,set texture2, render object2 and so on. Your suggestion would
mean that i fill all textures, set texture1.1,render object1, settexture2.1,
render object2, set texture 1.2, render object1 etc. It should be about the
same. might be wordh a try.
> Then again, since you already have this written you could just leave
> it unless its buggy or a problem.
I think your solution has a cleaner look to it and for smaller textures, or
graphics cards with large memory, my solution would still always write all
bytes for one texture every frame, while yours would probably do it once and
then the textures are already in video memory during the next render call.
> Either way, compressed textures will be a win.
I will try it out. My only fear now is that the image quiality will be too
degraded. I will just have to try it and see.
Thanks for the info.
