作者查詢 / VictorTom
作者 VictorTom 在 PTT [ C_and_CPP ] 看板的留言(推文), 共10783則
限定看板：C_and_CPP
看板排序：
全部C_and_CPP10783AntiVirus1060VideoCard420PC_Shopping277ToS260Fund107CFP103Gossiping72Insurance65WorkinChina55Instant_Mess48P2PSoftWare36CD-R27SFFamily27StupidClown26Bank_Service23Soft_Job23FLAT_CLUB13Programming13Ladies_Digi12Steam11DSLR10MIT10MP53-110Windows10Chinese8HCSHch13_3118MATLAB8Wrong_spell8Broad_Band7ECClab7NUU_CSIE7PCSH91_3057GreenParty6TA_AN6LCD5PDA5Rubiks5Stock5Tech_Job5About_Life4AndroidDev4customers4Education4FSHS-95-3084KS97-3104Linux4MCU_Talk4NKUTEE4NTPU-STAT954NTU-EM934NTUBIME-1024Prob_Solve4SYSOP4THUMath954YoungDotx34ASHS-93-li3Browsers3ck-talk3ck61st3213CSMU-CM-OP3CSMU-ST953CYSH97Y3183documentary3EE_DSnP3EMS3Finance3FJU-Law20063GameDesign3joke3KS96-3123media-chaos3NCTU_SP7073NDHU-His1003NTPU-CSIE973NTUIBMB973NYUST97_MBA3RESIT3Sony-style3XBOX3Army-Sir2ASHS-95RN2CodeJob2CSMU-MED952DJ_fightman2Economics2EZsoft2GVOnline2KHCHS-93-3092KS93-3132KS97-3162KS_PMAC2LAW2Math2MEMS424_95th2movie2NCCU_SEED2NIU-ECE94b2NKFUST-CCE902NTHU_STAT942NTU-MJ2NTUCL-BASKET2NTUGIPO_PNSL2NTUT_MMRE862NTUT_MMRE932NUK_AC982NUK_TALK2Orzhong97cl2OverClocking2PLT2SCU_BM_VB2Storage_Zone2TWSU2AD_NCCU_VB1AGEC931Ancient1ASIA-uni1ask1ASM1b974060XX1BadmintnClub1Bunco1C_Sharp1CCSH_91_3151CCSHwindband1Chan_Mou1Christianity1CHSH_98_3011CJCU_HCA981ck49th3101ck56th3151ck58th3041ck58th3121ck59th3061ck61st3241ckbc1cksh84th3121CLHS-50-141clsh-Chung941CMU_BST011CMU_CM43A1CMU_Guitar421CMU_M491CPU_FC7811CSGirl_Group1CSMU-D951CSMU-HSA961CT24th3371CTSH963021DC1DirectSales1Disabled1DPP1DummyHistory1DYU1Employee1ESP1FCU-PF20061FCU_ECON_93B1FCU_ME_99C1FHSH-89-3161FiremanLife1FJU-EE-2004A1FJU-EE-2006B1FJU-EE-COMM1FJU-EE-PIPO1FJU-STAT91B1FJU-STAT95B1Gintama1Hate1HatePolitics1HCHS593051HCHS901151HCHS923131HCU1HLHS_10thU1HRM1HSNU_10081HSNU_10651HSNU_10851HSNU_10911HSNU_10981HSNU_11081HSNU_11091HSNU_11101HSNU_11261HSNU_11671HSNU_9751ILSH-943131ILSH-963131InitialD1KingdomHuang1KMT1kochikame1KOU1KS91-3051KS92-3061KS96-3051KS96-3111KS97-3081KS98-3021KUAS_5880321KUAS_ME94A1LTK1LTSH-963111MartialArts1medstudent1MenTalk1Militarylife1Miracle1Modchip1Mudran1Nantou1nb-shopping1NCCU05_GIDS1NCCU08_Math1NCCU_KungFu1NCCUPHY981NCKU_DAA-991NCU91Finance1NCU_MATH861NCU_ME-94B1NCUECON961NCUT1NCYU_Fst_991NDHU-AIPhy1NDHU-LF981NDHU-PA961NDHU-phy941NDHU-phy991NDMC-M1081NFU-MDE98A1NSYSU-Chem991NSYSU_EE95-11NTHU_COM6071NTNU-HisSB1NTOU-EBFS931NTPU-ACC-BMT1NTPU-CSIE981NTPU-IIM981NTU-K51NTUCB1NTUE-CS991NTUE-DC991NTUE-EPC-971NTUGIEE_AMTG1NTUHorti961NTUICPSC1NTUMEB951NTUMEB961NTUmed911NTUphy961NTUST-EE-A971NTUST-TX-B921NTUST-TX-B951NTUST_ME1NTUST_Talk1NTUT_EE490A1NUTN_SSSS1NUU-EO-97A1NUU_Talk1Odoko-juku1Olympics_ISG1paranormal1Paul_59-1T1PCCU-CS1Pisces1PSJH5-3051PTGSH96-3161PublicIssue1PushDoll1Road1RSSH94_3061SAN-YanYi1San-Ying1SCU_Law101B1SCU_Talk1SCUG1scutran_city1Seiya1SSSH-16th3131SSSH_17th3141Starbucks1StraightMH1TCFSH67th3011TFG08Music1THU-CHE961THU_BA20001TKU_EE_92C1TNFSH98th1Tokusatsu1Transport981TryingTimes1TTU-AFL1TTU-Transfer1TWproducts1UFO1VET_961viatording971VictoryYouth1Warfare1Wine1WuLing46-3171WuLing50-3031WuLing50-3041XiangSheng1You_out1YP94-3101Yup01-041Zastrology1<< 收起看板(310)
2F推:你先單獨印sizeof struct裡的element, 即char/int等,02/25 00:00
3F→:然後再考慮一下struct的alignment/padding的用途, 才能02/25 00:01
4F→:推算出來為什麼在你的平台上你會跑出那樣的結果.02/25 00:01
5F→:如果已經確認了int是4byte, 那請查一下alignment的目的,02/25 00:03
6F→:並不是64bit的platform, struct的size就一定要對齊/為802/25 00:03
7F→:的倍數.02/25 00:04
10F推:噗~~小弟我是沒說原因啊, 不就說了請你去查查了解它嗎XD02/25 01:19
11F→:http://0rz.tw/ySgPF Wiki裡struct alignment的說明:)02/25 01:26
14F推:其實我不太懂怎麼了XD 本來想找中文的, 結果google前幾02/25 01:34
15F→:名都只提到一小部份或講#param pack, 所以只好拉Wiki.XD02/25 01:36
17F推:我想我已經推過了, 沒有規定64bit一定要以8為單位, "最02/25 09:59
18F→:小單位是8"是你錯誤的想法, struct的尾端要怎麼padding/02/25 10:00
19F→:alignment, 在我給的Wiki網頁裡的某一句粗體字說明....02/25 10:00
20F→:"the last member is padded with the number of bytes02/25 10:01
21F→:....", 一行推不完, 剩下的自己去看, 至於源由我想好好02/25 10:03
22F→:看完這則Wiki就應該會懂....02/25 10:03
8F推:N大說的是Gfx HW這端的可能實作方式, 但是spec上並沒有02/23 23:47
9F→:對寫AP的programmer定出這樣的限制; 所以如果真的是N大02/23 23:48
10F→:所提的問題, 那是Gfx的driver或HW沒有處理好這個feature02/23 23:48
11F→:, 這應該是Gfx端的bug. 所以請問原po用的顯示卡與驅動程02/23 23:49
12F→:式版本.02/23 23:50
13F→:啊, 看到是86GTS了, 先試著換driver到新一點的版本試試,02/23 23:51
14F→:(但不要到最新, N家A家的最新版驅動對舊世代顯卡通常都02/23 23:51
15F→:不是最佳的); 如果可以的話找不同家顯卡或不同世代的卡02/23 23:52
16F→:也交叉測試看看. (當然檢查NPOT的支援還是要做的XD)02/23 23:52
17F推:剛發現漏了一個盲點, 程式錯誤要關閉前有訊息告知你錯誤02/23 23:58
19F→:的module是哪個嗎??或者可以看看windows的事件檢視器.02/23 23:59
20F→:主要是希望釐清問題是texture餵給GL畫以後才發生, 還是02/24 00:00
21F→:讀/解圖檔的時候使用的lib或中間自己處理的code有疏乎:)02/24 00:00
26F推:0xC0000005嗎?? 這個比較像是您的code或其他SW的lib端出02/24 00:07
27F→:錯ㄟ.... 啊, 不好意思, 不小心斷到....Orz02/24 00:08
29F→:疑!?原來沒斷到XD 按下除錯後應該還會有VC的視窗導引你02/24 00:09
31F→:除錯程序, 找找看error發生的斷點是不是你的source code02/24 00:09
32F→:不是的話, 就看一下執行位址(就是0573FC29), 在VC的02/24 00:10
33F→:module list頁籤裡, 是屬於哪一個.exe或.dll的.02/24 00:10
36F推:查一下call glTexImage2D這行時傳進去的圖檔指標, 算一02/24 00:18
37F→:一下 0x0e00c001 是不是正好超過你傳進去的圖檔所佔記憶02/24 00:19
38F→:體的範圍. 不過如果該位址和您傳入的指標距離相差甚遠關02/24 00:21
39F→:係兜不起來, 就比較難辦了XD 不過仍然可以看一下module02/24 00:21
40F→:的頁籤, 看一下 0573FC29 這位址是屬於誰的range :)02/24 00:22
45F推:0x0e開使應該還不到kernel的位址區域吧??02/24 00:29
47F→:請scroll一下module的頁籤向右, 應該會有memory range,02/24 00:29
48F→:只是看起來似乎是NV的OGL driver出包機率比較高@_@"02/24 00:30
50F→:順便請教您的圖傳入glTexImage2D時的address值:)02/24 00:32
51F→:雄雄發現, nv的dll都是0x69開頭, 出錯的位址不像它了Orz02/24 00:34
53F推:不在圖裡XD 看一下它在誰的range回一下名字就行了XD02/24 00:37
56F→:這....那小弟我只能投子了Orz 介意把程式與當前這張圖檔02/24 00:47
57F→:share出來跑跑看嗎?02/24 00:47
59F推:我只有2005 XD 不過只拿.exe與.bmp的話, 應該VC版本就無02/24 00:56
61F→:關了吧@_@" 不過.exe可能RTL要用沒dll的那個選項build.02/24 00:57
66F→:.Net4好像我在Windows Update就裝過了, VC2010 redist02/24 01:10
67F→:MS不知道抓不抓得到XD02/24 01:10
72F推:對啊, 頗有趣的, 其實小弟對那個0573FC29這個resolve不02/24 01:22
73F→:出的module很有興趣XD 不過, 體力還能撐多久就....Orz02/24 01:22
79F推:個人覺得這裡alignment下1不應該有什麼錯, 另外, 小弟這02/24 02:06
80F→:邊NV 88GT, driver 178.24, XP sp3 32bit, 可以做出一樣02/24 02:07
81F→:的錯誤, 而且錯誤的disasm address還一模一樣. 初步看了02/24 02:08
82F→:一下該段disasm的內容, 的確應該是在搬你的圖檔到某個位02/24 02:10
83F→:址去, 還沒跟到是不是就這樣搬到超過範圍; 不過暫時建議02/24 02:10
84F→:您改借個ATI的平台先測測看....@_@"02/24 02:11
88F推:查了一下, PACK與UNPACK的alignment, 對應到原po的issue02/24 02:35
89F→:應該是glTexImage2D餵進去的圖是3byte緊連的, row與row02/24 02:37
90F→:中間沒有特殊alignment, 所以此時UNPACK的alignment應該02/24 02:38
91F→:設為1, 設成4的話driver會以為來源影像的row有對齊4byte02/24 02:39
92F→:於是這case大概copy到最後幾個row時就超過source範圍了.02/24 02:40
93F→:相對的如果餵入的source有做ROW的2/4/8 alignment, 就需02/24 02:40
94F→:要把alignment設成2/4/8, 這樣driver才會copy到正確的02/24 02:41
95F→:pixels. 小弟以前多是餵3byte不align的texture, 所以02/24 02:42
96F→:alignment自己老設為1, 所以....XD02/24 02:42
97F→:除了GL官網的man page, 剛goo到的這網頁寫的也不錯:02/24 02:43
98F→:http://book.51cto.com/art/200809/88181.htm (簡中)02/24 02:43
99F→:所以這error應該不是driver有錯, 而且glTexImage2D的02/24 02:44
100F→:source的alignment與glPixelStore的UNPACK alignment設02/24 02:44
101F→:定不一致所造成的, 所以改成1能夠解決原po的issue:)02/24 02:45
104F推:確實是不用二維陣列, 但是如果直接把BMP的DIB拿進來用,02/24 09:08
105F→:反而可能需要設alignment為4, 因為BMP的DIB在row上是會02/24 09:08
106F→:做padding的@_@" 不過目前看起來原po處理模式是透過lib02/24 09:09
107F→:把raw直接連續串起來餵給TexImage2D, 所以alignment設102/24 09:10
108F→:以後就能解決了:)02/24 09:10
109F→:PS. 上面這段推的alignment是只GL的UNPACK alignment.02/24 09:11
1F推:關於texture的寬高, 要能使用非2的冪次的texture, 必須02/23 09:18
2F→:要平台支援 GL_ARB_texture_non_power_of_two 這個02/23 09:18
3F→:extension才行, 所以你得先query/parse平台的 extension02/23 09:19
4F→:string, 才知道程式執行的平台上能否使用這種texture.02/23 09:19
5F→:然後, 什麼叫貼某些維度的texture"程式會爆"? 你實驗的02/23 09:20
6F→:"不行"又是怎樣不行?? 建議描述清楚問題的症狀, 如果可02/23 09:21
7F→:以, 用置底的網頁把code貼上來更好:)02/23 09:21
8F→:另外, 有些texture format有寬高的對齊限制, 只是看你的02/23 09:29
9F→:圖如果都是當24bppRGB送應該是還好, 不是的話可能還得寫02/23 09:30
10F→:出texture的source format是什麼....@_@"02/23 09:30
17F推:正確的說是, 你要看你執行程式的平台上支援到OpenGL的哪02/23 23:41
18F→:個版本或哪些extension feature, 你才能使用那些功能;02/23 23:41
19F→:source這邊比較有影響的是你得抓到夠新的gl.h/glext.h可02/23 23:42
20F→:能才會有夠新的feature相關的定義.02/23 23:42
21F推:沒想過函式也可以這樣*, 乍看之下還真像普通array與02/20 23:23
22F→:&array / *array ^[]02/20 23:24
23F→: 的關係@_@" // 怎麼一直漏字Orz02/20 23:25
3F推:也猜MMIO, 也有的是寫了之後馬上讀一次讓HW起作用的樣子02/20 20:53
3F推:不介意的話可以看一下小弟的拙作 #1CH8iM8N02/18 09:24
4F→:推文裡s大也有提到標準裡規定的部份 #18xs7RbK02/18 09:25
11F推:Er~~那個網站的第四點剛好略過了最小正數與最大負數的部02/17 23:45
12F→:份(簡單的說就是從0+到0與0-到0最接近0又非0的數).02/17 23:46
13F→:所以其實並沒有回答到樓主的問題XD02/17 23:46
14F→:denorm的數簡言之就是exp全為0的數, 這時候exp不以bias02/17 23:47
15F→:127的方式做計算, 而是直接以2^(-127)開始再往後算最多02/17 23:48
16F→:22位(扣掉全為0的+-0.0), 所以如果小弟沒記錯的話, 樓主02/17 23:49
17F→:推文說的那兩行應該是對的沒錯:)02/17 23:49
18F→:至少印象中以前用VC測是這樣, 至於是不是by implement就02/17 23:50
19F→:不清楚了; 只是我記得denorm本身也定義在IEEE754裡, 所02/17 23:51
20F→:以推測應該不是by implement才對....@_@"02/17 23:52
25F推:小弟有點疑問, 請問您的轉換公式是?? 查了一下YUV2RGB或02/14 02:24
26F→:反轉, 應該沒有用到branch啊?? 本來猜是不是用全整數運02/14 02:25
27F→:算需要clamp, 可是處理的對象又是source....@_@"02/14 02:25
29F→:啊對不起, 我查到fixed用的公式是有clamp沒錯....Orz02/14 02:27
33F→:疑, 可是查了一下YUV2RGB是clamp結果不是source啊@_@"02/14 02:28
36F→:看到修文了, 不好意思....:)02/14 02:30
38F→:可能從定義域或值域的range來把bitmask設得更精簡嗎??02/14 02:37
44F推:為什麼?? 不是跟負數一樣用個bit array就好了嗎??02/14 02:45
45F→:小弟想到的是 OR 0x00 或 0xFF....@_@"02/14 02:46
46F→:當然8th bit以上要一律AND 0掉, 這樣判斷<0先跑再跑>25502/14 02:47
47F→:應該可以吧....@_@"02/14 02:47
48F→:of=(R&0x0100)>>8; R = (R | bitmap[of]) & 0xFF;02/14 02:52
49F→:of用途同SIGN, bitmap就是bitand_map[]那個這樣@_@"02/14 02:53
54F→:不會啦XD02/14 02:59
60F→:小弟也覺得, 要是有低階指令可以做sat可能是最快的XD02/14 22:00
3F推:http://www.cplusplus.com/reference/02/13 20:34
4F→:http://msdn.microsoft.com/zh-tw/default02/13 20:34
5F→:或者直接一點google函式名, 要找到範例與說明並不難.02/13 20:34
6F→:好/新一點的IDE, 打func name通常參數就自動提示你了.02/13 20:35
13F推:M大是指像會名為 bible 之類的書嗎:D02/14 21:59
1F推:老實說不太懂你的問題, 既然你知道wav的format型態了,02/13 19:23
2F→:也知道size是從第某個byte開始的一組dword, 那你讀檔的02/13 19:23
3F→:時候直接用binary方式讀那個dword, 或者寫檔的時候在那02/13 19:24
4F→:個位址寫入一個dword不就得了?? fread()/fwrite().02/13 19:25
9F推:回去看一下變數定義就被j大搶先了....XD02/13 19:32
10F→:我猜wStyle那個大概也要加 & 才行....@_@"02/13 19:33
13F→:就是像j大那樣加個轉型就是了:)02/13 19:35