分類目錄歸檔:編程

MCMod教程開始恢復更新

MC1.9馬上就要發布了,按照"總是差一個版本"的慣例(這是哪的慣例啊),教程準備從1.7更新到1.8了 ? 剛才看了眼第一篇教程,文中介紹的Eclipse居然還是4.3...現在第一篇教程已經更新了,最近那麼多人抱怨沒法配置開發環境,現在看來一點也不奇怪(捂臉,那篇實在太陳舊了).

想看看當初給MC1.2寫ModLoader教程時的原始手稿,結果發現找不到了...這種東西還真能丟啊. 閱讀全文 [...]

FGOW1.2.1和FMMv4

Forge在更新到1.8.8之後FGOW1.2.0就不能用了,於是自然而然地就有了FGOW1.2.1,新版本在功能上沒有變化,只是支持了使用ForgeGradle2.1的Forge1.8.8和1.8.9.

下載地址:
SkyDrive:http://1drv.ms/21gcxy5
Dropbox:https://www.dropbox.com/s/ekig3gjx32uz3qp/fgow-1.2.1.jar?dl=0
百度網盤:http://pan.baidu.com/s/1geoIkin


此外,ForgeMavenMirror,也就是我們喜聞樂見的ForgeMaven倉庫鏡像,也更新到v4版本了.
更新內容包括:

  • 緩存了2.0、2.5和2.7的gradle文件,下載地址為"http://forgemavenmirror.sinaapp.com/gradle/gradle-[版本號]-bin.zip",啟用它們的方式是修改Forge(其實現在應該叫MDK了)目錄下的gradle/wrapper/gradle-wrapper.properties文件,將"distributionUrl="後面的下載地址改為鏡像的地址.我之前沒有弄這個是因為我不贊同這樣做,Gradle的文件策略相當有問題,它是根據下載地址的Hash來識別版本的,這意味着不同下載地址的同一版本Gradle(甚至是同一個地址的https和http下載鏈接)會被識別為不同文件,你知道我的機器上已經有4個版本的Gradle-2.7-bin了嗎?也許他們認為多版本並存很有意義,但我覺得僅憑下載地址來區分的多版本除了虐待硬盤以外毫無意義.不過現在考慮到Gradle已經成了GFW的重點關照對象之一,https鏈接幾乎已經連不通了,這裡還是提供了Gradle的緩存.
  • 增加了大量緩存,現在FMM已經可以代替所有的倉庫了!對,你可以刪掉除FMM以外的所有倉庫,經過實測1.8.9可以在只有FMM倉庫和本地Forge緩存目錄的情況下配置.
  • 智能重定向,過去FMM在失敗時只會重定向到Forge的倉庫(files.minecraft.net),現在FMM會重定向到"最有可能"的倉庫,此外,由於Oschina的Maven鏡像復活了,對於Maven中央倉庫的資源會重定向到Oschina的鏡像.
  • 可選的快速失敗,如果你不想要重定向功能的話,可以使用"http://forgemavenmirror.sinaapp.com/mavenff"這個倉庫,它會在沒找到緩存的情況下直接返回404,而不是重定向,這對於想要繼續混合使用其他倉庫的人來說很有用.
  • maven-metadata.xml緩存會在每天(北京時間凌晨1點)更新一次.因此,現在快照版本(Snapshot)又會被緩存了(之前由於maven-metadata.xml不會自動更新的問題,一度取消了快照版本的緩存).
  • 一些細微的優化.
閱讀全文 [...]

FGOW 1.1.0

更新內容:
新的配置方式
增強了源替換能力,現在Minecraft、MCP和Forge的Json版本文件都能被替換了,同時增加了assest下載地址的替換.
修正了一個關於構建經典開發目錄的Bug,這個Bug會導致源代碼和資源文件無法被正確地複製到工作環境中.


具體內容見http://www.hakugyokurou.net/wordpress/?page_id=1337 閱讀全文 [...]

Asm♂Event♂Bus

好吧,標題是逗悶子的,這個項目的名字確實是AsmEventBus,但我總是忍不住在裡面插入'♂'.

上一篇日誌提到正在做一個Java庫(如果你真的以為上一篇日誌僅僅是追悼我掛掉的高數的話...就點它的"繼續閱讀"吧),其中提到"一個基於類生成的事件總線系統",在寫完日誌後不久,我決定把事件總線系統從庫中分離出來,單獨作為一個項目. 閱讀全文 [...]

[3D圖形學]視錐剔除入門(翻譯)

最近在學3D圖形學...看到篇不錯的視錐剔除入門教程,於是搬來翻譯了...

時至今日,許多剛剛下海的3D引擎程序員仍不了解視錐剔除(Frustum Culling)的重要性和益處,這讓我和我的小夥伴們感到很震♂驚.我在Flipcode論壇中發現儘管網絡上有海量的相關資料,仍有許多人提出對視錐剔除實現的問題.因此我決定撰寫這篇文檔,簡單描繪出我現在所使用的四叉樹剔除引擎(Quad-tree Culled Engine)的工作方式.誠然,市面上有許多種成熟且高效的視錐剔除算法,但我認為這個算法足以用來學習視錐剔除的理論基礎.在正式開始前我還想說明一件事,以前我一直把Frustum(平截頭體)打成Frustrum(截頭錐),為此我沒少被論壇上的人噴.在這裡我承認Frustum是正確的拼寫.對那些以前被我冒犯的人我表示抱歉...你們這群吹毛求疵的傻[嗶-]...

大多數人已經知道什麼是視錐剔除了(譯者:如果你是手滑誤點進來的...視錐剔除是一個圖形渲染前的步驟,用於剔除掉不需要繪製的部分).視錐(準確說是平截頭體Frustum)的形狀酷似一個塔尖被削平了的金字塔,更準確地說,是一個四稜錐的頂點偏下位置被一個裁面(Clipping Plane,見圖1)裁斷.事實上,視錐本身就是由6個面所組成.這6個面被稱為近裁面,遠裁面,上裁面,下裁面,左裁面,右裁面.視錐剪裁僅僅是一個用來判斷物體是否需要被繪製的過程.儘管從本質上講視錐剔除應該是三維層面的,但事實上大多數時候它僅僅需要以純代數的方法便能解決.這也是為什麼我如此推崇視錐剔除的原因,它非常的快(如果算法好的話),而且是在渲染管線(Rendering Pipeline)之前進行的,不像背面剔除(Backface Culling)那樣需要在渲染管線之後一個頂點一個頂點地計算.對於被剪裁掉的物體都不會將其送入顯卡(譯者:那是...被剔除掉的壓根都不用渲染),因此視錐剔除對渲染速度有巨大的改善,畢竟什麼都不渲染是最快的渲染... 閱讀全文 [...]