其他

物理引擎的抉擇前面說了, 這一系列是針對c++&3D的, 所以排除Box2D之類的2D引擎.3D版的, 目前最流行的有3個:Havok: 說它是最NB的毫不為過. 但是要錢, 不給錢人家才不鳥你呢. 免費版本只有Win32, 所以排除PhysX: 目前佔有率最高, 跟遊戲開發商合作比較好. NaCl版本沒看到有, 所以排除Bullet: 開源. 想跨平台, 還是開源的東西比較靠譜, 一切盡在掌握. 已經有前人做了一些NaCl的移植工作了這個是Bullet的NaCl版本示範: http:/

最近業餘在做一個基於結點的編輯工具玩, 遇到一個問題, 就是結點和連線多了, 經常會出現重疊交叉的問題, 導致圖看不清楚:要是這個樣子, 還不如不用圖清楚呢, 所心就需要找一個方法來進行自動布局, 理想情況是這樣的(手動整理結果):當然, 手動整理的話, 每個人弄出來的結果都不一樣. 自動的演算法肯定沒有100%完美的, 但是總是能方便不少的在google了一會兒後, 發現這種結點-線組成的圖是一有個學名的: directed acyclic graph,

最近遇到個記憶體泄露, 查來查去竟然在FMOD模組裡要不是別的組件全部定製了記憶體配置函數, 還真不會懷疑到它頭上使用FMOD::EventSystem::getMemoryInfo()輸出記憶體資訊一看, 直接崩潰了, 100MB~200MB之前我是用XACT的, FMOD本以為是差不多的東西, 就沒怎麼在意, 結果摔一跟頭細細的去讀了一下文檔, 發現有3點:FMOD::Memory_Initialize可以把FMOD的記憶體 Clerk換成自己的,

看了Ogitor的代碼後, 自己又實踐了一把, 結合N3中學到的一些技巧, 在編輯器中得到了驗證.雖說做的是情境編輯器, 但是其它編輯器也可以用的, 畢竟思想都差不多.對於一個編輯器, 通常是由一個個的"實體"組成, 或者叫"對象". 而"對象"又是由各種"屬性"所組成.以情境編輯器為例, 我們通常會涉及以下操作:刷地形, 刷紋理擺模型, 設定模型參數擺光源, 設定光源參數擺特效/音效, 設定參數擺NPC, 設定相應參數...可以看到, 除了地形之外, 其它的操作都差不多. 如果把地形把塊對待,

最近老是感覺任務完成的不是很及時, 雖然晚上走的也很晚, 但是時間都去哪了呢?與項目組的人溝通進度/需求會議內部/外部講座分享RTX/郵件騷擾早上看RSS訂閱, 讀書時間太長google時看到個技術點就發散開來到處搜...飯後遊戲時間太長看到段不爽的代碼, 然後控制不住改掉寫文檔指導新人工作晚上BBS/新聞網站看多了等等對應的解決方式:盡量保持溝通的高效, 可以在溝通完後記錄下來, 延遲處理時間分配中預留出這部分時間能不去的就不去了吧...郵件關掉, 只在晚上或早上看. RTX放另一個顯示器上,

之前提到過<<關於工作時間分配>>上周有個同事做了一個這方面的分享, 原來這個問題是很多人都會苦惱的其實不只是工作上了, 生活中的時間也需要合理的安排就好比我自己, 報了駕照學習, 拖了一年多, 連個理論都沒去考...還有業餘, 不管是寫代碼也好, 學習也好, 往往做了一半就沒動靜了Google "GTD",

老機器用了4年多了, 說實話對它還是挺有感情的, 當初光配置單就前後糾結了4個版本最後定的是E7200+P45+2x2G+320G+9800GT+22LCD(1080p), 3dmark06分數12000+用下來最滿意的還是顯示器了, 1920x1080的解析度對於上網/編程/遊戲在體驗上都是一個質的飛越最不滿意的, 就是噪音, 後悔在電源上省錢, 沒弄個大風扇的, 後悔買9800GT, 費電不說, 發熱還很大, 有時機器還不穩定為了超頻選的記憶體/主板/機箱也沒發揮作用,

概述三維場影裡的天空並不是“真正”的天空，而是用圖片拼起來的，欺騙我們眼睛。通常把大家所在的情境用一個幾何體包裹起來，再在裡面貼上從各個角度的風景圖，就好像一個真正的環境一樣。想想CS之類的天空，是不是有點印象？原理現在的遊戲裡可能半球用的較多吧？不過原理上一樣，我們這裡以立方體為例。最簡單的方法，莫過於畫6個正方形，分別為它們貼上紋理。（要是真這樣，我就不用寫了-_-）這裡我們只用一個正方形，也只用一個紋理，HOHO~想知道怎麼回事？住下看吧（欠扁）立方體環境貼圖（Cubic

N3停止更新之後, 這個是目前我覺得品質最高的代碼http://heliumproject.org/代碼在GitHub上: https://github.com/HeliumProject預設是沒有sln檔案的, 需要用premake4產生:開啟Visual Studio 2008 Command Prompt轉到HeliumProject目錄如果不想編譯, 可以把premake4.lua裡的Helium.BuildXXX那一大段都注釋掉如果沒有裝Python和FBX SDK,

這兩年接觸了一些比較成熟的商業引擎, 慢慢得思想有所轉變以前總以為, 哪個引擎代碼寫得好看就牛, 太偏激了很多商業引擎的代碼那叫一個亂~後來覺得引擎工具很重要, 沒有經過成功項目的引擎不是好引擎現在呢? 當然工具還是很重要, 但另一個很重要的因素是: 製作效率能不能快速開發, 能不能快速搭建原型, 快速推出, 靈活定製才是一個引擎最有競爭力的地方這扯得有點虛了, 來點實際的在學習並抄襲夠了各種技術細節後, 開始從另一個角度看待一下引擎開發之前有說過, 引擎可以看作是一個資源管理員,

最近看了OGRE2.0的一個PPT, 觸動挺大的其實OGRE一直以來所為人詬病的效能問題, 何償不也是我們引擎存在的問題雖然很多時候我們都拿OGRE和GameBryo的效率當反面教材, 但是自己也沒有做到極致相對於GPU的效能最佳化來說, CPU的效能最佳化難得多就好比遊戲開發的書籍, 講API/渲染的多, 講架構&邏輯的少可能很多人以為, 做引擎開發就是做圖形開發, 對於國內的遊戲來說好像沒錯但是如果真正做下來, 資源管理, 情境管理, 動畫, 物理, AI, UI, 音效, 指令碼,

內容：經過站1路汽車：a,b,c,d..........2路汽車：e,f,c,g.........則從a-g需要在c站換車怎麼算？＄a = array('a','b','c','d');＄b = array('e','f','c','g');print_r(array_intersect(＄a,

色彩表現力這個是一些小引擎容易忽略的地方. 可能引擎各種功能都有, 但是為什麼做出來的東西不夠出彩呢? 除去美術自身的原因, 程式也要好好與美術進行溝通. 很多時候美術有一些很不錯的想法, 確總是做不出來, 這個就是程式的責任了. 以WOW的技術為一個起始點, 我想可以從這些方面來改善:法線貼圖. 這個只是用來做一些假的幾何細節, 最重要的是高光的體現. 不過從另一個角度來說, 高光太多雖然畫面看著很"次世代", 但是容易讓玩家眼睛疲勞, 需要把握一個度. 更換光照模型.

什麼是烘焙? 簡單地說, 就是把物體光照的明暗資訊儲存到紋理上, 即時繪製時不再進行光照計算, 而是採用預先產生的光照紋理(lightmap)來表示明暗效果. 那麼, 這樣有什麼意義呢?好處:由於省去了光照計算, 可以提高繪製速度對於一些過度複雜的光照(如光線追蹤, 輻射度, AO等演算法), Realtime Compute不太現實. 如果預先計算好儲存到紋理上, 這樣無疑可以大大提高模型的光影效果儲存下來的lightmap還可以進行二次處理, 如做一下模糊, 讓陰影邊緣更加柔和當然,

做之前要多想想，要不然只是折騰要給自己留點思考的時間，現在空閑都是新聞笑話遊戲陪老婆。。。平時要多做總結，免得別人問起了不知道說什麼要多溝通，在一個團隊裡資訊需要及時傳達，不然各種小問題會變成大問題嚴謹一點，避免很好，很費，很長時間等詞語，資料更有說服力最重要的是，要學會忽悠!好了，牢騷發完了最近技術上的總結：1.對於次世代的畫面LDR顏色是不夠用的2.記憶體對於效能的影響有時會比演算法更大，不管是cpu還是gpu

PropertyGrid Winforms's PropertyGrid 非WPF原生支援, 需要藉助WinFormHost風格不可定製PropertyInspectorView算是"官方"庫, 風格不可定製WPF Property Grid開源功能還不夠完善可以定製風格PropertyEditor for WPF開源功能比較實用, 有自己的特色Actipro PropertyGrid商業控制項Mindscape WPF Property

GLES2.0封裝到shader和vbo結合的部分, 蒙了vertex layout(或叫vertex declaration)要一個一個element的綁定到一個shader變數上(GL叫attribute), 也就是相當於HLSL的VS_INPUT結構體吧.問題是, GLSL裡沒有"semantic", 然後問題就來了舉個例子:一個簡單的頂點結構:struct Vertex{ float3 position; float3 normal; float2

在遊戲中顯示網頁? 為什麼要這麼做呢?其實可以做不少的應用:嵌入協助文檔, 比如技能介紹, 可以做得很漂亮, 各種排版方式用傳統UI做起來很費勁活動公告頁面直接在遊戲中查看遊戲內的BBS/社區玩家的個性展示/資料等等最重要的是, 所有的這些內容都可以扔到web伺服器上, 不用打包進用戶端最早是用LLMozLib 實驗過, 編譯這玩意兒費了我老大勁兒, 最終發布時還要帶一屁股的DLL和資源受不了了就用IE自己搞了個, 沒做完美, 到是把flash activex嵌入D3D給完成了當然,

 by José María Méndez 原文連結: http://www.gamedev.net/reference/programming/features/simpleSSAO/ 緒論 全域照明(global illumination, GI)是一個電腦圖形學術語, 它指的是所有表面之間相互作用的光照現象(光線來回跳動, 折射, 或者被遮擋), 例如: 滲色(color bleeding), 焦散(caustics), 和陰影. 很多情況下,

遊戲&引擎不要為了做引擎而做引擎脫離項目的引擎是一個沒有經過驗證的東西, 沒人敢用引擎設計要以人為本, 這不是一個技術問題, 是需要項目的沉澱和積累的技術&應用技術如果不轉化為生產力, 那麼它的價值就是停留在程式員們YY中的自我滿足只有技術能夠讓生產力得到提升, 或者產品品質的提高, 它才會被認可, 不管它是多麼得高深, 還是多麼得的簡單程式們往往只喜歡去挑戰有難度的部分,