What would be the smartest way of putting raw byte data , describing ARHB
texels, into a compressed texture?
I have a binary file which consists of framedeta for a video. Currently I
reead this into a locked texture and use it.
This could be changed into a method with transforming the binary data into
the data used in the compressed texture and doing the same write, but that
puts the job of converting the 4x4 texel blocks into compressed format onto
me, and I would have to rewrite the code if I change the format.

What would be a simpler solution? To transform the data by reading it into a
normal texture, as I do now, and then copying its surface into another
texture which is compressed and finally reading out the binary data from the
compressed texture?

Suggestions are welcome.

[Please do not mail me a copy of your followup]

"John Withe" spake the secret code
<47c2eb85$0$99014$157c6196@dreader2.cybercity.dk> thusly:

The smartest way is to do it at development time and ship with
compressed textures.

If your textures are dynamic and can't be compressed ahead of time,
then load the texture into a plain surface in system memory and use
D3DXLoadSurfaceFromSurface to transfer it to a compressed surface.
The target surface can be wherever you like -- D3DX will handle the
different situations accordingly. There are other compression
libraries from NVidia that you can use in place of D3DX, but D3DX is
already there so you might as well use it.

This is only worthwhile if you infrequently load the texture data and
frequently draw it. Otherwise the overhead of compression is too
high.

I ship the application and the end user uses it to display user defined
scenes with user defined movies in it, so I need the application to be able
to read an arbitrary movie and use its frames as textures. The actual
displaying needs to be fast, but if the conversion can be done ahead of
time, thus alowing a fast load, then it is fine.

[Please do not mail me a copy of your followup]

"John Withe" spake the secret code
<47c31f60$0$89169$157c6196@dreader1.cybercity.dk> thusly:

Yes, in that case I would do the conversion in system memory and save
out the compressed form to a cached folder/file. This will speed
subsequent loads. Storing lots of uncompressed frames in memory will
eventually exhaust video memory and result in texture thrashing
between system memory and video memory as you run through the video
frames.

Ok. Good to have confirmation that this makes sense.

The way I do it now is to have a lot of memory (64 bit system) and store the
data in a huge 2d array. I only have a single texture to which I copy. That
should not be a problem as far as I can see?

Could you comment on the way I move the data? Does it seem sensible or
should I go about it differently?

[Please do not mail me a copy of your followup]

"John Withe" spake the secret code
<47c33578$0$99022$157c6196@dreader2.cybercity.dk> thusly:

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.

Then again, since you already have this written you could just leave
it unless its buggy or a problem.

Either way, compressed textures will be a win.

"John Withe":

That is a problem, and one of the most frequently discussed topics here.

Gruss

Jan Bruns

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.

ok? I can not seem to locate discussions about it.
Would you care to elaborate?

"John Withe":

Say you have a render-loop like this

1. beginscene draw endscene
2. present, goto 1

This (at most) guarantees that there will be well defined contents visible on the screen.
But you can't decide when this will really happen. Any of the d3d calls may return
immediatly, because they just add a token to the gpu's (or driver's) task-list.
We just defined what wil be visible on the screen, may it be yet or some other day later.
Assuming the loop can run faster on CPU then the gpu can execute it, there will be
some kind of a blocking call in the loop whenever the driver/gpu doesn't want to
accept more tasks (note that this blocking call isn't always present()!).

Let's include a (discard-mode) lock,

1. lock, copy, unlock
2. beginscene draw endscene
3. present, goto 1