看板 ToS 關於我們 聯絡資訊
手機回文 印象中好像在板上看過不少次相關討論了 覺得好像可以來簡易科普一下 不知道發了會不會有點掃興,不過還是簡介一下 關於算術這件事情,其實就理論而言都很理想跟直觀 但真的牽扯到實作的時候,就會衍生很多細節 先來簡單舉個例子: 假設現在要做算術運算,而你只有一張紙 上面只有10個格子,而且你只能寫下0-9 最直觀的方法就是寫下多少就是對應的十位數整數 然後此時就可以推論出一些限制: 1. 範圍為0-9999999999的整數 然後就會問說,那負的怎麼辦? 所以我們把第一格寫1表示負0表示正 於是範圍變成 -999999999~999999999 雖然可以表示負數了,但最大值也被壓縮 但可能目前實務上不太可能超出上下界 於是乎開發人員就這麼決定了表示式 而過了好幾年,數字運算上開始會有超出範圍的需求 可能就會有人提出建議 「用科學記號不就好了,國中沒畢業嗎?」 好的,於是我們改變表示式的定義: 前八碼為科學記號前面的數字,後兩碼為10的次方 比方說 1 2 3 4 5 6 7 8 9 9 表示 1.2345678 * 10^99 若是有負的需求就再讓一格,而這樣改進以後 上下界的範圍被大大提升了,感謝這位聰明的先知 其實類似的概念就是變數型態裡面的浮點數 而為什麼這麼簡單的道理人家卻不採用呢? 現在我們回來思考一個問題: 以上述例子而言,表示式是怎麼對應到值域內的? 十個格子,無論怎麼表示,都最多只能表示100億個數字 而只有整數表示是可以在範圍內全部列舉的 這也是浮點數運算一個危險的地方,精準度 對電腦運算上,(1e50+1) - (1e50) 答案可能不會是 1 通常浮點數也是拿來算個近似值而已 以算傷害的需求而言我想並不太適當 最後做個總結: 1. 數值運算有上下界是因為實作限制 2. 整數運算較具有精準性 但回歸目前的使用狀況,要能不怕超出範圍也不是不可能 定義一個變數型態,然後覆寫四則運算及比較邏輯 讓它可以動態擴張自己的記憶體大小應該就可以達成 畢竟怪的血量目前不會超出int的範疇,而是否打死也只是一個比較邏輯而已 ----- Sent from JPTT on my Google Pixel 2. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 117.19.226.165 ※ 文章網址: https://www.ptt.cc/bbs/ToS/M.1534918416.A.2FF.html
a0193143: 如果傷害沒有膨脹這麼多應該比較不會有這種問題08/22 14:19
drajan: 好像在看我同事的code review 長篇大論一長串(讚美)08/22 14:22
acer5738G: 推一個 不然別人以為我看不懂08/22 14:34
Satansblessi: 長知識了08/22 14:42
elvisleeee: 我是覺得不錯啦樓下怎麼看08/22 14:53
katseng5566: 所以為什麼要用int而不用跟實際傷害顯示一樣的code08/22 15:01
就用int去存阿,不懂你的問題....
peter0627: 我幫樓下問有沒有文組版本08/22 15:01
sanji7700: 推一個假裝自己看得懂08/22 15:07
※ 編輯: tony123930 (117.19.226.165), 08/22/2018 15:17:46
hok: 嗯嗯,跟我想的差不多08/22 15:22
kids1243: 他是說小字已經可以顯示超過21e,max damage卻還是用int08/22 15:22
pippen2002: 長姿勢了!!08/22 15:24
andy19960407: 文組問個,為啥堅持要用int 不用long long之類的08/22 15:30
先回答這個,根據我多年來研究程式心理學 我想答案很簡單: 沒為什麼,也不是堅持 就只是一開始用int去存而已 然後後面code一多就改不太動了 所謂的歷史共業 以往還可以說int記憶體需求比較少,效能會比較好 但在現在一堆硬體效能過剩的時代已經沒說服力了 ※ 編輯: tony123930 (117.19.226.165), 08/22/2018 15:37:27
wizoza77658: 跟資源規劃有點關係,傷害值的資料型態在非常早期就08/22 15:41
wizoza77658: 必須決定,那時無法預測傷害的範圍,為了不知多遠的08/22 15:41
wizoza77658: 將來(誰知道這遊戲活這麼久?)先把傷害值的資料型態08/22 15:41
wizoza77658: 調整成 long 甚至更大範圍,只是浪費手機的資源而已08/22 15:41
wizoza77658: ,因為即使數字很小,花費的空間都是相同的。極端一08/22 15:41
wizoza77658: 點來說,甚至有可能因為這樣的資源浪費,造成某些較08/22 15:41
wizoza77658: 低階的手機無法進行遊戲。08/22 15:41
wizoza77658: 以一個大型project來說,底層的code基本都沒什麼人想08/22 15:45
wizoza77658: 動,因為很容易搞出大問題,比較經典的例子,應該是W08/22 15:45
wizoza77658: oW(魔獸世界)的16格包包問題,有興趣的話可以查查看08/22 15:45
wizoza77658: 。08/22 15:45
其實需求只是要傷害變數需要更大,只有幾個變數改一下應該還好啦 而且我不覺得這個會造成多大的資源影響 大多都是區域變數,是可以回收的
krizarlid: 自己寫個物件然後overload實作operator = =?08/22 15:45
用cpp宣告一個class,裡面存一個vector之類的 然後實作operator,麻煩的地方應該是在進位的部分 至於比較可以把參數設定為int,原本的code就可以維持原樣 只有需要超過int的才需要修改型態
krizarlid: 會造成這樣的原因很簡單 code不是一個人maintain的08/22 15:47
我覺得這個才是主因,他們的code八成很亂吧 再加上這幾年來人可能來來去去的 有時候要找屎code的始作俑者可能都不可考了
krizarlid: 有些東西就是牽扯太多不好改 08/22 15:47
birdjack: 因為不同資料型態之間運算容易出錯,能避免是最好 08/22 15:50
SamFuld: 沒錯,你把我想講的全部講完了 08/22 15:58
rehearttw: 推專業 08/22 16:16
aki1023: 快推免得别人以為我們看不懂 08/22 16:22
wak: 應該很快就會有21億血量的怪,然後21億的防禦,再無視破防.. 08/22 16:56
glassesguy: 假借科普 偷鞭科學記號 08/22 17:06
arsia: 英文系畢業表示完全看不懂 08/22 17:12
※ 編輯: tony123930 (101.11.41.118), 08/22/2018 17:23:02
pdemonq: 無視破防? 傷害盾不就是了嗎?08/22 17:19
wak: 不太一樣。防禦力是牆(低於防禦傷害為0),傷害盾是比例弱化08/22 17:48
bell1708: 資工系大一C語言就教了08/22 17:57
※ 編輯: tony123930 (101.11.41.118), 08/22/2018 18:08:13
omyg0d2007: 推 不明覺厲08/22 18:16
phoenix286: 好奇這種手遊都是用C實作的嗎?我學的code很多都不用08/22 18:26
phoenix286: 自己宣告變數型態08/22 18:26
我印象中他們用的是unity,我沒用過 但我之前用過其他開發框架玩過,是用cpp寫的 ※ 編輯: tony123930 (101.11.41.118), 08/22/2018 18:29:08
y36987412: 左轉code板08/22 18:50
閒聊咩,那些板我很常逛了啦 但倒是沒看過有什麼板真的叫code的 ^^ ※ 編輯: tony123930 (101.11.41.118), 08/22/2018 18:55:27
kimp01pr1nce: 看不懂。先推08/22 18:55
beef68: 其實就是太多了難改 但這個功能應該比小字的晚吧 小字都用08/22 19:01
beef68: 大數存了 max damage沒辦法很怪08/22 19:01
NIKE74731: 整數用int真的很直覺 更何況還比long好打多了 打long還08/22 19:20
NIKE74731: 要動到無名指 超不方便 ㄎ08/22 19:20
surimodo: new int[1000];08/22 19:28
nodnarb1027: 還特別幫那個科學記號同學釋疑,推個08/22 19:38
其實我沒這麼好心,看到的第一眼其實滿反感的 我很不喜歡在那邊裝懂,尤其是還帶著優越感的 一副「這麼簡單你們都想不到」的口吻 實際上更顯露出自己的草率,所以想鞭一下而已
krizarlid: 進位簡單啦 MCU的資料都是兩個8接一起 只是這樣寫有浪08/22 19:46
krizarlid: 費空間的嫌疑 08/22 19:46
krizarlid: 資料沒大到需要封裝 這樣接不是很好 08/22 19:49
特地定義一個class的好處就是,不怕overflow了 總是超出long long都可以保持一樣的精準度 但就是會需要額外動態要記憶體的功
Bensonoc: 嗯嗯跟我想得一樣08/22 19:50
g06cj6: 對於會寫出風暴這種智障技能的工程師,我是不會指望他們08/22 20:19
g06cj6: 能把事情做得多好啦08/22 20:19
麥安內,技能不一定是工程師想的 頂多只能說他們實作的效能很差,以後還得寫上android建議規格
dsa3717: 這是歷史共業 08/22 20:19
chigi: 其實有個很實際的考量,就是畫面長度08/22 21:13
chigi: 在畫UI的時候,上面能夠提供寫數字的範圍是有限的,08/22 21:13
chigi: 位數增加時勢必會讓字體變小或是其他狀況,導致UI效果差08/22 21:14
chigi: 你看他在寫超過21e的時候並不是overflow,表示工程師有考慮08/22 21:14
其實每次超出億的時候我都看不清楚數字,要打上去才知道 有人可以支援超過21億的圖嗎?
chigi: 超過時的狀況,評估結果後捨棄精準的數字 反正這數字只是爽08/22 21:15
chigi: 這樣的UI設計理念事實上很清楚也很簡單08/22 21:16
drajan: 我想樓上是對的 畢竟沒有overflow08/22 21:59
※ 編輯: tony123930 (101.11.41.118), 08/22/2018 23:40:10
krizarlid: 當然 當你的Data因原先的Container總是會有不正常行為08/23 00:06
krizarlid: 本來就需要繼承或定義新的物件來封裝08/23 00:09
krizarlid: 不過我覺得這玩意不太會造成UserConfuse/異常終止08/23 00:09
krizarlid: 也不用這麼認真啦 XD08/23 00:10
krizarlid: 但認真覺得他們工程師蠻混的就是08/23 00:11
BaseGi: 這篇好認真 推一個08/23 01:46
adam8520: 快推 不然別人以為我們看不懂08/23 09:12
omyg0d2007: https://i.imgur.com/69edHi4.jpg 支援超過21億的圖08/24 01:58
啊啊,我其實是說小字或打在怪上的 > <
vwwvwvvvwvv: 推08/24 21:17
※ 編輯: tony123930 (101.11.41.118), 08/24/2018 23:45:45
omyg0d2007: 哈哈 小字的 我暫無存w 08/26 00:34