逍遥剑客

UE4如果需要在真机上测试, 通常编译+打包+安装需要很长的时间.所以UE4提供了Cook On The Fly的功能, 就是默认只编译, 资源的Cook在运行时由FileHostServer进行Cook, 这样就不用每次测试经历痛苦的打包过程.对于Android平台来说, 只需要安装apk, 资源文件(默认在obb里)仍然保存在PC机上, 通过网络进行访问.PC机做为FileHostServer, 对于请求的文件进行Cook , 如果没有请求的则不会进行Cook.但是对于公司的网络策略来说, 手机

如果是从源代码编译出来的UE4, 明明代码完全一样, 不同机器编译出来的dll却无法兼容, 这对于多分支开发非常不方便.在老版本里有个通过版本号判断的逻辑, 新版本改没了. 分析UE4源码后发现目前是通过BulidId来判断dll跟引擎是不是兼容的. 那BuildId是哪里来的呢?其实像发布的UE4版本是通过"-Formal"参数来生成固定的BuildId的, 不过我们也可以直接修改Engine/Build/Build.version来生成固定的BuildId:改完后如果代码一样, 不同机器

Jobs子系统是Nov2009这版本新加入的. 最初的背景可能是官方在把引擎移植到PS3上时, 为了充分利用SPU而做的优化. 参考KILLZONE2, SPU上可以计算的部分有:·         动画 ·         危险预测 AI ·         弹道回避 AI ·         障碍物规避 AI ·         冲撞判定 ·         物理演算

下载 Native Client SDKhttps://developers.google.com/native-client/sdk/download需要设置两个环境变量, Python2.7.3的安装路径加到PATH里, NACL_SDK_ROOT设置为对应版本目录CHROME_PATH这个是后面VS调试用的, 如果不用VS开发, 可以不设置C++ 教程https://developers.g

在《传统3D游戏引擎的Web化》中, 当时我还说emscripten不够成熟, 可是短短几个月它就有了很大的进步, 可用性甚至超过了flascc!在GDC2013上, Unreal发布了基于emscripten的移植Demo, 据说只用了4天时间, 足以看出这个移植过程的平滑floh前几天发布了一个PPT: 《C++ on the Web: Run your big 3D game in the

NaCl的3D渲染API使用的GLES2.0, 这也很好理解, 因为这已经是公认的跨平台标准了. 手机, 平板, 网页, PC都可以使用.就算在Windows上, 也有一些基于DX9的GLES2.0实现, 比如ANGLE. 有时候我真在想, 像M$这种升级个操作系统版本号就淘汰一种API的做法, 还不如全都使用标准库, 这样也节省了跨平台移植的成本~所以什么DX10/DX11, 还是省省吧其实从D

物理引擎的抉择前面说了, 这一系列是针对c++&3D的, 所以排除Box2D之类的2D引擎.3D版的, 目前最流行的有3个:Havok: 说它是最NB的毫不为过. 但是要钱, 不给钱人家才不鸟你呢. 免费版本只有Win32, 所以排除PhysX: 目前占有率最高, 跟游戏开发商合作比较好. NaCl版本没看到有, 所以排除Bullet: 开源. 想跨平台, 还是开源的东西比较靠谱, 一切尽在掌握.

大体浏览过emscripten的那一堆demo后, 心想试试移植个游戏试试, 顺便体验下这项技术的实用程度首先尝试了Onescripter, 因为手头上有可以编译运行的FateStayNight. 在工程配置中增加新的Platform: Emscripten, 并选择编译成可以执行的html编译提示缺少bzlib.h, 增加libbz2工程(开源), 注意这个就需要编译.bc库了(相当于.lib)

最近在做动画系统的一些重构工作, 顺便就看了下成熟的引擎的动画部分. 之前做过一个动作游戏的预研, 所以对这部分感触比较大, 因为相比业界一流的厂商, 动画技术可以说是国内游戏开发最落后的的一部分了在我看来, 动画系统分成这么几个级别吧:可以把DCC中制作的动作导入播放, 有Play/Stop/Pause之类的接口. 开源或者自研的引擎多停留在这一阶段在多个动画之间可以定义混合转换方式, 可以很好

最近看了OGRE2.0的一个PPT, 触动挺大的其实OGRE一直以来所为人诟病的性能问题, 何偿不也是我们引擎存在的问题虽然很多时候我们都拿OGRE和GameBryo的效率当反面教材, 但是自己也没有做到极致相对于GPU的性能优化来说, CPU的性能优化难得多就好比游戏开发的书籍, 讲API/渲染的多, 讲架构&逻辑的少可能很多人以为, 做引擎开发就是做图形开发, 对于国内的游戏来说好像没错但是如

Gamasutra上有篇文章讲得挺细的: Sponsored Feature: Behind the Mirror - Adding Reflection to C++RTTI在Class声明后加入RTTI宏的做法几乎快成各种引擎的标配了, 谁叫C++的rtti太弱来着.之前只是认为自己实现RTTI的原因是dynamic_cast的效率不高和对象工厂的需要, 原来关掉这个编译选项还可以减少占用的内

一些限制相对于Win32来说, NaCl相当于另一个平台, 一些操作系统相关的API需要移植. 除此之外, 参考Technical Overview, 还有一些其它的限制:不支持硬件异常不支持创建进程不支持传统的TCP/UDP sockets (有其它方式去实现, RakNet已经有个预览版本)不支持查询可用内存内联汇编必须兼容 Native Client 验证器(使用SDK中的 ncval 工具

最近floh大神的blog又复活了, 现在n3的主要发展发向是web化其实也是跟PC和主机平台的衰落有关, 各种移动设备正在逐渐取代PC的地位而做为一个3D游戏引擎, 想要适应这个潮流却不是很容易先不考虑其它, 光技术上面临的问题就很棘手:C++目前无法直接用于web开发, 必然要面临老代码转换/移植的问题3D硬件加速的渲染在浏览器这边, 没有一个统一的标准多线程, web浏览器里对于线程的使用有

https://developer.valvesoftware.com/wiki/Particle_System_Overview文件格式PCF编辑器Particle EditorMemory Fields这里其实也是组件模式的一种应用, 否则内存和CPU的开销会很大Control Points每个粒子系统最大有64个控制点, 0号默认为粒子的原点每个控制点可以设置位置, 朝向, 实体TF中医生的

<br />N3架构上是分了三层的, foundation, render, application.<br />一直以来看的都是foundation和render, 上层的一直没怎么看<br />今天大体上浏览了下, 感觉东西还是满多的<br />很多引擎都没这一层的, 如果没有实际项目的积累, 也没法抽象出复用的部分来<br />这里说的Entity不是GraphicsEntity, 而是Game::Entity, 代表游戏中的一个对象, 比如人, 道具什么的<br />一个Entity由以下几部分组成

N3停止更新之后, 这个是目前我觉得质量最高的代码http://heliumproject.org/代码在GitHub上: https://github.com/HeliumProject默认是没有sln文件的, 需要用premake4生成:打开Visual Studio 2008 Command Prompt转到HeliumProject目录如果不想编译, 可以把premake4.lua里的Helium.BuildXXX那一大段都注释掉如果没有装Python和FBX SDK, 可以把Helium.Chec

目前我了解到使用Mono做脚本的只有Unity和SecondLife, SpringEngine也有个扩展实现.当然, 最成熟的还是Unity于是下载了一个看看它的脚本是怎么应用的它的编辑器界面很简洁, 实际操作了一下才发现所有的功能其本上都是由inspector面板完成所有的GameObject都是由Component所组成, 如Mesh/Physics/Audio/Script等等脚本都是从M

个人对脚本语言认识不深, 尤其是动态语言...但是问了好多人为什么逻辑用脚本写, 答案都是不用编译这也只能怪DT的C++当初没设计好由于WOW的成功, 让lua几乎成了游戏脚本的标准原来的python/ruby/tcl啥的一下子就没落了, 都怪暴雪啊~虽然lua做为一个脚本语言来说, 非常的完美但是我对它不是很感冒, 可能习惯了C系语言的语法了对于C/C++/C#/Java/JS/AS类的我才看着

编译冒似不编译没有.lib可以用从官方上下载稳定版本的代码, 不要去GitHub直接拉默认的工程有几个路径和宏之类的不对, 小改一下就可以如果缺文件, 可以到GitHub的历史版本里去找编译好了就一个lib, 一个dll, pdb看需要环境配置C++这边肯定要链接mono.lib, 所以dll要拷贝到exe的目录除了mono本身外, 还需要.net的runtime assembly, 最精简的情况

序列化这个比较简单, .net直接就支持, 以XML序列化为例: public static string SerializeToString (object obj) { XmlSerializer serializer = new XmlSerializer (obj.GetType ()); using (StringWriter writer = new StringWrit

以前用过lua, 调试时很痛苦. 当然现在已经有比较成熟的调试器了, 比如decoda在没有调试器之前都是怎么调试的呢?printf打印到控制台之类的输出窗口. 如果做了热更新的话可以边改边看输入命令, 让控制台显示结果. 对于C++来说控制台是个很不爽的东西, 因为每个指令都要写个解析函数. 而脚本则可以直接把脚本语句当指令敲进去, 比如CsharpRepl当然, 最理想的情况还是能够下断点,

在实际使用脚本之前, 根本不知道为什么要用脚本, 直到我膝盖中了一箭在之前我也问过很多人, C++写逻辑什么的也行啊, 为什么要引入另一种语言呢? 听得最多的理由是:不用编译的确,  C++的编译速度很浪费时间, 但也不是不能接受. 不过, 用过其他语言之后, 再想想, 持这种观点的人都是习惯了慢罢了当然, 还有很多其它原因, 可以参见miloyip的两篇文章: 混合语言的游戏开发系统架构, C+

这两年接触了一些比较成熟的商业引擎, 慢慢得思想有所转变以前总以为, 哪个引擎代码写得好看就牛, 太偏激了很多商业引擎的代码那叫一个乱~后来觉得引擎工具很重要, 没有经过成功项目的引擎不是好引擎现在呢? 当然工具还是很重要, 但另一个很重要的因素是: 制作效率能不能快速开发, 能不能快速搭建原型, 快速推出, 灵活定制才是一个引擎最有竞争力的地方这扯得有点虚了, 来点实际的在学习并抄袭够了各种技术

有用N3 + CLR做界面的冲动 新建一个CLR WinForm工程, 直接引入N3的头文件和库进行编译........ 编译不过, 找了半天才发现原因晕死, .Net和N3都有个System命名空间, 没法改Microsoft的东西, 只好把N3的System改成了NSystem 然后就是链接不过 一是__fastcall不被CLR支持, 改成__cdecl

参数编辑可以说, 引擎工具在除了一些特定操作外, 80%的事情都是在进行参数的编辑与保存等. 从我接触工具开发开始, 就一直在学习如何简化这么部分的工作. 因为我见过很多业余的编辑器, 大多都是每加一个参数就在UI层写一些代码, 在IO层加一些版本兼容代码等. 而这些代码常常都是大同小异的, 很多都是Ctrl+C, Ctrl+V出来的. 说起来, 这个探索过程中我也走了不少的弯路, 顺便写出来当教

C++/CLI只能使用MD/MDd的运行库, 所以N3的编译选项需要改一下. 可以在makeslnwin32.tcl里改, 然后重新生成所有的工程文件.N3的System命名空间与.Net的冲突. 主要是byteorder.h这个头文件里的Math命名空间, 改成"::Math"或"using namespace Math"都可以.编译时有些代码(估计是内联部分)会提示无法编译成托管代码, 只需要把#include用#pragma unmanaged/#pragma managed包起来XNAMath的对齐

函数声明UE4中有两种函数, 一种是传统的C++函数, 一种是UFunction. UFunction通过加入一些描述符来支持一些特殊功能UFUNCTION([specifier, specifier, ...], [meta(key=value, key=value, ...)])ReturnType FunctionName([Parameter, Parameter, ...])主要有几

Wiimote最早在玩Wii的模拟器游戏时候, 就发现其中有关于Wiimote的一些设置, 了解到其实Wii的控制器可以连接到PC上使用. 去年做了Kinect的体感游戏后, 也想了解下Wii的, 所以就淘宝买了Wiimote Plus. 完整的Wiimote有三部分: - Wii手柄(这个集成了motion plus) - Nunchunk(外号”鸡腿”) - IR感应条 跟PC

最近在UE4中实现了程序实时生成的Mesh顶点动画， 由于使用的顶点数目很多（几十万量级）一开始是创建Dynamic Vertex Buffer， 然后每帧去更新顶点数据，发现效率比较低效率的瓶颈在顶点坐标的计算上， 毕竟数量有点多于是改成了基于Vertex Texture(Material中的World Position Offset)的实现，那VB就不用更新了， 只需要每帧更新Texture这

上篇已经能在VR中画出来了, 但是还存在两个问题: 1. 透明物体会被Native画的东西挡住 2. VR中Native画的东西透视关系有点问题, 跟Unity绘制的场景不能很好地融合在一起先来解决一个透明排序的问题, 这个问题有两个思路去解决:双Camera双Camera的思路就是, 一个Camera只画不透明物体, OnPostRender中回调Native Renderer, 另一个Cam

官方的Sample只是画了一个屏幕空间的三角形, 怎么改成世界空间的呢? 以D3D11为例:Native:struct ConstantBuffer{ DirectX::XMMATRIX World; DirectX::XMMATRIX View; DirectX::XMMATRIX Projection;} g_CB;extern "C" void UNITY_INT

跟Delegate一起用FTimerDelegate TimerCallback;TimerCallback.BindLambda([]{ // callback;});FTimerHandle Handle;GetWorld()->GetTimerManager().SetTimer(Handle, TimerCallback, 5.0f, false);UI回调事件 SNew(S

UE4每次升级个版本总是要提交大量文件到Perforce, 是件很麻烦的事. 我们的引擎编译好了会连同Binaries一起上传, 这样美术和策划都可以直接使用跟程序一样的版本. 这样的话, Perforce上的引擎就需要有这些注意事项:引擎目录完全包含所有代码和引擎依赖资源引擎编译输出的dll, exe等也都需要提交, 保证策划和美术能够直接拉取引擎版本引擎编译过程中会写入的文件, 需要改成w

文章目录背景UE4的内存统计memreportMemoryProfiler2LLMAndroid进程内存DDMSMemoryAnalyzer背景UE4游戏在Android上的进程内存占用(PSS)很让人困惑, 没有一个清晰直观的方式可以统计到每一部分的内存占用. 所以在做内存分析的过程中顺手做了一个统计工具, 可以从系统底层统计UE4在Android的所有内存分配(包括Graphics部分),...

最近把HairWorks整合到了UE4 4.20, 整合的过程中发现了一些没法直接merge的代码, 主要集中在LightRendering.cpp和DeferredLightingPixelShader.usf中. 所以顺便简单读了一下代码, 把其中的一些关键字概念整理出来方便查阅理解.Uniform Buffer StructUE4使用了一些宏来辅助定义UniformBuffer中的结...

增加类编辑器中有一个类向导, 可以生成类所需要的文件和基础宏头文件由于UE4对C++做了扩展, 实现了如序列化反射等特性, 跟Qt的做法类似: 在代码中加入一些宏关键字, 在编译期间生成相应的C++代码. 因此, 对于每个类来说, 都有会生成一个ClassName.generated.h的文件类声明UCLASS([specifier, specifier, ...], [meta(key=valu

跟Class一样, 类成员变量也可以像C#那样加一堆的描述UPROPERTY([specifier, specifier, ...], [meta(key=value, key=value, ...)])Type VariableName;主要有4种基础类型:整数浮点数布尔值除bool外, 可以使用bitfield, 如uint32 bIsHungry : 1;字符串FString: 动态字符串

UE4有很多个Module, GamePlay部分也是一个或多个Module, 每个Editor也是一个Module搜索了一下, Module总数170+, 总共分三类: Runtime, Editor, DeveloperRuntime这边比较重要的是Core, UObject, EngineCore数据类型数据库容器IO/LogUObject: 所有对象的基类. UE中还有个约定是Object

自己的超级本挂了后, 一直没有电脑用正好

官方WIKI上面有个FPS C++ Tutorial, 照着做一遍可以体会一下UE4整