因为之前业余时间太累了,目前主要还是休息,所以现在放慢节奏写点东西.
目前已经把3DS MAX的SDK环境搭好, 用它自带的模板创建了solution,已经加到在MAX里面了,引擎的Model插件也着手编写,目前一边熟悉MAX SDK,一边添加Mode插件中模型保存/加载需要的接口.
遇到一个问题就是, MAX导出插件也依赖引擎的基础DLL, 把导出插件放到$(ADSK_3DSMAX_x86_2013)\plugins 中以后,
把引擎的基础DLL放到这个$(ADSK_3DSMAX_x86_2013)\plugins中,MAX加载它会失败,估计是DLL SEARCH PATH问题,
把引擎的基础DLL放到max运行目录$(ADSK_3DSMAX_x86_2013)就好了.
但是我是有洁癖的,总觉得觉得导出插件的依赖应该放到max的plugins里面,而不是max的运行目录下,但这个是MAX的问题,不好直接解决,想到的方案有两个
1.把引擎DLL编译成Lib,直接链接.
2.生成SDK,把SDK\bin\放到环境变量Path中.
因为第一种方案的静态库, 有已知的问题:
在MSVC下,静态库的编译单元内的所有变量或者函数如果没有被引用过,链接的时候此编译单元的二进制(lib中的obj)可能不会被链入目标,所以静态变量可能链接不到EXE/DLL中,导致最终镜像不存在该变量,而不能初始化.
之前也在考虑中,主要是考虑Console,手机等没有动态链接的系统,但目前还有完善的解决方案, 现在虽然给基础库加了手动初始化函数来保证静态变量都可以初始化,但是插件不好处理,以前插件DLL是自动搜索加载(模仿Max),如果用静态库可能需要手动链接和初始化插件了.
第二种方案相对比较简单,所以选用第二种,写了个一个cmd/bat脚本将include, lib\x86, bin\x86复制到"自己的SDK目录"中,并添加了环境变量,导出插件可以正常工作了.
后来的工作是给引擎添加了x64平台,主要的配置工作是将原来bin\debug,bin\release生成的文件改为bin\debug_win32, bin\debug_x64和bin\release_win32, bin\release_x64.
因为在最初已经考虑到x64平台了,加入了X86和X64的平台判断宏,所以移植到x64的改动和问题不多,主要是工程配置的修改.
遇到的问题有
1.指针到数字的转换. 这个已经被提前考虑了.就是指针 (如void*)转到数值,要用intptr_t或者uintptr_t (用Win32的INT_PTR也可以,当然用C/C++标准的更好),而不使用int/uint/DWORD, 因为x64平台下的void*或者任何指针都是64位的, 转到DOWRD(win x64的LLP64下的long)就被截断到32位了.
这个问题基本没有遇到,因为之前已经很注意这个问题了,但是有一段FreeImage相关的AlignedMalloc代码,直接复制FreeIamge里面的AlignedMalloc,他用的是void*-->long,当时直接Ctrl+V,没仔细看,所以这里程序就崩溃了.
2.对齐的问题.目前Win32下 VC10默认对齐到8字节,x64对齐到16字节.因为之前的内存管理没有考虑x64平台的内存对齐,所以会有一些问题.遇到的一个问题就是libPNG(FreeImage的依赖)中使用的setjmp(作为一个C++程序猿, setjmp/longjmp我从来不用的),执行到读写FPU状态标记(一个WORD)和MMX指令就崩溃,提示内存读0地址,但是看内存是好好的,调试了半天找不到原因,最后看了下创建的pngstruct没有对齐到16字节边界,尝试性的试了下,居然好了.怀疑是读写非对齐内存的问题,但记得x86下不对齐只会有性能损失,x64会出错么? 不太了解,有空了再多搜搜文档,了解下.
目前解决方案是,内存管理模块会根据目标平台,选择对应的对齐大小.
3.Win32下的各种API,一些MFC的三方库没有用DWORD_PTR和INT_PTR作为参数.其他主要是GetWndLongPtr这类,看msdn上说要用这个保持x86/x64兼容,这个早已经用了,但没发现对应的宏,GWL_XXX的对应要用GWLP_XXX的版本,这个一开始也是觉得诡异,怎么x64下没有这个宏了,不知道有什么问题,后面google了一下就出来了,相对比较简单.
4.内联汇编,在MSVC的x64编译器不支持内联汇编了.其实也没怎么用内联汇编,主要就是同步锁用了lock cmpxchg,解决方法也很简单,去掉所有内联汇编,用MSVC的intrins: _InterlockedCompareExchange / _InterlockedCompareExchange64和GCC的builtin:__sync_fetch_and_add / __sync_add_and_fetch / __sync_bool_compare_and_swap一族.
最后,延续一下上次的,地形加载profiling的问题,在release下地形的四叉树操作,耗时在1ms-2ms,虽然debug下有20ms左右,但目前觉得不需要过多的优化.以后根据实际情况再做处理.