Read this post in english:http://androgeek.info/?p=299
以前代碼經(jīng)驗(yàn)很多都是基于windows的，所以對(duì)android下面的計(jì)時(shí)函數(shù)不是太了解。
在寫Friut3D時(shí)，我用的代碼是用gettimeofday()來計(jì)時(shí)的。但是效果不好，游戲里有個(gè)場(chǎng)景跑起來十分卡，acepig兄和我都覺得這個(gè)問題很詭異。開始覺得這是模型的問題，現(xiàn)在看來是計(jì)時(shí)函數(shù)不精確惹得禍。
看看當(dāng)時(shí)寫的獲取系統(tǒng)時(shí)間的代碼：
static long getTime(void)
{
gettimeofday(&now, NULL);
return (long)(now.tv_sec*1000 + now.tv_usec/1000);
}
今天在一個(gè)google討論組里得知gettimeofday()記得的tick是不準(zhǔn)確的。而這個(gè)游戲邏輯依賴于time delta來計(jì)算各個(gè)物體運(yùn)動(dòng)，計(jì)時(shí)不精確，渲染自然會(huì)卡頓。
于是用納秒級(jí)的準(zhǔn)確度的clock_gettime()重寫了getTime()函數(shù)：
static long _getTime(void)
{
struct timespec now;
clock_gettime(CLOCK_MONOTONIC, &now);
return now.tv_sec*1000000 + now.tv_nsec/1000;
}
改了計(jì)時(shí)函數(shù)后，游戲各個(gè)場(chǎng)景都流暢了。
IK在骨骼動(dòng)畫里常常能看到，作用就是根據(jù)子骨骼的方位推算出它的那些父骨骼方位。可是一直都是知道有那么回事，但是又不太知道具體是怎么實(shí)現(xiàn)的。
在multi-crash.com上看到一篇骨骼動(dòng)畫反向動(dòng)力學(xué)(IK)的實(shí)現(xiàn) ，內(nèi)容寫的很易懂。
這是基于CCD(Cyclic Coordinate Descent)算法的。還有種雅可比矩陣的算法，不過這種算法我還不太清楚，希望高手指教啊。
下面講講CCD，先看這張圖。
注意圖中的紅線和綠線，紅線是當(dāng)前骨骼與目標(biāo)骨骼的連線，綠線是目標(biāo)骨骼與最終位置的連線。
從子骨骼到父骨骼的順序迭代計(jì)算，旋轉(zhuǎn)紅線到綠線。這樣多迭代幾次就會(huì)得到較好的結(jié)果。
要注意的是需要對(duì)骨骼的旋轉(zhuǎn)范圍加以限制，因?yàn)槿梭w的關(guān)節(jié)不是以可以任意方式旋轉(zhuǎn)的。
[例如圖中藍(lán)色部分為可以旋轉(zhuǎn)的范圍]
http://androgeek.info/
AndroGeek[安卓極客]是我正在辦的一個(gè)網(wǎng)站，內(nèi)容以Android 編程開發(fā)與資訊為主。
如果有好的Logo創(chuàng)意或者有寫Android相關(guān)的文章的想法，請(qǐng)聯(lián)系我～～～
AndroGeek歡迎大家。
[為了國際化，這是一個(gè)英文站點(diǎn)]
Android是個(gè)好系統(tǒng)哇，特別是Android NDK r3出來以后，可以用OpenGL ES 2.0了。
自己也試了試用NDK編一個(gè)OpenGL ES 2.0的程序，可是，編譯的時(shí)候出現(xiàn)了一大堆錯(cuò)。
如圖，滿屏幕都是 undefined reference to 那些OpenGL ES函數(shù)。
看來是庫文件沒有鏈接進(jìn)來。
這是NDK例子里的Android.mk的寫法：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libgl2jni
LOCAL_CFLAGS := -Werror
LOCAL_SRC_FILES := gl_code.cpp
LOCAL_LDLIBS := -llog -lGLESv2
include $(BUILD_SHARED_LIBRARY)
問題就出在用紅色標(biāo)出的那行。
把那句修改為：
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
LOCAL_LDLIBS+=-L$(SYSROOT)/usr/lib -lGLESv2
就可以正常編譯了。
還有一些注意點(diǎn)是：
編譯程序前要clean，否則編譯會(huì)出錯(cuò)；
每次更新了自己的.so文件后，在eclipse的那個(gè)java項(xiàng)目里要記著refresh一下。
直接用timeGetTime()這個(gè)函數(shù)的誤差是有目共睹的，在15ms左右，于是，如果游戲的消息循環(huán)用了timeGetTime()，那么3D游戲畫面會(huì)因?yàn)閮蓭g時(shí)間誤差大而有些抖動(dòng)。
今天在csdn上看到了一篇文章：http://blog.csdn.net/lanzhengpeng2/archive/2008/05/06/2401554.aspx
講的也正好是這個(gè)問題，記錄一下。
在使用timeGetTime()的代碼塊的前后加上timeBeginPeriod(1)和timeEndPeriod(1)，就可以提高timeGetTime()的精度。
同時(shí)，可以利用timeSetEvent寫了一個(gè)靠得住的休眠函數(shù)[代碼來自上述文章]：
static void XSleep(DWORD dwDelay,HANDLE hEvent)
{
MMRESULT hTimer = timeSetEvent(dwDelay,1,(LPTIMECALLBACK)hEvent,0,TIME_ONESHOT | TIME_CALLBACK_EVENT_SET);
MsgWaitForMultipleObjectsEx(1,&hEvent,INFINITE,QS_ALLINPUT,0); //當(dāng)有Windows消息時(shí)，還能繼續(xù)處理Windows消息。故選擇了這個(gè)函數(shù)。
timeKillEvent(hTimer);
}
消息循環(huán)[代碼來自上述文章]：
MSG msg;
DWORD dwLastTime;
HANDLE hSleepEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
timeBeginPeriod(1);
dwLastTime = timeGetTime();
while(isActive())
{
//需要一直處理Windows消息到無消息處理為止
for(;PeekMessage(&msg,NULL,0,0,PM_REMOVE);)
{
if(msg.message == WM_QUIT)
{
CloseHandle(hSleepEvent);
timeEndPeriod(1);
return ;
}
if(!TranslateAccelerator(msg.hwnd,hAccelTable,&msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
DWORD FrameDelay = max(1,1000/max(1,GetMaxFPS()));
DWORD dwTime = timeGetTime();
if(dwLastTime + FrameDelay > dwTime)
{
XSleep(dwLastTime + FrameDelay - dwTime,hSleepEvent);
}
else
{
update();
dwLastTime += ((dwTime - dwLastTime) / FrameDelay) * FrameDelay; //當(dāng)實(shí)際幀數(shù)嚴(yán)重低于預(yù)期幀數(shù)時(shí)，這段代碼可以完成跳幀功能；當(dāng)實(shí)際幀數(shù)大于等于預(yù)期幀數(shù)時(shí)，這段代碼仍然可以使幀之間的時(shí)間間隔固定。之前謝Boss沒有處理好的主要就是這個(gè)。
}
}
CloseHandle(hSleepEvent);
timeEndPeriod(1);
這樣，時(shí)間誤差就會(huì)在1ms之內(nèi)了，游戲也就不會(huì)抖動(dòng)了。