OpenGL纹理贴图效率问题!100分,不够可以再加,最多给1000分!

JerryGR 2002-04-16 07:03:28
我现在想不断的刷新纹理图像的内容,但找不到很好的方法!

对于大图像的纹理贴图,效率不是很高!
但又不能够使用显示列表的方式(因为数据是不断更新的)
用glDrawPixel发现做放缩时速度很慢!一幅800*600放大到1024*768速度难以忍受!

所以看各位高手看看有没有很好的方法!

左右缓冲区是什么?怎么用?会不会对实时刷新纹理贴图有帮助?

谢谢,必有重谢,明天我会在此等待!
...全文
239 7 打赏 收藏 转发到动态 举报
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
chinagdh 2002-04-18
  • 打赏
  • 举报
回复
其实,看你有多大需要了。 一般游戏中用的不会有那么高的要求。
而且都会想些别的办法,如果专用,那就请用专用设备了。
搞个什么超大显存的显卡, 大约可以达到256MB以上。
想想比现在的内存还要大,你要是一个动态纹理有200MB 就完全可以用这种方法了。如果是游戏, 那我的第一个建意就是不那么用。
640x480x4 = 1228800字节,如果你以30fps播放也不过是 x30倍 = 36864000
\= 35MB 每秒需要35MB的纹理, 在我的机器上实际每秒从硬盘读取不超过20MB显然在我机器上达不到很高速度。 如果机器速度快,可考滤压缩纹理,
如果显卡支持压缩那最好。 如果不支持,需要一个快速CPU。象上面的计算可以知道正常情况下256MB显存也就只有6秒的播放。经过压缩处理的会达到几分钟到10几分钟,也就这样。如果把你的压缩纹理改用256色的数据,那么可以
达到原来的4倍。如果这样就可以做缓冲处理,前提是,你的CPU,总线,硬盘,显卡的数据传送绝对快。再有,就是你需要只放一个屏幕放动画吗?
如果是固定的,可考滤用2D的方法完成。如果不是那就请等待机器速度的提升了。目前我还没看到哪个3D游戏中有电随意播放内容的电视墙,DUKE3D中有一段,但他是把它处理成2D缩放,而且是一个1秒钟的循环动画。非常小64x64的。
抬头看路 2002-04-17
  • 打赏
  • 举报
回复
刷新subtexture
JerryGR 2002-04-17
  • 打赏
  • 举报
回复
我的纹理图像来自外部设备!
通过实际图像和3d模型模拟一个真实的环境!
所以必须高速度的刷新纹理图像!

看看各位还有没有方法!
chinagdh 2002-04-17
  • 打赏
  • 举报
回复
不刷新才好, 实时演算。得到真实效得。
不影响其它效果的方法,用一个极低占用率的线程进行更新。
可能最后每秒只有5-6frame/s
不过,不久的将来将成为现实。
ruixp 2002-04-17
  • 打赏
  • 举报
回复
我用过一段比较好的程序,280m的图像纹理,读入比较慢,但是一旦读入后,就像没有纹理一样快
chenlee 2002-04-16
  • 打赏
  • 举报
回复
另:PC上好像没什么硬件可以支持左右缓冲
chenlee 2002-04-16
  • 打赏
  • 举报
回复
在nvidia上有一篇render-to-texture的教学:
http://developer.nvidia.com/view.asp?IO=ogl_rtt

另外我想,无论用什么方法,频繁刷新大尺度贴图的效率也不会高,
dx6sdk中有一个用AVI做动画贴图的例子,不过那也只是128*128的贴图

也许你该想想有什么方法能避免刷新贴图。

16,471

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧