1999 年 4 月留言板(上)

云风工作室

留言: 好久没有到这边来看,不想老弟的工作室内容越来越丰富,我自愧不如.
希望继续努力.

名字: winnt
E-Mail: winnt@zg169.net
主页: http://www.zg169.net/~winnt
来自: cn 202.98.117.45
Thursday, April 15, 1999 at 15:18:55 (CST)
留言: 好久没有到这边来看,不想老弟的工作室内容越来越丰富,我自愧不如.
希望继续努力.

名字: 王世贵
E-Mail: winnt@zg169.net
主页: http://www.zg169.net/~winnt
来自: cn 202.98.117.45
Thursday, April 15, 1999 at 15:12:07 (CST)
留言: 好久没有到这边来看,不想老弟的工作室内容越来越丰富,我自愧不如.
希望继续努力.

名字: 王世贵
E-Mail: winnt@zg169.net
主页: http://www.zg169.net/~winnt
来自: 202.98.117.45
Thursday, April 15, 1999 at 15:11:16 (CST)
留言: 昨天搞到ZIP 1.0的源码,不过压缩太慢,还有bug,它用到搜索办法较LHZ种树苗要快,不过还是比高版本的ZIP要慢一个数量级,也差太远了。
扔了。

名字: limoon
来自: 202.96.141.231
Thursday, April 15, 1999 at 14:50:36 (CST)
留言: bitq,蛮臭屁的嘛。:),你说速度已经不是瓶颈是不是以为每个player都在使用着P2 +MGA400?,directx的速度我知道, 封装不顶事, 还是需要一些技巧,如RLE的SURFACE,
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.100.171
Thursday, April 15, 1999 at 08:07:44 (CST)
留言: 风魂总得来说:
太简单乐
想当年,我的DOS下的基于VESA的
图形库也比它要全
希望你们能继续开发
有用,我现在用的DirectX包是个VC类库
建议不必再写汇编乐,速度已经不是视频瓶颈
关键是封装

名字: bitq
E-Mail: bitq263@263.net
主页: http://202.38.87.16/~szhao/
来自: 202.38.87.16 202.38.87.16
Thursday, April 15, 1999 at 04:34:05 (CST)
留言: 请教一个弱智问题
什么是矩阵的谱半径

名字: freemind
来自: 202.98.46.15
Thursday, April 15, 1999 at 00:15:42 (CST)
留言: 如果不出意外, 明天可以看到风魂的一个新的 demo ;-)
名字: 云风
来自: 202.103.110.201
Wednesday, April 14, 1999 at 20:11:33 (CST)
留言: 我这怎么没有 CRC 错误?
不过还是上传了一遍

名字: 云风
来自: 202.103.110.201
Wednesday, April 14, 1999 at 18:46:31 (CST)
留言: 好象 windsoul 的zip文件中compress.c CRC错误.
请重新上载一遍啦.

名字: myway
来自: BJ 159.226.21.168
Wednesday, April 14, 1999 at 18:16:00 (CST)
留言: 3000行带码, 老大,你虎。。。
I服了U哟。。。

名字: HC
来自: 195.44.0.224
Wednesday, April 14, 1999 at 10:31:45 (CST)
留言:
看了两天VB,感觉功能太弱了。做界面还可以。

名字: dai
来自: 202.103.155.151
Wednesday, April 14, 1999 at 07:58:42 (CST)
留言: 下午再来吧 xi.xi,表面也不慢哟 :)
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.112.77
Wednesday, April 14, 1999 at 07:27:51 (CST)
留言: CLOUD对CODE精益求精
精神可加,值得大家学习

名字: freemind
来自: 202.98.33.78
Wednesday, April 14, 1999 at 00:10:52 (CST)
留言: 各位高手, 大家有没有给等级为0的菜鸟的GUILD呀?
这里太高深了。。。

名字: Heaven'sCloud
来自: 195.44.0.224
Tuesday, April 13, 1999 at 12:39:51 (CST)
留言: test
名字: lll
来自: 202.102.198.137
Tuesday, April 13, 1999 at 01:36:03 (CST)
留言: 16 级就不算偷懒了 ;-) 实际上硬件支持 64K 的 Alpha 混合时就是 16 级的
我用 8 级才算偷懒, 不过好象够了. 刚才发现我的 RLE Sprite 宽度超过
256 点时有 bug, 正在解决
下一步我想将 Alpha 通道的位图支持加进去

名字: 云风
来自: 202.103.110.254
Monday, April 12, 1999 at 17:06:02 (CST)
留言: 我要对alpha混合部分再优化一下, 你使用了8 级, 我也偷懒只用了16级, 昨天在和朋友插科打诨,在玩《太阁3》,感觉KOEI越来越像square ........宁滥勿缺.
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.100.14
Monday, April 12, 1999 at 07:27:54 (CST)
留言: 我等着和 TinyHsu 的较量 ;-)
btw,等我把不压缩的 Sprite 的 ALpha 混合重写完, 就发布风魂 0.07
这次有汉字/E 文的支持, 数据包的管理.

这个留言版的 CGI 是 netease 提供的, 我动不了 :-( 大家注意
流言中写大于小于号的时候请用全角.
本来我想写的 javascript 在 post 流言的时候自动转换, 可害怕
影响刷新流言板的速度 ;-( 大家注意点吧

名字: 云风
来自: 202.103.110.125
Monday, April 12, 1999 at 04:17:10 (CST)
留言: 发现了一个BUG,删除文件会越删越多。
名字: 沐枫
来自: 202.101.116.204
Monday, April 12, 1999 at 00:47:28 (CST)
留言: 我给你的程序收到了吗?可以用吗?
名字: 沐枫
E-Mail: lin.y@263.net
来自: 202.101.116.243
Sunday, April 11, 1999 at 23:33:34 (CST)
留言: 有些游戏机硬件支持平面的 Sprite 碰撞检查 (道听途说的)
至少有专门的Sprite 的硬件控制, 现在PC 的显卡支持
显存间 Blit 就是从这个来的

名字: 云风
来自: 202.103.110.217
Sunday, April 11, 1999 at 22:00:21 (CST)
留言: 闭关两天, 重写 3000 行代码, RLE 结构全部更换, Alpha 混合代码全部更换
RLE 例程速度提高 18%, Alpha 混合提高 9%
共提高 29% ^_^
马上就可以拿出来了

名字: 云风
来自: 202.103.110.217
Sunday, April 11, 1999 at 21:00:05 (CST)
留言: 我这几天老在想
光写些程序有什么用
离一个成功的游戏还差很远呢
今天计算了一下引擎需要的人物图片
每个要80多幅,已经是省了又省
真不知何年才会完成
但我不会气馁就是了

名字: freemind
来自: 202.98.33.58
Sunday, April 11, 1999 at 20:14:22 (CST)
留言: 昨天晚上去打了一下街机,有个好象是(雷电)的特别
版,就是有五到六个飞机,可加小飞机,憋住后可放
些特别的子弹。开始还不觉的如何,后来用的一架飞机,
副枪是导弹,吃满后憋气再发射,哇,满屏的导弹加子弹。
具体数目就不知了,反正画面没延迟。
我想起以前曾打过街机的一些飞机游戏,如1945等。
有时画面的东西太多,画面会延迟,由此我想到在游戏的
进程中应有速度方面的控制作用,不然肯定会时快时慢。
不过街机有硬件,在PC上可能就复杂了。因为DX的速度
和画面等都有些关系,是否我的出发点错误,不能拿PC和
街机相比。

名字: dai
来自: 202.103.152.59
Sunday, April 11, 1999 at 11:25:27 (CST)
留言: 你们作的非常好!!!使我对编游戏发身生了兴趣!我将尽快的掌握Allegro 编程
Thank you very much!!

名字: 李晓宇
E-Mail: I don't know!
主页: I don't know what means this is.
来自: China 202.99.200.119
Sunday, April 11, 1999 at 11:06:13 (CST)
留言: 非常弱智的测试:
全屏,640 * 480 * 16 ,只是在屏幕上绘制100个64*64的spirit.
非常惊人的结果:
a:在BackBuffer上attach一个640*480的Clipper,绘制一帧要47ms;
b:不要这个Clipper,绘一帧只须不到 0.1ms !!!!!!!!

fuck Clipper!!! fuck M$ !!!
sorry,请原谅我这么激动,我快气疯了.

所以我建议在全屏模式下大家还是自己做裁剪吧...

(真想不通是为什么,可能是我的硬件Bliter不支持裁剪.my accelerator is Riva 128 )

名字: LXH
来自: 202.111.129.47
Sunday, April 11, 1999 at 09:59:40 (CST)
留言: cloudwu哟,我的RLE sprite也完成喽, 要不要再比一下呀? :)
名字: tinyhsu
E-Mail: tinyhsu@netease.com
主页: www.deep.163.net
来自: 202.96.100.86
Sunday, April 11, 1999 at 08:35:17 (CST)
留言: PCE模拟器中有一个非常有趣的特性,在HU6280中有一个SPMC内存数据段,其大小是和当前输出屏幕为一比一,256x256,312x256,在PCE的射击游戏使用的判断方法是刷新SPMC,再将SPM中的所有精灵取不同纯色影印在SPMC中来判断的,这样只需要判断机体周围很小一部分范围的的数据就可以判断碰撞,PC-ENGINE主机上这一部分工作由硬件完成, 我对STG研究不深, 不知道这样能不能减少工作量,但我所知道的是很方便的。
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.100.86
Sunday, April 11, 1999 at 08:32:59 (CST)
留言: TO:LXH
有没有搞错?做射击游戏用得着用那么麻烦办法的去检测碰撞吗?
对每2个对象之间进行判定这种方案完全可行。就算屏幕上有500枚炮弹
100个敌人(够多了吧?其实二、三十个敌人就已经铺天盖地了),也
不过是做500*100次检测碰撞,而检测碰撞无非就是几个加减和几个if
罢了,这对于每秒上亿次运算的CPU来说不过是九牛一毛。这点计算所
用时间和绘制这200个Sprite的时间比起来算得了什么?
至于计算要有多少像素相交,也不难。只要为每个Sprite定义个碰
撞检测区(定义个多边形),就可以算出两个多边型有多少像素相交,
也就是两个Sprite有多少像素相交。当然,对于射击游戏用不着那么严
格去检测碰撞,只要用个矩形就可以了。
  我个人认为没有必要过分拘泥于算法的优化上,只需要优化那些造
成速度瓶颈的算法。有些代码(比如检测碰撞)只占运行时间的很小部
分(几乎可以忽略),优化的再好又有什么用?
不知LXH老兄的射击游戏是何方神圣?物体数要达4、5位数。你可
以测试一下物体数最多时,对每2个对象之间进行判定的方法用时多少?
如果造成速度瓶颈,我也无话可说。但在我的STG游戏用这方法绝对没有
速度瓶颈。
射击游戏没有什么太多的逻辑/AI,我认为主要应该优化的是Sprite
的绘制,以及各种光影特效。
  我个人不喜欢用粒子系统,实现麻烦,效果又没有光影特效好,吃
力不讨好,即便是爆炸碎片等效果,我也作为一个物体处理,也没什么
不好。但在游戏中加入大量的光影/半透明(如激光、爆炸、烟雾、闪
烁、风、云、电),视觉效果绝对好。
  我不喜欢LXH依赖显存的方法。原来我也是利用显存双缓冲的方法,
但为了迁就Alpha Blend而改用内存BUFFER,至少内存BLIT到显存的速度
并不慢。我很欣赏云风的Alpha Blend的速度,不过好象有点小BUG,而
且才提供了八级Alpha Blend,应该是32级才对呀。
不过,我很赞同LXH关于重视游戏编程的结构性与逻辑性的观点。要
理顺游戏内部各种要素,实体之间的关系的确不简单。只有好的结构才能
写的顺手,因此我比较喜欢用C++。
不知LXH的射击游戏怎么样了,有空我们交流、交流,我也在做STG。


名字: Analyst
E-Mail: analyst@kali.com.cn
来自: 202.109.40.183
Saturday, April 10, 1999 at 20:22:47 (CST)
留言: 我也觉的碰撞的判定和实际游戏有很大的关系,
不能一概而论。

名字: dai
来自: 202.103.155.156
Saturday, April 10, 1999 at 16:52:30 (CST)
留言: To 云风兄:
看了你的帖子,我觉得我们之间差别很大,可以说是2个不同的流派.
1.总的来说,我觉得你对底层的东西研究得很深,我在这方面的道行远远不如你,所以没什么可说的.我本人侧重于游戏编程的结构性与逻辑性, 我认为这是很重要的. 程序应该从一开始就有一个漂亮的结构,而且理顺游戏内部各种要素,实体之间的关系,我觉得这个问题本身就很不简单.(要不就是我的智力有问题)

2.我正在做一个STG,在我的项目里,我的风格和你的可以说是两个极端.可能和STG与RPG的区别有关吧.

你是决不用显存,我是尽可能充分利用显存.我是这样实现的: 实体对象本身不参与绘图,所有的绘图和位图是集中处理的(这没什么).所有的位图都Load到系统内存里,当使用该位图的对象可见时,我的程序总是尝试在显示内存里建立该位图数据的一个Copy,如果成功,后续的绘图就使用显存里的这个Copy.如果该对象不再显示,就迅速释放掉所占用的显存.对于4m的显卡来说,这种动态管理的机制可以保证所有的Blit都在显存里进行.

我设计这个方案主要出于以下考虑:

1.实体对象由不可见变为可见,只是一帧内发生的事件,而以后它每存在一秒钟,就要绘制50次,因此尝试建立显存里的位图的额外开销是可以忽略不记的.再有,根据统计的观点,所有实体对象在同一帧里都产生这种操作是不大可能的.但是,所有可见的实体对象都必须在每一帧里进行绘制.

2.这种机制附带解决了显存里数据丢失的问题: 如果进行Blit时发现位图丢失,就重新进行一次尝试,万一失败,可以从系统内存保存的数据直接Blit.

3.使用显存的好处(真是废话): 我用的是华硕的V3000(chip:riva 128),它的2d加速性能在我早先的测试里曾让我大吃一惊:我的程序在窗口模式下和全屏几乎一样快.就是说窗口模式里把自建的640x480x16的BackBuffer Blit 到primary Buffer 几乎和全屏时Back 和 primary Buffer 之间的Flip一样快. 可能是在硬件Bliter的支持下,Blt函数一调用就返回了(尽管我用了DDBLT_WAIT标志). 从此我的程序没下过200fps; 不过我相信用你的s3感觉就不会一样了.

4.关于特效,你好象很重视Alpha Blend, 我是尽可能避免大面积的透明,原因不言自明 :-) ... 我比较重视实现各种粒子系统来烘托场面的动感与火爆.当然不可能和3D Max里的粒子系统一样细(它有时间,我没有),不过道理是一样的, 实现的效果是丰富多彩的.

我还有很多想法和你不一样, 有空慢慢聊.
----------------
BTW:指出你的留言板的一个小Bug: 只要我的文章里出现尖括号,你的留言版就认定我这是个超文本,让我重写.要知道,不止是超文本里的脚注才有尖括号啊...也许是大于号,小于号,对象指针和它成员之间的箭头... 你还是改改吧.

名字: LXH
E-Mail: lee@public.zz.ha.cn
主页: Xinhai.yeah.net
来自: Zhengzhou 202.111.129.26
Saturday, April 10, 1999 at 16:51:28 (CST)
留言: 昨天晚上把我的 RLE Sprite 结构推翻了, 用更好的, 结果报废了 3000 行代码
只为了大约 1% 的速度提升, 和1% 的内存节省, 有气魄吧 ;-)
等我写完了再和大家争, 先写几句.
如果所有的物体都是凸多边形. 我们看看比较检查要多少次.
每两个A 和 B比, 得出下面四个结论:
A 在 B 前, A 在 B 后, A 和 B 碰撞 , A 和 B 无前后关系
实际上, 就是 N 个数据排序的问题.
由前向后排序, 如果分不出前后, 就有可能碰撞
即使用简单的插入排序, 插入的时候简单的对份查找,
也可以避免大量的碰撞检查.
所以绝对不用判断 n*(n-1) 次

当然我赞同用 IBuffer,
只是 Ibuffer 的缺点在于, 判断比较大的物体是否有碰撞
要去判断 Buffer 里对于的所有点.
而直接碰撞检查, 往往是判断矩形或者一个垂线

名字: 云风
来自: 202.103.110.156
Saturday, April 10, 1999 at 16:27:39 (CST)
留言:
TO:LXH
其实大家说来说去也没太大的作用,
还是实际行动重要,毕竟要靠事实说话啊.
我时间不多,每天都不能保证有1小时的
时间,不过我会尽我所能去做的.
先搞个程序出来再说吧.

名字: dai
来自: 202.103.153.208
Saturday, April 10, 1999 at 16:03:55 (CST)
留言: To DAI:
My STG:
Test: PII233 , 4M VRam , Riva128 accelerator.
also in window mode, window size : 640 * 480
Frame Rate : 230 fps.
---------------
I haven't seen A-10 before, but I think it can be more faster.
I am sorry my STG not completed , once it is done , I will offer you my source code ( VC++, Win32 SDK programming style ).

名字: LXH
来自: 202.102.254.228
Saturday, April 10, 1999 at 14:23:49 (CST)
留言: 各位,首先请原谅我的固执,实际上我认为基于iBuffer的方法是解决射击游戏碰撞的唯一途径.

To 云风:
1)这个方法的本质是很简单,我上小学时用Basic编的射击游戏就用到了. 8-) . 但是目前实现的方法和功能是原来不能比的.就如Tile set engine, FC上的炸弹人比Starcraft幼稚的多,但构筑场景的基本思路是一样的, 只是实现的复杂程度有天壤之别.

2)
#define a 两两判定法
#define b iBuffer法

我们不能直接比较a和b谁快.如果10个以内的物体进行判定,我相信很可能是a快,但是:
设对x个物体进行判定,总的时间开销是y, 对于每个物体a方法判定一次耗时c(常数),b方法耗时为d(另一个常数).所以有:
对于a:
y1 = c x1(x1-1)约= cx1平方; (式1)
对于b:
y2 = d x2; (式2)
式1是一个2次曲线,式2是一条直线,无论c和d如何取值,它们总能相交(很快!),就是说不管a,b两方法判定一次的运算量如何,a方法的总开销随着参与判定的物体的数量的增加总能很快超过b方法,关于交点的位置,我估计x小于50是没问题的.
如果参与判定的物体数上了三位数,四位数...hehe...式一的二次曲线会让系统情同死机的.

To Dai:
请无论如何不要小看这个问题...
我说过参与判定的物体数可能达到三位数,对射击游戏来说一点不夸张.
几乎所有的实体对象都要参与碰撞判定,玩过'雷电2'没? 我就拿它作个例子吧, 它包含的实体对象可如下分类:
1.我方角色: = 2个
2.我方角色射击的火力: 主枪如果使用红色的大霰弹,相信 大于20个是没问题的,加上副枪一次十枚的导弹,应 大于30;因为可能是双打,所以还要乘2.
3.敌方角色: 至少应考虑 大于20 个;
4.敌方角色射击的火力: 目前的潮流是至少 100 个,玩玩'首领蜂2'就知道了.
当然还没完...
5.比如表现爆炸,火焰,导弹尾迹的粒子单位.它们的总数也很可能上三位数.
6.大型不规则物体,如体积巨大的Boss,甚至属于背景的形状怪异的山峰对我们的空中骑士而言也是致命的.
也许我还没说完,不过相信已经可以说明问题了.

关于内存消耗,我的实践证明采用1:4的比例,即160x120的Buffer就足够了,这样的Buffer需要2个,原因我上次说过了.因此共需160*120*2*2 = 76800 字节的内存,相对于我们要处理的大量位图数据,这点开销真的是很值得.


名字: LXH
E-Mail: lee@public.zz.ha.cn
主页: none
来自: Zhengzhou 202.102.254.228
Saturday, April 10, 1999 at 14:13:48 (CST)
留言:
A10的测试结果
在我的PC上 : p-166 32M 2M VRAM,WIN98,DX6.0
当将敌方对象设定成320个左右时 FPS:15
当将敌方对象设定成500个左右时 FPS:9-10
当将敌方对象设定成50个左右时 FPS:50
全部源程序和工程文件我放入信箱中,谁要看自己
去D吧.
E_mail: daibox@263.net password:12345
由于A10是在窗口模式下工作,所以我想改成全屏的
能更快,看看 雷电2 在我的PC上跑的也是飞快,
同屏的子弹等东东应该不会超过100个左右.
不过有些别的特技倒是很COOL,也不知是咋做的.

IDirectInput IDirectInputDevice
LPDIRECTINPUT LPDIRECTINPUTDEVICE

以上两种DINPUT的声明方式有何不同,对程序有何影响?



名字: dai
来自: 202.103.154.223
Saturday, April 10, 1999 at 08:08:52 (CST)
留言: 两两判断并不会做100*99那么多
一般都只同相邻的比较
不过这要利用已有的内部索引

名字: freemind
来自: 202.98.46.173
Saturday, April 10, 1999 at 02:04:56 (CST)
留言: 突然想起件事, 上次写斜视角 Engine 的时候也写过碰撞等问题的程序
其实直接两两判断也没有想象中的慢.
我们可以在做判断的时候把前后关系也理出来. 这样后面的判断可以快很多.
(大多因为前后关系而马上得出是否碰撞了)
若在理前后关系的时候, 再加个插入排序将以判断的物体
按前后关系排序, 效果更好, 新的物体先用
2 分查找定位,看附近的几个物体是什么, 然后在就进判断
(不过这个方法对非凸多边形还要进一步处理)

名字: 云风
来自: 202.103.110.223
Friday, April 09, 1999 at 20:55:08 (CST)
留言: 我前两年写的一个射击游戏就是用的这个方法 ^_^
我找.... 好象还找的到那个 Game
用 Allegro 写的第一个程序 ;-)
其实简单的说就是开个 2 维数组描述屏幕(或想控制的区域)
哪些地方有子弹(或别的东西) 那些地方是安全的
子弹等东西运动时, 就刷新这个 2 维数组

名字: 云风
来自: 202.103.110.223
Friday, April 09, 1999 at 20:27:55 (CST)
留言:
TO:LXH
你好.看到你的留言,很高兴有一位兄弟也是对此感兴趣的.
从你的解决方法中我个人的理解如下,由于智力原因可能会歪曲你的原意,请包涵.

用像素级的方法,自机要和敌人的子弹相判断时就在敌子弹的BUFFER中进行
自机所处的像素位置的核对,如已经和敌子弹发生了重叠则被击中.
同理敌方的飞机也用此方法.
不知以上理解是否正确?
不知你看过老王的A10没有?
他写的A10是用矩形的判断方法,其实就是 if else 之类的东西.不过还是可行的.

我个人不建议用建BUFFER的方法,因为内存一大总是不好的,何况还是整屏的!
要是想精确测量非用单个像素级不可,其实也可用矩形,只打中飞机的机身
才算.至于要判定的东西一多会咋样我还没把握,不过今天晚上我会用老王
的A10进行测试,看达到多少才会降低速度.等我明天的留言.

名字: dai
来自: 202.103.152.141
Friday, April 09, 1999 at 20:22:23 (CST)
留言: To Dai:
关于射击游戏的碰撞判定.
正确的方法使用所谓I-Buffer(impact buffer,我瞎掰的词儿).
我举个例子:炮弹击中飞机

1)所有的实体对象(如战机CFighter,炮弹CShell)都直接/间接继承自同一个基类CObj(用MFC的朋友注意,和MFC里的CObj冲突了).
2)建立一个全局指针数组,所有对象在它的生命周期里都有其中一个指针与之对应: 
CObj * g_objList[MAXCOUNT];
3)每个对象建立时往这个List"注册",并在对象内部保存其在List里的序号:
g_objList[wIndex] = (CObj *)this;
CFighter::m_wIndex = wIndex;
4)在Heap里分配一个和Primary Buffer等大的内存区域:
WORD * a_iBuffer = (WORD *)malloc(640*480*2);

工作原理:
1)CFighter类的对象把其所覆盖的区域都填上它的m_wIndex的值,可以是非矩形的(like ColorKey blit);
2)CShell类的对象,每次根据自己的坐标从iBuffer里抽点(如果炮弹的面积较大可以取3-4个离散的点),抽得的数值如是"0",就什么事没有,否则就是其牺牲品的wIndex,进一步从g_objList里取得目标的指针,就可以通知它安息了.

Note:
1.上例只是为了说明构想,实际的实现要复杂的多.
2.如果不需要全精度的像素级的判定,可以降低iBuffer的精度;如碰撞的精度可以降到四个像素,屏幕为640*480, iBuffer 就为160*120, 运算量和内存消耗就只有原来的十六分之一!
3.因为参与判定的对象可能多于一百个,所一无法保证在处理同一帧时,目标的置点先于猎手的抽点完成(想想同一个对象可能既是目标,又是猎手这种情况),所以应该建立2个iBuffer,每个Buffer在某一帧里写,下一帧里读,如此交替.

To Dai 兄:
对每2个对象之间进行判定这种方案是行不通的:100个对象之间需要判定100*99次,就是说该算法的开销的增加是按参与判定的对象的数量增加的平方而增加的...想想是不是很恐怖.iBuffer法对于每个对象只是进行了一次读和一次写,该法的开销是线性增长的,可以满足大量判定的需要,而且iBuffer法还可以简化各种不同类型的对象之间的互动,及可以支持不规则图形的像素级的判定.

名字: LXH
E-Mail: lee@public.zz.ha.cn
主页: none
来自: Zhengzhou 202.102.255.48
Friday, April 09, 1999 at 19:11:17 (CST)
留言: 你提供源码我当然想换.
不要 GNU 的. 这样不利于风魂的代码完全Free
(我想游戏库不适合做成 GNU 的, 商业游戏一般不会按 GPL公开源码的)
打包的东东有朋友在做了 ;-)

名字: 云风
来自: 202.103.110.244
Friday, April 09, 1999 at 14:09:43 (CST)
留言: 我想ZIP所用的LZSS改进算法的压缩率以及速度会比Lempel-Ziv算法要好点。它的解码速度很快。想不想换? :-)
btw, 你找到人帮你写包的管理程序了吗?老实说我现在每天至多只有3-4小时的时间写程序。:-(
如果你不怕耽搁风魂0.07的推出,我可以帮你写。^_^

名字: limoon
来自: 202.96.141.232
Friday, April 09, 1999 at 13:50:20 (CST)
留言: d3d 的 alpha blending 需要硬件支持, 不支持的时候慢到了极点
而且那个需要带 alpha 通道的位图. 大多数情况下, 对 2d 游戏是极大的内存浪费
更重要的是, 如果你的 surface 不在显存就干不了这个, 而 2d
游戏是不可能将位图都放在显存的. 所以它只适合做些表面的效果.
举例, Isometric Engine 中, 人被房子挡住, 我希望用半透明的形式去画小人
而不是让他变的看不见, 用 D3D 的 alpha surface 就非常的不合适.

btw, 刚才读了 Intel 的利用 MMX 做 Alpha 混合的文章, 好笨的方法 ;-)

to Dai, 谁说, M$ 的 VC 的东东就不要 .DLL 了?
用 MFC 很多情况一样要. 只不过, 有些是 Windows 自己有了, 有些是你装 VC
时装进去了. ( Windows 9x 应该有大量代码也是 VC 写的吧? 用同样的东东
写 Win32 程序, 需要的外加库应当少多了吧 ^_^ 同理, Netscape 没有 IE
的启动速度快, 尤其在 win98 里)

名字: 云风
来自: 202.103.110.162
Friday, April 09, 1999 at 12:14:13 (CST)
留言:
当用BC5.0编译DX的程序时,明明将DX的LIB都COPY到
BC5的LIB目录下,可编译时确告诉我LINK不到XXXX
其实都在LIB的目录下,看了OPTION的路径也没错,
真不知BC是什么问题和DX过不去。
不过编了个WIN32 API(不基于类库)的程序,和VC
中的SRC相同,EXE的SIZE是VC编的四分之一。看来
还有些可取之处。可一旦利用了BC提供的类库OWL等
乱七八糟的东东,EXE就要XXX.DLL了,实在很别扭,
不象VC,编的啥都能在WINDOWS上用,不用自带DLL。

名字: DAI
来自: 202.103.155.90
Friday, April 09, 1999 at 11:44:18 (CST)
留言: 其实我很蠢, 但你们没几个聪明的. 我们可以直接用D3D来搞2D 的ALPHA BLENDING! 非常非常快! 有Direct3D这么好的工具为什么不用呢?
名字: Gamester
来自: 128.174.0.228
Friday, April 09, 1999 at 11:38:14 (CST)
留言: 如果我有 1 周时间专门写一篇文章就好了
写主页都是在熬夜写程序困的受不了的时候作为调剂写的
连错别字都懒的查 ;-)

名字: 云风
来自: 202.103.110.162
Friday, April 09, 1999 at 10:18:02 (CST)
留言: "lock了表面后, 剪裁矩形是不起作用的" --- 这个玩意只能给3D用。好像有办法绕过,但是具体怎么作,我记不清了,可以帮你们问问。我用最老土的办法算好矩阵在内存中的位置,然后用一个特殊的LOOP兼数学公式计算来搞定。特浪费时间。

云风介绍的洋文技术文章真好,怎么云风就写不出这么完善详尽的技术文章??

名字: Gamester
来自: 128.174.0.228
Friday, April 09, 1999 at 05:38:47 (CST)
留言: 马上就要完成了哟 ;-)
压缩用的 Lempel-Ziv 算法, 压缩比不高, 但解码速度比硬盘速度快多了
打包用了类似 WestWood 的 .mix 结构
文件名不放在包内, 而是从文件名算出一个 32bit 的 ID
(有利于高速检索文件)
文件按 64K 分块打包. 包里支持虚拟目录. 这套库可以越权操作.
就是说, 当前目录下有同名的实际文件就不去包内取压缩的版本.
我现在基本完成. 但是只支持读操作, 库本身不支持打包.
我另外写了个简单的打包程序, 太简单了, 就是从一个 lst 文件中取出
文件名, 依次打包到一个数据包里. 有兴趣写个带漂亮的 GUI 界面的
包的管理程序吗? (低层函数我都做好了, 只做个界面就可以)

名字: 云风
来自: 202.103.110.252
Thursday, April 08, 1999 at 13:14:40 (CST)
留言: 你用什么算法压缩打包?
名字: limoon
来自: 202.104.218.15
Thursday, April 08, 1999 at 12:53:28 (CST)
留言: 我现在没有时间写 ;-(
你先看看老外写的一篇吧

名字: 云风
主页: http://www.gameprog.com/article.htm#Jesse Towner
来自: 202.103.110.199
Thursday, April 08, 1999 at 10:42:12 (CST)
留言:
那位大虾能详细贴一篇讲Alpha的文章?
如,Alpha 怎样取值等。我现在一窍不通,万望帮助!!!!

名字: bben
E-Mail: bbenmi@263.net
来自: 202.96.180.122
Thursday, April 08, 1999 at 09:15:20 (CST)
留言: 一个问题,怎样读取3dMAX 留alpha 通道的资源?
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.112.118
Thursday, April 08, 1999 at 08:14:32 (CST)
留言: 你说得对. DX不会差到这地步, 不然早叫人扔到垃圾桶里! :-) 我的程序一定有点问题. btw, lock了表面后, 剪裁矩形是不起作用的, 我试过不检查边界, 即死!

名字: limoon
来自: 202.96.141.203
Thursday, April 08, 1999 at 00:24:30 (CST)
留言: 知道你肯定明白 ;-) 不过想帮你(和大家看留言板又不想费脑筋的朋友)算算那
1 帧速度的增加还是很多的. 而 115帧的减少也没有那么恐怖.
顺便提醒你再优化下程序 ;-)
TinyHsu 不是也用表面做 Alpha 混合的吗? 没有那么慢呐, 我想你程序一定还有
问题, 等我打包压缩的程序写完了, 再帮你看看.
还有想问一下, lock 了表面后, 对表面的直接操作时, 剪裁矩形还在起作用吗?
(应该是不起作用了吧? 否则就太慢了)
btw, 我也是用全拼的 ^_^

做 3D 游戏没有兴趣, 要我做, 还不如拿个现成的 3D Engine 再在上面加工算了
前两天看了 Duke Forever 的演示, 太.... 这十年我们算是赶不上老外了

名字: 云风
来自: 202.103.110.208
Wednesday, April 07, 1999 at 23:44:51 (CST)
留言: 你说的单位错误, 我是知道的. 如果这个还不知道, 干脆一头......^_^
为了简单地用几个字表达意思, 不得不这样写, 我打字速度慢, 而且不喜欢打字, 我知道在座的一定明白我说的是什么, 因此我也不会费神打太多的字. 因此只要大家明白, 下次我还是用这个说法, 请不要见怪喔! :-)
说了大家不要笑, 我不会打五笔, 现在用拼音输入! :-)
btw, 就算把表面建立在内存里, 还是慢. 看来这跟DX有关, 想要快, 还是用风魂的办法. 你首先做了! :-)
你对3D游戏有无兴趣?

名字: limoon
来自: 202.96.141.226
Wednesday, April 07, 1999 at 23:24:15 (CST)
留言: haha 又犯单位错误了, fps 的变化不能当成速度变化单位的.
9fps 到 10fps 速度可是每帧减少了 0.011 秒(1/9-1/10)
而 125fps 到 10fps 速度下降可也有 0.092 秒
(0.092s 相当大, 但0.011s 也不是小数字)
如果真是读显存的原因的话, 倒是有这么慢, 显存读的速度之慢是难以想象的
而我想做的游戏要大量使用光影效果, 所以我坚决不用显存


名字: 云风
来自: 202.103.110.138
Wednesday, April 07, 1999 at 18:53:20 (CST)
留言: 把MMX的混合代码删除乘法后, 只是快了1帧! :-(
看来问题不在这里, 如果在显存建立后台缓冲, 在只有四个sprite交叉运动及背景滚动时, DX速度高达125fps. 但增加了八个alpha混合sprite后, 一下掉到10fps!.
简直不能相信, MMX的alpha混合耗费了115帧的时间. 内存数据送到显存不会慢到这个地步吧. 不知DX在搞什么东东, 怪! !@#$&*#$^!

名字: limoon
来自: 202.104.218.39
Wednesday, April 07, 1999 at 18:38:54 (CST)
留言: 我就说要帧间压缩吧, 你只需要将每帧间的区别记下来就可以了
btw, 风魂将低层支持帧间压缩的精灵动作

名字: 云风
来自: 202.103.110.251
Wednesday, April 07, 1999 at 17:56:32 (CST)
留言:
乖乖弄的东,韭菜炒大葱。
早上是第42750,下午是42836。
看来拜访云风的人真是不少!
用RAMIX找了个小兵的动画,竟有660幅。
妈呀!这还咋让俺咋搞啊!。。。昏倒!

名字: dai
来自: 202.96.180.80
Wednesday, April 07, 1999 at 16:40:52 (CST)
留言: 565 的不正常 ;-(
粗略看了一下 Alpha 混合部分, 发现一个非常影响速度的地方,
我的 Alpha 混合是一个级别一个函数, 这样完全避免了乘法.
而你的是用加法模拟乘法, 所以就慢了

名字: 云风
来自: 202.103.110.195
Wednesday, April 07, 1999 at 14:16:20 (CST)
留言: 补充:我的显卡是555的,不知565运行是否正常. :-)
名字: limoon
来自: 202.104.218.60
Wednesday, April 07, 1999 at 11:23:27 (CST)
留言: 我的程序是和风魂差不多,7个sprite. 我还未认真看你的代码,不过我写的MMX混合很慢,不知慢在什么地方,请给点意见。DX在某方面真的不如风魂。

非MMX的混合我试用了个新办法,一次算四点,不过混合运算工作不正常,还未有时间修改,不过估计速度快不了。这几天国家XX局的专家来,说要捐款给我们公司,真是忙到抽筋。

该程序最快的环境是:关闭硬件加速,在内存建立表面,用blit操作弹出。
我把它放在这里了:http://www.zhanjiang.gd.cn/nethome/zjlixd/download/st2.zip
这个程序可以作为反面教材,帮忙看看, 程序需要windsoul.bmp和back.bmp.

名字: limoon
主页: http://www.zhanjiang.gd.cn/nethome/zjlixd/download/st2.zip
来自: 202.96.141.224
Wednesday, April 07, 1999 at 11:07:36 (CST)
留言: 啥?读显存慢?真是不很理解。

名字: dai
来自: 202.96.181.169
Wednesday, April 07, 1999 at 10:38:16 (CST)
留言: CLOUD说的对,读显存非常慢
名字: freemind
来自: 202.98.46.163
Wednesday, April 07, 1999 at 00:28:46 (CST)
留言: limoon, 我昨天也把硬件加速关掉了, 结果发现 DirectDraw 初始化不了 ;-(
我的想法是, 有可能 DirectX 想自己利用显卡带的传输数据的特性
结果因为 Alpha 混合大量读Surface, 所以导致缓慢(猜的,没有根据)
btw, 你的帧数是指的什么样的一个程序? 是全屏混合吗?
不过有一点是肯定的, 读显存非常的慢, 速度的影响多半是因为读显存的原因

名字: 云风
来自: 202.103.110.189
Tuesday, April 06, 1999 at 17:51:55 (CST)
留言: 初睹风云,扼腕击节。
哪位大侠肯不吝指教,HTML和URL是哪几个英语字?
最好是密语传音,悄悄给伊妹说一声就行,她会转告在下的。
在下生性胆小,向来不敢到人多的地方去。
谢不轻言,后会有期。
BUDDHAS@263.NET

名字: buddhas
E-Mail: buddhas@263.net
来自: buddhas 210.78.130.98
Tuesday, April 06, 1999 at 13:13:48 (CST)
留言: 云风,你对我上一贴所说的情况有什么看法?
名字: limoon
来自: 202.96.141.248
Tuesday, April 06, 1999 at 09:11:07 (CST)
留言: 我用汇编写了个带轮廓平滑的汉字显示函数 ;-)
效果可以看看下面这张图

名字: _云风_
主页: http://www.netease.com/~cloudwu/windsoul/hz.png
来自: 202.103.110.242
Tuesday, April 06, 1999 at 06:52:33 (CST)
留言: 昨天写了一个DX下的alpha混合程序, 先看看结果:
MMX的alpha混合:
1. 缓冲在显存: 8fps(简直慢到抽筋!)
2. 缓冲在内存: 6fps
非MMX的alpha混合:
3. 缓冲在显, 内存: 6fps

以下用dxtool.exe禁止DirectDraw硬件加速的结果:
MMX的alpha混合:
1. 缓冲在内存: 31fps(还差不多)
非MMX的alpha混合:
2. 缓冲在内存: 14fps

我搞不清楚为什么禁止了硬件加速的结果反而更快(缓冲都在内存的情况下), 怎样一回事?

名字: limoon
来自: 202.104.218.62
Monday, April 05, 1999 at 19:32:28 (CST)
留言:
RA的编辑器RAMIX真是好,
所有的AUD和动画都能抓出来,哈哈。
可以“拿来主义”了。。

名字: dai
来自: 202.103.154.21
Monday, April 05, 1999 at 14:04:08 (CST)
留言:
TO:ALL
有个关于射击游戏的问题总是不知如何解决。
在射击游戏中自己的子弹很多,敌人的子弹
也很多。所以判断时很麻烦,总是要一个对
一个的去判别。可是有时敌人多有时敌人少,
那样的话速度岂不是时快时慢?
此想法是看了老王的A10后有感。

名字: dai
E-Mail: superdai@263.net
来自: 202.103.154.130
Monday, April 05, 1999 at 10:18:23 (CST)
留言: mmx技术 的第四节没有呀?
mmx4.html没有?

名字: sunway
E-Mail: codingboy@126.com
来自: 鼎立工作室 202.101.255.152
Sunday, April 04, 1999 at 21:41:45 (CST)
留言: 请问能不能下载那个direct的翻译过来的东东!网上浏览速度太慢。有可能的话,能不能帮忙E-mail到我的信箱bub_smile@263.net先谢过了!
顺便说一句,很高兴认识你这个湖北老乡的!我是湖北荆门的,现在在清华读书。

helley^_^

名字: 小点
E-Mail: bub_smile@263.net
来自: 清华 166.111.2.243
Sunday, April 04, 1999 at 19:17:26 (CST)
留言: 请问能不能下载那个direct的翻译过来的东东!网上浏览速度太慢。有可能的话,能不能帮忙E-mail到我的信箱bub_smile@263.net先谢过了!
顺便说一句,很高兴认识你这个湖北老乡的!我是湖北荆门的,现在在清华读书。

helley^_^

名字: 小点
E-Mail: bub_smile@263.net
来自: 清华 166.111.2.243
Sunday, April 04, 1999 at 19:16:57 (CST)
留言: 今天一天的成果是一个压缩解压程序, 大家可以下载看看,写在下面了 ;-)
如果急着要源码,不想等到风魂 0.07 出来, email 我
(只能操作一个文件, 还不能打包)

名字: 云风
主页: http://www.netease.com/~cloudwu/windsoul/lz.exe
来自: 202.103.110.223
Sunday, April 04, 1999 at 19:08:39 (CST)
留言: 失踪了两天,
好消息是已经拿到了DIRECTX MEDIA SDK :)
坏消息是恐怕没时间去看,要开始复习准备迎接6月份的专业统考了 :(



名字: freemind
来自: 202.98.35.73
Sunday, April 04, 1999 at 19:02:47 (CST)
留言: 闻言晕倒...
我是推荐书呀, 又不是超文本, 去书店去找嘛

名字: 云风
来自: 202.103.110.223
Sunday, April 04, 1999 at 17:59:33 (CST)
留言: To 云风
你说的”好书推荐“的那本讲保护模式汇编程序设计的书,怎么找
遍整个主页也找不到,到底是哪本书?能告诉我吗?

名字: 小羊
E-Mail: tengephone@163.net
来自: 202.101.255.187
Sunday, April 04, 1999 at 17:37:21 (CST)
留言: 哪位同志能告诉我djgpp下用rhide所需的部件,最好能告诉我
其它部件的用途!
谢谢!

名字: 周迅
E-Mail: zph@tonghua.com.cn
主页: linux_zph.163.net
来自: 202.119.230.9
Sunday, April 04, 1999 at 10:54:51 (CST)
留言: 不幸的消息是 PANDN mm0,mm0/ mm0 就等于 0 了, PANDN 实际是一个微操作
所以并不是两步(先取反再和反值AND) 而是一步 (反值和本身 AND)

名字: 云风
来自: 202.103.110.164
Saturday, April 03, 1999 at 23:17:28 (CST)
留言: 云风:
其实MMX的NOT操作,只需把MMX寄存器自己本身进行PANDN(AND, NOT),如PANDN mm0,mm0。这样就可以把mm0取反。用不着搞个常数 FFFFFFFFFFFFFFFF, 想想看! ^_^ Intel还是没有做错! :-)

我想还有一个更快的办法,待我有空时验证一下。^_^

名字: limoon
来自: 202.96.141.206
Saturday, April 03, 1999 at 19:29:42 (CST)
留言: 晚上聊天室见 :)
名字: gary
来自: 202.96.133.196
Saturday, April 03, 1999 at 17:09:31 (CST)
留言: 编译器的性能不是这样比的, 程序的速度主要看写程序的人.
如果真的对几个 C 编译器的速度感兴趣, 可以看这里
(连不上就用 proxy)

名字: 云风
主页: http://www.geocities.com/SiliconValley/Vista/6552/compila.html
来自: 202.103.110.118
Saturday, April 03, 1999 at 16:37:35 (CST)
留言:
TO:freemind
看到GAMESTER说你没用过DX6,是这样吗?我倒是D了,当然
很大,不过只要H和LIB的话也只有2百多K。他说的DIRECTXMEDIA
我没研究过,所以不很清楚是不是在这些文件中。
如果你需要的话可跟我联系。
我能力低,不过谁要啥,只要俺有就找我好了。
TO:ALL
DJGPP确实比WATCOM慢很多,我是从实际程序中体验出来的。
使用WATCOM的NG模拟器玩98格斗王只要等很短的时间。
可用DJGPP的MAME,还是最新版,玩97格斗王等的时间居然
比WATCOM的慢至少5倍的时间。虽然有交换文件的因素,但
感觉上DJGPP还是要差些。
拥护DJGPP的兄弟可不要骂俺呀!

名字: dai
E-Mail: superdai@263.net
来自: 202.103.153.206
Saturday, April 03, 1999 at 16:29:46 (CST)
留言: 总算搞清楚了ws中有关alpha blending的代码,thanks cloud!.PDX也会支持高速的alpha blending喽,有一个问题想请教大家,最近一个朋友拖我写一些关于平台加密的代码,其中有一个问题是判断操作平台绝对语种的问题,我知道可以通过判断win.ini中有关[Associated CharSet]下使用代码页来判断,可这不够,可以通过修改来欺骗我的代码, 有更好的方法吗?


名字: tinyhsu
E-Mail: tinyhsu@netease.com
主页: www.deep.163.net
来自: 202.96.112.130
Saturday, April 03, 1999 at 14:57:27 (CST)
留言: To TinyHsu:
Thanks a lot! I owe you!!

名字: Gamester
来自: 128.174.0.228
Saturday, April 03, 1999 at 13:45:32 (CST)
留言: To TinyHsu:
你说的那个,是ddrawxcl吧???我COMPILED 50多次,每次运行都说: ILLEGAL OPERATION。。。。,一DEBUG,说在DDRAWOBJ.h中DECLARE_IUNKNOWN是不合法的执行,所以,我从未搞出来过那个程序。

我倒是看到DirectDrawFactory能构造不同的IDirectDraw对象: IDirectDraw, IDirectDraw2, IDirectDraw3, 但我不知道能不能构造IDirectDraw4,那样可是更帅了!!

我一直以为那个鸟东西根本不能用,是你的贴子提醒了我,你能弄得出来我也能,没想到随便写了个鸟程序还成功了。OK,这次你又提醒了我!我看了看那个DDRAWXCL的例子,其中的CDdrawObj类可以轻易地被改过来,加上那个VIDPLAY类,IT IS GOING TO BE AWESOME。

SCREW OVERLAY!!操他妈OVERLAY!

名字: Gamester
来自: 128.174.0.228
Saturday, April 03, 1999 at 13:43:36 (CST)
留言: 公开致谢。
云风好样的!我遇到一个汇编问题,请教云风,云风两次回mail,帮我克服了困难,在此公开鸣谢。并愿意象云风一样,对各位网友提供力所能及的帮助。我有能力在一个大城市的电视台介绍和推广游戏。诸位开发的游戏,如果够水平了,我愿意帮忙.
祝云风风卷云行,走向成功。
litek@mail.sc.cninfo.net

名字: litek
来自: 202.98.108.75
Saturday, April 03, 1999 at 10:52:08 (CST)
留言: 看了近期的许多文章,发现自己的确搞错了,
这也奇怪了,我平时一向对图象的格式和大小都是很在意的,
关键时候却居然算出了个1M(少乘了个8)*~|~*
看了云风关于alpha blending优化的文章,千言万语化成三个字:你好牛!
老王终于有点动摇了,虽然现在忙得要死,
昨天还是忙里偷闲,跑到清华买了一本讲汇编的书。
这也怪我的电脑配置,前年就有了mmx200、4.3G,
对程序的优化一直都不关心,要是我现在用的还是P100的话,
嘿嘿,肯定也会整天与什么CPU、寄存器、CACHE打交道的。

另外:这几天可能会有些时间,我会写一篇文章详细的介绍一下水波特效的的制作(gamester要是你还嫌写得太浅,我可就没折了)。如果有可能,程序中的关键代码我也将改为汇编的(云风是否能帮我一下)相信到那时,那个水池就不会只有320x240那么小了,再加上光影的效果,西西、哈哈、霍霍霍...

名字: 老王
主页: http://dxstudio.yeah.net
来自: 202.94.2.54
Saturday, April 03, 1999 at 10:31:28 (CST)
留言: sorry,gamester,你一定没仔细看dxmedia的文档,我的代码是在ddxcl(好像是这个)上改写的,没有基于DirectDrawFactory也没有基于IDirectDraw3,用那个方法我知道很容易,但问题是我不能为了播放一段video clip就要将所有的surface release 掉再release掉directdraw4,再建directdrawfactory,create directdraw3.这点倒是ws很方便, 所有位图都基于内存, 不必要释放,:)。
to freemind,在directShow下抽线很方便的。:),而且不会存在同步堵塞的问题。你试过从CDROM上读取一个较大的AVI文件会怎么样吗?呵,:P 像"糨糊"一样把所有的文件拷到硬盘上去? ;-) my god 1.2G

名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.100.3
Saturday, April 03, 1999 at 10:28:56 (CST)
留言: 我可真希望我能帮助,就是不象云风那么悠闲,我没有时间搞翻译,一堆的考试,一堆得作业,一堆的程序项目(作业),我的打字速度是8个字一分钟。谁知道我在短时间能写多少技术文章?我只能给你们一个15MB的COMPILED HTML HELP。谁能提供一个FTP SERVER有足够的空间!我的邮箱太下,没办法发给大家。

To tinyhsu:
并不需要OVERLAY来播放。我写的程序用来播放MOVIE CLIP就没有用到OVERLAY,我不太确定。有没有试那个TRANSFORMATION?AWESOME!

名字: Gamester
来自: 128.174.0.228
Saturday, April 03, 1999 at 08:49:30 (CST)
留言: MS在DirectMedia中使用了DirectDrawFactory来create DirectDraw interface,这本来就是个折中的办法,我仔细研究了directMedia中有关在exclusive下播放DVD的sample,其实只要修改少部分的代码就可以在不支持overly的显卡上输出,而且速度上是可以接受的,我试过在P100下播放,15 fps,1M 显存,号称解压速度一流的“超级结巴“5.5 也不过就 17 fps 左右,而且不支持抽线, 我觉得有些东西M$已经解决,没有这个必要再在这部分浪费时间(个人观点), 而且究正 freemind的一个错误的地方, directShow本身可以通过hel来模拟YUV支持,还有,现在谁的机器还在装着dx 3.0 玩游戏?
名字: tinyhsu
E-Mail: tinyhsu@netease.com
来自: 202.96.112.178
Saturday, April 03, 1999 at 08:14:58 (CST)
留言: Sorry, I found those articles!
名字: 老K
来自: 129.174.124.123
Saturday, April 03, 1999 at 07:18:59 (CST)
留言: 云风,记得以前你这有几篇关于斜视角引擎的文章,怎么不见了?
很着急看你的关于alpha-blending的文章! 优化在什么时候都
是值得的! 即使大家都用PII,PIII,上面跑的软件为Pentium和
MMX优化仍然是极少的!

关于MS的API,其实跟Windows一样,东西本身真不怎么样,就是因为它是标准,
所以所有的硬件都提供对它的支持,对于想快点出产品的人或公司来说,当然
要用,可实际上真正NB的东东都是自己做出来的.不一定是一个人,利用网络
一起干嘛!Linux,GNU就是很好的例子.希望你们的东西也是一样!

名字: 老K
E-Mail: KlamasZhu@hotmail.com
来自: 129.174.124.123
Saturday, April 03, 1999 at 07:16:33 (CST)
留言: 是啊是啊, YUV 转 RGB 很慢, 我优化 Allegro 的 MPEG 库时就感觉到了
拖下来好多速度. 主要是要乘个矩阵.

名字: 云风
来自: 202.103.110.102
Saturday, April 03, 1999 at 02:18:48 (CST)
留言: 补充一句,我说的低是指 P100 + DX3.0(你要2.0也行)
我还是不相信MS在不用YUV加速的情况下会有那么快
你关掉VCD播放的硬件加速试试

不过,可能是我的思想方法有问题,
我总是倾向于用CPU演算来做各种低层工作,而不喜欢用其它加速设备
觉得这样能提供更高的灵活性,

否则,那些设备一天一个样,你只有用别人提供的DRIVER和API
那也是一天一个样,你想优化?不行,只有等厂商和微软来做

我现在这样做,主要是为了摸清低层,今后就算离开微软平台,也可以不受任何影响

这种肯定不是商业化的想法,我做游戏一直是靠兴趣作为动力(动机很纯?)
在这里消息又闭塞,想学新东西都难…………

想出产品赚钱的同志,把我当反面教材好了,千万听GAMESTER的话,跟微软走

名字: freemind
来自: 202.98.33.3
Saturday, April 03, 1999 at 02:13:02 (CST)
留言: freemind, 我有个建议, 不知道你能不能接受
能不能把你的播放程序加到风魂里. 这个本不是我个人的作品
不过风魂是个完全开放的产品,加进来就意味着完全公开,
比 GNU 还公开, 别人用了代码一点责任都不用付.
这有些让人不好接受的. 具体见风魂的文档中版权声明的部分.
不过好处是, 可以促进国内游戏的发展, 我希望有一天风魂能像
Allegro 那样在世界范围的游戏设计业余爱好者间流行

名字: 云风
来自: 202.103.110.102
Saturday, April 03, 1999 at 01:55:46 (CST)
留言: Gamester 能讲一下你用DXMEDIA的经验吗?


名字: freemind
来自: 202.98.35.84
Saturday, April 03, 1999 at 01:50:16 (CST)
留言: Gamester 说得对,我接受
名字: freemind
来自: 202.98.35.84
Saturday, April 03, 1999 at 01:47:08 (CST)
留言: To freemind:
又搞错了不是,DirectX Miedia6.0中的DirectShow支持IDirectDraw Interface, IDirectDraw3 Interface, 只要是高于版的DirectX,就能用DirectX Media6.0。出乎我的意料,DirectX Media竟不能支持IDirectDraw4。在低版本的DX上就能跑? SURE,NO PROBLEM。

DirectX Media需不需YUV硬件支持,这我不知道。

你是如何定义低档机?p100好象不能RUN WINDOWS98。所以我用P200MMX试过,也是快如飞。再用下ff7,好象那个游戏在P200MMX下非常快。同样使用DirectX Media,还是老版本的DirectX Media。

你的东西最多只能支持DirectX不知什么版本。而且,你的PLAYER只能支持一种格式的读取和播放。DirectX Media不需要有DirectX的知识,在WIN32 API,MFC,VISUAL BASIC,甚至用HTML也能用上。

我怀疑你根本没有见过DirectX Media6.0。这很合理,89MB的东西,我用T1都DOWNLOAD了近20分钟,中国的INTERNET不是很方便,89MB也太... 但是你说你的东西比DirectX Media6.0好,这肯定是胡说八道,请不要这么狂妄。

我们不能和WESTWOOD,BLIZZARD比,他们有多少人?十几,二十甚至四十多人一个设计组,每个人都有一定的分工。写东西当然不必都用MS的东西。你只有一人,我的设计组只有两人,我和PETER ZERO。我当然没有办法精通所有的技术!我想你也没有办法精通所有的技术。唯一的出路就是运用当前别人搞好的技术,这些技术只有一天天变得更加完善,配合硬件的进步而进步,在中国这的确是个问题,我想如果你能精心设计地话,你总能打破重重障碍的。

名字: Gamester
来自: 128.174.0.228
Saturday, April 03, 1999 at 01:36:00 (CST)
留言: 我现在在写 RLE Sprite 的Alpha 混合.
MMX 版本还好说, 这个 非 MMX 版本把我烦死了.
先写 不混合的时候为了速度, 结构设计的太复杂, 寄存器已经不够用,
现在想加上 Alpha 混合的简直没办法进行下去

名字: 云风
来自: 202.103.110.243
Friday, April 02, 1999 at 18:07:17 (CST)
留言: 更正"游戏的五月"的连接
mays.yeah.net

名字: mays
主页: http://www.tianfu.net/~mays/gindex.html
来自: 202.103.237.100
Friday, April 02, 1999 at 16:51:17 (CST)
留言: 更正"游戏的五月"的连接
名字: mays
主页: http://www.tianfu.net/~mays/gindex.htm
来自: 202.103.237.100
Friday, April 02, 1999 at 16:47:46 (CST)
留言: to Gamester:

你说的对,用别人尤其是M$的东西肯定来得快,但你看到我的AVI播放器的实际效果没有?
同DIRECTX MEDIA的最大区别:
1 在低版本的DX上就能跑
2 不需YUV硬件支持
3 在低档机上也跑得飞快
4 支持抽线加平滑,效果比DIRECTX MEDIA放的AVI要好!

不过只能支持AVI显然是不够的,我会改进解码部分,提供更好的效果的

我的看法是:要想做好游戏,不能说有就行了,一定要做得比别人更好,所以要深入
你什么时候看到WESTWOOD、BLIZZARD偷过懒的?

名字: freemind
来自: 202.98.33.92
Friday, April 02, 1999 at 16:43:52 (CST)
留言: wow, wow, 刚才的一棍真厉害!^_^ 看了下MMX文档,真是要拉INTEL去枪毙! 连not指令都没有. 如果有10个...,现在就算证实了我最后的想法,也快不了一倍,看来要贬值了,0.2倍... :-(
慢着,还是试过再说,要不然又得挨棍子了! ^_^

名字: limoon
来自: 202.104.218.37
Friday, April 02, 1999 at 11:52:27 (CST)
留言: 不是我想规定, 我现在在做游戏了, 程序量很大, 而且我做笔记写注释
不够详细. 一停工, 就难以继续干了

名字: 云风
来自: 202.103.110.243
Friday, April 02, 1999 at 11:38:11 (CST)
留言: 请问云风:
为什么你要规定自己每天写一定数量的代码呢? 这样做最大的好处是什么? 要提高编程的能力,是否只要多写多看就行了呢?


名字: damn
来自: 202.102.81.237
Friday, April 02, 1999 at 11:35:17 (CST)
留言: 补充一点, 这个不能完全跟着上次那种方法的思路走.(主要是 MMX 指令贫乏,
能在普通寄存器里完成的操作,许多都不能用于 MMX)
上次我和一帮老外讨论,就是基于那个思路的, 由于跳不出框框,所以
大家都没有得出我现在这个的算法.
btw, 现在的算法比带 MMX 加速的, Sprite Blit 只慢 20%

名字: 云风
来自: 202.103.110.243
Friday, April 02, 1999 at 10:52:30 (CST)
留言: MMX 的指令集里指令少的可怜, 你用过才知道的. 如果很简单就可以实现,
去年 Allegro 里就用了.
举例: MMX 的寄存器不能立即寻址, 所以常数要保留在寄存器里
(8个寄存器是否不够?) 如果我告诉你那里面连 not 操作也不能直接实现, 你作何
感想?
MMX 的比较是不影响标志位的, 这相当讨厌, alpha 混合多用于 Sprite,
而不是一个矩形的图块... 还有许多问题, 必须写程序才能发现.
事情往往不是想象中的简单, 否则 DirectX 6 就会支持 Alpha 平面的


名字: 云风
来自: 202.103.110.243
Friday, April 02, 1999 at 10:46:27 (CST)
留言: 我看到你在新浪网上的贴子,说一次算4个点的alpha混合。我也花了一分钟想出个办法来,利用MMX寄存器一次可以运算4个点,不过8个MMX寄存器也够了。^_^
不知道我的办法跟你的有什么区别? :-) 不过我还有个想法,证实了还会快一倍! ^_^

唉,这段时间还未有空看MMX英文文档( 还是买不到中文书籍:-( ),要不然把它写出来看看。:-(

名字: limoon
来自: 202.104.218.5
Friday, April 02, 1999 at 10:21:22 (CST)
留言: 我是劲捷的LYL。今天是4月2日早晨。邮电分家,我分在邮政,所以,实在对不起,
我也没有能力给你送信了,不知道你现在怎么办?Tell me OK??

名字: 刘元路
E-Mail: liuyuanlu263.net
来自: 202.97.252.97 202.97.252.117
Friday, April 02, 1999 at 08:16:03 (CST)
留言: 经过两小时的艰苦奋战,终于搞出了DirectX + DirectX Media混合的电影播放器,可以播放:AVI, QT, MOV, MPG. 还是全屏的!

FREEMIND多少多少天的工作,我在两小时就搞出来了。可见使用他人的技术提高功效20000%,反正我以后是搞数据结构&AI,也不在乎自己会不会这些技术,省下时间:看书&上网乱屁。

名字: Gamester
来自: 128.174.0.228
Friday, April 02, 1999 at 08:07:15 (CST)
留言: 请问云风:
为什么你要规定自己每天写一定数量的代码呢? 这样做最大的好处是什么? 要提高编程的能力,是否只要多写多看就行了呢?

thanks ;)

名字: ohNo
来自: 202.104.64.118
Friday, April 02, 1999 at 04:11:32 (CST)
留言: to Cloud:
我去新浪拉了个Wheel of Time的片头动画(3274K)就跑得上好呀?
不过我已经扔了两个片段到主页上,去看看吧

名字: freemind
主页: http://freemind.163.net
来自: 202.98.35.80
Friday, April 02, 1999 at 01:58:56 (CST)
留言: 您好欢迎您访问我的网页!
名字: 甲壳虫
E-Mail: zhoujiang1@163.net
主页: www.jkc.163.net
来自: 西安 202.100.27.234
Friday, April 02, 1999 at 01:55:00 (CST)
留言: to tinyhsu:
Your program can't work in DX5

名字: freemind
来自: 202.98.33.163
Friday, April 02, 1999 at 01:52:31 (CST)
留言: to limoon :
microsoft 啥产品都有,但那个又能让你满意呢?

名字: freemind
来自: 202.98.35.72
Friday, April 02, 1999 at 00:53:10 (CST)
留言: 163登陆人数又超员,唉............. :(
名字: tinyhsu
E-Mail: tinyhsu@netease.com
主页: www.deep.163.net
来自: 202.96.100.66
Thursday, April 01, 1999 at 18:38:11 (CST)
留言: vplay filename.ext 试试播放个AVI什么的 freemind ?,程序可从我的主页上下载。是0.1版本的,我修正了音频流输出上的一个错误.
名字: tinyhsu
E-Mail: tinyhsu@netease.com
主页: www.deep.163.net
来自: 202.96.100.66
Thursday, April 01, 1999 at 18:36:41 (CST)
留言: MMX 真难用, 可用的指令又少, (连 PNOT 都没有)
限制多(比如不能直接立即寻址 64 位数), 今天我真烦死了, 不过现在
:-DD 简直无法形容我的心情. 大家还记得去年我优化的 16bit Alpha 混合算法吗?
自从前几天找到新的算法后, 我一直试图用在 MMX 上, 终于让我成功了.
我自己都没有想到, 速度比上次我那个要快 2.7 倍, 对你没看错, 是 2.7 倍
速度只比不透明的Sprite 慢一点点, 奇迹啊.
btw, 去年我和一帮老外讨论的结果是, MMX 只能加速 24bit 的 alpha 混合,
对 16bit 只加快了 6%. hehe 我这次算是突破极限了 :DD 大家等着看我的文章吧
btw, 我还想写一篇 MMX 编程技巧, 纪念我今天的痛苦经历

名字: 云风
来自: 202.103.110.122
Thursday, April 01, 1999 at 18:24:42 (CST)
留言: 请问斑竹,可编程游戏驱动杆是怎么回事?提供编程资料吗?哪里能买到,品牌、价格如何?急盼告知。谢谢。
名字: ll
来自: 202.98.108.230
Thursday, April 01, 1999 at 17:36:06 (CST)
留言: 其实有必要自己写个AVI播放吗? window支持的格式多着呢!:)
名字: limoon
来自: 202.104.218.45
Thursday, April 01, 1999 at 16:38:37 (CST)
留言: 哈哈,不知道大家视频制作熟不熟,如果不熟悉的话,我应该写一篇《视频制作入门》什么的来填补空白了 ^-'
名字: freemind
来自: 202.98.33.27
Thursday, April 01, 1999 at 15:47:43 (CST)
留言: 其实《电脑报游戏世界配套光盘》上就能找到很多CINEPAK CODEC格式的AVI
你们试的那些AVI多半是用INTEL的INDEO压的,我还没找到INDEO的解码方法,所以暂时不能支持
但你可以用Adobe primiere把他们转成CINEPAK CODEC格式的,

^-^,我估计你们可能以前没自己做过视频,对这些格式以及相应处理不太熟悉,
看来只有等今天晚上再上传已经做好的样本给大家看了,有好几兆:(

名字: freemind
来自: 202.98.46.23
Thursday, April 01, 1999 at 15:41:36 (CST)
留言: 看到了,一个人的图就有11M,真可怕
我终于明白为什么DIABLO TOO的游戏国内为什么没很多人跟风了

名字: julien
来自: 202.104.64.91
Thursday, April 01, 1999 at 13:27:43 (CST)
留言: 那张图本来就用的你的 ^_^
btw,刚才看有人说, Diablo 里光一个小人就几千张图

名字: 云风
来自: 202.103.110.197
Thursday, April 01, 1999 at 12:35:18 (CST)
留言: 算错了,少乘了个8,怪不得我算的会那么少。:3(
这几天教研室的活儿一大堆,看来是没有时间更新主页了
哎!真恨不得长个三头六臂。
另外:哈哈,你的demo居然和我用的是一样的图!:3)

名字: 老王
主页: http://dxstudio.yeah.net
来自: 202.94.2.147
Thursday, April 01, 1999 at 09:03:55 (CST)
留言: 刚才我把留言板又整理了一下, 同时仔细看了下这几天的留言.
老王, Sprite 很多情况下是不能左右 Mirror 的, 我不是举了个例子吗?
Sprite(杨过)左手拿着(玄铁)剑, Mirror 一下, 就边成右手了.
大部分Sprite 并不是左右对称的.

汇编的问题, 保护模式下, 一般是调用 DPMI 的, 实模式下的中断不能直接用
同时, 我也没有直接用 ASM 对Win32 编程过, 据说是很简单的.
关于保护模式的汇编设计, 我在好书推荐里介绍了一本书

关于 Sina 的讨论, 我认为网上讨论大多都带点吹牛的性质, 稍微闲下来,
去灌灌水也是蛮有意思的 ^_^

Freemind, 我这里也找不到合适的 AVI :-( 在 sina 上下载了几个 5,6 M
的都不行.

名字: 云风
来自: 202.103.110.217
Thursday, April 01, 1999 at 03:05:12 (CST)
留言: 今天同人谈论顶视的效果,完全不被认可
都说在顶视下看到的人不舒服,这点我也知道
但如果用斜视觉引擎会使工作量增加太多,
那样我一个人做根本就无法完工,
太令我沮丧了…………

名字: freemind
来自: 202.98.35.91
Thursday, April 01, 1999 at 02:19:23 (CST)
留言: 求教:那位在95/98上面做过汇编程序?实模式与保护模式如何转换,我做不通。还有,BIOS中断哪些在95/98中还能用?有什么要注意的地方?改成实模式以后是否能象DOS下一样读写存储器?
先谢过

名字: 初学者
来自: 202.98.111.145
Thursday, April 01, 1999 at 00:26:21 (CST)
写写留言版吧:-)