#
void split(std::string& s, std::string& delim,std::vector< std::string >* ret)
{
size_t last = 0;
size_t index=s.find_first_of(delim,last);
while (index!=std::string::npos)
{
ret->push_back(s.substr(last,index-last));
last=index+1;
index=s.find_first_of(delim,last);
}
if (index-last>0)
{
ret->push_back(s.substr(last,index-last));
}
}
給一個(gè)比較老的圖形引擎添加讀取png的功能
使用devil
添加過(guò)程很簡(jiǎn)單，但是發(fā)現(xiàn)貼圖總是倒的
根據(jù)以往的經(jīng)驗(yàn)
這肯定是和讀出來(lái)的raw data的字節(jié)序有關(guān)的
于是老是在調(diào)整字節(jié)順序
最后終于發(fā)現(xiàn)
讀取圖片前使用
ilEnable(IL_ORIGIN_SET)后
一切正常。
總的來(lái)說(shuō)nv的5系列的顯卡是很爛的系列
nv在6系列之前都是被ati壓著。
說(shuō)說(shuō)5200這塊爛卡
通過(guò)測(cè)試發(fā)現(xiàn)5200的固定管線比可編程管線要快許多
所以，
雖然5200支持到sm2
但是游戲中還是要把它劃為和mx440一個(gè)等級(jí)上去
相同測(cè)試在5600和ati9550上執(zhí)行
均沒(méi)有發(fā)生這樣的事情。
特此備忘
新建一個(gè)QT的工程
發(fā)現(xiàn)使用的ZIP函數(shù)庫(kù)總是在編譯的時(shí)候報(bào)關(guān)于Unicode的錯(cuò)誤
我在vs2003下工作的都很順利
于是很自然的把vs2005的工程設(shè)置里面的使用字符集 改成了多字節(jié)
再編譯，但是問(wèn)題依舊
。。。。。。。。
。。。。。。。
最后，偶然的打開(kāi)vs2005的c++設(shè)置選項(xiàng)
赫然發(fā)現(xiàn)一個(gè)unicode的宏定義 在上面
刪之，
世界太平
幾乎每一本windows編程的書(shū)都會(huì)告訴你
dll目錄的查找順序
如果你對(duì)第三方提供的dll
進(jìn)行了某些hack
那么請(qǐng)十分注意你的dll的路徑
因?yàn)閣indows第一個(gè)查找的路徑是
windows\system32
如果這個(gè)目錄中不幸的也有你需要使用的dll
那么你所做的hack將會(huì)無(wú)用。
前天來(lái)制作游戲的離線更新包
突然發(fā)現(xiàn)以前很正常的代碼突然link錯(cuò)誤了
而且Link錯(cuò)誤是報(bào)庫(kù)之間的函數(shù)沖突libc，libcmtd.lib和微軟的函數(shù)沖突
弄了半天未果
于是惱怒之下把原來(lái)備份的代碼翻出來(lái)
把cpp和.h替換之后
在編譯 又OK了
當(dāng)時(shí)時(shí)間緊迫，也沒(méi)多想。
周一來(lái)上班
發(fā)現(xiàn)這個(gè)問(wèn)題又出現(xiàn)了，
于是好好的檢查了一番。
經(jīng)過(guò)一層層抽絲剝繭
字節(jié)比對(duì)之后
很偶然的發(fā)現(xiàn)
原來(lái)是一個(gè)cpp文件導(dǎo)致了這個(gè)Link的問(wèn)題
把這個(gè)cpp從項(xiàng)目中排除之后
再編譯會(huì)提示說(shuō)XXx函數(shù)找不到的link錯(cuò)誤
然后再把這個(gè)cpp包含進(jìn)來(lái)
再編譯 就ok了
如果這個(gè)時(shí)候你把vc2003再關(guān)掉
再打開(kāi)，rebulid
那么錯(cuò)誤又會(huì)出現(xiàn)。
原因是什么
至今尚未查清。
使用d3d Device提供的獲得顯存的函數(shù)
在有的ati低端顯卡上得到的數(shù)值與實(shí)際有較大出入
例如ati 9100
本來(lái)就64m顯存，通過(guò)d3d的函數(shù)得到的數(shù)字有110m
估計(jì)是把a(bǔ)gp部分也算進(jìn)去了
這不是我們想要的。
于是換一個(gè)方法
使用ddraw的方法來(lái)查詢，
經(jīng)檢驗(yàn)這個(gè)方法是可行的。
于是修改引擎代碼
期間遇到com組件幾個(gè)問(wèn)題
最后遇到一個(gè)問(wèn)題
編輯器在初始化引擎的時(shí)候有個(gè)函數(shù)
莫名奇妙的跳轉(zhuǎn)到另外一個(gè)函數(shù)
久思，
最后原因只能是和剛才添加了一個(gè)虛函數(shù)，導(dǎo)致編譯出來(lái)的類的結(jié)構(gòu)已經(jīng)變了
于是到處查到底是哪里不對(duì)，
查到工程的link屬性
發(fā)現(xiàn)其中指向的目錄是分支版本前的目錄
又把增量編譯給關(guān)了
但是問(wèn)題依舊。
最后又過(guò)了半天才想起是include的目錄沒(méi)有改過(guò)來(lái)。
哎
分支版本真是害死人啊。
教訓(xùn)：
碰到這種問(wèn)題很明顯就是項(xiàng)目的配置問(wèn)題
一定要仔細(xì)檢查，
這一次都已經(jīng)想到是link有問(wèn)題了
卻沒(méi)有進(jìn)一步想到include 的問(wèn)題。
凡是遇到d/r運(yùn)行結(jié)果不一樣
或者使用vc調(diào)試運(yùn)行的結(jié)果和直接運(yùn)行Exe的結(jié)果不同的
首先需要檢查變量是否初始化
尤其是圖形方面的程序
先檢查相機(jī)的各個(gè)參數(shù)
今天Load項(xiàng)目的Effect.dll
死活Load不進(jìn)來(lái)
突然想起以前用OD調(diào)試程序，
機(jī)器上沒(méi)有OD，不過(guò)隨vc倒是有depency
打開(kāi)一看
赫然發(fā)現(xiàn)原來(lái)是這個(gè)Effect.dll的一個(gè)依賴的dll沒(méi)有放進(jìn)來(lái)
于是乎
眾DLL歸位，一切正常。
QRegExp是Qt的正則表達(dá)式類.
Qt中有兩個(gè)不同類的正則表達(dá)式.
第一類為元字符.它表示一個(gè)或多個(gè)常量表達(dá)式.
令一類為轉(zhuǎn)義字符,它代表一個(gè)特殊字符.
一.元字符
. 匹配任意單個(gè)字符.例如, 1.3 可能是1. 后面跟任意字符,再跟3
^ 匹配字符串首. 例如, ^12可能是123,但不能是312
$ 配字符串尾. 例如, 12$可以是312, 當(dāng)不能是 123
[] 匹配括號(hào)內(nèi)輸入的任意字符.[123]可以為1, 2 或3
* 匹配任意數(shù)量的前導(dǎo)字符. 例如, 1*2可以為任意數(shù)量個(gè)1(甚至沒(méi)有), 后面跟一個(gè)2
+ 匹配至少一個(gè)前導(dǎo)字符. 例如, 1+2必須為一個(gè)或多個(gè)1, 后跟一個(gè)2
? 匹配一個(gè)前導(dǎo)字符或?yàn)榭? 例如 1?2可以為1或這12
二.統(tǒng)配模式
通過(guò) QRegExp::setPatternSyntax(QRegExp::Wildcard);可以將元字符設(shè)置為統(tǒng)配模式.在統(tǒng)配模式下,只有3個(gè)元字符可以使用.他們的功能沒(méi)有變化.
? 匹配任意單個(gè)字符, 例如, 1?2可以為1,后面跟任意單個(gè)字符, 再跟2
* 匹配任意一個(gè)字符序列. 例如, 1*2, 可以為1, 后面跟任意數(shù)量的字符, 再跟一個(gè)2
[] 匹配一個(gè)定義的字符集合. 例如, [a-zA-Z\.]可以匹配 a到z之間任意一個(gè)字符和. [^a]匹配出小寫(xiě)a以外的字符.
三.轉(zhuǎn)義序列
\. 匹配"."
\^ 匹配"^"
\$ 匹配"$"
\[ 匹配"["
\] 匹配"]"
\* 匹配"*"
\+ 匹配"+"
\? 匹配"?"
\b 匹配響鈴字符,使計(jì)算機(jī)發(fā)出嘟的一聲.
\t 制表符號(hào)
\n 換行符號(hào)
\r 回車符鉿
\s 任意空格
\xnn 匹配16進(jìn)制為nn的字符
\0nn 匹配8進(jìn)制的nn字符
這些表達(dá)式均以\開(kāi)始, 與C++的轉(zhuǎn)義字符相同,所以為了定義QRegExp中的一個(gè)轉(zhuǎn)義序列,
需要在前面添加兩個(gè)\\