从网络上简单收集整理,大概有下面几点(欢迎大佬补充):
1.循环结构(状态保持)
图形界面本质上是“循环”,保证其运行而不退出的状态。区别就在于“循环结构”。用户无操作时:GUI程序会被阻塞,将线程资源让给其它程序,资源开销较小;游戏引擎开发的游戏,即便用户不操作,也会有待机动画等,需要一直暂用CPU,资源开销较大。
2.CPU与GPU的使用
GUI程序主要用CPU渲染画面;游戏引擎多用GPU渲染画面。显然GPU的渲染效率更高。
3.游戏引擎有更多预设功能
游戏引擎包含GUI,此外还包含:物理系统(碰撞检测),音频处理,画面渲染,寻路算法,动画时间轴,资源管理,打包发布,网络联机等,能提高游戏开发效率。而GUI(Qt)程序一般用不到"物理碰撞"吧~
4.本质上没有区别
无论Qt还是Unity还是Godot,游戏引擎还是GUI,底层都是一堆C语言代码(打个比方),编译以后都是一条条汇编指令。他们的区别无非就是“对C语言代码的封装方式、组合方式不同”(瞎说的)。
个人记录本
1.游戏引擎主要关注实时渲染,所以离线渲染可能要求不是那么高,当然如果你光追学得很牛逼,实时光追很了解得话还是有用的。至于数字几何处理、计算几何这些,感觉算是一些前置基础知识,不用太过系统和详细地去学,用到的时候再学可能效率会更高。
下面附上参考资料:
作者:小白龙龙
链接:https://www.zhihu.com/question/32021953/answer/1815005800
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
说点底层的区别吧。
从CPU的角度看,程序就是一串有逻辑顺序的指令序列,整体上是从头到尾按顺序执行的。执行到尾部,程序也就结束了。
无论是常规的图形界面程序,还是电子游戏,都应当保证其运行而不退出的状态,除非用户明确下达退出指令。这与传统的命令行式程序是两种完全不同的工作方式。
而实现不退出的运行状态也很简单,就是在程序完成前期准备工作后进入一个循环指令结构,此时CPU就无法执行到程序的尾部。
常规的图形界面程序和电子游戏的底层区别,就在于这个循环指令结构。
对于常规的图形界面程序来说,图形界面的动态元素较少,用户随机输入的频率较低,大部分时间只需要在用户输入事件到达后进行一次渲染然后持续输出即可。因此,如果没有用户输入事件或系统事件,图形界面程序会主动阻塞线程,释放时间片,让出执行权给其他需要的线程,系统整体上处于较低的工作压力。
大多数的电子游戏的动态元素较多,用户随机输入的频率较高,即使用户不操作,游戏里的角色、物体通常也需要产生“不操作时”的动画,因此电子游戏需要持续的更新状态和渲染输出。相比于常规的图形界面程序,电子游戏不会因为没有用户输入事件而阻塞线程,需要尽可能的占用CPU时间片以更新游戏状态,系统整体上处于较高的工作压力。
作者:匿名用户
链接:https://www.zhihu.com/question/32021953/answer/1817439176
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
GUI一开始绘制的内容相对简单,主要使用CPU计算,因为早期的显卡没有这么稳定,功能也不强大,不如CPU可靠,界面也就显得简单了,这也让早期程序也节省资源,但是CPU单核性能进步慢,卡的程序放到好的电脑上也不会变得流畅多少
游戏引擎主要是围绕GPU渲染设计的,目的是更绚丽的画面效果,更自然的光影等,这些需要大量的计算,但是对于GPU来说效率非常高
所以随着富界面越来越多,CPU渲染起动画和复杂图形来力不从心,更别提什么3D了,而且各个系统的GUI机制越来越复杂,所以现在的趋势就是利用图形api跨平台去做高性能渲染,不过现在各种新的api也不断提出,利用GPU去绘制的GUI机制,能更好的发挥整个电脑或者手机的性能,减少瓶颈,只要代码不去卡UI,越好的电脑就可以越流畅
游戏引擎内置的GUI目前还不足以应对普通的GUI程序去方便快速的开发,不过这也是一个需要完善的趋势
而GUI也在加强高速的渲染,可以嵌入更多的图形动画,但是GUI内的3d内再嵌入GUI呢? 其实也都基本没做,所以他们的互嵌入是不一样的
目前用游戏引擎做GUI占用资源会比较大,开发也会比较困难,开发速度慢,现成控件少,但这些都是可以解决的非底层机制问题,只能等待有一天真的做起来了
GUI主要是事件驱动的,而游戏引擎是帧驱动的,使得他们初始思维不太一样,不过其实也不是本质区别,都是可以封装的
作者:人类的大敌
链接:https://www.zhihu.com/question/32021953/answer/1824270696
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
竟然是6年前的问题啊,既然被顶上来了,那我也来吐槽一下:
gui可以作为游戏引擎的一部分,游戏引擎可能包含gui,但gui不会包含游戏引擎。
虽然不知道6年前游戏引擎是否流行,我还是以现在游戏引擎的发展情况来描述。
游戏引擎在拥有gui系统的情况下,还具有:物理系统(碰撞检测),音频处理,画面渲染,寻路算法,动画时间轴,资源管理,打包发布,网络联机……等多项功能。
如果只是用gui系统做个界面应用,根本不需要用到这么多功能。
举个例子:我就想开发个文件批量重命名工具,用游戏引擎来做,结果把物理系统给打包进去了,这就会导致不必要的冗余。你说一个简单的文件重命名工具要物理系统干嘛?
所以如果在注重程序优化的情况下,一般不用游戏引擎开发界面应用,本来把gui单独拉出来,追求的就是一个轻量级。
竟然是6年前的问题啊,既然被顶上来了,那我也来吐槽一下:
gui可以作为游戏引擎的一部分,游戏引擎可能包含gui,但gui不会包含游戏引擎。
虽然不知道6年前游戏引擎是否流行,我还是以现在游戏引擎的发展情况来描述。
游戏引擎在拥有gui系统的情况下,还具有:物理系统(碰撞检测),音频处理,画面渲染,寻路算法,动画时间轴,资源管理,打包发布,网络联机……等多项功能。
如果只是用gui系统做个界面应用,根本不需要用到这么多功能。
举个例子:我就想开发个文件批量重命名工具,用游戏引擎来做,结果把物理系统给打包进去了,这就会导致不必要的冗余。你说一个简单的文件重命名工具要物理系统干嘛?
所以如果在注重程序优化的情况下,一般不用游戏引擎开发界面应用,本来把gui单独拉出来,追求的就是一个轻量级。