Creature3D游戏引擎

lomaxhong

地铁解压时出现scene.cre文件crc错，刚才赛车也是unititled.wav出错，用unititled1代替了，scene.cre用什么来代替？

caitht

scene.cre是场景文件，wav可以找别的代替没问题，但scene要么就找别的cre文件代替，用不同版本生成的.cre文件并不保证兼容，我最近也老出现解压错误，一些以前的压缩文件，不知道为什么会出现解压错误，会不会是rar出什么问题了

lomaxhong

可能是硬盘，也可能是内存，病毒也有可能，还以为是下载出问题呢！

funcman

caitht: Re:Creature3D游戏引擎

scene.cre是场景文件，wav可以找别的代替没问题，但scene要么就找别的cre文件代替，用不同版本生成的.cre文...

我上次内存坏了，就是这个症状。伴随win经常莫明崩溃。

经常遇上解压最好马上排查原因，我上次因此起码损坏了几G的数据。我的是凡是读过的压缩包，全部出问题。

dscky

刚下了你的demo，看了一下，提几点意见，仅供参考，1，所有的图片格式都是以插件的形式引入，dll太多。用开源的freeimage或devil都只有一个dll而已，也可以支持你大部分图片格式，另外，对图片类型的支持似乎不应该以dll来扩展，整个image接口只作为一个dll即可，其工作包括：图像的读写、变换、以及过程纹理的生成等。自我感觉你的系统框架设计可能不是很好，所以后期扩展必须以单独dll来实现，建议看看设计模式，以及成熟的开源软件的架构。2看了一下dl的名称l，感觉你用了cal3d、openal、ode、ogg等等开源软件或库。这些软件遵循的开放协议不尽相同，但一般来说，如果直接使用到商业软件中的话，通常都要email通知作者，或在软件发布的显著位置标明的，如果你仅仅是参考他们的代码，重写到自己的模块中去的话，则不用这些。不知道你做了这些工作没有，如果没做的话，等软件作大后，相关的纠纷比较多。3你的打包文件cre太多东西包到里面，感觉是直接写入的，这样的话，读写很容易出错，一般的做法是：将各个文件独立放置，最后统一打包，像id那样。4。看了你的主页，那个软件著作权登记看不太清楚，想弱弱的问一下，这个登记要准备哪些东西？一般要花费多少银子？通过容易不容易？

dscky

刚才又看了一下，那个故宫demo，程序明显没有经过优化，内存耗用很大，树木抠的也不干净，一些细节破坏了整体的印象，，不知道楼主是否一个人完成这所有的工作的？感觉专业美工不应该这么差的，如果是一个人完成的，楼主也不容易，我就不说什么了。

flyv

来晚了
准确来说……是太晚来了，“今天”中午再看吧。

caitht

Creature3D游戏引擎新增后台动态调度功能，理论上能支持无限大场景，测试案例也包含在creature3d060430里面

caitht

看了dscky的留言我想简单做下解释：1.并非所有的image格式是借用插件读写的，而是所有的文件操作的读写都是借用插件来实现的，采用代理模式设计，统一由CRIOManager管理，这样做的目的自然显而易见，极大的提高了读写可扩展性。至于对于系统架构如何设计，自然个人有个人不同的理解。我是不喜欢把所有东西统包在一个库里，自绝了系统扩展之路的。2.我的确用到了这些开源的库，他们基本上相当独立，我只在我的系统里写了与其相关的对接模块。等到要开始商业应用的时候我是应该要给他们的作者发邮件的。但是变数也是存在的，目前GPU物理正在兴起，可能过一年半载我就改用GPU物理引擎了也说不定。谢谢提醒！3.cre里面是包含了所有场景的东西（除了声音），这方便不使用后台动态调度的场景，而且也不会因为发布东西而将相应图片资料都公布或者另做一个图片的存储格式。cre的读写是采用设计模式思想设计的，读写上并不容易出错，只是现在未加入版本识别，因为还没开始商业化。对于4月30号后的版本，完成了后台动态调度，所以需要将贴图分离出来。当然，对于以后应用，如果不需要用到后台动态调度的情况下，仍然是可以统一包在一个cre文件里的。4.软件著作权需要60页源码，需包含系统的起止源码，软件设计说明书，1kRMB详细情况我就不说了，相关网站上有。5.creature3D自然是做过大量优化的，当然也许你有更好的优化方案，故宫场景内容贴图用的都很多，而且很多是在512*512这样的大贴图，甚至有用到2048*的，所以内存占用较大，当然对于被绑定成texture的image是会被释放掉的。至于故宫场景美工问题，这个吗，我自己并非美工人员，制作故宫场景的人也非专业美工，而且也没有游戏美工及如何为游戏优化制作的思想。否则故宫用的贴图也就不会出现这么浪费的情况了。
最后，谢谢你的关注！