|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
| autor |
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
23.05.2010 16:46:40
byte array jääb väikseks? |
|
|
Kasutan GLubyte massiivi, et hoida arve 0-255 (terrain heightmap). Kuni 255x255 maastikuni toimib käik hästi, aga alates 256x256 jookseb programm kokku. Tundub, et pole rohkem ruumi andmeid rohkem salvestada.
GLuint ja GLfloat kasutades aga tekivad imelikud seosetud arvud massiivi.
Mis võimalused oleks 1024*1024 arvu hoida massiivis, mis algselt on unsigned byte tüüpi?
GLubyte *data0 = new GLubyte[width*height*3 + 2]; // Piksli 3 värvi hoidmiseks
GLubyte *data = new GLubyte[width*height + 2]; // Grayscale ehk lõplik massiiv
ilCopyPixels(0, 0, 0, width, height, 1, IL_RGB, IL_UNSIGNED_BYTE, data0);
ilDeleteImages(1, &texid);
data[0] = width;
data[1] = height;
for(int i = 0; i < width*height*3; i+=3) {
data[i/3 + 2] = 0.3 * data0[i] + 0.59 * data0[i+1] + 0.11 * data0[i+2];
} |
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
 |
Ohohh
Kreisi kasutaja
liitunud: 13.09.2003
|
|
23.05.2010 19:19:06
|
|
|
| Tee üks pointerite massiiv suurusega 0..1023, kus iga element viitab massiivile 0..1023, siis saadki 1024x1024 kuid mälu ei pea ühe tükina olema.
|
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
6 |
|
| tagasi üles |
|
|
Supiplex
HV veteran
liitunud: 11.12.2002
|
|
24.05.2010 10:05:04
|
|
|
Massiivi võid sa teha ükskõik kui suure hoolimata sellest mis tüüpi elemendid seal sees on. Bool, byte, int, float - miski ei takista sind tegemast neist 1024*1024 massiivi kui mälu jagub. Muide - kas muutujad "width" ja "height" on 32-bitised? Kui nad on näiteks 16-bitised, siis tekib nende korrutamisel väike overflow.
Üldiselt kasutatakse selliste probleemide puhul debuggerit. Soovitan soojalt programm debuggeris käima tõmmata ja vaadata kas juhtuvad sellised asjad nagu sa ootad.
_________________
The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions. |
|
| Kommentaarid: 38 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
34 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
24.05.2010 12:38:27
|
|
|
| Ohohh kirjutas: |
| Tee üks pointerite massiiv suurusega 0..1023, kus iga element viitab massiivile 0..1023, siis saadki 1024x1024 kuid mälu ei pea ühe tükina olema. |
Tõsi kuid sellisel kujul on andmeid üsna keerukas videomällu transportida.
Muidu ühinen Supiplex'i arvamusega, kui width/height on midagi muud, kui 32bit int tüüpi siis tõenäoliselt tekib viga nonde overflow'ga.
Huvi pärast küsin, et miks massiivide loomisel on seal nood lisa +2 elementi? Kui kardad overflow pärast siis sellisel viisil sa lihtsalt peidad vigu kuigi peaks koodi kirjutama nii, et overflow'd ei saa tekkida.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
|
25.05.2010 09:40:34
|
|
|
| GLuint ongi 32-bit integer, GLubyte aga 8-bit integer. Tõsi, võtsid selle +2 maha ja midagi ei muutunud.
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 09:56:53
|
|
|
| asjameez kirjutas: |
| GLuint ongi 32-bit integer, GLubyte aga 8-bit integer. |
Seda küll kuid mis tüüpi on su width/height muutujad? Kui nad on gl(u)byte siis nende korrutamisel tekib overflow ning saadki vale suurusega massiivid.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
|
25.05.2010 10:06:35
|
|
|
| Ho Ho kirjutas: |
| asjameez kirjutas: |
| GLuint ongi 32-bit integer, GLubyte aga 8-bit integer. |
Seda küll kuid mis tüüpi on su width/height muutujad? Kui nad on gl(u)byte siis nende korrutamisel tekib overflow ning saadki vale suurusega massiivid. |
Pikkuse ja laiuse saan nii:
GLuint width = ilGetInteger(IL_IMAGE_WIDTH);
GLuint height = ilGetInteger(IL_IMAGE_HEIGHT); |
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 10:19:40
|
|
|
Debuggerit proovisid et leida mis koha peal täpselt kokku jookseb? gcc'l ja msvc'l baseeruvad kompilaatorid-ide'd omavad kõik suht-koht asist debuggerit.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
|
25.05.2010 11:35:43
|
|
|
| GDB ei näita midagi.
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 11:40:41
|
|
|
kui crashib siis peab näitama. Kui ei näita siis kasutad gdb'd valesti.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
THNS
HV vaatleja
liitunud: 12.05.2010
|
|
25.05.2010 12:11:57
Re: byte array jääb väikseks? |
|
|
Mälu küll ei tohiks puudu jääda, aga saad kindlaks teha selle kui paned "new" try catch blocki sisse.
try
{
GLubyte *data0 = new GLubyte[width*height*3 + 2]; // Piksli 3 värvi hoidmiseks
GLubyte *data = new GLubyte[width*height + 2]; // Grayscale ehk lõplik massiiv
}
catch( const std::bad_alloc& e )
{
//mälu otsas kuskil räme memory leak
}
|
Suurem tõenäosus on, et saad GL funktsioonides vastu pükse. Vaata compileri warningud üle!
|
|
| tagasi üles |
|
|
Supiplex
HV veteran
liitunud: 11.12.2002
|
|
25.05.2010 13:01:13
|
|
|
| asjameez kirjutas: |
| GDB ei näita midagi. |
Ei, oma tarkusest ta väga palju ei näita - kuigi karmi pange (exception või segfault) peale laseb vist vähemalt stacktrace välja. Sealt saab välja lugeda, mis kood täpselt ennast täis situb.
Debuggerit tuleb kasutada. Enimlevinud nipp on panna breakpoint umbkaudu paar rida enne seda koodi kus sa kahtlustad crashi (või kui stack trace on sulle täpse reanumbri öelnud, siis kasuta seda). Siis lased programmi debuggeris käima, mispeale ta lippab kuni breakpointini ja seiskub soovitud real. Seejärel jooksutad ühe rea haaval kuni leiad selle rea kus crash tegelikult toimub. See on esimene ja kõige kasulikum vihje vea leidmiseks. Reeglina on programm selleks hetkeks juba nii perses, et kohalikest muutujatest midagi head välja lugeda ei anna. Siis tuleb operatsiooni uuesti alustada ning seekord panna breakpoint vahetult enne crashi rida. Siis tuleb programm jooksutada sinnamaani ja uurida, mis tegelikult toimub enne kui pauk käib. Uurid kohalikke muutujaid, kui toimub mingi funktsiooni väljakutse siis kindlasti vaatad selle argumendid üle, astud sinna sisse ja vaatad mis toimub, kratsid kukalt jne.
_________________
The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions. |
|
| Kommentaarid: 38 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
34 |
|
| tagasi üles |
|
|
THNS
HV vaatleja
liitunud: 12.05.2010
|
|
25.05.2010 13:29:52
|
|
|
Teine asi mis mul meelde tuli on see, et kui muutuja width on unsigned char ja sa omistad talle väärtuse 256 siis mällu jääb väärtus 0 kuna unsiged char limiit on 0 - 255. Isegi kui ta ei ole unsiged char jama tekib ikkagi kui
|
|
| tagasi üles |
|
|
blinx
HV vaatleja
liitunud: 28.11.2009
|
|
25.05.2010 15:21:37
Re: byte array jääb väikseks? |
|
|
| THNS kirjutas: |
Mälu küll ei tohiks puudu jääda, aga saad kindlaks teha selle kui paned "new" try catch blocki sisse.
try
{
GLubyte *data0 = new GLubyte[width*height*3 + 2]; // Piksli 3 värvi hoidmiseks
GLubyte *data = new GLubyte[width*height + 2]; // Grayscale ehk lõplik massiiv
}
catch( const std::bad_alloc& e )
{
//mälu otsas kuskil räme memory leak
}
|
Suurem tõenäosus on, et saad GL funktsioonides vastu pükse. Vaata compileri warningud üle! |
new võib throw-ida alles siis kui eraldatud mälu on "katsutud", st. kui tegelik alloc toimub.
_________________
'Just buy everything then you're safe' |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 15:27:49
|
|
|
Enne kui new sul exceptioneid viskama hakkab on su kõvakettale tekitatud mõne giga jagu swap'i ning masin niigi suremise äärel. Exceptionitega mälu probleemide otsimine on üsna lootusetu üritus ning annab kasu ainult siis, kui on võimalus et pärid mälu liigsuurte tükkide kaupa. Kuigi sel puhul on lihtsal kontrollida, kas tagastati korralik pointer või null.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
THNS
HV vaatleja
liitunud: 12.05.2010
|
|
25.05.2010 15:42:13
|
|
|
| C++-s new ei tagasta kunagi null pointerit v.a siis kui sul on märgitud notthrow või new operaator on overloaditud.
|
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 16:00:13
|
|
|
| THNS kirjutas: |
| C++-s new ei tagasta kunagi null pointerit v.a siis kui sul on märgitud notthrow või new operaator on overloaditud. |
Tõsi, kuid minu mäletamist mööda on defauldis notthrow sisse lülitatud ning, et new/delete hakkaks exceptioneid loopima tuleb need välja lülitada.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
|
25.05.2010 18:44:24
|
|
|
| THNS kirjutas: |
Teine asi mis mul meelde tuli on see, et kui muutuja width on unsigned char ja sa omistad talle väärtuse 256 siis mällu jääb väärtus 0 kuna unsiged char limiit on 0 - 255. Isegi kui ta ei ole unsiged char jama tekib ikkagi kui
|
Tabasid naelapea pihta  cout'idega debugides jõudsin lõpuks sinnamaale. Veel pole aga leidnud moodust, mismoodi number 256 ja suuremad sinna data-massiivi saaks panna...
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
|
-ordi-
HV vaatleja
liitunud: 03.06.2009
|
|
25.05.2010 19:18:52
|
|
|
| asjameez kirjutas: |
| THNS kirjutas: |
Teine asi mis mul meelde tuli on see, et kui muutuja width on unsigned char ja sa omistad talle väärtuse 256 siis mällu jääb väärtus 0 kuna unsiged char limiit on 0 - 255. Isegi kui ta ei ole unsiged char jama tekib ikkagi kui
|
Tabasid naelapea pihta cout'idega debugides jõudsin lõpuks sinnamaale. Veel pole aga leidnud moodust, mismoodi number 256 ja suuremad sinna data-massiivi saaks panna... |
Miks sa gdb ei kasuta? Ise olen sellega KWini debuginud. Mis asi see cout'idega debuggimine on?
Gdb ise lambist ei näita midagi.
http://www.ibm.com/developerworks/library/l-gdb/
|
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
|
virus152
HV vaatleja
liitunud: 05.03.2009
|
|
25.05.2010 20:25:38
|
|
|
| Ho Ho kirjutas: |
| THNS kirjutas: |
| C++-s new ei tagasta kunagi null pointerit v.a siis kui sul on märgitud notthrow või new operaator on overloaditud. |
Tõsi, kuid minu mäletamist mööda on defauldis notthrow sisse lülitatud ning, et new/delete hakkaks exceptioneid loopima tuleb need välja lülitada. |
Vastupidi, vaikimisi pillub erindeid ja nothrow'ga lülitad ümber.
http://www.cplusplus.com/reference/std/new/nothrow/
|
|
| Kommentaarid: 2 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
2 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
25.05.2010 21:58:47
|
|
|
| asjameez kirjutas: |
| Veel pole aga leidnud moodust, mismoodi number 256 ja suuremad sinna data-massiivi saaks panna... |
Pigem on küsimus et miks sa tahad üldse hoida oma heightmap'is tollesama heightmap'i dimensioone. See karjub igast kandist "disainiviga".
Kui väga tahad ikkagi seal suuremaid väärtusi hoida siis on see võimalik kuid enne kui seletama hakkan tahaks kuulda põhjust miks seda tarvis on 
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
asjameez
Kreisi kasutaja
liitunud: 10.12.2006
|
|
26.05.2010 09:34:48
|
|
|
Lahedus leitud!
Tegin maasiku jaoks omakorda eraldi klassi 'Terrain'.
Ütlen Terrain klassile, et loe sisse heighmap pildist andmed. Andmed ning dimensioonid salvestatakse Terrain klassi muutujatesse.
Järmisena ütlen Terrain klassile, et joonista mulle maastik. Terrain klass joonistab siis eelnevalt salvestatud dimensioonide ja andmetega maasiku.
Tänud kõigile, kes lahenduse leidmisel kaasa aitasid
|
|
| Kommentaarid: 63 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
61 |
|
| tagasi üles |
|
|
|
:: KKK
:: otsing 
:: statistika
:: kasutajate nimekiri
:: kasutajate grupid
:: registreeri
teata moderaatorile
