游戏开发论坛

 找回密码
 立即注册
搜索
楼主: xjyhust

自己写游戏引擎——Get your hands dirty!!! (01)

[复制链接]

14

主题

131

帖子

136

积分

注册会员

Rank: 2

积分
136
发表于 2006-8-8 11:17:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

你统一opengl和directx接口看似很好,但实际上有很多问题,比如你的DWORD    GetFVF() 函数返回的是DWORD类型,而这类型只在win32上定义,如果有人在linux系统下开发,没有相应的头文件这个类型将无法识别,当然,这个问题有很多解决办法,但我只是想说这样的接口不太好,还有一个问题,就是matrix类的问题,如果你为一个数学类比如matrix定义一个抽象接口,使得能将dx和opengl的自带矩阵函数统一封装起来,那么效率是个问题,我们都知道虚函数有相应的效率损失,如果把频繁使用的数学库封装成抽象类,并提供纯虚的函数接口对效率来说是不太现实的,你对这个问题是怎么解决的,想听听你的意见。

22

主题

191

帖子

217

积分

中级会员

Rank: 3Rank: 3

积分
217
QQ
 楼主| 发表于 2006-8-8 14:34:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

恩,这个问题考虑了很久的,关于公共的接口。现在没有考虑跨平台的库,ok.DWORD的问题就暂时不管了。数学类会完全不用抽象的,在引擎的内核里面会有简单,基本的几个数学类,这个方面效率不会比dx或者gl的效率差太多(数学我基本上是抄的ogre的,自己写水平还不到家),尽量用汇编级别的优化。其他的接口,小函数会尽量做成内联的,关于渲染,若不是管理的接口,能够在公共部分实现的,就在公共部分实现,这个时候的效率损失也是难以避免的(但是可以忽略,同渲染的流水线效率相比),其他的有多渲染器的引擎好像也都是这样解决的,我也在想改进的办法。

6

主题

390

帖子

400

积分

中级会员

Rank: 3Rank: 3

积分
400
发表于 2006-8-8 16:55:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

挺好的,lz坚持写完哪

36

主题

1047

帖子

1147

积分

金牌会员

Rank: 6Rank: 6

积分
1147
发表于 2006-8-8 17:43:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

首先 OGRE 的数学库效率并不高,和 d3dx 比起来,自己是几乎写不出来跟它一样的效率的数学库的,这个可以自己测试一下便知,实际上我怀疑 OGRE 的性能不高跟这个是有很大关系的。
如果你不用 cpu 扩展指令集来优化数学库,自己写的 asm 优化代码还不如编译器写得好,但如果你使用了 扩展指令集,就要对不同 cpu 进行分支判断,这种性能开销也不小,目前做得最好的就是 D3DX 数学库,我相信不会有人能做出性能又高,又能做到动态决定使用目标 cpu 指令集的数学库来,大家可以看看 Release 下编译出来的 D3DX 代码。
对于这个问题,我的做法是是封装函数库,但不用 c++ 虚拟机制,这样就不会存在虚函数的调用开销,而是把函数库封装在 static lib 里,封装的类内部调用的是 d3dx 或者是 opengl 的数学函数,并且强制内联。不过这样在不同平台上使用要重新编译,不能做到运行时切换。不过虽然这样,经过测试发现还是有一些效率的损失。

14

主题

131

帖子

136

积分

注册会员

Rank: 2

积分
136
发表于 2006-8-8 19:59:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

这里存在很大的矛盾,如果要统一接口就必须使用虚函数,而要保证效率就不能使用虚函数,所以我认为在整个引擎接口设计上需要改进,我认为没必要使用统一接口,而是分别提供UHEDirectXEnvioronments大环境和UHEOpenglEnvioronments大环境来分别封装DX(包括D3DX)和OpenGL,因为使用抽象类接口最大的目的就是两个目的:1.方便以后进一步添加相应的功能,进行扩展。2.提供用户统一界面。先讨论第一个目的,这个目的放在这个问题就需要考虑一下了,因为这么多年了,全世界真正被应用的图形库只有两套:DX和OPENGL,并且将来可能很长时间内都是这两套API,所以这就失去了第一个目的 地意义了;再看第二个问题,其实在两个大环境中可以使用统一的界面这个不是问题,并且这样可以解决虚函数效率问题以及大量的downcasting转换问题,并且将来也只可能使用这两套图形库,所以不管你将来怎样扩展你的引擎并不会使接口变得很臃肿,也不用太多的代码重写,但可以带来很多好处。
大家一起来探讨一下。

22

主题

191

帖子

217

积分

中级会员

Rank: 3Rank: 3

积分
217
QQ
 楼主| 发表于 2006-8-9 01:39:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

恩,同意congy和jiangwei的观点,我也是这样想的。
关于虚函数的效率而言,是有一定的损失(不过经常的被夸大),但是经别人测试过发现这种损失也是可以接受的,特别是在游戏引擎中,时间几乎都是花在了渲染上,应该把优化的功夫尽量花在这个上面。
另外,c++中的虚函数效率似乎也有待改进(好像新标准正在研究这个问题),有人测试过,几十级的虚函数运行时解析起来速度竟然比java还要慢(当然是代码水平上的速度,忽略java虚拟层),希望新标准出来以后这一点会得到改善(c++CLI),的确,虚函数和纯虚类是设计的利器。

36

主题

1047

帖子

1147

积分

金牌会员

Rank: 6Rank: 6

积分
1147
发表于 2006-8-9 16:35:00 | 显示全部楼层

Re: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

jiangwei: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

这里存在很大的矛盾,如果要统一接口就必须使用虚函数,而要保证效率就不能使用虚函数,所以我认为在整个引...

能说说你的这种方案的具体实现吗?我没看懂。不统一接口,你的引擎内部与 Renderer 的交互怎么办?除非你说的“大环境”是两套引擎。

36

主题

1047

帖子

1147

积分

金牌会员

Rank: 6Rank: 6

积分
1147
发表于 2006-8-9 16:45:00 | 显示全部楼层

Re: 自己写游戏引擎——Get your hands dirty!!! (01)

其实 Renderer 的抽象已经是图形引擎的工业标准了,现在主流的的商业引擎都是这种方式来实现跨 Graphic 平台的。不过我也见过为不同的 3D API 写两套引擎实现的,比如 Renderware,是我目前接触到的商业引擎中效率最高的。
像 xjyhust 说的,使用 c++ 虚拟机制,在效率上也不会有太大的开销。我觉得对性能的影响还是要看引擎的整体架构设计,是否最小化渲染状态切换,是否合理的组织场景等等,是否最优的资源管理等等,这应该是引擎设计中一开始就要考虑的问题。

36

主题

1047

帖子

1147

积分

金牌会员

Rank: 6Rank: 6

积分
1147
发表于 2006-8-9 16:53:00 | 显示全部楼层

Re: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

jiangwei: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

你统一opengl和directx接口看似很好,但实际上有很多问题,比如你的DWORD    GetFVF() 函数返回的是DWORD类...

对于这个问题,我习惯于定义自己的类型,我会把所有 c++ 基本类型和 windows \ linux 类型都 typedef 成自己的名字,然后创建一个 PlatformConfige.h 来配置, 这样在不同的平台下有不同的定义实现,引擎内部使用自己的类型定义,在不同平台上发布时只要改变一下配置再编译就可以了。

14

主题

131

帖子

136

积分

注册会员

Rank: 2

积分
136
发表于 2006-8-9 18:06:00 | 显示全部楼层

Re: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

congy: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

其实 Renderer 的抽象已经是图形引擎的工业标准了,现在主流的的商业引擎都是这种方式来实现跨 Graphic 平台...

很好,但你的数学库比如matrix,vector怎么统一,难道不考虑效率而依然使用虚函数吗。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2026-1-25 12:43

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表