aalex

I am still looking for the most efficient way of managing multiples textures for animated sprites. I chose Lua for doing most of the work, because we can draw rectangles using only OpenGL functions, thus not resetting the transformation matrix on every loop. I need to unload and reload some textures between each scenarios, which are small 2D games. Below is the Lua function I use for loading a new texture :

texture = jit.new("jit.gl.texture", this.drawto)

(maybe setting the .dim and .name attributes is useless) I observed that using many small films read by jit.qt.movie is slower (FPS speaking) than using many textures that are already loading on the GPU. Of course ! The thing is that the VRAM is limited. I tried to loadram the jit.qt.movie, but it is still pretty slow when playing 6 movies that are 100 X 100 px.

I think that the best bet would be to load the textures from a list PNG files before every scenario starts. At the end of the scenario, I would delete those texture objects, or something.

I know that is it possible to load texture by sending a message to the jit.gl.render : would this approach use less RAM or be faster than using many jit.gl.texture ? I am not much concerned about RAM, but VRAM seems to be an issue. I didn't find any VRAM monitor application for Windows (yes, it uses Windows XP).

Otherwise, is there a way to optimize the jit.qt.movie playback ? I tried sending it the message "loadram" before, and after the "read " message, but it is still slow.

Hi, 
I am still looking for the most efficient way of managing multiples textures for animated sprites. I chose Lua for doing most of the work, because we can draw rectangles using only OpenGL functions, thus not resetting the transformation matrix on every loop. I need to unload and reload some textures between each scenarios, which are small 2D games. Below is the Lua function I use for loading a new texture : 

function createTexture(filename, w, h)
  texture = jit.new("jit.gl.texture", this.drawto)
  texture.dim = {w, h}
  texture:read(filename)
  texture.name = filename
  return texture 
end

(maybe setting the .dim and .name attributes is useless) I observed that using many small films read by jit.qt.movie is slower (FPS speaking) than using many textures that are already loading on the GPU. Of course ! The thing is that the VRAM is limited. I tried to  loadram the jit.qt.movie, but it is still pretty slow when playing 6 movies that are 100 X 100 px. 

I think that the best bet would be to load the textures from a list PNG files before every scenario starts. At the end of the scenario, I would delete those texture objects, or something. 

I know that is it possible to load texture by sending a message to the jit.gl.render : would this approach use less RAM or be faster than using many jit.gl.texture ? I am not much concerned about RAM, but VRAM seems to be an issue. I didn't find any VRAM monitor application for Windows (yes, it uses Windows XP). 

Otherwise, is there a way to optimize the jit.qt.movie playback ? I tried sending it the message "loadram" before, and after the "read " message, but it is still slow. 

frames-loading-unloading

You might consider loading the frames of your animations into a larger

grid texture and use texcoord manipulation to animate the sprite. Since

your movies are only 100x100, you should be able to fit several frames

into one texture. Of course, your VRAM will be the limiting factor.

For a Jitter patcher based solution, you might check out the Jitter

Recipe called Tiny Video. You can find it here:

https://cycling74.com/story/2006/2/17/153427/406

Hello,
You might consider loading the frames of your animations into a larger
grid texture and use texcoord manipulation to animate the sprite.  Since
your movies are only 100x100, you should be able to fit several frames
into one texture.  Of course, your VRAM will be the limiting factor.

For a Jitter patcher based solution, you might check out the Jitter
Recipe called Tiny Video.  You can find it here:
https://cycling74.com/story/2006/2/17/153427/406

Does this technique use less VRAM at all ? It's probably not so significant.

I just have done more tests with many textures, and it's about twice as fast as playing jit.qt.movie. What I need to figure out is : how can I completely free the VRAM that a jit.gl.texture uses ?

Does this technique use less VRAM at all ? It's probably not so significant. 

I just have done more tests with many textures, and it's about twice as fast as playing jit.qt.movie. What I need to figure out is : how can I completely free the VRAM that a jit.gl.texture uses ? 

The OS manages VRAM based on its best guess as to what is needed in

the near future. If you texture:bind() texture:unbind(), it will

probably (I say probably because I haven't verified) get loaded onto

the GPU so that your next use will be more responsive. If your

animations aren't very long, load them into one giant texture and

This is a tricky area and I'm not sure what best practice here is, so

you're just going to have to play around with things to see what works

> Does this technique use less VRAM at all ? It's probably not so significant.

> I just have done more tests with many textures, and it's about twice as fast as playing jit.qt.movie. What I need to figure out is : how can I completely free the VRAM that a jit.gl.texture uses ?

The OS manages VRAM based on its best guess as to what is needed in
the near future.  If you texture:bind() texture:unbind(), it will
probably (I say probably because I haven't verified) get loaded onto
the GPU so that your next use will be more responsive.  If your
animations aren't very long, load them into one giant texture and
animate by texture coordinate offsets.

This is a tricky area and I'm not sure what best practice here is, so
you're just going to have to play around with things to see what works
best.

On 8/2/07, Alexandre Quessy  wrote:
>
> Hi,
> thanks for the suggestion, Andrew.
>
> Does this technique use less VRAM at all ? It's probably not so significant.
>
> I just have done more tests with many textures, and it's about twice as fast as playing jit.qt.movie. What I need to figure out is : how can I completely free the VRAM that a jit.gl.texture uses ?
>
> Thanks !
>
> a
>


Frames loading & unloading