Powered by and 圖示來源

2007年12月29日 星期六

幾經修正我後,預想中我的家應該會變這樣...
坪數太小怎麼做都不對,如果再多一坪可以運用應該會差很多..

全視圖

上視圖

前視圖

後視圖


畫完才發現... 阿... 我的電腦要放那?.. 好像只亂放一台notebook
沒有放到我的desktop PC


2007年12月25日 星期二

我的家是挑高套房(星築SOGO)... 但是夾層跟隔間要自行處理
用手畫總是畫不準... 在網路上找畫圖的工具...
居然找到這個好用的免費軟體...

畫好了久...想要在小小的空間硬塞2個房間...而且都配上雙人床..
看來是失敗了...

全圖

上視圖

前視圖

後視圖

整個格局都不對了... 找個時間再畫一次...

最後附上 sketchup 的網址
中文網站 -- 這個網站做的有點遜
英文網站 -- 這個就比較有官方的感覺了


2007年12月21日 星期五

雷曼兔2-五大區都拿到金盃了

美國全破!

美國:
一群死兔子在車上亂跳.
用wiimote瞄準做亂搞的兔子... 左手用力向下甩...
有點像一代的合唱團那關...

吃東西往下面吐. 沒金牌
wiimote 上下快速的晃..吃滿之後左右晃吐出去...
這關很難...

同時間只會有3隻兔子在吧檯上.. 我只吐的到中間的3隻...
中間的3xx分,左右的700分.. 所以快速的吐這三個可以上萬分

記舞步
只有三個動作.. 甩右手 甩左手 跟 A鍵
記到後來會有 ? 出現..
要聽聲音去判斷是上面三個動作的哪一個 然後背下來...

打橄欖球
用左手控制人物.. 甩右手是撲球
拿到球之後就一直跑...最好是跑左上.右下.之類 斜的方向球比較容易拿久一點

把快死的兔子打死
在氣條滿時..把右手快速向下甩... 沒什麼難度...

蜘蛛人
用wiimote控制左右.. 按A把有網子的敵人打下來..
打下來之後換我們有網子.. 左右閃..按A會飛起來...
所以我們可以在2d 的整個畫面運動...

在戲院講電話
白目的兔子在戲院一定是拿手機聊天的...
放映時拿起wiimote 在耳邊作講話姿勢
等戲院管理員過來時快點放下手機..並快速按A

指認犯人
就記憶而已,沒什麼技巧


歐洲全破!
歐洲:
腳踏車比賽
wiimote拿橫的(跟另一個手推車拿直的不一樣),按2是攻擊對手
基本上想拿高分就是把路記熟... 還有不要攻擊對手
攻擊對手.. 對手暈完會在後方... 換他有攻擊權...
要得高分就是要早點到終點... 以不暈為最高原則

冰上吃冰
用左手的控制人物... 甩右手是推人
但是右手推人的效果不大...
要得高分就要趁最右邊的商店開店時搶分
最左邊的店雖然最近但是常常會一堆兔子卡在一起反而不好得分

印度引蛇人
wiimote拿直的... 小心的跟著按不要搶快
穩穩的就能拿金牌... 想衝高分當然要練一下

毒死兔子
一共有3種藥,跟2個顏色所共有6種不一樣的可能
架子上有12瓶藥.. 也就是每種藥各有2瓶
所以要過關.. 就是要靠記憶
我個人記憶不好... 所以都是請人幫忙
一人記黃色3瓶 一人記紫色3瓶

在凱旋門上喝汽水
wiimote拿直的...非常快速的上面搖...
這關只要快... 所以震幅不必太大...
搖完馬上按A... 然後把wiimote拿起做喝的動作
金牌就到手了

下棋
說真的...不知道在搞什麼
每次就是把左右手拿到耳邊等它結束
分數在10000~15000 之間... 不知道差別在哪?


送漢堡(歐洲)
wiimote水平拿... 有點像一點兔腦滾珠的關卡的控制
按A可以剎車... 所以一直走一直按A一步一步走
穩穩的來盡量不要掉東西... 這樣就可以拿到金牌了

貼紙機自拍
wiimote直拿. 揮圈是把人向上調
按A人會向下降...
把人控制在中間偏上一點點...可以拿到近5000的分數


亞洲全破!
亞洲:
打投手
白爛的雷曼兔怎麼可能正正常常的打棒球
一開始我們是投手以跑步的手法上下揮讓投手快速的跑回本壘
也不用太快...只要能量條是滿的就好了 省點力關卡還很多
最後投手飛向本壘時.. 不要急... 它會出現字叫你打
叫你打你才打.. 分數才會高....

河邊洗內褲
雙手前後交錯做洗衣服的動作... 水會慢慢由黑變白
雙手舉起做投降的手勢檢查內褲...
成功就會有分數跳出來... 沒洗乾淨還是洗過頭破了都算失敗
用心算大概洗3秒多一點就可以... 時間抓的好內褲還會洗成亮晶晶的


通馬桶
wiimote拿直的...快速上下震動
在凱旋門上喝汽水的簡化版本

在辦公室搞怪
趁老闆不在上下晃動wiimote
不用太快有數字出來就好... 老闆出來前要停下來
這個多幾次就會習慣

在學校搞怪
這關跟在辦公室差不多...
只是老師轉過來時... 我們要指認是誰在亂搞
不要太早指認... 被最多人指的人會扣分
所以要留下你手上唯一的一票來作票

手推車比賽
wiimote拿直的... 左右偏來控制方向
對手會一直卡過來... 我們要卡回來 以保持不被暈
簡簡單單就拿金牌

辣烤 鴨
辣椒有三種顏色,依辣度排序為紅.黃.綠
盡量把辣吃到滿會有較高的分數..但又不能過辣
甩右手是吃...甩左手是不吃
通常不用甩左手太浪費時間了
紅+綠就可以噴(按A)... 紅的吃了之後手上不是綠的就直接噴
其他綠的跟黃的就自已抓 反正不要丟掉去浪費時間

轉盤子
wiimote拿直的在水平面畫圓...
畫圓的速度要適中..且隨著盤子的數量變多...轉速也不同
轉太快...人物會單手偏右
轉太慢...人物會單手偏左
得高分就要讓人物保持雙手搖盤子


南美全破!
南美:
樂園牛仔騎士
這關很麻煩... 會亂數變換三種手勢
上下動... 快速小小的上下震動即可 一次跳21分
前後動... 快速前後且大幅度的運動 一次跳120分
畫圓... 盡量畫很大的圓 速度不好抓 一次跳400分
想拿金牌... 畫圓這個要畫的很順...

鋸木頭
wiimote拿橫的做大幅度的上下運動..
要又快動作又大... 這樣才能拿高分
很累的關卡

在頂樓開碰碰車
wiimote拿橫的... 按2加速...
想辦法撞對方的側邊加分...如果撞到對方掉下去會再加分

跑給大石頭追
就是一直快速的跑. 沒什麼技巧

送漢堡(南美)
一樣是送漢堡... 技巧一樣...
這次是在高樓上面... 而且要送到對面的客人那邊
所以想辦法走窄的那個路比較快...

西部牛仔的對決
一開始把wiimote放到腰間 然後耐心的等
等他畫面出現"拿槍 and 按B"時才拿槍攻擊
太早拿就算失敗...

吃蝴蝶
用左手控制人物... 按著A不放可以一直吃蝴蝶
找綠的跟黃的吃... 這兩種分數高
如果對手吃到綠的跟黃的甩右手用捕蟲網打它..叫他吐出來
平常沒事吃吃藍的 不無小補

在峽谷中飛行
用右手控制盡量不要撞到東西


熱帶地區全破!
熱帶:
騎蝸牛
跑給大石頭追一樣

燙手蛋糕
跟打橄欖球(美洲)差不多...只是這次是以不拿到蛋糕為主

挖沙子
指著自己的沙坑按A不放... 指到別人的沙坑放開A
連續上述動作... 應該不難...

沙灘西瓜排球
只要是打球通通是右手向下震..
通常球變紅是正確時間點... 按A是跳
所以舉球舉的好...按A跳之後時間點對了右手向下震就會有殺球

引爆炸藥
wiimote拿橫的... 倒數之前引爆
如果能在0.000引爆可以得到五千分

跳垃圾桶
說明是左右手同時向上才會跳
實際操作上...
隨著人物落地雙手也急下然後急上這樣可以常常有噴火跳

四項混合游泳賽
跟著指示變換4種動作... 快速的動就可以超過12000分

頭昏賽跑
wiimote 拿橫的... 沒什麼技巧..
想辦法早點到終點就是


音樂關卡就跟天份比較有關... 沒辦法寫成攻略了~!


最後由一群兔子跳支舞當做謝幕


2007年12月20日 星期四

程式怎麼寫都行,complier看的懂最重要
但是....

如果有一天你寫的程式必需加入到linux kernel (為什麼要機會加入呢? 遇到你就知道了! kernel code)
我在這邊告訴你... 他們對code style是有"龜定"的

在此之外... 很少有單位對code style做嚴格的要求
因此,這唯一的"龜定" 不彷趁早習慣
除非... 抱定一輩子不跟linux kernel打交道的決心 (真這麼有信心? 想想舉手之勞做環保...就這樣想吧!)

好,那就來看看他們有什麼"龜定"吧...!


-------------------以下為原文-------------------
Linux kernel coding style
This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won't force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too. Please at least consider the points made here.

First off, I'd suggest printing out a copy of the GNU coding standards, and not read it. Burn them, it's a great symbolic gesture.

Anyway, here goes:

Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.

Chapter 2: Placing Braces
The other issue that always comes up in C styling is the placement of braces. Unlike the indent size, there are few technical reasons to choose one placement strategy over the other, but the preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first, thusly:

if (x is true) {
we do y
}
However, there is one special case, namely functions: they have the opening brace at the beginning of the next line, thus:

int function(int x)
{
body of function
}
Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are right and (b) K&R are right. Besides, functions are special anyway (you can't nest them in C).

Note that the closing brace is empty on a line of its own, except in the cases where it is followed by a continuation of the same statement, ie a "while" in a do-statement or an "else" in an if-statement, like this:

do {
body of do-loop
} while (condition);
and

if (x == y) {
..
} else if (x > y) {
...
} else {
....
}
Rationale: K&R.

Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on.

Chapter 3: Naming
C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand.

However, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function "foo" is a shooting offense.

Global variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that "count_active_users()" or similar, you should not call it "cntusr()".

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

Local variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next chapter.

Chapter 4: Functions
Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's ok to have a longer function.

However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it that you would have done).

Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things, anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.

Chapter 5: Commenting
Comments are good, but there is also a danger of over-commenting. Never try to explain how your code works in a comment: it's much better to write the code so that the working is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell what your code does, not how. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 4 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly why it does it.

Chapter 6: You've made a mess of it
That's ok, we all do. You've probably been told by your long-time unix user helper that "GNU emacs" automatically formats the C sources for you, and you've noticed that yes, it does do that, but the defaults it uses are less than desirable (in fact, they are worse than random typing - a infinite number of monkeys typing into GNU emacs would never make a good program).

So, you can either get rid of GNU emacs, or change it to use saner values. To do the latter, you can stick the following in your .emacs file:

(defun linux-c-mode ()
"C mode with adjusted defaults for use with the Linux kernel."
(interactive)
(c-mode)
(setq c-indent-level 8)
(setq c-brace-imaginary-offset 0)
(setq c-brace-offset -8)
(setq c-argdecl-indent 8)
(setq c-label-offset -8)
(setq c-continued-statement-offset 8)
(setq indent-tabs-mode nil)
(setq tab-width 8))
This will define the M-x linux-c-mode command. When hacking on a module, if you put the string -*- linux-c -*- somewhere on the first two lines, this mode will be automatically invoked. Also, you may want to add

(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
auto-mode-alist))
to your .emacs file if you want to have linux-c-mode switched on automagically when you edit source files under /usr/src/linux.

But even if you fail in getting emacs to do sane formatting, not everything is lost: use "indent".

Now, again, GNU indent has the same brain dead settings that GNU emacs has, which is why you need to give it a few command line options. However, that's not too bad, because even the makers of GNU indent recognize the authority of K&R (the GNU people aren't evil, they are just severely misguided in this matter), so you just give indent the options "-kr -i8" (stands for "K&R, 8 character indents").

"indent" has a lot of options, and especially when it comes to comment re-formatting you may want to take a look at the manual page. But remember: "indent" is not a fix for bad programming.

-------------------原文結束-------------------
原文載於 : http://pantransit.reptiles.org/prog/CodingStyle.html
其實只要安裝kernel source 都可以找到這份文件!

沒有很難吧....!
看他說的彷彿立意良善....
趁早習慣,有益無害....

有在寫 C 就趁早習慣囉....


2007年1月1日 星期一


nothing






##HIDEME##

##HIDEME##