Navigation


SEARCH: 統計



全部類型 | 遊戲 | 技術 | 新聞 | 軟體 |

好玩的東西~

0000-00-00, 夕姛菪姬,

站長在翻閱 MSDN 時看到的東西 ~ Windows 16 bit核心 與 32 核心 的 Utf 比較表~

很久以前站長畫的圖

0000-00-00, 夕姛菪姬,

隨便看看即可(用小畫家畫的)

三個小突破

0000-00-00, 夕姛菪姬,

最近這幾天,站長因為工作到了一個段落,且學校剛好也放寒假。所以這幾天就拿出過去開發時有遇到瓶頸的模組來好好研究。也許是這幾天真的太閒了吧。一口氣開發了三個系列的模組函式,一個是VB6與資料庫的連接模組(並非ODBC),站長覺得雖然VB本身對於資料庫的存取已經是相當的簡單與方便了,但是站長這人就是覺得還是沒辦法簡單上手所以又自己開發了,一套連接函式 JDB_MODS 但是目前他的資料庫存取功能雖然都已經有經過簡單的測試與最佳化。不過並還沒有透過他來開發任何商業用的大型程式,所以目前該模組還是與JS模組整合在,等未來模組達到一定的成熟度,在將他獨立出來。

另一個是IFV的連接模組,其實PHP本身的GD函式庫本身對於圖像的處理已經算是相當的完整,不過對於大量的圖像轉換與簡單的像素最佳化,其實對PHP這CGI程式語言來說,是沒必要的也是很難達到的。所以絕大多數的功能事實上還是利用前端程式來處理比較恰當。例如像素的縮減、批次的大量點陣圖最佳化等。不過既然是CGI怎可以用前端呢?於是一開始站長嘗試將CGI透過DOS的BATCH來連接前端IFV核心,雖然功能正常,但是BATCH只能傳遞命令與參數,卻無法將錯誤回傳,簡單說在IFV處理圖像的時候,如發生錯誤,前端如需等待回應,而後端又沒辦法模擬人工回應的時候,將產生IFV整個死機的狀態。後來站長就開始在BATCH傳遞命令前,先用PHP的IS系列指令組合,盡量排除有可能發生的任何錯誤,研究IS模組的同時,突然發現,其實如果直接透過PHP來傳遞IFV控制指令與參數,其實也可以,於是將整個連接模組整個重新設計,終於將這個系列模組整個設計完成(一個錯誤排除模組、一個命令解釋傳遞模組)。

另一個突破是一個最早在SAMBAR就知道的毛病,就是C&S資料傳遞的時候,檔案超過1~2MB的同時,伺服器將拒絕傳回任何資料,甚至連錯誤訊息都沒有傳回,也因為錯誤訊息沒有回傳,所以站長一直以來都無法解決該問題,只能告訴自己,這是系統自己的核心限制,雖然後來有參考別人的使用與相關白皮書,但是所有文獻都沒有提到該硬性限制,在SAMBAR官方未提出一個具體的解決方案前,站長就把這問題給擱置了,但是最近站長又拿到SAMBAR官方發布的63B2的版本,於是馬上測試,該問題是否存在。遺憾的是,該問題還是由50R一直到63B2都還是存在的。於是站長把整個SAMBAR的可設參數全部研究一番。最後在主設定參數檔中,找到了解決方案。這時候站長心想,該不會這問題事實上在50R早就可以如此解決吧,於是站長立刻拿出60R的版本出來。果然!60R在相同的設定之下,也解除了該硬性限制。暈。這設定與問題站長在網路上常常看見有其他使用者提出,但是卻沒有任何人有具體的解決方法(包含官方)只能說...汗顏!

一個剛寫好的小玩具~ VNS

0000-00-00, 夕姛菪姬,

這程式"簡單說" 就是加強OS底下的NETSTAT功能,並可以偵測、統計、通知使用者。在通知前,也可以經過使用者所設定的篩選機制進行設定,功能還算滿多的,且這是一個綠色軟體(免安裝、單一執行檔),檔案才30K。

有興趣的按我下載

網站更新

0000-00-00, 夕姛菪姬,

最近站長收到了一些支持與給站長加油打氣的信件,覺得滿開心的。多久沒收到類似這樣的訊息呢?信件中也提到希望VCE能夠繼續持續更新與修正,其實目前VCE在單機遊戲修改上已經算是相當完美了,僅剩下有關網路相關模組,還有相當大的改進、最佳化空間。拿出過去看過的一些程式文獻報導,突然想起一句在程式設計界相當有名的一句話:「最佳化阻礙演化」這句話相當有意思,有時候程式設計師會為了讓某模組達到最高效能,而將此段程式碼透過不同、專屬的最佳化寫法重新設計,導致未來程式整體更新時,會造成設計師一個巨大的阻礙。話說VCE後期的版本,都是如此不是嗎?"最佳化在最佳化".. 卻沒有"演化"過。

這幾天站長拼命研究有關DIV與TABLE的替換、差異性,只為了提高整個前端程式的執行效率,有時候較多的程式碼不見得會讓執行效能便慢,有時反而會有較高的執行效率,不過相對的程式會變大、變得複雜與難以演化,但是取捨之下也許是效能比較重要吧。持續努力、持續研究─

共勉之

站長近日雜談

0000-00-00, 夕姛菪姬,


近站長除了持續開發有關DB延伸軟體以外(工作需要),也有在開發N-BAI(DB衍伸軟體),不過N-BAI部分也因為近日太過於忙碌,暫停開發了。至於VCE... 好久沒動工了,不談也罷。

知道為什麼,站長最近"超"容易動怒,常因一些小事而大發脾氣,朋友跟我說「事出必有因」。於是我開始推敲:
一、我有沒女友哪來感情問題;
二、學校課業成敗我根本一點不在意被當我也不會心痛;
三、職場上爾盧我詐也是司空見慣應該也不是。
同學說也許是我"更年期"到了,所以才會如此吧!(哈)我深信不疑呢。

所以最近站長都超早就寢,因為懷疑是因為睡眠不足吧(但是以前我每天只睡一小時也不會有此情況?)。難道真的是更年期到了?不過就算早早躺到床上,但也都是在床上翻來覆去睡不著。

顯卡大戰

0000-00-00, 夕姛菪姬,


緣起

還記得筆者的第一張顯示卡當時是 ET4000 ,當時顯示卡並沒有所謂的3D加速功能,僅靠上面的簡單積體電路作個輸出介面罷了。話說當時也並沒所謂的3D遊戲。筆者的第一張3D加速卡是SIS6326,這張顯示卡是AGP規格的第一張顯示卡,雖然號稱支援硬體加速,但是這張顯示卡卻連DX7的規格都無法滿足。第一張"能看"的顯示卡是MX200(NVIDIA) ,筆者購入此顯示卡時雖然NVIDIA早推出MX400(64MB版本),但當時主流的遊戲是CS,且筆者升級顯示卡主要是用來讓PS模擬器(EPSXE)與N64模擬器順暢執行,另一原因是MX200與MX400的價格差異不小。後來這張顯示卡也伴隨我好多年。直到FX5600的推出這張顯示卡終於除役。

FX5600以後筆者對於顯示卡的了解越來越多,筆者慢慢開始升級自己的配備,記得當時FX5600筆者是將他裝載P3-500 的主機上,效能幾呼完全發揮不出來。於是將整套系統完全升級為C2.2G + 512MB 的記憶體,才開始感受到 "FX" 的威力。沒多久,又投入5700 的懷抱,最後在6600的6X系列推出之下,5系列完全無招架之力,尤其是在DX9.0C下5系列簡直由跑車變成腳踏車,除非玩家願意將這些"C"的特效關閉。但6600的顯示卡價位上實在是太廉價了(大約台幣3500)在DX9的表現上大約與 5950 差不多。但是DX9.0C上卻超越3倍以上的效能。玩家要注意的是5950價格大約在5000左右。相較之下6600幾乎是現在玩家的首選。

近期大戰又起

唯一能跟NVIDIA抗衡的ATi近日動作頻頻,雖然當時有推出同等級的X 系列打算與NVIDIA的6系列對抗,但不管是價位、效能、CP值都還是以NVIDIA 6600較佔優勢,且因有滿多玩家都知道6200有機會可以刷成6600(6200大約台幣2000元,但後來此密季被公佈後6200價格飆漲,但CP值相較之下還是相當高),於上個月ATI又發布 XK系列顯示卡,一度打垮NVIDIA目前頂級的7系列顯卡,效能上多出10%以上。在上禮拜NVIDIA發布了512位元匯流排板的7800顯示卡與之抵制,又將局勢整個逆轉。

筆者每次看到新的顯示卡的推出,總會覺得有趣。一是又有新的技術與戰況可以觀摩、二是前代顯示卡又要降價了,筆者又有新的顯示卡可以考慮入手,目前筆者最高檔的顯示卡是6800 LE OC 6800GT 的顯示卡,雖然搭配的CPU是2.4G的電腦,但是效能還是相當驚人。7800站長還在觀望,目前筆者手頭上實在沒有任何軟體需要此等級顯示卡阿,何況是7800 512?。

SAMBAR 的一個嚴重 BUG 發現~

0000-00-00, 夕姛菪姬,

SAMBAR 是一套筆者個人很喜歡的一套 WEB SERVER 軟體。不管在功能上、效能上與遠端遙控的介面上,都相當完整。且還是免費軟體。註冊後甚至擁有 MAIL SERVER 的功能。所以站長大多數都是用此軟體來架設網站。

以往

在遠端介面操作時,常常會發生一個很奇特的現象!就是遠端遙控重新啟動時!會發生無法啟動的情況,過去筆者發生此情狀只能把CONFIG.BAK 復原回 CONFIG.CFG 即可改善,但是次數一多也讓筆者開始頭痛不已.. 。於是站長就把發生問題的CONFIG.CFG 與 CPONFIG.BAT 透過 FC 進行交叉比對。FC很快就找出兩者的錯誤處...

令人傻眼

的問題是,想不到問題竟然是出在 "自動搜尋省略符號庫" 。 CONFIG.CFG 裡面有一個程序式,用來記載,有哪些符號需要執行而哪些則省略。相對的有許多控制符號,是SB(以下SAMBAR簡稱SB)不允許當作搜尋關鍵字的,舉例如:退位符號... 等等。這些符號如果當作搜尋條件,往往會發生許多不預期的情況,針對CONFIG.CFG的如此設計當然是出自好意。但是有趣的情況發生了,這些符號不應該出現在搜尋關鍵,相對的也不能出現在所有的"CFG設定檔"中,也因此造成一個好玩的連鎖反應。

ERROR CODE=ABCDEFG......!@#$%[錯誤CODE]
INDEX CODE=abcde.....

以上兩行設定值乍看沒問題。但是當利用遠端遙控按下SAVE CFG 時!則變成...

ERROR CODE=ABCDEFG......!@#$%[錯誤CODE]INDEX CODE=abcde.....

雖然第二行的設定值被併到了上一行,事實上並不會影響系統的執行。但是如果這時候使用者在次按下 SAVE CFG 則...

ERROR CODE=ABCDEFG......!@#$%[錯誤CODE]INDEX CODE=abcde.....[錯誤CODE]INDEX CODE=abcde.....

且每按一次存檔,就會多出一段... 直到SB的容許錯誤字元最大數達到頂額。然後SB將會無法啟動(傻眼)。
這BUG解決辦法滿簡單的。只要把後面不可視字元給手動移除即可(在管理系統中筆者竟然找不到可以移除的選項,只能用記事本手動到CONFIG.CFG裡面將這段後半段的文字給移除)筆者不知道如此會有什麼延伸出來的後果,但是目前只能等官方自己將這BUG移除了,在官方還沒有採取任何解決方案前,依照筆者的做法,還是最快的解決了吧。

DMS 一個好玩的研究。

0000-00-00, 夕姛菪姬,

DMS (時間管理系統),最近這兩週,應公司程式需要,全力開發此系統。開發期間遇到了許多瓶頸。(自認為自己是第一個需要用到此系統模組的,開發前沒到古狗爬文,全部自己摸索開發)很多時間準位都不是很準確。可笑的是開發完畢後才發現,古狗裡面就有一堆參考資料(笑~這兩週我都在做什麼~)。

時間管理系統,顧名思義就是針對時間做管理。(如回到前一天、後一天之類的),目前開發完成度沒辦法作細部微調(如前一小時、後一小時),反正這功能現階段運用的到的部分只需要前推後推以(DAY)為單位。該系統算是已經設計完成了,雖然BUG應該是有的,不過這系統已經很方便操作者使用。(整個核心相當的小,搭配其他系統應該都有不錯的效果)。例如搭配衛星定位監控系統(GPMS)之類的,透過DMS作Z字比對,應該滿有趣的。

提外話:作者上班、上課、開發程式。最近計算下來竟然每天只睡3小時左右。(頭暈)

加記憶體?還是買顆超高速硬碟?

0000-00-00, 夕姛菪姬,

「為何我的電腦一進入遊戲就會硬碟狂讀」

「阿!你的記憶體才256MB 。至少要加到512跑XP+GAME才會順...」


樣的話語,在過去一、二年內屢見不窮。但在2005年的現在,記憶體一條512DDR不過1,500元低價。許多新裝機玩家,絕大多數都是直接在添購新電腦時,直接買兩條256DDR再加上雙通道的加持,跑起現在絕大多數的作業系統、遊戲都是絕對沒問題的。

還記得在4~5年前,當時的電腦都是128MB左右呢!(當時128約台幣1,200左右,能加到256MB 的玩家幾乎等同於現在的1G等級~)。隨著現在遊戲對於遊戲中的貼圖、互動物件(非實體物件)的增加,對於顯示卡、電腦延伸記憶體的需求越來越大,目前市面上已經出現需要2G記憶體才能跑出好成績的遊戲出現!

示卡記憶體部分,目前已128MB為主流較多但事實上對於顯示卡而言如不開啟FA/AA或者將遊戲解析度設定為1,600 * 1,200 對於現今的遊戲而言對於顯示卡的記憶體需求顯然比不上,顯示卡上的DX支援度、時脈與光影、粒子管線數來的重要,對於這方面的技術可以找到滿多文獻的,本章就不綴談。

業系統(以MICROSOFT WINDOWS為例)目前針對記憶體的不足,常態解決辦法,就是自動增加虛擬記憶體(以下簡稱VM)。所謂的VM,就是在硬碟等非抽取是儲存裝置上啟動一個檔案區塊(這區塊不一定是連續區塊),作為記憶體的對照區,但由於硬碟速度往往(絕對?)比不上記憶體讀寫速度所以在記憶不足的情況,遊戲對作業系統提出記憶體不足需求,作業系統及時啟動VM後,遊戲、程式效能會即往直下,雖然目前微軟的純32BIT作業系統的新VM技術可以,由背景快速統計出最少使用的服務、驅動裝置,在適當的停止、移動與選擇適當記憶體區塊之下效能已比非存量32BIT時的VM獲得更多的反應時間,但隨著存量的32BIT作業系統增加的新功能與支援更多的硬體裝置情況之下,對於記憶體(VM?)的需求不減反增?這就是為何以前的WINDOWS 98 在不考慮大型應用程式以外只要64MB的記憶體即可順暢執行、而現在的WINDOWS XP 專業版卻在擁有256MB記憶體下仍有不足之窘境。

買大量的記憶體是否為,唯一避免作業系統對VM的濫用(?)的唯一解決方案?最近筆者在網路上找到的滿有趣的文獻資料,即是探討這問題!
隨著現在的硬碟速度越來越快已由ATA120演進至"所謂"的SATA,轉速也由7,200轉提升到了12,000轉(相對的溫度也跟著演進阿.笑)但是唯一不變的即是售價!目前一個7,200轉 8M 快取的 80G硬碟,玩家只要花費1,500至1,800元台幣即可購進。但是如果玩家想要將記憶體增添至 80G 需要消瘦多少荷包呢?撇開目前記憶體製程與主機板記憶體擴充能力。假定一個主機板上裝上80支1G的記憶體,初步估算,大約要28萬元台幣(但條件只建立在廠商能提供可插"80支"DDR記憶體主機板)。

恆不變的道理,記憶體速度一定比硬碟快,雖然未來硬碟(機械?)一定會比現在的硬碟更快,但是未來的今天記憶體已經能到達何種境界呢?這並不值探討,先前說過了這可以說是永恆的道理,畢竟電子的"溫度耗損"問題比機械所造成"磨損耗熱"問題簡單解決多了。至少現今的技術而言是如此。

到正題,上一段似乎是天馬行空了些,畢竟在至少4~5年內,是遇不到有軟體、電玩遊戲高達80G的記憶體需求!但是對於要求在2G~4G的遊戲,相信在2年內將陸續推出,相對到時記憶體在售價上4G的記憶體,也許只要2,000元不到呢。另一個上面有提到的殘酷訊息,目前的主機板低階系列絕大多數是2~3個記憶體擴充位置,高階則以4~6個較多,如果現在玩家已在上面插上2條512MB記憶體來踏入雙通道環境,剩下的記憶體空間究竟能有多少擴充能力?

個好玩的文獻?VM的定位!如果玩家想在128MB記憶體的硬體環境,打開2G 的VM,想跑順"戰地風雲2"等先進遊戲,基本上是完全不可能的(就算裝上兩張7800 跑SLI 在加上 FX57也不可能),舉例:對於戰地風雲2這類需求在2G的遊戲,如果玩家只有1G的記憶體,有下列三個解決方案:

1. 關閉遊戲的特效,但這僅能治標不能治本!
2. 在添購1G的記憶體,加裝至2G。這是較直接的解決辦法!
3. 購買一顆 80 G 高轉速硬碟專門用來跑VM~

第三種方法顯然是一個相當特別的解決方案。雖然方案二相當直接,但往往在添購了記憶體後將主機板記憶體擴充位置差滿後,在未來又有新遊戲的推出,又將自己綁死。只能對著已插滿的記憶體擴充插槽哭泣。試算!1G的記憶體大約售價在3,500 至 5,500 不等。而80G的硬碟卻能在2,000元以內的價格入手!除了價格上佔盡優勢以外。價格上換取的"空間"差距也相當驚人。至於速度!硬碟當然不能與記憶體與之相比,如我玩家朋友們常說的「這是一種迷思」。在已搭配1G記憶體的電腦上跑這些"超大型"遊戲,其實真正所需的交換VM並沒有想像中如此頻繁。且遊戲中的材質記憶體就算在有256BIT的傳輸管帶幫助下,要將這些隨便超過40~50MB的材質資料交換至顯示卡,這些時間其實早已大過於那些VM交換時差(指有1G的實體記憶體)。剩下的差額時間,事實上只要透過,一顆專門跑VM的硬碟,即可禰補1G的差距。

論:如果在短少的記憶體(512MB以下),直接添購更大的記憶體硬體是無庸置疑的。但是如果玩家的記憶體已經是1G甚至是1.5G、2G。如果要繼續添購記憶體,不妨考慮使用獨立硬碟加上VM來加持吧!

透過獨立的VM硬碟,加上1G的實體記憶體,很輕易跑出近2G記憶體的狀況。

現在的硬碟是相當廉價的。

<< 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 >>

會員登入

帳號
密碼
二段
忘記密碼 | GUEST | OSS

功能選單




相關分站


好站連解


線上會員[1]