|
|
2016年10月10日
这个问题是在学习 Introduction to 3D Game Programming with DirectX 11 一书时遇到 最正确的解决方案是这里 D3D11 D3DX11CreateEffectFromMemory returns E_NOITERFACE好像是因为D3DX库已经被弃用了. Effect也是. 而DIRECTX库也被包含在win sdk里面不再作为单独的SDK发布. 而D3DX的库在发布时使用的是VS2010编译的, 当使用VS2012或更高版本时, 会有错误 以上都是个人理解. 我可以保证的是肯定有理解的不对的地方. 在stackOverflow上的大神建议的是把D3DX和Effect都用最新的接口替换掉并给出了新旧接口的对照页面链接, 太麻烦了实在不适合我这种浅尝辄止的人. 最后我个人的解决方案是这样. VS2013中. Project property -> Configuration Properties -> General -> Platform Toolset -> change the "Visual studio 2013 (v120)" to "Visual Studio 2013 - Windows XP (v120_xp)"
这样既可规避错误. 具体原因: 不明
2015年10月17日
使用VS自带命令行
lib /list lib文件名.lib
2015年10月8日
程序集，对于C#程序员来说一定不陌生，不就是VS生成的那些exe,dll么。是的，程序集(.net中exe与dll的区别就是exe有程序接入口，即Main函数)就是.net框架下，可以被CLR加载并运行的一堆数据集(类似java中的jar包，无法脱离虚拟机自己运行)。它们和之前C\C++生成的可执行程序和动态链接库有本质的区别。
说了半天，程序集里到底有什么呢。作为一堆数据集，程序集的数据可以分为：类型元数据，程序元数据，IL代码，资源。
先说下什么是元数据，元数据一般就是指描述自身的数据。
程序集元数据：包含程序集的版本信息，安全信息，签名等。
类型元数据：记录了程序集将引用了哪些类，用户自定义了哪些类，字段，数据类型等一系列信息（VS的编程助手靠的就是反射获取类型元数据）。
IL代码：MSIL，微软中间语言，微软跨语言的根基所在，所有的C#代码都编译成IL代码，保存在程序集中，在被CLR加载后，由JIT调用BCL,FTL即时编译成机器码来让CPU运行。
资源：图片，视频，音频不一而足。
原地址 http://blog.sina.com.cn/s/blog_7e0127220101blgd.html
2014年7月9日
DDA算法
直线倾向的轴坐标每步加一, 另一个轴的坐标加上斜率, 得到的值取整, 作为像素的XY值
书上给的缺点是取整和浮点数运算很耗时
Bresenham
有点复杂
以 0<斜率<1 为例
f(x) = mx+b
X每步加一
分别算出可能取到的两个Y值与直线在这个点上的真正的取值的差, 即
DiffUpper : y[k+1] - m(x+1) - b
DiffLower : m(x+1) - b - y[k] ( 直线会从这个像素的上半部分穿过, 所以y值一定比像素中心点的y值大 )
再算出两个差值的差
DD = DiffLower - DiffUpper
这里谁减谁无所谓, 因为是靠这个值的符号来决定画哪个像素
到这里因为m是实数的原因, 运算还是浮点数, 为了消除浮点数, 在等式两端乘以deltaX, 即终点和起点的X差值
Sign[k] = ( DiffLower - DiffUpper ) * deltaX
然后, 用Sign[k+1]减去Sign[k], 会得到一个整数的增量, 这个增量经计算会是一个与DD有关的整数
这样, 只要算出第一个点的Sign[0]再不断的加上这个增量, 就能算出下一个点的坐标了
书上给的优点是可以只用整数运算就画出直线
据说可以画任意曲线, 稍微想了一下, 没想出来改进方法, 算了
2014年3月28日
读此文笔记:
http://www.cnblogs.com/soroman/archive/2008/03/24/1118996.html
所谓的万向节死锁, 是当某一个轴转到与另一轴重合或相反的方向之后, 转动的操作, 无法在原始数据上继续累加, 亦无法通过单纯的欧拉角的记录方式还原本次转动.
按上文举的栗子. 假设有欧拉变换为[30, 90, 40], 完成后Z轴与负X轴重合
此时的任何转动, 都无法通过累加到原变换上的方式重现
比如此时绕X轴转1度, 可以想象Z轴将不再与负X轴重合, 但如果把这1度累加到原来的数据上, 变成[31, 90, 40]可以想象变换完以后Z轴还是与负X轴重合的.
2013年7月18日
此文是介绍如何设置在NDK中编译完成后, SO文件的输出路径 查了很多地方, 说的什么LOCAL_MODULE_PATH, 都是放屁, 一点用都没有 其实要用这个宏 NDK_APP_DST_DIR 注意路径的最后一定要是$(TARGET_ARCH_ABI) for example: NDK_APP_DST_DIR := ../../../libs/$(TARGET_ARCH_ABI)
以上
2012年7月9日
#define fun(a) \
#ifdef NEST
function(a)
#endif
以上是不行的, 只能这样
#ifdef NEST
#define fun(a) function(a)
#endif
2012年6月12日
其实就是:
当纹理需要缩小的时候, 会根据缩小的程度, 从MIPMAP中选择一层
当选择MIPMAP层的时候,
如果LOD_BIAS小于零
分辨率更高的层"更容易"被选中 //分辨率更高: 像素更多, 比例更大
如果LOD_BIAS大于零
分辨率更低的层"更容易"被选中
2012年4月10日
VirtualAllocEx针对进程ID分配了一段内存, 内存中的页有三种状态, 空闲, 保留 和 提交.
在向其他程序的ListView控件发送LVM_GETITEMTEXT中直接把申请的内存(应该是一个单独的页)设为了COMMIT.
WINDOWS的每个进程拥有4G的VAS(Virtual Address Space), 2G是与操作系统和其他进程共享的, 2G是独占的.
通过: plvitem=(LVITEM*)VirtualAllocEx(hProcess, NULL, sizeof(LVITEM), MEM_COMMIT, PAGE_READWRITE);
SendMessage(hwnd, LVM_GETITEMTEXT, (WPARAM)iItem, (LPARAM)plvitem);
这两句代码来看, plvitem的地址在当前进程和hProcess的进程中都可用, 也就是说应该是分配在了那2G共享的VAS中
2012年4月8日
今天试图通过FindWindow找到ListView后用ListView_GetItemText直接取出条目的文本, 结果失败报错, 内存不能写
原因是, ListView_GetItemText实际上是发了一个消息给List, LParam是LVItem的地址, 但是因为地址空间的问题, 在ListView所在的进程中, 传进去的那个地址是无效的.
而hwnd却可以通过消息传出, 也就是说hwnd是"跨进程全局"的. 记得以前总是疑问句柄和指针到底有什么区别, OK, 起码现在明白指针是进程内唯一, 而Hwnd句柄是系统内唯一
|