不会飞的鸟

2010年12月10日 ... 不鸟他们!!! 我要用自己开发的分布式文件系统、分布式调度系统、分布式检索系统, 做自己的搜索引擎!!!大鱼有大志!!! ---杨书童

#

游戏引擎基础(六)(声音系统,音频APIs)

6部分: 声音系统,音频APIs


声音系统
  由于人们玩的游戏在种类和技术上的进步,声音和音乐近几年来在游戏中正逐渐变得重要起来(声音是一个实际游戏的可玩特点,比如在Thief和其它同类游戏中的听觉提示)。现在四声道环绕系统在游戏玩家的宝库中是负担得起的和平常的事。给定空间的声音,噪音的障碍和闭塞,和动态的音乐,如今许多游戏使用这些提高玩家情绪上的反应,更多的关注投入到这个领域就不足为奇了。

  现在在PC竞技场中,游戏玩家实际上只有一种声音卡可以选择 -- PC声卡制造商创新公司(Creative Labs)的Sound Blaster Live 从旧的时间个人计算机声音卡片制造业者有创造力的中心. 多年来创新公司已经为DirectX提供了他们的EAX声音扩展,并且他们是发起新的OpenAL(开放音频库Open Audio Library)的创立者。就如同OpenGL是一个图形API一样,OpenAL,像它起来听一样,是一个声音系统的APIOpenAL 被设计为支持大多数通常声卡的许多特征,而且在一个特定的硬件特征不可得时提供一个软件替代。

  为了更好的定义 OpenAL,我向创新公司的Garin Hiebert询问了其定义:

  "这里借用我们的 " OpenAL 规格和叁考" 的一个定义:

  OpenAL 是对音频硬件的一个软件接口,给程序员提供一个产生高质量多通道输出的能力。OpenAL 是在模拟的三维环境里产生声音的一种重要方法。它想要跨平台并容易使用,在风格和规范上与OpenGL相似。任何已经熟悉OpenGL的程序员将发现OpenAL非常熟悉。

  OpenAL API能容易地被扩展适应插件技术.创新公司已经把EAX支持加入到这套API了,程序员可以用来给他们的声音环境增加复杂的反响,比赛和障碍效果。

  如同Jedi Knight II: Outcast 一样,连同Eagle 世界/声音特征编辑器,Soldier of Fortune II 以这个新系统为特征。什么是Eagle 在介绍这个以前,让我们讨论一些其他的系统,并定义一些声音术语。


  另外的一个系统是Miles声音系统。Miles是一家公司,它为你的代码生产插件,在充分利用每块声卡时处理所有必须的到特定声音卡的说话(比如Sound Blaster Live!系列,或者老的A3D声卡)。它非常像一个API前端,捆绑了一些额外的特征在里面。 在其他事物当中Miles让你存取一些事物像MP3解压缩。 它是很好的解决方案,但像任何事一样,它花费金钱并是你的代码和硬件之间的额外一层。虽然对於快速的声音系统制造,它非常有用,而且他们有段时间了,因此他们的确精通自己的业务。


声音术语
  让我们开始障碍和闭塞。它们听起来一样,但不是这样。闭塞基本上意谓着一个声音在播放时听者在他们之间有一些闭合的障碍物。

  比如说,在NOLF2的一个屏幕镜头上你听到房子里面坏蛋的声音。你能听到他们,但是他们的声音相当低沉而沙哑。障碍是相似的,但是你和声音之间的障碍物并不是闭合的。一个好的例子就是在你和声源之间有一根柱子。由于房间中的回声你仍然听得到这个声音,但是它和声音直接传递到你的耳朵里是不同的。当然这确实依赖于知道在你的耳朵和声源之间的直线上是什么。而且根据房间的大小,声源到你的距离等等,需要的处理能变得相当耗时。后面我们将会谈到跟踪--足可以说它时常是比较慢的幀速率的原因。Quake III 里面的A3D 代码做了这些事情,关闭这些选项通常能够提高幀速率。Tribe 2 是这种弊病的另外一个受害者。关闭3D声音选项则你的幀速率立即好转,这在你考虑Tribes世界有多大和你能看见多远时有意义。

  接着是声音物质的特征。大部分声卡可以让你能够用可定义的过滤器作用于声音从而修正播放的声音。例如,在水下,或者在一个布料遮盖的房间中,或者在一个长的走廊中,或者在歌剧院,听到的声音有着很大的不同。能够根据你所处的环境改变你听到声音的方式是相当不错的。

  我们回到Eagle… 这是一个编辑器,允许多数第一人称射击游戏地图设计者将他们的地图导入到这个工具,然后构造简化的几何形体来为实际游戏引擎中的EAX代码产生一个声音地图。其思想是你不需要一个真实的图形地图的复杂几何形体来模拟声音环境。你也能够给产生的简化地图分配声音物质,这样声音环境就能够动态地改变。我亲眼目睹了这在Soldier of FortuneUnreal Tournament上的示范,确实相当引人注目。 我这在财富和 Unreal 巡回赛和它的军人上真的对示范是证人相当醒目. 当你跳入水中时,听到所有的声音改变,这是一个非常令人沉浸的经历。

  好,让我们继续吧。

  对于游戏机,由于静态的硬件,你的各种可能性会更受限制尽管在PlayStation 2Xbox上,硬件相当不错。我说的限制,仅仅是指扩展,而不是它所能够做的。我一点也不会感到惊讶看到这些游戏机上的游戏很快支持杜比数字5.1Dolby Digital 5.1)输出。Xbox ,由于它的 MCP 音频处理器,能够将任何游戏音频编码为5.1,并且游戏不需要特别编码就能利用这个特征。杜比(Dolby)把ProLogic II 带到了 PS2 上,并与Factor 5合作为GameCube游戏实现了ProLogic II。在 Xbox 之上,Halo, Madden 2002 Project Gotham Racing等游戏都有5.1杜比数字音频内容。DTS最近也为 PS2 游戏开发者发布了SDK,为这个平台上的游戏带来了降低了比特率的DTS音频版本。


位置的声音--一个复杂的世界
  现在有一些很少有处理的声音空间化问题。我说的是把声音放在一个真实的3D世界中。有四个扬声器在你周围是一个很棒的开始,但这仍然只是在二维方向。在你的上方和下方没有扬声器,你没有真正获得3D声音。有一些声音调制过滤器试图解决这个问题,但实际上没有真实东西的代替物。当然真实地大多数游戏多半只是在二维方向上,因此这仍然不是太大的问题。

  实际上任何声音系统最重要的特征之一是把声音混合在一起。根据你所处的位置,空间中声音的位置,每个声音的音量大小,一旦你决定了实际上你能够听到的声音,然后你必须混合这些声音。通常声音卡自己处理这些,这首先是声音卡存在的主要原因。然而,外面有一些引擎决定首先用软件做一次预混合。直到你着眼于一点点历史以前,这并没有真正地带来多大的意义。

  当声音卡最初问世的时候,有许多不同的混合方法。一些声卡可以混合8种声音,一些单位16种,一些32种,等等。 如果你总想听到16种可能的声音,但你不知道声音卡是否能够处理,那么你回到了尝试和试验的道路上 就是你自己用软件混合。这实际上是Quake III声音系统的工作方式,但提一个问题:"Quake III是为A3DSound Blaster Live!声卡世界发布的,这比以前更加标准化,为什么还这样做?" 这是个好问题。实际上Quake III的声音系统几乎每行代码都和Quake II中的声音系统一样。而且Quake I,甚至Doom也是这样。你想一想,向上直到 A3D 声卡和 SB Live! 声卡,许多年来声音系统的需求没有真正地改变过。两个扬声器,二维方向,音量简单地随着距离减小。从Doom一直到Quake III没有发生太大变化。而且在游戏行业中,如果不是迫不得已,别理会它。

  通常你会仅仅使用DirectSound为你做声音混合,因为它会可以使用的声音硬件,或者转而依靠软件,很多地方就像DirectX3D显示卡所做的一样。在 90% 的声音情形中,依靠软件混合对你的幀速率没有真正发生太多不同。当DirectSound在一些狂热的编码者眼中甚至还不是一丝光线时,Doom引擎就已经产生了。它从来没有得到更新过,因为它从来就没有真的需要更新。

  当然,你可以使用 SoundBlaster Live!声卡的一些聪明特征,例如房间的回声特性: 一块石窟,或一个礼堂,一个巨穴, 一个足球体育馆等。而且你真的应该使用由硬件提供的混合器,毕竟,那是它存在的目的。这种方法的一个不足之处是程序本身时常无法获得混合结果,因为混合是在声卡内部完成而不是在主存。如果由于某种原因你需要看到产生的音量,你是运气不好。


Music Tracks in Games
(游戏中的音轨)
  我们没有过多的谈到游戏中的音乐生成。传统的有两种方法,一种是简单的音乐 .wav 文件(或同等物)。它被预先制作做好,准备运行,和最小忙乱。然而,这些在内存和回放时间方面很昂贵。第二种方式用预设的样本编码MIDI音轨。这时常比较节省内存,但缺点是必须同时把一些声音混合在一起,因而会把声音通道用光。

  动态音乐就是根据在游戏中目睹的行动改变你的音乐的能力,比如探险用慢节奏的音乐,战斗用快节奏的音乐。预先制作的音乐的一个困难之处是要合拍,因此你可以从一段音乐渐弱到另一段音乐,这对于MIDI音轨比较容易。尽管时常你足够快速地淡出,或者一段音乐在播放另一段音乐之前已经消失了,你能侥幸不被察觉。

  在我们离开这个主题之前,顺便说一下,值得一提的是存在一些公司专门为你的游戏创作特定意义的音乐。FatMan(www.fatman.com) 就是一家这样的公司。音乐可能比其他别的东西更加容易外包,这是他们存在的方式。

  最后,游戏现在的事情自然是MP3格式,允许巨大的11 1的声音样本压缩,然而在送到声音卡之前只花费CPU很少的时间解压缩。当我在Rave Software工作时,在Star Trek Voyager: Elite Force 中,我们设法用MP3在一张CD上面完全支持三种语言,仍然为较多的图形留有空间。主要地,我们 MP3 只用于非玩家角色(NPC)的语音,由于游戏的全部音频效果MP3流和动态解压缩超出了硬件的处理能力,虽然在将来这是肯定可能的。比较新的格式,如来自 Dolby AAC 和来自微软的WMA,以将近两倍MP3的压缩率提供了相等或者更高的音频质量(实际上一半的比特率),可能应用到将来的游戏中。

  以上是这一章节的内容,下面将是网络和连线游戏环境的开发。



梦在天涯 2007-12-04 13:20 发表评论

posted @ 2009-04-10 10:44 不会飞的鸟 阅读(305) | 评论 (0)编辑 收藏

游戏引擎基础(四)(模型与动画,细节级别)

4部份: 模型与动画,细节级别


角色建模与动画
  你的角色模型在屏幕上看起来怎么样,怎样容易创建它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`因素来说至关重要。角色模型系统逐渐变得复杂起来, 包括较高的多边形数量模型, 和让模型在屏幕上移动的更好方式。

  如今你需要一个骨骼模型系统,有骨架和网格细节层次,单个顶点骨架的评估,骨架动画忽略,以及比赛中停留的角度忽略。而这些甚至还没有开始涉及一些你能做的很好的事情,像动画混合,骨架反向运动学(IK),和单个骨架限制,以及相片真实感的纹理。这个清单还能够继续列下去。但是真的,在用专业行话说了所有这些以后,我们在这里真正谈论的是什么呢?让我们看看。

  让我们定义一个基于网格的系统和一个骨骼动画系统作为开始。在基于网格的系统,对于每一个动画幀,你要定义模型网格的每个点在世界中的位置。举例来说,你有一个包含200 个多边形的手的模型,有 300 个顶点(注意,在顶点和多边形之间通常并不是3个对1个的关系,因为大量多边形时常共享顶点使用条形和扇形,你能大幅减少顶点数量)。如果动画有 10 幀,那么你就需要在内存中有300个顶点位置的数据。 总共有300 x 10 = 3000 顶点,每个顶点由xyz和颜色/alpha信息组成。你能看见这个增长起来是多么的快。Quake III III 都使用了这种系统,这种系统确实有动态变形网格的能力,比如使裙子摆动,或者让头发飘动。

  相比之下,在骨骼动画系统,网格是由骨架组成的骨骼( 骨架是你运动的对象) 网格顶点和骨架本身相关,所以它们在模型中的位置都是相对于骨架,而不是网格代表每个顶点在世界中的位置。因此,如果你移动骨架,组成多边形的顶点的位置也相应改变。这意谓着你只必须使骨骼运动,典型情况大约有 50 个左右的骨架很明显极大地节省了内存。


骨骼动画附加的好处
  骨骼动画的另一个优点是能够根据影响顶点的一些骨架来分别估价每个顶点。例如,双臂的骨架运动,肩,脖子而且甚至躯干都能在肩中影响网格。当你移动躯干的时候,网格就活像一个角色一样移动。总的效果是3D角色能够实现的动画更加流畅和可信,且需要更少的内存。每个人都赢了。

  当然这里的缺点是,如果你想要使有机的东西运动且很好,比如说头发,或者披肩,为了让它看起来自然,你最后不得不在里面放置数量惊人的骨架,这会抬高一些处理时间。

  基于骨骼的系统能带给你的一些其他事情是忽略特定层次骨架的能力 -- ,"我不关心动画想要对这块骨架所做的事情,我想要让它指向世界中的一个特定点"。这很棒。你能让模型着眼于世界中的事件,或者使他们的脚在他们站着的地面保持水平。这一切非常微妙,但它可以帮助带给场景附加的真实感。

  在骨骼系统,你甚至可以指定"我需要把这个特别的动画用於模型的腿,而一个不同的携枪或射击动画在模型躯干上播放,且那家伙(角色)叫喊的不同动画效果在模型的头部播放"。非常妙。Ghoul2 ( Soldier of Fortune II: Double Helix and Jedi Knight I: Outcast中使用了Raven的动画系统 ) 拥有所有这些好东西,且特别被设计为允许程序员使用所有这些忽略能力。这对动画的节省像你一样难以相信。像你一样的动画上的这次救援不相信. Raven有一个角色行走的动画和一个站立开火的动画,并在它同时行走和开火形下把这两个动画合并,而不是需要一个动画表示角色行走并开火。


More Skeletons in the Closet
  先前描述的效果可以通过具有层次的骨骼系统来完成。这是什么意思呢?意思是每块骨架实际上的位置相对于它的父亲,而不是每个骨架直接位于空间中的地方。这意谓着如果你移动父亲骨架,那么它所有的子孙骨架也跟着移动,在代码上不需要任何额外的努力。这是让你能够在任何骨架层次改变动画,而且通过骨骼其余部分向下传递的东西。

  创建一个没有层次的骨骼系统是可能的 -- 但那时你不能忽略一个骨架并且预期它工作。你所看到的只是身体上的一个骨架开始了新动画,除非你实现了某种向下传递信息的系统,否则在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始,你就自动地获得这些效果。

  许多今天的动画系统中正开始出现一些比较新的特征,如动画混合,从一个正在播放的动画转变到另外一个动画需要经过一小段时间,而不是立即从一个动画突然转变到另外一个。举例来说,你有个角色在行走,然后他停了下来。你不是仅仅突然地转变动画,让他的腿和脚停在无效位置,而是一秒钟混合一半,这样脚似乎自然地移到了新的动画。不能够过高的评价这种效果 -- 混合是一个微妙的事情,但如果正确的运用,它真的有些差别。


反向运动学
  反向运动学 (IK) 是被许多人们丢弃的一个专业术语,对它的真实含义没有多少概念。IK 是如今游戏里面一个相对比较新的系统。使用 IK ,程序员能够移动一只手,或一条腿, 模型的其余关节自动重新定位,因此模型被正确定向。而且有模型的关节新位置的其馀者他们自己,因此模型正确的被定向。比如,你将会说,"好,手 , 去拾起桌子上的那个杯子"并指出杯子在世界中的位置。手就会移动到那里,且它后面的身体会调节其自身以便双臂移动,身体适当弯曲,等等。

  也有和IK相反的事情,叫做前向运动学,本质上与 IK 工作的次序相反。想像一只手,手附着在手臂上,手臂附着在身体上。现在想像你重重地击中了身体。通常手臂像连迦般抽动,且手臂末梢的手随之振动。 IK 能够移动身体,并让其余的四肢自己以真实的方式移动。基本上它需要动画师设定每种工作的大量信息 -- 像关节所能通过的运动范围,如果一块骨架前面的骨架移动,那么这块骨架将移动多少百分比,等等。

  和它现在一样,尽管很好,它是一个很大的处理问题,不用它你可以有不同的动画组合而脱身。值得注意的是,真正的 IK 解决办法需要一个层次骨骼系统而不是一个模型空间系统 -- 否则它们都耗时太多以致无法恰当地计算每个骨架。


LOD
几何系统
  最后,我们应当快速讨论一下与缩放模型几何复杂度相关的细节级别(LOD)系统(与讨论MIP映射时使用的LOD相对照)。假定如今绝大多数PC游戏支持的处理器速度的巨大范围,以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色还是12个?) 你通常需要一些系统来处理这样的情况,比如,当系统接近极限试图同时在屏幕上绘制出12个角色,每个角色有3000个多边形,并维持现实的幀速率。 LOD 被设计来协助这样的情景中。最基本的情况,它是在任何给定时间动态地改变你在屏幕上绘制的角色的多边形数量的能力。面对现实吧,当一个角色走远,也许只有十个屏幕像素高度,你真的不需要3000个多边形来渲染这个角色 -- 或许300个就够了,而且你很难分辨出差别。

  一些 LOD 系统将会需要你建立模型的多个版本,而且他们将会依靠模型离观察者的接近程度来改变屏幕上的LOD级别, 以及多少个多边形正被同时显示。更加复杂的系统实际上将会动态地减少屏幕上的多边形数量,在任何给定时间,任何给定的角色,动态地 -- MessiahSacrifice包括了这种风格的技术,尽管在CPU方面并不便宜。你必须确信,与首先简单地渲染整个事物相比,你的 LOD 系统没有花较多的时间计算出要渲染那些多边形(或不渲染)。 任一方式都将会工作,由于如今我们试图要在屏幕上绘制的多边形数量,这是件非常必要的事情。注意, DX9 将会支持硬件执行的自适应几何缩放(tessellation)

  归结起来是,得到一个运动流畅,其表现和移动在视觉上可信,屏幕上看起来逼真的模型。流畅的动画时常是通过手工建造动画和运动捕捉动画的组合得到。有时你仅仅手工建立了一个给定的动画 -- 当你在为一个模型做一些你在现实生活中不能做到的事情的动画时, 你倾向于这样做 -- 举例来说,你确实不能向后弯腰,或像Mortal Kombat 4中的Lui Kang那样在行进的脚踏车上踢腿,通常运动捕捉这时候就出局了! 通常运动捕捉动画 -- 实际上视频捕捉活生生的演员贯穿于你想在屏幕上所看到的动画 -- 是得到逼真的东西的方式。真实感的东西能使一款普通游戏看起来很棒,而且能掩饰许多事情。比如 NFL Blitz,屏幕上的模型大约有 200 个多边形。它们在静止站立时看起来可怕的斑驳,一旦这些模型跑动起来它们就有快速流畅的动画,模型自身的许多丑陋消失了。眼睛容易看见的是 '逼真的' 动画而不是模型自身的结构。 一个不错的模型设计师能够掩饰大多数模型缺陷。

  我希望这些带给你对模型和动画问题的洞察力。在第五部份中,我们将会更加深入3D世界的建造,讨论一些物理,运动和效果系统的东西。



梦在天涯 2007-12-04 13:18 发表评论

posted @ 2009-04-10 10:44 不会飞的鸟 阅读(127) | 评论 (0)编辑 收藏

游戏引擎基础(三)(内存使用,特效和API)

3部份: 内存使用,特效和API


关于内存使用的思考
  让我们想一想,在今天实际上是如何使用3D 显卡内存的以及在将来又会如何使用。 如今绝大多数3D显卡处理32位像素颜色,8位红色, 8位蓝色,8 位绿色,和 8 位透明度。这些组合的红,蓝和绿256个色度,可以组成 167 百万种颜色-- 那是你我可以在一个监视器上看见的所有颜色。

  那么,游戏设计大师John Carmack 为什么要求 64 位颜色分辨率呢? 如果我们看不出区别,又有什么意义呢? 意义是: 比如说, 有十几个灯光照射模型上的点,颜色颜色各不相同。 我们取模型的最初颜色,然后计算一个灯光的照射,模型颜色值将改变。 然后我们计算另外的一个灯光, 模型颜色值进一步改变。 这里的问题是,因为颜色值只有8位,在计算了4个灯光之后,8位的颜色值将不足以给我们最后的颜色较好的分辨率和表现。分辨率的不足是由量化误差导致的,本质原因是由于位数不足引起的舍入误差。

  你能很快地用尽位数,而且同样地,所有的颜色被清掉。每颜色16 32 位,你有一个更高分辨率,因此你能够反复着色以适当地表现最后的颜色。这样的颜色深度很快就能消耗大量的存储空间。我们也应提到整个显卡内存与纹理内存。这里所要说的是,每个3D 显卡实际只有有限的内存,而这些内存要存储前端和后端缓冲区,Z 缓冲区,还有所有的令人惊奇的纹理。最初的 Voodoo1 显卡只有2MB显存,后来 Riva TNT提高到16MB显存。然后 GeForce ATI Rage32MB显存, 现在一些 GeForce 2 4的显卡和 Radeons 带有 64MB 128MB 的显存。 这为什么重要? 好吧,让我们看一些数字

  比如你想让你的游戏看起来最好,所以你想要让它以32位屏幕, 1280x1024分辨率和32 Z- 缓冲跑起来。 好,屏幕上每个像素4个字节,外加每个像素4字节的Z-缓冲,因为都是每像素32位。我们有1280x1024 个像素也就是 1310720个像素。基于前端缓冲区和Z-缓冲区的字节数,这个数字乘以8,是 10485760字节。包括一个后端缓冲区,这样是 1280x1024x12 也就是 15728640 字节, 15MB 在一个 16MB 显存的显卡上,就只给我们剩下1MB 来存储所有的纹理。 现在如果最初的纹理是真32 位或 4字节宽,那么我们每幀能在显卡上存储 1MB/4字节每像素 = 262144个像素。这大约是4 256x256 的纹理页面。

  很清楚,上述例子表明,旧的16MB 显卡没有现代游戏表现其绚丽画面所需要的足够内存。很明显,在它绘制画面的时候,我们每幀都必须重新把纹理装载到显卡。实际上,设计AGP总线的目的就是完成这个任务,不过, AGP 还是要比 3D 掀卡的幀缓冲区慢,所以你会受到性能上的一些损失。很明显,如果纹理由32位降低到16位,你就能够通过AGP以较低的分辨率传送两倍数量的纹理。如果你的游戏以每个像素比较低的色彩分辨率跑, 那么就可以有更多的显示内存用来保存常用的纹理 (称为高速缓存纹理) 但实际上你永远不可能预知使用者将如何设置他们的系统。如果他们有一个在高分辨率和颜色深度跑的显卡,那么他们将会更可能那样设定他们的显卡。



  我们现在开始讲雾,它是某种视觉上的效果。如今绝大多数的引擎都能处理雾, 因为雾非常方便地让远处的世界淡出视野,所以当模型和场景地理越过观察体后平面进入视觉范围内时,你就不会看见它们突然从远处跳出来了。 也有一种称为体雾的技术。这种雾不是随物体离照相机的距离而定,它实际上是一个你能看见的真实对象,并且可以穿越它,从另外一侧出去 -- 当你在穿越对象的时候,视觉上雾的可见程度随着变化。想象一下穿过云团 -- 这是体雾的一个完美例子。体雾的一些好的实现例子是Quake III一些关卡中的红色雾,或新的Rogue Squadron II Lucas Arts GameCube 版本。其中有一些是我曾经见过的最好的云--大约与你能看见的一样真实。

  在我们讨论雾化的时候,可能是简短介绍一下 Alpha 测试和纹理Alpha混合的好时机。当渲染器往屏幕上画一个特定像素时,假定它已经通过 Z- 缓冲测试 (在下面定义),我们可能最后做一些Alpha测试。我们可能发现为了显示像素后面的某些东西,像素需要透明绘制。这意味着我们必须取得像素的已有值,和我们新的像素值进行混和,并把混合结果的像素值放回原处。这称为读-修改-写操作,远比正常的像素写操作费时。

  你可以用不同类型的混合,这些不同的效果被称为混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。还有加法混合,将旧像素的一些百分比,和特定数量(而不是百分比)的新像素相加。 这样效果会更加鲜明。 (Kyle's Lightsaber Jedi Knight II 中的效果)

  每当厂商提供新的显卡时,我们可以得到硬件支持的更新更复杂的混合模式,从而制作出更多更眩目的效果。GF3+4和最近的Radeon显卡提供的像素操作,已经到了极限。


模板阴影与深度测试
  用模板产生阴影效果,事情就变得复杂而昂贵了。这里不讨论太多细节(可以写成一篇单独的文章了),其思想是,从光源视角绘制模型视图,然后用这个把多边形纹理形状产生或投射到受影响的物体表面。

  实际上你是在视野中投射将会在其他多边形上面的光体。最后你得到看似真实的光照,甚至带有视角在里面。因为要动态创建纹理,并对同一场景进行多遍绘制,所以这很昂贵。

  你能用众多不同方法产生阴影,情形时常是这样一来,渲染质量与产生效果所需要的渲染工作成比例。有所谓的硬阴影或软阴影之分,而后者较好,因为它们更加准确地模仿阴影通常在真实世界的行为。 通常有一些被游戏开发者偏爱的足够好的方法。如要更多的了解阴影,请参考 Dave Salvator 3D 流水线一文。


深度测试
  现在我们开始讨论深度测试, 深度测试丢弃隐藏的像素,过度绘制开始起作用。过度绘制非常简单在一幀中,你数次绘制一个像素位置。它以3D场景中Z(深度)方向上存在的元素数量为基础,也被称为深度复杂度。如果你常常太多的过度绘制, -- 举例来说, 符咒的眩目视觉特效,就象Heretic II,能让你的幀速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时,Heretic II设计的一些最初效果造成的情形是,他们在一幀中对屏幕上每个相同的像素画了40! 不用说,这必须调整,尤其是软件渲染器,除了将游戏降低到象是滑雪表演外,它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术,这样我们就能够避免绘制那些隐藏的对象。

  看着场景并想想你所看不见的。 换句话说,是什么在其他场景对象前面,或者隐藏了其他场景对象? 是深度测试作出的这个决定。

  我将进一步解释深度深度如何帮助提高幀速率。想像一个很琐细的场景,大量的多边形 (或像素)位于彼此的后面,在渲染器获得他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序( Z- 方向上),首先渲染离你最近的那些多边形,优先使用距离最近的像素填充屏幕。所以当你要渲染它们后面的像素(由Z或者深度测试决定)时,这些像素很快被丢弃,从而避免了混合步骤并节省了时间。如果你从后到前绘制,所有隐藏的对象将被完全绘制,然后又被其他对象完全重写覆盖。场景越复杂,这种情况就越糟糕,所以深度测试是个好东西。


抗锯齿
  让我们快速的看一下抗锯齿。当渲染单个多边形时,3D 显卡仔细检查已经渲染的,并对新的多边形的边缘进行柔化,这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。 第一种方法是单个多边形层次,需要你从视野后面到前面渲染多边形,这样每个多边形都能和它后面的进行适当的混合。如果不按序进行渲染,最后你会看见各种奇怪的效果。在第二种方法中,使用比实际显示更大的分辩率来渲染整幅幀画面,然后在你缩小图像时,尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错,但因为显卡需要渲染比实际结果幀更多的像素,所以需要大量的内存资源和很高的内存带宽。

  多数新的显卡能很好地处理这些,但仍然有多种抗锯齿模式可以供你选择,因此你可以在性能和质量之间作出折衷。对於当今流行的各种不同抗锯齿技术的更详细讨论请参见Dave Salvator 3D 流水线一文。


顶点与像素着色
  在结束讨论渲染技术之前,我们快速的说一下顶点和像素着色,最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式,不使用API。举例来说,如果显卡支持硬件 T & L ,你可以用DirectXOpenGL编程,并希望你的顶点通过 T & L 单元 (因为这完全由驱动程序处理,所以没有办法确信),或者你直接利用显卡硬件使用顶点着色。它们允许你根据显卡自身特征进行特别编码,你自己特殊的编码使用T & L 引擎,以及为了发挥你的最大优势,显卡必须提供的其他别的特征。 事实上,现在nVidia ATI 在他们大量的显卡上都提供了这个特征。

  不幸的是,显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL 那样,为顶点着色编写一次代码就可以在任何显卡上运行,这可是个坏消息。然而,因为你直接和显卡硬件交流,它为快速渲染顶点着色可能生成的效果提供最大的承诺。( 如同创造很不错的特效 -- 你能够使用顶点着色以API没有提供的方式影响事物)。事实上,顶点着色正在真的将3D 图形显示卡带回到游戏机的编码方式,直接存取硬件,最大限度利用系统的必须知识,而不是依靠API来为你做一切。对一些程序员来说,会对这种编码方式感到吃惊,但这是进步代价。

  进一步阐述,顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情,或者使用显卡上的顶点着色。 为动画模型变换网格是顶点程序的主选。

  像素着色是那些你写的例程,当绘制纹理时,这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这允许你做一些很不错的像素效果, 比如,使远处的纹理模糊,添加炮火烟雾, 产生水中的反射效果等。一旦 ATI nVidia 能实际上就像素着色版本达成一致( DX9's 新的高级阴影语言将会帮助促进这一目标), 我一点不惊讶DirectX OpenGL采用Glide的方式-- 有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望将来。


最后(In Closing...
  最终,渲染器是游戏程序员最受评判的地方。在这个行业,视觉上的华丽非常重要,因此它为知道你正在做的买单。对于渲染器程序员,最坏的因素之一就是3D 显卡工业界变化的速度。一天,你正在尝试使透明图像正确地工作;第二天 nVidia 正在做顶点着色编程的展示。而且发展非常快,大致上,四年以前为那个时代的 3D 显卡写的代码现在已经过时了,需要全部重写。 甚至John Carmack 这样描述过,他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码,如今很平凡 -- 因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic Tim Sweeney赞同 -- 这里是去年他给我的评论:

  我们已经足足花费了9个月时间来更换所有的渲染代码。最初的 Unreal 被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡,且多边形吞吐量是Unreal Tournament100倍。

  这需要全部替换渲染器。很幸运,该引擎模块化程度足够好,我们可以保持引擎的其余部分编辑器,物理学,人工智能,网络--不改动,尽管我们一直在以许多方式改进这些部分。

  搭配长篇文章的短篇报导(Sidebar):API -- 祝福和诅咒
  那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说,很大程度上每种3D显示卡的3D实现方式都有所差别。然而,他们全部都呈现一个一致的前端给最终使用者或者程序员,所以他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧,不管怎样理论上是那样。 大约在三年以前这可能是相当真实的陈述,但自那以后,在nVidia 公司的引领下,3D显卡行业的事情发生了变化。

  如今在PC领域,除非你正计划建造自己的软件光栅引擎,使用CPU来绘制你所有的精灵,多边形和粒子 -- 而且人们仍然在这样做。跟Unreal一样,Age of Empires II: Age of Kings有一个优秀的软件渲染器否则你将使用两种可能的图形APIOpenGL或者 DirectX 之一。OpenGL是一种真正的跨平台API (使用这种API写的软件可以在LinuxWindowsMacOS上运行。) 而且有多年的历史了,为人所熟知,但也开始慢慢地显示出它的古老。 大约在四年以前,定义OpenGL驱动特征集一直是所有显示卡厂商工作的方向。

  然而,一旦在目标达成以后,没有预先制定特征工作方向的路线图,这时候,所有的显卡开发商开始在特征集上分道扬镳,使用OpenGL扩展。

  3dfx 创造了T- 缓冲。 nVidia 努力寻求硬件变换和光照计算。Matrox努力获取凹凸贴图。等等。 我以前说过的一句话,"过去几年以来,3D显示卡领域的事情发生了变化。"委婉地说明了这一切。

  无论如何,另一个可以选择的API DirectX。这受Microsoft公司控制,且在PC Xbox 上被完美地支持。由于明显的原因,DirectX 没有Apple或者 Linux 版本。因为Microsoft控制着 DirectX,大体上它容易更好地集成在Windows里面。

  OpenGLDirectX之间的基本差别是前者由社区拥有,而后者由Microsoft拥有。如果你想要 DirectX 为你的 3D 显示卡支持一个新的特征,那么你需要游说微软,希望采纳你的愿望,并等待新的 DirectX发行版本。对于OpenGL,由于显示卡制造商为3D显示卡提供驱动程序,你能够通过OpenGL扩展立即获得显示卡的新特征。这是好,但作为游戏开发者,当你为游戏编码的时候,你不能指望它们很普遍。它们可能让你的游戏速度提升50%,但你不能要求别人有一块GeForce 3 来跑你的游戏。好吧,你可以这么做,但如果你想来年还在这个行业的话,这是个相当愚蠢的主意。

  这是对这个问题极大的简单化,对我所有描述的也有各种例外情况,但这里一般的思想是很确实的。对于DirectX ,在任何既定时间你容易确切地知道你能从显示卡获得的特征,如果一个特征不能获得,DirectX 将会用软件模拟它(也不总是一件好事情,因为这样有时侯非常的慢,但那是另外一回事)。对于OpenGL,你可以更加贴近显示卡的特征,但代价是不能确定将会获得的准确特征。



梦在天涯 2007-12-04 13:17 发表评论

posted @ 2009-04-10 10:44 不会飞的鸟 阅读(94) | 评论 (0)编辑 收藏

游戏引擎基础(二)(3D环境的光照和纹理)

2部份: 3D环境的光照和纹理


世界的灯光
  在变换过程中, 通常是在称为观察空间的坐标空间中, 我们遇到了最重要的运算之一: 光照计算。 它是一种这样的事情, 当它工作时,你不关注它,但当它不工作时, 你就非常关注它了。有很多不同的光照方法,从简单的计算多边形对于灯光的朝向,并根据灯光到多边形的方向和距离加上灯光颜色的百分比值,一直到产生边缘平滑的灯光贴图叠加基本纹理。而且一些 API 实际上提供预先建造的光照方法。举例来说,OpenGL 提供了每多边形,每顶点,和每像素的光照计算。

  在顶点光照中,你要决定一个顶点被多少个多边形共享,并计算出共享该顶点的所有多边形法向量的均值(称为法向量),并将该法向量赋顶点。一个给定多边形的每个顶点会有不同的法向量,所以你需要渐变或插值多边形顶点的光照颜色以便得到平滑的光照效果。 你没有必要用这种光照方式查看每个单独的多边形。 这种方式的优点是时常可以使用硬件转换与光照(T & L)来帮助快速完成。 不足之处是它不能产生阴影。 举例来说,即使灯光是在模型的右侧,左手臂应该在被身体投影的阴影中,而实际上模型的双臂却以同样的方式被照明了。

  这些简单的方法使用着色来达到它们的目标。 当用平面光照绘制一个多边形时, 你让渲染(绘制)引擎把整个多边形都着上一种指定的颜色。这叫做平面着色光照。 (该方法中,多边形均对应一个光强度,表面上所有点都用相同的强度值显示,渲染绘制时得到一种平面效果,多边形的边缘不能精确的显示出来)

  对于顶点着色 ( Gouraud 着色) ,你让渲染引擎给每个顶点赋予特定的颜色。 在绘制多边形上各点投影所对应的像素时,根据它们与各顶点的距离,对这些顶点的颜色进行插值计算。 (实际上Quake III 模型使用的就是这种方法, 效果好的令人惊奇)

  还有就是 Phong 着色。如同 Gouraud 着色,通过纹理工作,但不对每个顶点颜色进行插值决定像素颜色值, 它对每个顶点的法向量进行插值,会为每个顶点投影的像素做相同的工作。对于 Gouraud 着色,你需要知道哪些光投射在每个顶点上。对于 Phong 着色,你对每个像素也要知道这么多。

  一点也不令人惊讶, Phong 着色可以得到更加平滑的效果,因为每个像素都需要进行光照计算,其绘制非常耗费时间。平面光照处理方法很快速, 但比较粗糙。Phong 着色比 Gouraud 着色计算更昂贵,但效果最好,可以达到镜面高光效果("高亮") 这些都需要你在游戏开发中折衷权衡。


不同的灯光
  接着是生成照明映射,你用第二个纹理映射(照明映射)与已有的纹理混合来产生照明效果。这样工作得很好, 但这本质上是在渲染之前预先生成的一种罐装效果。如果你使用动态照明 (即,灯光移动, 或者没有程序的干预而打开和关闭),你得必须在每一幀重新生成照明映射,按照动态灯光的运动方式修改这些照明映射。灯光映射能够快速的渲染,但对存储这些灯光纹理所需的内存消耗非常昂贵。你可以使用一些压缩技巧使它们占用较少的的内存空间,或减少其尺寸大小, 甚至使它们是单色的 (这样做就不会有彩色灯光了),等等。 如果你确实在场景中有多个动态灯光, 重新生成照明映射将以昂贵的CPU周期而告终。

  许多游戏通常使用某种混合照明方式。 Quake III为例,场景使用照明映射, 动画模型使用顶点照明。 预先处理的灯光不会对动画模型产生正确的效果 -- 整个多边形模型得到灯光的全部光照值 -- 而动态照明将被用来产生正确的效果。 使用混合照明方式是多数的人们没有注意到的一个折衷,它通常让效果看起来"正确" 这就是游戏的全部做一切必要的工作让效果看起来"正确",但不必真的是正确的。

  当然,所有这些在新的Doom引擎里面都不复存在了,但要看到所有的效果,至少需要 1GHZ CPU GeForce 2 显卡。是进步了,但一切都是有代价的。

  一旦场景经过转换和照明, 我们就进行裁剪运算。 不进入血淋淋的细节而,剪断运算决定哪些三角形完全在场景 (被称为观察平截头体) 之内或部份地在场景之内。完全在场景之内的三角形被称为细节接受,它们被处理。对于只是部分在场景之内的三角形, 位于平截头体外面的部分将被裁剪掉,余下位于平截头体内部的多边形部分将需要重新闭合,以便其完全位于可见场景之内。 (更多的细节请参考我们的 3D 流水线指导一文)

  场景经过裁剪以后,流水线中的下一个阶段就是三角形生成阶段(也叫做扫描 线转换),场景被映射到2D 屏幕坐标。到这里,就是渲染(绘制)运算了。


纹理与MIP映射
  纹理在使3D场景看起来真实方面异常重要,它们是你应用到场景区域或对象的一些分解成多边形的小图片。多重纹理耗费大量的内存,有不同的技术来帮助管理它们的尺寸大小。纹理压缩是在保持图片信息的情况下,让纹理数据更小的一种方法。纹理压缩占用较少的游戏CD空间,更重要的是,占用较少内存和3D 显卡存储空间。另外,在你第一次要求显卡显示纹理的时候,压缩的(较小的) 版本经过 AGP 接口从 PC 主存送到3D 显卡, 会更快一些。纹理压缩是件好事情。 在下面我们将会更多的讨论纹理压缩。


MIP
映射(多纹理映射)
  游戏引擎用来减少纹理内存和带宽需求的另外一个技术就是 MIP 映射。 MIP 映射技术通过预先处理纹理,产生它的多个拷贝纹理,每个相继的拷贝是上一个拷贝的一半大小。为什么要这样做?要回答这个问题,你需要了解 3D 显卡是如何显示纹理的。最坏情况,你选择一个纹理,贴到一个多边形上,然后输出到屏幕。我们说这是一对一的关系,最初纹理映射图的一个纹素 (纹理元素) 对应到纹理映射对象多边形的一个像素。如果你显示的多边形被缩小一半,纹理的纹素就每间隔一个被显示。这样通常没有什么问题 -- 但在某些情况下会导致一些视觉上的怪异现象。让我们看看砖块墙壁。 假设最初的纹理是一面砖墙,有许多砖块,砖块之间的泥浆宽度只有一个像素。如果你把多边形缩小一半, 纹素只是每间隔一个被应用,这时候,所有的泥浆会突然消失,因为它们被缩掉了。你只会看到一些奇怪的图像。

  使用 MIP 映射,你可以在显示卡应用纹理之前,自己缩放图像,因为可以预先处理纹理,你做得更好一些,让泥浆不被缩掉。当 3D 显卡用纹理绘制多边形时,它检测到缩放因子,说,"你知道,我要使用小一些的纹理,而不是缩小最大的纹理,这样看起来会更好一些。" 在这里, MIP 映射为了一切,一切也为了 MIP 映射。


多重纹理与凹凸映射
  单一纹理映射给整个3D 真实感图形带来很大的不同, 但使用多重纹理甚至可以达到一些更加令人难忘的效果。过去这一直需要多遍渲染(绘制),严重影响了像素填充率。 但许多具有多流水线的3D 加速卡,如ATI's Radeon nVidia's GeForce 2及更高级的显卡,多重纹理可以在一遍渲染(绘制)过程中完成。 产生多重纹理效果时, 你先用一个纹理绘制多边形,然后再用另外一个纹理透明地绘制在多边形上面。这让你可以使纹理看上去在移动,或脉动, 甚至产生阴影效果 (我们在照明一节中描述过)。绘制第一个纹理映射,然后在上面绘制带透明的全黑纹理,引起一种是所有的织法黑色的但是有一个透明分层堆积过它的顶端 这就是 -- 即时阴影。 该技术被称为照明映射 ( 有时也称为 暗映射),直至新的Doom ,一直是Id引擎里关卡照明的传统方法。

  凹凸贴图是最近涌现出来的一种古老技术。几年以前 Matrox 第一个在流行的 3D 游戏中发起使用各种不同形式的凹凸贴图。就是生成纹理来表现灯光在表面的投射,表现表面的凹凸或表面的裂缝。 凹凸贴图并不随着灯光一起移动 -- 它被设计用来表现一个表面上的细小瑕疵,而不是大的凹凸。 比如说,在飞行模拟器中,你可以使用凹凸贴图来产生像是随机的地表细节,而不是重复地使用相同的纹理,看上去一点趣味也没有。

  凹凸贴图产生相当明显的表面细节,尽管是很高明的戏法,但严格意义上讲,凹凸贴图并不随着你的观察角度而变化。比较新的 ATI nVidia 显卡片能执行每像素运算,这种缺省观察角度的不足就真的不再是有力而快速的法则了。 无论是哪一种方法, 到目前为止,没有游戏开发者太多的使用; 更多的游戏能够且应该使用凹凸贴图。


高速缓存抖动 = 糟糕的事物
  纹理高速缓存的管理游戏引擎的速度至关重要。 和任何高速缓存一样,缓存命中很好,而不命中将很糟糕。如果遇到纹理在图形显示卡内存被频繁地换入换出的情况,这就是纹理高速缓存抖动。发生这种情况时,通常API将会废弃每个纹理,结果是所有的纹理在下一幀将被重新加载,这非常耗时和浪费。对游戏玩家来说,当API重新加载纹理高速缓存时,会导致幀速率迟钝。

  在纹理高速缓存管理中,有各种不同的技术将纹理高速缓存抖动减到最少这是确保任何 3D 游戏引擎速度的一个决定性因素。 纹理管理是件好事情这意味着只要求显卡使用纹理一次,而不是重复使用。这听起来有点自相矛盾,但效果是它意谓着对显卡说,"看, 所有这些多边形全部使用这一个纹理,我们能够仅仅加载这个纹理一次而不是许多次吗?" 这阻止API ( 或图形驱动软件) 上传多次向显卡加载纹理。象OpenGL这样的API实际上通常处理纹理高速缓存管理,意谓着,根据一些规则,比如纹理存取的频率,API决定哪些纹理储存在显卡上,哪些纹理存储在主存。 真正的问题来了:a) 你时常无法知道API正在使用的准确规则。 b)你时常要求在一幀中绘制更多的纹理,以致超出了显卡内存空间所能容纳的纹理。

  另外一种纹理高速缓存管理技术是我们早先讨论的纹理压缩。很象声音波形文件被压缩成 MP3 文件,尽管无法达到那样的压缩比率,但纹理可以被压缩。 从声音波形文件到MP3的压缩可以达到 11:1的压缩比率,而绝大多数硬件支持的纹理压缩运算法则只有 4:1 的压缩比率,尽管如此,这样能产生很大的差别。 除此之外,在渲染(绘制)过程中,只有在需要时,硬件才动态地对纹理进行解压缩。这一点非常棒,我们仅仅擦除即将可能用到的表面。

  如上所述,另外一种技术确保渲染器要求显卡对每个纹理只绘制一次。确定你想要渲染(绘制)的使用相同纹理的所有多边形同时送到显卡,而不是一个模型在这里,另一个模型在那里,然后又回到最初的纹理论。仅仅绘制一次,你也就通过AGP接口传送一次。Quake III 在其阴影系统就是这么做的。处理多边形时,把它们加入到一个内部的阴影列表,一旦所有的多边形处理完毕,渲染器遍历纹理列表,就将纹理及所有使用这些纹理的多边形同时传送出去。

  上述过程在使用显卡的硬件 T & L(如果支持的话)时,并不怎么有效。你面临的结局是,满屏幕都是使用相同纹理的大量的多边形小群组,所有多边形都使用不同的变换矩阵。这意谓着更多的时间花在建立显卡的硬件 T & L 引擎 ,更多的时间被浪费了。 无论如何,因为他们有助于对整个模型使用统一的纹理,所以它对实际屏幕上的模型可以有效地工作。但是因为许多多边形倾向使用相同的墙壁纹理,所以对于世界场景的渲染,它常常就是地狱。通常它没有这么严重,因为大体而言,世界的纹理不会有那么大,这样一来API的纹理缓存系统将会替你处理这些,并把纹理保留在显卡以备再次使用。

  在游戏机上,通常没有纹理高速缓存系统(除非你写一个)。在 PS2 上面,你最好是远离"一次纹理" 的方法。在 Xbox 上面, 这是不重要的,因为它本身没有图形内存(它是 UMA 体系结构),且所有的纹理无论如何始终保留在主存之中。

  事实上,在今天的现代PC FPS 游戏中,试图通过AGP接口传送大量纹理是第二个最通常的瓶颈。最大的瓶颈是实际几何处理,它要使东西出现在它应该出现的地方。在如今的3D FPS 游戏中,最耗费时间的工作,显然是那些计算模型中每个顶点正确的世界位置的数学运算。如果你不把场景的纹理保持在预算之内,仅居其次的就是通过AGP接口传送大量的纹理了。然而,你确实有能力影响这些。 通过降低顶层的 MIP 级别(还记得系统在哪里不断地为你细分纹理吗?) 你就能够把系统正在尝试送到显卡的纹理大小减少一半。你的视觉质量会有所下降-- 尤其是在引人注目的电影片断中--但是你的幀速率上升了。这种方式对网络游戏尤其有帮助。实际上,Soldier of Fortune IIJedi Knight II: Outcast这两款游戏在设计时针对的显卡还不是市场上的大众主流显卡。为了以最大大小观看他们的纹理,你的3D 显卡至少需要有128MB的内存。这两种产品在思想上都是给未来设计的。

  上面就是第 2 部份。在下面章节中,我们将介绍许多主题,包括内存管理,雾效果,深度测试, 抗锯齿,顶点着色,API等。



梦在天涯 2007-12-04 13:16 发表评论

posted @ 2009-04-10 10:44 不会飞的鸟 阅读(217) | 评论 (0)编辑 收藏

游戏引擎基础(一)(渲染和构造3D世界)

     摘要:  本系列转自:http://www.cppblog.com/orlando/archive/2007/12/03/37734.html 谢谢作者有这么好的文章与大家共享!代表所有有幸阅读到次书的读者谢谢先!第1部分: 游戏引擎介绍, 渲染和构造3D世界介绍  自Doom游戏时代以来我们已经走了很远。 DOOM不只是一款伟大的游戏,它同时也开创了一种新的游戏编程模式: 游戏 "引...  阅读全文

梦在天涯 2007-12-04 13:14 发表评论

posted @ 2009-04-10 10:44 不会飞的鸟 阅读(125) | 评论 (0)编辑 收藏

[转载]堆栈,堆栈,堆和栈的区别

堆和栈的区别
一、预备知识—程序的内存分配
一个由c/C++编译的程序占用的内存分为以下几个部分
1、栈区(stack)— 由编译器自动分配释放 ,存放函数的参数值,局部变量的值等。其操作方式类似于数据结构中的栈。
2、堆区(heap) — 一般由程序员分配释放, 若程序员不释放,程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事,分配方式倒是类似于链表,呵呵。
3、全局区(静态区)(static)—,全局变量和静态变量的存储是放在一块的,初始化的全局变量和静态变量在一块区域, 未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。 - 程序结束后有系统释放 
4、文字常量区—常量字符串就是放在这里的。 程序结束后由系统释放
5、程序代码区—存放函数体的二进制代码。
二、例子程序 
这是一个前辈写的,非常详细 
//main.cpp 
int a = 0; 全局初始化区 
char *p1; 全局未初始化区 
main() 

int b; 栈 
char s[] = "abc"; 栈 
char *p2; 栈 
char *p3 = "123456"; 123456\0在常量区,p3在栈上。 
static int c =0; 全局(静态)初始化区 
p1 = (char *)malloc(10); 
p2 = (char *)malloc(20); 
分配得来得10和20字节的区域就在堆区。 
strcpy(p1, "123456"); 123456\0放在常量区,编译器可能会将它与p3所指向的"123456"优化成一个地方。 

 


二、堆和栈的理论知识 
2.1申请方式 
stack: 
由系统自动分配。 例如,声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间 
heap: 
需要程序员自己申请,并指明大小,在c中malloc函数 
如p1 = (char *)malloc(10); 
在C++中用new运算符 
如p2 = (char *)malloc(10); 
但是注意p1、p2本身是在栈中的。 


2.2 
申请后系统的响应 
栈:只要栈的剩余空间大于所申请空间,系统将为程序提供内存,否则将报异常提示栈溢出。 
堆:首先应该知道操作系统有一个记录空闲内存地址的链表,当系统收到程序的申请时, 
会遍历该链表,寻找第一个空间大于所申请空间的堆结点,然后将该结点从空闲结点链表中删除,并将该结点的空间分配给程序,另外,对于大多数系统,会在这块内存空间中的首地址处记录本次分配的大小,这样,代码中的delete语句才能正确的释放本内存空间。另外,由于找到的堆结点的大小不一定正好等于申请的大小,系统会自动的将多余的那部分重新放入空闲链表中。 

2.3申请大小的限制 
栈:在Windows下,栈是向低地址扩展的数据结构,是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的,在WINDOWS下,栈的大小是2M(也有的说是1M,总之是一个编译时就确定的常数),如果申请的空间超过栈的剩余空间时,将提示overflow。因此,能从栈获得的空间较小。 
堆:堆是向高地址扩展的数据结构,是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的,自然是不连续的,而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见,堆获得的空间比较灵活,也比较大。 


2.4申请效率的比较: 
栈由系统自动分配,速度较快。但程序员是无法控制的。 
堆是由new分配的内存,一般速度比较慢,而且容易产生内存碎片,不过用起来最方便. 
另外,在WINDOWS下,最好的方式是用VirtualAlloc分配内存,他不是在堆,也不是在栈是直接在进程的地址空间中保留一快内存,虽然用起来最不方便。但是速度快,也最灵活。 

2.5堆和栈中的存储内容 
栈: 在函数调用时,第一个进栈的是主函数中后的下一条指令(函数调用语句的下一条可执行语句)的地址,然后是函数的各个参数,在大多数的C编译器中,参数是由右往左入栈的,然后是函数中的局部变量。注意静态变量是不入栈的。 
当本次函数调用结束后,局部变量先出栈,然后是参数,最后栈顶指针指向最开始存的地址,也就是主函数中的下一条指令,程序由该点继续运行。 
堆:一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。 

2.6存取效率的比较 

char s1[] = "aaaaaaaaaaaaaaa"; 
char *s2 = "bbbbbbbbbbbbbbbbb"; 
aaaaaaaaaaa是在运行时刻赋值的; 
而bbbbbbbbbbb是在编译时就确定的; 
但是,在以后的存取中,在栈上的数组比指针所指向的字符串(例如堆)快。 
比如: 
#include 
void main() 

char a = 1; 
char c[] = "1234567890"; 
char *p ="1234567890"; 
a = c[1]; 
a = p[1]; 
return; 

对应的汇编代码 
10: a = c[1]; 
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh] 
0040106A 88 4D FC mov byte ptr [ebp-4],cl 
11: a = p[1]; 
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h] 
00401070 8A 42 01 mov al,byte ptr [edx+1] 
00401073 88 45 FC mov byte ptr [ebp-4],al 
第一种在读取时直接就把字符串中的元素读到寄存器cl中,而第二种则要先把指针值读到edx中,在根据edx读取字符,显然慢了。 


2.7小结: 
堆和栈的区别可以用如下的比喻来看出: 
使用栈就象我们去饭馆里吃饭,只管点菜(发出申请)、付钱、和吃(使用),吃饱了就走,不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作,他的好处是快捷,但是自由度小。 
使用堆就象是自己动手做喜欢吃的菜肴,比较麻烦,但是比较符合自己的口味,而且自由度大。 



windows进程中的内存结构


在阅读本文之前,如果你连堆栈是什么多不知道的话,请先阅读文章后面的基础知识。 

接触过编程的人都知道,高级语言都能通过变量名来访问内存中的数据。那么这些变量在内存中是如何存放的呢?程序又是如何使用这些变量的呢?下面就会对此进行深入的讨论。下文中的C语言代码如没有特别声明,默认都使用VC编译的release版。 

首先,来了解一下 C 语言的变量是如何在内存分部的。C 语言有全局变量(Global)、本地变量(Local),静态变量(Static)、寄存器变量(Regeister)。每种变量都有不同的分配方式。先来看下面这段代码: 

#include <stdio.h> 

int g1=0, g2=0, g3=0; 

int main() 

static int s1=0, s2=0, s3=0; 
int v1=0, v2=0, v3=0; 

//打印出各个变量的内存地址 

printf("0x%08x\n",&v1); //打印各本地变量的内存地址 
printf("0x%08x\n",&v2); 
printf("0x%08x\n\n",&v3); 
printf("0x%08x\n",&g1); //打印各全局变量的内存地址 
printf("0x%08x\n",&g2); 
printf("0x%08x\n\n",&g3); 
printf("0x%08x\n",&s1); //打印各静态变量的内存地址 
printf("0x%08x\n",&s2); 
printf("0x%08x\n\n",&s3); 
return 0; 

编译后的执行结果是: 

0x0012ff78 
0x0012ff7c 
0x0012ff80 

0x004068d0 
0x004068d4 
0x004068d8 

0x004068dc 
0x004068e0 
0x004068e4 

输出的结果就是变量的内存地址。其中v1,v2,v3是本地变量,g1,g2,g3是全局变量,s1,s2,s3是静态变量。你可以看到这些变量在内存是连续分布的,但是本地变量和全局变量分配的内存地址差了十万八千里,而全局变量和静态变量分配的内存是连续的。这是因为本地变量和全局/静态变量是分配在不同类型的内存区域中的结果。对于一个进程的内存空间而言,可以在逻辑上分成3个部份:代码区,静态数据区和动态数据区。动态数据区一般就是“堆栈”。“栈(stack)”和“堆(heap)”是两种不同的动态数据区,栈是一种线性结构,堆是一种链式结构。进程的每个线程都有私有的“栈”,所以每个线程虽然代码一样,但本地变量的数据都是互不干扰。一个堆栈可以通过“基地址”和“栈顶”地址来描述。全局变量和静态变量分配在静态数据区,本地变量分配在动态数据区,即堆栈中。程序通过堆栈的基地址和偏移量来访问本地变量。 


├———————┤低端内存区域 
│ …… │ 
├———————┤ 
│ 动态数据区 │ 
├———————┤ 
│ …… │ 
├———————┤ 
│ 代码区 │ 
├———————┤ 
│ 静态数据区 │ 
├———————┤ 
│ …… │ 
├———————┤高端内存区域 


堆栈是一个先进后出的数据结构,栈顶地址总是小于等于栈的基地址。我们可以先了解一下函数调用的过程,以便对堆栈在程序中的作用有更深入的了解。不同的语言有不同的函数调用规定,这些因素有参数的压入规则和堆栈的平衡。windows API的调用规则和ANSI C的函数调用规则是不一样的,前者由被调函数调整堆栈,后者由调用者调整堆栈。两者通过“__stdcall”和“__cdecl”前缀区分。先看下面这段代码: 

#include <stdio.h> 

void __stdcall func(int param1,int param2,int param3) 

int var1=param1; 
int var2=param2; 
int var3=param3; 
printf("0x%08x\n",¶m1); //打印出各个变量的内存地址 
printf("0x%08x\n",¶m2); 
printf("0x%08x\n\n",¶m3); 
printf("0x%08x\n",&var1); 
printf("0x%08x\n",&var2); 
printf("0x%08x\n\n",&var3); 
return; 

int main() 

func(1,2,3); 
return 0; 

编译后的执行结果是: 

0x0012ff78 
0x0012ff7c 
0x0012ff80 

0x0012ff68 
0x0012ff6c 
0x0012ff70 


├———————┤<—函数执行时的栈顶(ESP)、低端内存区域 
│ …… │ 
├———————┤ 
│ var 1 │ 
├———————┤ 
│ var 2 │ 
├———————┤ 
│ var 3 │ 
├———————┤ 
│ RET │ 
├———————┤<—“__cdecl”函数返回后的栈顶(ESP) 
│ parameter 1 │ 
├———————┤ 
│ parameter 2 │ 
├———————┤ 
│ parameter 3 │ 
├———————┤<—“__stdcall”函数返回后的栈顶(ESP) 
│ …… │ 
├———————┤<—栈底(基地址 EBP)、高端内存区域 


上图就是函数调用过程中堆栈的样子了。首先,三个参数以从又到左的次序压入堆栈,先压“param3”,再压“param2”,最后压入“param1”;然后压入函数的返回地址(RET),接着跳转到函数地址接着执行(这里要补充一点,介绍UNIX下的缓冲溢出原理的文章中都提到在压入RET后,继续压入当前EBP,然后用当前ESP代替EBP。然而,有一篇介绍windows下函数调用的文章中说,在windows下的函数调用也有这一步骤,但根据我的实际调试,并未发现这一步,这还可以从param3和var1之间只有4字节的间隙这点看出来);第三步,将栈顶(ESP)减去一个数,为本地变量分配内存空间,上例中是减去12字节(ESP=ESP-3*4,每个int变量占用4个字节);接着就初始化本地变量的内存空间。由于“__stdcall”调用由被调函数调整堆栈,所以在函数返回前要恢复堆栈,先回收本地变量占用的内存(ESP=ESP+3*4),然后取出返回地址,填入EIP寄存器,回收先前压入参数占用的内存(ESP=ESP+3*4),继续执行调用者的代码。参见下列汇编代码: 

;--------------func 函数的汇编代码------------------- 

:00401000 83EC0C sub esp, 0000000C //创建本地变量的内存空间 
:00401003 8B442410 mov eax, dword ptr [esp+10] 
:00401007 8B4C2414 mov ecx, dword ptr [esp+14] 
:0040100B 8B542418 mov edx, dword ptr [esp+18] 
:0040100F 89442400 mov dword ptr [esp], eax 
:00401013 8D442410 lea eax, dword ptr [esp+10] 
:00401017 894C2404 mov dword ptr [esp+04], ecx 

……………………(省略若干代码) 

:00401075 83C43C add esp, 0000003C ;恢复堆栈,回收本地变量的内存空间 
:00401078 C3 ret 000C ;函数返回,恢复参数占用的内存空间 
;如果是“__cdecl”的话,这里是“ret”,堆栈将由调用者恢复 

;-------------------函数结束------------------------- 


;--------------主程序调用func函数的代码-------------- 

:00401080 6A03 push 00000003 //压入参数param3 
:00401082 6A02 push 00000002 //压入参数param2 
:00401084 6A01 push 00000001 //压入参数param1 
:00401086 E875FFFFFF call 00401000 //调用func函数 
;如果是“__cdecl”的话,将在这里恢复堆栈,“add esp, 0000000C” 

聪明的读者看到这里,差不多就明白缓冲溢出的原理了。先来看下面的代码: 

#include <stdio.h> 
#include <string.h> 

void __stdcall func() 

char lpBuff[8]="\0"; 
strcat(lpBuff,"AAAAAAAAAAA"); 
return; 

int main() 

func(); 
return 0; 

编译后执行一下回怎么样?哈,“"0x00414141"指令引用的"0x00000000"内存。该内存不能为"read"。”,“非法操作”喽!"41"就是"A"的16进制的ASCII码了,那明显就是strcat这句出的问题了。"lpBuff"的大小只有8字节,算进结尾的\0,那strcat最多只能写入7个"A",但程序实际写入了11个"A"外加1个\0。再来看看上面那幅图,多出来的4个字节正好覆盖了RET的所在的内存空间,导致函数返回到一个错误的内存地址,执行了错误的指令。如果能精心构造这个字符串,使它分成三部分,前一部份仅仅是填充的无意义数据以达到溢出的目的,接着是一个覆盖RET的数据,紧接着是一段shellcode,那只要着个RET地址能指向这段shellcode的第一个指令,那函数返回时就能执行shellcode了。但是软件的不同版本和不同的运行环境都可能影响这段shellcode在内存中的位置,那么要构造这个RET是十分困难的。一般都在RET和shellcode之间填充大量的NOP指令,使得exploit有更强的通用性。 


├———————┤<—低端内存区域 
│ …… │ 
├———————┤<—由exploit填入数据的开始 
│ │ 
│ buffer │<—填入无用的数据 
│ │ 
├———————┤ 
│ RET │<—指向shellcode,或NOP指令的范围 
├———————┤ 
│ NOP │ 
│ …… │<—填入的NOP指令,是RET可指向的范围 
│ NOP │ 
├———————┤ 
│ │ 
│ shellcode │ 
│ │ 
├———————┤<—由exploit填入数据的结束 
│ …… │ 
├———————┤<—高端内存区域 


windows下的动态数据除了可存放在栈中,还可以存放在堆中。了解C++的朋友都知道,C++可以使用new关键字来动态分配内存。来看下面的C++代码: 

#include <stdio.h> 
#include <iostream.h> 
#include <windows.h> 

void func() 

char *buffer=new char[128]; 
char bufflocal[128]; 
static char buffstatic[128]; 
printf("0x%08x\n",buffer); //打印堆中变量的内存地址 
printf("0x%08x\n",bufflocal); //打印本地变量的内存地址 
printf("0x%08x\n",buffstatic); //打印静态变量的内存地址 

void main() 

func(); 
return; 

程序执行结果为: 

0x004107d0 
0x0012ff04 
0x004068c0 

可以发现用new关键字分配的内存即不在栈中,也不在静态数据区。VC编译器是通过windows下的“堆(heap)”来实现new关键字的内存动态分配。在讲“堆”之前,先来了解一下和“堆”有关的几个API函数: 

HeapAlloc 在堆中申请内存空间 
HeapCreate 创建一个新的堆对象 
HeapDestroy 销毁一个堆对象 
HeapFree 释放申请的内存 
HeapWalk 枚举堆对象的所有内存块 
GetProcessHeap 取得进程的默认堆对象 
GetProcessHeaps 取得进程所有的堆对象 
LocalAlloc 
GlobalAlloc 

当进程初始化时,系统会自动为进程创建一个默认堆,这个堆默认所占内存的大小为1M。堆对象由系统进行管理,它在内存中以链式结构存在。通过下面的代码可以通过堆动态申请内存空间: 

HANDLE hHeap=GetProcessHeap(); 
char *buff=HeapAlloc(hHeap,0,8); 

其中hHeap是堆对象的句柄,buff是指向申请的内存空间的地址。那这个hHeap究竟是什么呢?它的值有什么意义吗?看看下面这段代码吧: 

#pragma comment(linker,"/entry:main") //定义程序的入口 
#include <windows.h> 

_CRTIMP int (__cdecl *printf)(const char *, ...); //定义STL函数printf 
/*--------------------------------------------------------------------------- 
写到这里,我们顺便来复习一下前面所讲的知识: 
(*注)printf函数是C语言的标准函数库中函数,VC的标准函数库由msvcrt.dll模块实现。 
由函数定义可见,printf的参数个数是可变的,函数内部无法预先知道调用者压入的参数个数,函数只能通过分析第一个参数字符串的格式来获得压入参数的信息,由于这里参数的个数是动态的,所以必须由调用者来平衡堆栈,这里便使用了__cdecl调用规则。BTW,Windows系统的API函数基本上是__stdcall调用形式,只有一个API例外,那就是wsprintf,它使用__cdecl调用规则,同printf函数一样,这是由于它的参数个数是可变的缘故。 
---------------------------------------------------------------------------*/ 
void main() 

HANDLE hHeap=GetProcessHeap(); 
char *buff=HeapAlloc(hHeap,0,0x10); 
char *buff2=HeapAlloc(hHeap,0,0x10); 
HMODULE hMsvcrt=LoadLibrary("msvcrt.dll"); 
printf=(void *)GetProcAddress(hMsvcrt,"printf"); 
printf("0x%08x\n",hHeap); 
printf("0x%08x\n",buff); 
printf("0x%08x\n\n",buff2); 

执行结果为: 

0x00130000 
0x00133100 
0x00133118 

hHeap的值怎么和那个buff的值那么接近呢?其实hHeap这个句柄就是指向HEAP首部的地址。在进程的用户区存着一个叫PEB(进程环境块)的结构,这个结构中存放着一些有关进程的重要信息,其中在PEB首地址偏移0x18处存放的ProcessHeap就是进程默认堆的地址,而偏移0x90处存放了指向进程所有堆的地址列表的指针。windows有很多API都使用进程的默认堆来存放动态数据,如windows 2000下的所有ANSI版本的函数都是在默认堆中申请内存来转换ANSI字符串到Unicode字符串的。对一个堆的访问是顺序进行的,同一时刻只能有一个线程访问堆中的数据,当多个线程同时有访问要求时,只能排队等待,这样便造成程序执行效率下降。 

最后来说说内存中的数据对齐。所位数据对齐,是指数据所在的内存地址必须是该数据长度的整数倍,DWORD数据的内存起始地址能被4除尽,WORD数据的内存起始地址能被2除尽,x86 CPU能直接访问对齐的数据,当他试图访问一个未对齐的数据时,会在内部进行一系列的调整,这些调整对于程序来说是透明的,但是会降低运行速度,所以编译器在编译程序时会尽量保证数据对齐。同样一段代码,我们来看看用VC、Dev-C++和lcc三个不同编译器编译出来的程序的执行结果: 

#include <stdio.h> 

int main() 

int a; 
char b; 
int c; 
printf("0x%08x\n",&a); 
printf("0x%08x\n",&b); 
printf("0x%08x\n",&c); 
return 0; 

这是用VC编译后的执行结果: 
0x0012ff7c 
0x0012ff7b 
0x0012ff80 
变量在内存中的顺序:b(1字节)-a(4字节)-c(4字节)。 

这是用Dev-C++编译后的执行结果: 
0x0022ff7c 
0x0022ff7b 
0x0022ff74 
变量在内存中的顺序:c(4字节)-中间相隔3字节-b(占1字节)-a(4字节)。 

这是用lcc编译后的执行结果: 
0x0012ff6c 
0x0012ff6b 
0x0012ff64 
变量在内存中的顺序:同上。 

三个编译器都做到了数据对齐,但是后两个编译器显然没VC“聪明”,让一个char占了4字节,浪费内存哦。 


基础知识: 
堆栈是一种简单的数据结构,是一种只允许在其一端进行插入或删除的线性表。允许插入或删除操作的一端称为栈顶,另一端称为栈底,对堆栈的插入和删除操作被称为入栈和出栈。有一组CPU指令可以实现对进程的内存实现堆栈访问。其中,POP指令实现出栈操作,PUSH指令实现入栈操作。CPU的ESP寄存器存放当前线程的栈顶指针,EBP寄存器中保存当前线程的栈底指针。CPU的EIP寄存器存放下一个CPU指令存放的内存地址,当CPU执行完当前的指令后,从EIP寄存器中读取下一条指令的内存地址,然后继续执行。 


参考:《Windows下的HEAP溢出及其利用》by: isno 
《windows核心编程》by: Jeffrey Richter 



摘要: 讨论常见的堆性能问题以及如何防范它们。(共 9 页)

前言
您是否是动态分配的 C/C++ 对象忠实且幸运的用户?您是否在模块间的往返通信中频繁地使用了“自动化”?您的程序是否因堆分配而运行起来很慢?不仅仅您遇到这样的问题。几乎所有项目迟早都会遇到堆问题。大家都想说,“我的代码真正好,只是堆太慢”。那只是部分正确。更深入理解堆及其用法、以及会发生什么问题,是很有用的。

什么是堆?
(如果您已经知道什么是堆,可以跳到“什么是常见的堆性能问题?”部分)

在程序中,使用堆来动态分配和释放对象。在下列情况下,调用堆操作: 

事先不知道程序所需对象的数量和大小。


对象太大而不适合堆栈分配程序。
堆使用了在运行时分配给代码和堆栈的内存之外的部分内存。下图给出了堆分配程序的不同层。


GlobalAlloc/GlobalFree:Microsoft Win32 堆调用,这些调用直接与每个进程的默认堆进行对话。

LocalAlloc/LocalFree:Win32 堆调用(为了与 Microsoft Windows NT 兼容),这些调用直接与每个进程的默认堆进行对话。

COM 的 IMalloc 分配程序(或 CoTaskMemAlloc / CoTaskMemFree):函数使用每个进程的默认堆。自动化程序使用“组件对象模型 (COM)”的分配程序,而申请的程序使用每个进程堆。

C/C++ 运行时 (CRT) 分配程序:提供了 malloc() 和 free() 以及 new 和 delete 操作符。如 Microsoft Visual Basic 和 Java 等语言也提供了新的操作符并使用垃圾收集来代替堆。CRT 创建自己的私有堆,驻留在 Win32 堆的顶部。

Windows NT 中,Win32 堆是 Windows NT 运行时分配程序周围的薄层。所有 API 转发它们的请求给 NTDLL。

Windows NT 运行时分配程序提供 Windows NT 内的核心堆分配程序。它由具有 128 个大小从 8 到 1,024 字节的空闲列表的前端分配程序组成。后端分配程序使用虚拟内存来保留和提交页。

在图表的底部是“虚拟内存分配程序”,操作系统使用它来保留和提交页。所有分配程序使用虚拟内存进行数据的存取。

分配和释放块不就那么简单吗?为何花费这么长时间?

堆实现的注意事项
传统上,操作系统和运行时库是与堆的实现共存的。在一个进程的开始,操作系统创建一个默认堆,叫做“进程堆”。如果没有其他堆可使用,则块的分配使用“进程堆”。语言运行时也能在进程内创建单独的堆。(例如,C 运行时创建它自己的堆。)除这些专用的堆外,应用程序或许多已载入的动态链接库 (DLL) 之一可以创建和使用单独的堆。Win32 提供一整套 API 来创建和使用私有堆。有关堆函数(英文)的详尽指导,请参见 MSDN。

当应用程序或 DLL 创建私有堆时,这些堆存在于进程空间,并且在进程内是可访问的。从给定堆分配的数据将在同一个堆上释放。(不能从一个堆分配而在另一个堆释放。)

在所有虚拟内存系统中,堆驻留在操作系统的“虚拟内存管理器”的顶部。语言运行时堆也驻留在虚拟内存顶部。某些情况下,这些堆是操作系统堆中的层,而语言运行时堆则通过大块的分配来执行自己的内存管理。不使用操作系统堆,而使用虚拟内存函数更利于堆的分配和块的使用。

典型的堆实现由前、后端分配程序组成。前端分配程序维持固定大小块的空闲列表。对于一次分配调用,堆尝试从前端列表找到一个自由块。如果失败,堆被迫从后端(保留和提交虚拟内存)分配一个大块来满足请求。通用的实现有每块分配的开销,这将耗费执行周期,也减少了可使用的存储空间。

Knowledge Base 文章 Q10758,“用 calloc() 和 malloc() 管理内存” (搜索文章编号), 包含了有关这些主题的更多背景知识。另外,有关堆实现和设计的详细讨论也可在下列著作中找到:“Dynamic Storage Allocation: A Survey and Critical Review”,作者 Paul R. Wilson、Mark S. Johnstone、Michael Neely 和 David Boles;“International Workshop on Memory Management”, 作者 Kinross, Scotland, UK, 1995 年 9 月(http://www.cs.utexas.edu/users/oops/papers.html)(英文)。

Windows NT 的实现(Windows NT 版本 4.0 和更新版本) 使用了 127 个大小从 8 到 1,024 字节的 8 字节对齐块空闲列表和一个“大块”列表。“大块”列表(空闲列表[0]) 保存大于 1,024 字节的块。空闲列表容纳了用双向链表链接在一起的对象。默认情况下,“进程堆”执行收集操作。(收集是将相邻空闲块合并成一个大块的操作。)收集耗费了额外的周期,但减少了堆块的内部碎片。

单一全局锁保护堆,防止多线程式的使用。(请参见“Server Performance and Scalability Killers”中的第一个注意事项, George Reilly 所著,在 “MSDN Online Web Workshop”上(站点:http://msdn.microsoft.com/workshop/server/iis/tencom.asp(英文)。)单一全局锁本质上是用来保护堆数据结构,防止跨多线程的随机存取。若堆操作太频繁,单一全局锁会对性能有不利的影响。

什么是常见的堆性能问题?
以下是您使用堆时会遇到的最常见问题: 

分配操作造成的速度减慢。光分配就耗费很长时间。最可能导致运行速度减慢原因是空闲列表没有块,所以运行时分配程序代码会耗费周期寻找较大的空闲块,或从后端分配程序分配新块。


释放操作造成的速度减慢。释放操作耗费较多周期,主要是启用了收集操作。收集期间,每个释放操作“查找”它的相邻块,取出它们并构造成较大块,然后再把此较大块插入空闲列表。在查找期间,内存可能会随机碰到,从而导致高速缓存不能命中,性能降低。


堆竞争造成的速度减慢。当两个或多个线程同时访问数据,而且一个线程继续进行之前必须等待另一个线程完成时就发生竞争。竞争总是导致麻烦;这也是目前多处理器系统遇到的最大问题。当大量使用内存块的应用程序或 DLL 以多线程方式运行(或运行于多处理器系统上)时将导致速度减慢。单一锁定的使用—常用的解决方案—意味着使用堆的所有操作是序列化的。当等待锁定时序列化会引起线程切换上下文。可以想象交叉路口闪烁的红灯处走走停停导致的速度减慢。 
竞争通常会导致线程和进程的上下文切换。上下文切换的开销是很大的,但开销更大的是数据从处理器高速缓存中丢失,以及后来线程复活时的数据重建。

堆破坏造成的速度减慢。造成堆破坏的原因是应用程序对堆块的不正确使用。通常情形包括释放已释放的堆块或使用已释放的堆块,以及块的越界重写等明显问题。(破坏不在本文讨论范围之内。有关内存重写和泄漏等其他细节,请参见 Microsoft Visual C++(R) 调试文档 。)


频繁的分配和重分配造成的速度减慢。这是使用脚本语言时非常普遍的现象。如字符串被反复分配,随重分配增长和释放。不要这样做,如果可能,尽量分配大字符串和使用缓冲区。另一种方法就是尽量少用连接操作。
竞争是在分配和释放操作中导致速度减慢的问题。理想情况下,希望使用没有竞争和快速分配/释放的堆。可惜,现在还没有这样的通用堆,也许将来会有。

在所有的服务器系统中(如 IIS、MSProxy、DatabaseStacks、网络服务器、 Exchange 和其他), 堆锁定实在是个大瓶颈。处理器数越多,竞争就越会恶化。

尽量减少堆的使用
现在您明白使用堆时存在的问题了,难道您不想拥有能解决这些问题的超级魔棒吗?我可希望有。但没有魔法能使堆运行加快—因此不要期望在产品出货之前的最后一星期能够大为改观。如果提前规划堆策略,情况将会大大好转。调整使用堆的方法,减少对堆的操作是提高性能的良方。

如何减少使用堆操作?通过利用数据结构内的位置可减少堆操作的次数。请考虑下列实例:

struct ObjectA {
   // objectA 的数据 
}

struct ObjectB {
   // objectB 的数据 
}

// 同时使用 objectA 和 objectB

//
// 使用指针 
//
struct ObjectB {
   struct ObjectA * pObjA;
   // objectB 的数据 
}

//
// 使用嵌入
//
struct ObjectB {
   struct ObjectA pObjA;
   // objectB 的数据 
}

//
// 集合 – 在另一对象内使用 objectA 和 objectB
//

struct ObjectX {
   struct ObjectA  objA;
   struct ObjectB  objB;
}

避免使用指针关联两个数据结构。如果使用指针关联两个数据结构,前面实例中的对象 A 和 B 将被分别分配和释放。这会增加额外开销—我们要避免这种做法。


把带指针的子对象嵌入父对象。当对象中有指针时,则意味着对象中有动态元素(百分之八十)和没有引用的新位置。嵌入增加了位置从而减少了进一步分配/释放的需求。这将提高应用程序的性能。


合并小对象形成大对象(聚合)。聚合减少分配和释放的块的数量。如果有几个开发者,各自开发设计的不同部分,则最终会有许多小对象需要合并。集成的挑战就是要找到正确的聚合边界。


内联缓冲区能够满足百分之八十的需要(aka 80-20 规则)。个别情况下,需要内存缓冲区来保存字符串/二进制数据,但事先不知道总字节数。估计并内联一个大小能满足百分之八十需要的缓冲区。对剩余的百分之二十,可以分配一个新的缓冲区和指向这个缓冲区的指针。这样,就减少分配和释放调用并增加数据的位置空间,从根本上提高代码的性能。


在块中分配对象(块化)。块化是以组的方式一次分配多个对象的方法。如果对列表的项连续跟踪,例如对一个 {名称,值} 对的列表,有两种选择:选择一是为每一个“名称-值”对分配一个节点;选择二是分配一个能容纳(如五个)“名称-值”对的结构。例如,一般情况下,如果存储四对,就可减少节点的数量,如果需要额外的空间数量,则使用附加的链表指针。 
块化是友好的处理器高速缓存,特别是对于 L1-高速缓存,因为它提供了增加的位置 —不用说对于块分配,很多数据块会在同一个虚拟页中。

正确使用 _amblksiz。C 运行时 (CRT) 有它的自定义前端分配程序,该分配程序从后端(Win32 堆)分配大小为 _amblksiz 的块。将 _amblksiz 设置为较高的值能潜在地减少对后端的调用次数。这只对广泛使用 CRT 的程序适用。
使用上述技术将获得的好处会因对象类型、大小及工作量而有所不同。但总能在性能和可升缩性方面有所收获。另一方面,代码会有点特殊,但如果经过深思熟虑,代码还是很容易管理的。

其他提高性能的技术
下面是一些提高速度的技术: 

使用 Windows NT5 堆 
由于几个同事的努力和辛勤工作,1998 年初 Microsoft Windows(R) 2000 中有了几个重大改进:

改进了堆代码内的锁定。堆代码对每堆一个锁。全局锁保护堆数据结构,防止多线程式的使用。但不幸的是,在高通信量的情况下,堆仍受困于全局锁,导致高竞争和低性能。Windows 2000 中,锁内代码的临界区将竞争的可能性减到最小,从而提高了可伸缩性。


使用 “Lookaside”列表。堆数据结构对块的所有空闲项使用了大小在 8 到 1,024 字节(以 8-字节递增)的快速高速缓存。快速高速缓存最初保护在全局锁内。现在,使用 lookaside 列表来访问这些快速高速缓存空闲列表。这些列表不要求锁定,而是使用 64 位的互锁操作,因此提高了性能。


内部数据结构算法也得到改进。
这些改进避免了对分配高速缓存的需求,但不排除其他的优化。使用 Windows NT5 堆评估您的代码;它对小于 1,024 字节 (1 KB) 的块(来自前端分配程序的块)是最佳的。GlobalAlloc() 和 LocalAlloc() 建立在同一堆上,是存取每个进程堆的通用机制。如果希望获得高的局部性能,则使用 Heap(R) API 来存取每个进程堆,或为分配操作创建自己的堆。如果需要对大块操作,也可以直接使用 VirtualAlloc() / VirtualFree() 操作。

上述改进已在 Windows 2000 beta 2 和 Windows NT 4.0 SP4 中使用。改进后,堆锁的竞争率显著降低。这使所有 Win32 堆的直接用户受益。CRT 堆建立于 Win32 堆的顶部,但它使用自己的小块堆,因而不能从 Windows NT 改进中受益。(Visual C++ 版本 6.0 也有改进的堆分配程序。)

使用分配高速缓存 
分配高速缓存允许高速缓存分配的块,以便将来重用。这能够减少对进程堆(或全局堆)的分配/释放调用的次数,也允许最大限度的重用曾经分配的块。另外,分配高速缓存允许收集统计信息,以便较好地理解对象在较高层次上的使用。

典型地,自定义堆分配程序在进程堆的顶部实现。自定义堆分配程序与系统堆的行为很相似。主要的差别是它在进程堆的顶部为分配的对象提供高速缓存。高速缓存设计成一套固定大小(如 32 字节、64 字节、128 字节等)。这一个很好的策略,但这种自定义堆分配程序丢失与分配和释放的对象相关的“语义信息”。 

与自定义堆分配程序相反,“分配高速缓存”作为每类分配高速缓存来实现。除能够提供自定义堆分配程序的所有好处之外,它们还能够保留大量语义信息。每个分配高速缓存处理程序与一个目标二进制对象关联。它能够使用一套参数进行初始化,这些参数表示并发级别、对象大小和保持在空闲列表中的元素的数量等。分配高速缓存处理程序对象维持自己的私有空闲实体池(不超过指定的阀值)并使用私有保护锁。合在一起,分配高速缓存和私有锁减少了与主系统堆的通信量,因而提供了增加的并发、最大限度的重用和较高的可伸缩性。

需要使用清理程序来定期检查所有分配高速缓存处理程序的活动情况并回收未用的资源。如果发现没有活动,将释放分配对象的池,从而提高性能。

可以审核每个分配/释放活动。第一级信息包括对象、分配和释放调用的总数。通过查看它们的统计信息可以得出各个对象之间的语义关系。利用以上介绍的许多技术之一,这种关系可以用来减少内存分配。

分配高速缓存也起到了调试助手的作用,帮助您跟踪没有完全清除的对象数量。通过查看动态堆栈返回踪迹和除没有清除的对象之外的签名,甚至能够找到确切的失败的调用者。

MP 堆 
MP 堆是对多处理器友好的分布式分配的程序包,在 Win32 SDK(Windows NT 4.0 和更新版本)中可以得到。最初由 JVert 实现,此处堆抽象建立在 Win32 堆程序包的顶部。MP 堆创建多个 Win32 堆,并试图将分配调用分布到不同堆,以减少在所有单一锁上的竞争。

本程序包是好的步骤 —一种改进的 MP-友好的自定义堆分配程序。但是,它不提供语义信息和缺乏统计功能。通常将 MP 堆作为 SDK 库来使用。如果使用这个 SDK 创建可重用组件,您将大大受益。但是,如果在每个 DLL 中建立这个 SDK 库,将增加工作设置。

重新思考算法和数据结构 
要在多处理器机器上伸缩,则算法、实现、数据结构和硬件必须动态伸缩。请看最经常分配和释放的数据结构。试问,“我能用不同的数据结构完成此工作吗?”例如,如果在应用程序初始化时加载了只读项的列表,这个列表不必是线性链接的列表。如果是动态分配的数组就非常好。动态分配的数组将减少内存中的堆块和碎片,从而增强性能。

减少需要的小对象的数量减少堆分配程序的负载。例如,我们在服务器的关键处理路径上使用五个不同的对象,每个对象单独分配和释放。一起高速缓存这些对象,把堆调用从五个减少到一个,显著减少了堆的负载,特别当每秒钟处理 1,000 个以上的请求时。

如果大量使用“Automation”结构,请考虑从主线代码中删除“Automation BSTR”,或至少避免重复的 BSTR 操作。(BSTR 连接导致过多的重分配和分配/释放操作。)

摘要
对所有平台往往都存在堆实现,因此有巨大的开销。每个单独代码都有特定的要求,但设计能采用本文讨论的基本理论来减少堆之间的相互作用。 

评价您的代码中堆的使用。


改进您的代码,以使用较少的堆调用:分析关键路径和固定数据结构。


在实现自定义的包装程序之前使用量化堆调用成本的方法。


如果对性能不满意,请要求 OS 组改进堆。更多这类请求意味着对改进堆的更多关注。


要求 C 运行时组针对 OS 所提供的堆制作小巧的分配包装程序。随着 OS 堆的改进,C 运行时堆调用的成本将减小。


操作系统(Windows NT 家族)正在不断改进堆。请随时关注和利用这些改进。
Murali Krishnan 是 Internet Information Server (IIS) 组的首席软件设计工程师。从 1.0 版本开始他就设计 IIS,并成功发行了 1.0 版本到 4.0 版本。Murali 组织并领导 IIS 性能组三年 (1995-1998), 从一开始就影响 IIS 性能。他拥有威斯康星州 Madison 大学的 M.S.和印度 Anna 大学的 B.S.。工作之外,他喜欢阅读、打排球和家庭烹饪。



http://community.csdn.net/Expert/FAQ/FAQ_Index.asp?id=172835
我在学习对象的生存方式的时候见到一种是在堆栈(stack)之中,如下  
CObject  object;  
还有一种是在堆(heap)中  如下  
CObject*  pobject=new  CObject();  
 
请问  
(1)这两种方式有什么区别?  
(2)堆栈与堆有什么区别??  
 
 
---------------------------------------------------------------  
 
1)  about  stack,  system  will  allocate  memory  to  the  instance  of  object  automatically,  and  to  the
 heap,  you  must  allocate  memory  to  the  instance  of  object  with  new  or  malloc  manually.  
2)  when  function  ends,  system  will  automatically  free  the  memory  area  of  stack,  but  to  the 
heap,  you  must  free  the  memory  area  manually  with  free  or  delete,  else  it  will  result  in  memory
leak.  
3)栈内存分配运算内置于处理器的指令集中,效率很高,但是分配的内存容量有限。  
4)堆上分配的内存可以有我们自己决定,使用非常灵活。  
---------------------------------------------------------------  

posted @ 2009-04-10 09:11 不会飞的鸟 阅读(137) | 评论 (0)编辑 收藏

[交互设计工具/原型创作工具]Axure RP Pro 5.0新特性 破解版 注册码

先感谢木的{moond},要不是一次提供了那么多画原型图的工具,我现在还在Word和Visio里面打转呢。

这些软件能试用的我差不多都用了一下,其中觉得Axure的RP Pro 4挺好的,功能包括站点地图、流程设计、页面框架设计、简单交互设计等,可以生成HTML、Word等格式。

RP操作比用Dreamweaver简单多了,图片、文字、输入框等等所有组件全是可视化操作,可以很方便的实现网站交互内容的原型设计,可将以前死板的页面版式全部替换为有点击、链接效果的网页,nice~

同时可以为网站设计提供AJAX式的交互处理,RP提供一种动态层的组件,在同一页设定不同状态的效果,然后用链接、按钮等触发即可产生动态效果,这样网站设计就变得更加生动,意图也就更加直观。

可惜,这么好的软件只能试用30天,哪位兄台要是有解决方法一定要通知我,这里先谢了~

以下对RP5的新特性做了下简单翻译:

Axure RP Pro 5.0增加了众多新特性,并且着重增强了设计师间的协作、交互功能和更多的定制功能,生成也变的更快。

新功能包括:

1. 共享工程
1.1 可以在网络驱动器上创建共享工程,而不必非安装在服务器上
1.2 管理和便捷页面只需要通过简单的 check in / check out 即可
1.3 维护和浏览历史版本
1.4 更多介绍

2. 交互功能的增强
2.1 OnFocus 和 OnLostFocus 事件 (更多)
2.2 使用和禁止Widgets行为
2.3 模仿在图片上的锚点/热区行为 (更多)
2.4 移动动态层(Dynamic Panels)行为 (更多)
2.5 在其他行为运行之前暂停当前行为
2.6 页面间多达25个变量的储存

3. 规范的增强
3.1 可以更快的把演示生成为Microsoft Word 2007格式(使用Microsoft Office兼容包可与Microsoft Word 2000+兼容)
3.2 有1栏和2栏布局的选项
3.3 可以更简单的定制Word模板
3.4 有更多新选项去配置规范内容

4. 更多增强
4.1 优化Tab交互
4.2 可以选择与主窗体分离(比如Sitemap和Widgets)
4.3 有更好的保存机制来处理关闭和重开一个文件
4.4 带有梯度和透明设置的颜色工具
4.5 打印设置是被保存的

查看原文

同时提示一下:如果之前装过RP4,并且有license的话,RP5可以直接使用,
是作为免费升级的,当然,你也可以只当下来看看,有30天试用

=======================================================================

互联网行业产品经理的一项重要工作,就是进行产品原型设计(Prototype Design)。而产品原型设计最基础的工作,就是结合批注、大量的说明以及流程图画框架图wireframe,将自己的产品原型完整而准确的表述给UI、UE、程序工程师,市场人员,并通过沟通会议,反复修改prototype 直至最终确认,开始投入执行。

进行产品原型设计的软件工具也有很多种,我写的这个教程所介绍的Axure RP,是taobao、dangdang等国内大型网络公司的团队在推广使用的原型设计软件。同时,此软件也在产品经理圈子中广为流传。之所以Axure RP得到了大家的认同和推广,正是因为其简便的操作和使用,符合了产品经理、交互设计师们的需求。

在正式谈Axure RP之前,我们先来看看做产品原型设计,现在大致有哪些工具可以使用,而他们的利弊何在。
纸笔:简单易得,上手难度为零。有力于瞬间创意的产生与记录,有力于对文档即时的讨论与修改。但是保真度不高,难以表述页面流程,更难以表述交互信息与程序需求细节。
Word:上手难度普通。可以画wireframe,能够画页面流程,能够使用批注与文字说明。但是对交互表达不好,也不利于演示。
PPT:上手难度普通。易于画框架图,易于做批注,也可以表达交互流程,也擅长演示。但是不利于大篇幅的文档表达。
Visio:功能相对比较复杂。善于画流程图,框架图。不利于批注与大篇幅的文字说明。同样不利于交互的表达与演示。
Photshop/fireworks:操作难度相对较大,易于画框架图、流程图。不利于表达交互设计,不擅长文字说明与批注。
Dreamweave:操作难度大,需要基础的html知识。易于画框架图、流程图、表达交互设计。不擅长文字说明与批注。

以上这些工具,都是产品经理经常会使用到的,但是从根本上来说,这些工具都不是做prototype design的专门利器,需要根据产品开发不同的目的,不同的开发阶段,选择不同的工具搭配使用,才能达到表达、沟通的目的。

比如使用纸笔,更适合在产品创意阶段使用,可以快速记录闪电般的思路和灵感;也可以在即时讨论沟通时使用,通过图形快速表达自己的产品思路,及时的画出来,是再好不过的方法。而word则适合在用文字详细表达产品,对产品进行细节说明时使用,图片结合文字的排版,是word最擅长的工作。而ppt自然是演示时更好。visio则可以适用于各种流程图、关系图的表达,更可通过画use case 获取用户需求。PS/FW是图片处理的工具,DW则是所见即所得的网页开发软件,这些是设计师的看家本领,对于普通的产品经理来说,需要耗费太多的精力去掌握。

其实每件工具,每个软件,在创造它的初期,软件设计师们都给它赋予了性格、气质。因为每个工具的产生,都是为了满足人类的某一方面需求。比如锄头是锄土的,起子是起螺丝的,电熨斗是烫衣服的。但是不同的工具都有自己的工作领域,在其他领域它并不擅长。而以上的软件在创造的初期,并非为了帮助产品经理、ue完成产品原型设计,因此他们都不能在prototype design 这件工作上得心应手。而Axure RP正是在互联网产品大张其道的前提下,为满足prototype design创建的需求,应运而生。

Axure RP 能帮助网站需求设计者,快捷而简便的创建 基于目录组织的原型文档、功能说明、交互界面以及带注释的wireframe网页,并可自动生成用于演示的网页文件和word文档,以提供演示与开发。

没错!Axure RP 的特点是:

  • 快速创建带注释的wireframe文件,并可根据所设置的时间周期,软件自动保存文档,确保文件安全。
  • 在不写任何一条html与javascript语句的情况下,通过创建的文档以及相关条件和注释,一键生成html prototype演示。
  • 根据设计稿,一键生成一致而专业的word版本的原型设计文档。

说到这里相信很多人已经激起了兴趣,但是在开始学习之前,我认为我们还是有必要先了解一下软件短短的历史,创造这一软件的公司-Axure Software Solutions, Inc.该公司创建于2002年五月,Axure RP是这一软件公司的旗舰产品,2003年一月Axure RP第一版本上线发表,至今已经正式发行到了第四个版本,而我提笔写到这里的时候,Axure 5.0版本beta版本已经正式提供下载试用,虽然我已经下载使用,但是我想,写教程还是应该先从稳定的4.6版说起,至于5.0版,我们可以伴随着软件一起成长。

接下来我会结合图片,分几个步骤分享我对Axure的认识,
一、 界面与功能
二、 工具栏
三、 站点地图
四、 组件与使用方法
五、 复用模板与使用
六、 交互功能与注释
七、 实例

当然,在书写的过程中我会根据具体的情况再进行调整,尽量做到图文并茂,易于理解。写这个教程的目的,一方面为自己熟悉与更加理解Axure,另一方面也鞭策自己完善自己的blog网站www.2tan.net,同时也希望以自己的绵薄之力,为希望学习Axure的朋友分享一点经验。由于这是我第一次尝试写教程,难免会出现偏颇,也希望朋友们能够不吝赐教,共同进步。

另,为e文好的朋友附上自学Axure RP的几个途径:
1、 打开软件,按F1调取帮助文档,对照文档学习。
2、 登录http://www.axure.com/au-home.aspx 查看flash视频学习。
3、 登录 Axure 博客 http://axure.com/cs/blogs/Default.aspx,了解软件最新信息。
4、 登录讨论组http://axure.com/cs/forums/Default.aspx,参与讨论。

并提供Axure RP pro 4.6版本的下载
http://www.2tan.net/LoadMod.asp?plugins=downloadForPJBlog
由于放存软件的网络硬盘在下载数量不多的情况下可能会删除文件,如遇到死链接,可留言给我,我将重新上传:)
(软件仅供学习使用,反对商业用途 -_-!!!)


Name:3ddown
Serial:FiCGEezgdGoYILo8U/2MFyCWj0jZoJc/sziRRj2/ENvtEq+7w1RH97k5MWctqVHA

posted @ 2009-03-20 13:23 不会飞的鸟 阅读(757) | 评论 (1)编辑 收藏

PowerDesigner下建索引、自增列、检查设计模型

From: http://www.qqread.com/java/2006/07/u996183002.html

这段时间,使用PD做数据库模型,感觉很不错,将自已的经验总给一下.还有许多功能我没时间总结,以后有时间,继续补吧
  
. 如何在PowerDesigner下建索引
  
 1. 双击表设计图,出来Table Properties,在Tab 页中选择 Indexes
  
   数据库建模工具PowerDesigner总结(组图)



 2. 单击新建索引的属性,出现Indexex Properties
  
 数据库建模工具PowerDesigner总结(组图)



 3. 增加一个索引包含的字段
  
 数据库建模工具PowerDesigner总结(组图)



点击"下图中的增加列图标出现图如下"



选中相关字段后,点OK
最后返回属性页,点preview出现图如下



好了,索引建立成功

======================================

.如何在PowerDesigner 下建自增列
  
 1. 使用SqlServer 数据库中的下列语句来完成
  
  建表语句中,在要做为自增列的字段中,加上如下
  IDENTITY(1,1)
  
  还有可以使用下面语句,重置自增种子
  dbcc checkident(ConfigSys,reseed,0);
  
.如何在PowerDesigner 下检查设计模型
  
  1. 在菜单栏中选择 Tools -? Check Model, 如下图
  
 数据库建模工具PowerDesigner总结(组图)



  2. 选择要检查的每项设置
  
 数据库建模工具PowerDesigner总结(组图)



  3. 确定后,将出来检查结果汇总信息
  
 数据库建模工具PowerDesigner总结(组图)

posted @ 2009-03-18 09:03 不会飞的鸟 阅读(2034) | 评论 (0)编辑 收藏

c语言中rand()函数怎么用?

rand(产生随机数)
相关函数
srand

表头文件
#include<stdlib.h>

定义函数
int rand(void)

函数说明
rand()会返回一随机数值,范围在0至RAND_MAX 间。在调用此函数产生随机数前,必须先利用srand()设好随机数种子,如果未设随机数种子,rand()在调用时会自动设随机数种子为1。关于随机数种子请参考srand()。

返回值
返回0至RAND_MAX之间的随机数值,RAND_MAX定义在stdlib.h,其值为2147483647。

范例
/* 产生介于1 到10 间的随机数值,此范例未设随机数种子,完整的随机数产生请参考
srand()*/
#include<stdlib.h>
main()
{
int i,j;
for(i=0;i<10;i++)
{
j=1+(int)(10.0*rand()/(RAND_MAX+1.0));
printf("%d ",j);
}
}

执行
9 4 8 8 10 2 4 8 3 6
9 4 8 8 10 2 4 8 3 6





srand(设置随机数种子)
相关函数
rand

表头文件
#include<stdlib.h>

定义函数
void srand (unsigned int seed);

函数说明
srand()用来设置rand()产生随机数时的随机数种子。参数seed必须是个整数,通常可以利用geypid()或time(0)的返回值来当做seed。如果每次seed都设相同值,rand()所产生的随机数值每次就会一样。

返回值

范例
/* 产生介于1 到10 间的随机数值,此范例与执行结果可与rand()参照*/
#include<time.h>
#include<stdlib.h>
main()
{
int i,j;
srand((int)time(0));
for(i=0;i<10;i++)
{
j=1+(int)(10.0*rand()/(RAND_MAX+1.0));
printf(" %d ",j);
}
}

执行
5 8 8 8 10 2 10 8 9 9
2 9 7 4 10 3 2 10 8 7

posted @ 2009-03-11 11:04 不会飞的鸟 阅读(6796) | 评论 (0)编辑 收藏

如何使用 类进行文件的 I/O 处理

原文出处:How to Use <fstream> Classes for File I/O
摘要:传统的文件 I/O 库如 Unix 的 <io.h> 和 <stdio.h> ,由于其程序接口的原因,在很大程度上强制程序员进行某些处理,缺乏类型安全和国际化支持。C++ 的 <fstream> 库则在文件的 I/O 方面提供了一个增强的、面向对象的、具有国际化意识的库。本文将介绍如何使用这个库进行文件的 I/O 处理并利用它来编写易于跨平台的代码。


  大多数 C++ 程序员都熟悉不止一个文件 I/O 库。首先是传统的 Unix 风格的库,它由一些低级函数如 read() 和 open()组成。其次是 ANSI C 的 <stdio.h> 库,它包含 fopen() 和 fread()等函数。其它的还有一些具备所有权的库或框架,比如 MFC,它有很多自己的文件处理类。
  这些库一般都很难跨平台使用。更糟的是,上述提到的 C 库由于其程序接口的原因,在很大程度上强制程序员进行某些处理,而且缺乏类型安全支持。
  标准 C++ 提供提供了一个增强的、面向对象的、具有国际化意识的  <fstream> 库。这个库包含一系列派生于标准 ios_base 和 ios 类的类模板。因此, <fstream> 提供了高级的自动控制机制和健壮性。本文下面将示范如何使用  <fstream> 类实现文件的输入/输出处理:

第一步:创建文件流
  输入文件流(ifstream)支持重载的 >> 操作符,同样,输出文件流(ofstream)支持重载的 << 操作符。结合了输入和输出的文件流被称为 fstream。下面的程序创建了一个 ifstream 对象:dict,并将该对象中的每一个单字显示到屏幕上:

#include <iostream>
#include <string>
#include <fstream>
#include <cstdlib>
using namespace std;
int main()
{
string s;
cout<<"enter dictionary file: ";
cin>>s;
ifstream dict (s.c_str());
if (!dictionary) // were there any errors on opening?
exit(-1);
while (dictionary >> s) cout << s <<''\n'';
}      
  我们必须调用 string::c_str() 成员函数,因为 fstream 对象只接受常量字符串作为文件名。当你将文件名作为参数传递时,构造函数试图打开指定的文件。接着,我们用重载的 !操作符来检查文件的状态。如果出错,该操作符估值为 true。最后一行是个循环,每次反复都从文件读取一个单字,将它拷贝到 s,然后显示出来。注意我们不必显式地检查 EOF,因为重载操作符 >> 会自动处理。此外,我们不用显式地关闭此文件,因为析构函数会为我们做这件事情。
  过时和荒废的 <fstream.h> 库支持 ios::nocreate 和 ios::noreplace 标志。但新的 <fstream> 库已经取代了 <fstream.h> 并不再支持这两个标志。
 
文件的打开模式
  如果你不显式指定打开模式,fstream 类将使用默认值。例如,ifstream 默认以读方式打开某个文件并将文件指针置为文件的开始处。为了向某个文件写入数据,你需要创建一个 ofstream 对象。<fstream> 定义了下列打开模式和文件属性:
ios::app // 从后面添加
ios::ate // 打开并找到文件尾
ios::binary // 二进制模式 I/O (与文本模式相对)
ios::in // 只读打开
ios::out // 写打开
ios::trunc // 将文件截为 0 长度

你可以用位域操作符 OR 组合这些标志:

ofstream logfile("login.dat", ios::binary | ios::app);

fstream 类型对象同时支持读和写操作:

fstream logfile("database.dat", ios::in | ios::out);

第二步:设置文件的位置
  文件具备一个逻辑指针,它指向该文件中的某个偏移位置。你可以通过调用seekp()成员函数,以字节为单位将这个指针定位到文件的任意位置。为了获取从文件开始处到当前偏移的字节数,调用seekp()即可。在下面的例子中,程序将文件位置前移10个字节,然后调用 tellp()报告新位置:

ofstream fout("parts.txt");
fout.seekp(10); // 从0偏移开始前进 10 个字节
cout<<"new position: "<<fout.tellp(); // 显示 10

你可以用下面的常量重新定位文ian指针:

ios::beg // 文件开始位置
ios::cur // 当前位置,例如: ios::cur+5
ios::end // 文件尾

第三步:读写数据
  fstream 类为所有内建数据类型以及 std::string 和 std::complex 类型重载 << 和 >> 操作符。下面的例子示范了这些操作符的使用方法:

fstream logfile("log.dat");
logfile<<time(0)<<"danny"<<''\n''; // 写一条新记录
logfile.seekp(ios::beg); // 位置重置
logfile>>login>>user; // 读取以前写入的值

posted @ 2009-03-05 11:52 不会飞的鸟 阅读(188) | 评论 (0)编辑 收藏

仅列出标题
共9页: 1 2 3 4 5 6 7 8 9