kép forráskódjának használata

C/C++

Sziasztok!

Azt szeretném megtudni, hogy GIMP ből .c, vagy .h formátumba mentett képet hogy lehet használni a forráskódban? Ha jól láttam, valamilyen struktúrát készít a GIMP kimeneti állományként. De hogy lesz abbol megjeleníthető kép a programban? (SDL-t használok).
Köszi!

  • 3080 megtekintés

( Jason v | 2009. 02. 02., h – 09:36 )

GLibbel tudod használni. (Mivel a GIMP az GTK -s)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

valahol láttam kifejtve rendesen a rövidítést:
GNU is Not Unix Image Manipulation Program Toolkit
Jááj. Ha a G-t mondjuk Gnome-ként bontjuk fel, még jobb…

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( hrgy84 | 2009. 02. 02., h – 09:52 )

Kezdjuk az elejen: szerintem te a xpm formatumra gondolsz, ami valoban egy C-s header file-t jelent. Ezt csak siman be kell #include -olni, es a megfelelo (xpm) megjelenito cuccokkal maris hasznalhato.

De fixme, ha nem erre gondoltal.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Hiena v | 2009. 02. 02., h – 10:35 )

A gimp altal mentett forras != xpm és !=xbm. Elobbi ugyanis egy idexelt ascii kepformatum, tehat forrashoz nem sok koze van, az utobbi pedig egy fekete-feher bitmapformatum C forraskodban.
A gimp altal forrasban mentett adatok emlekeim szerint, a kepnev a
struktura neve, vizszintes meret, fuggoleges meret, a keppontok tombkent, ahol a pixelek rgba sorrendben vannak megadva. (Ezt igy kutfejbol, mert nincs linuxos gep a kozelemeben.)
Ha SDLben akarod hasznalni, akkor kirajzolhatod pixelenkent, pixelszin olvas tombbol -> SDL pixel kirajzol modszerrel, vagy komplett tombkent.
Az otthoni gepemen van egy hackelt peldaprogim ami direktbe X-et hasznal. Keresre, szivesen atkuldom.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Alapban az SDL tud bitmap kepeket kezelni, ezt a SDL_LoadBMP() fuggveny vegzi. Ennek a kimenete egy SDL_Surface tipusu, amit SDL_DisplayFormattal tudsz Image-be atalakitani es utana SDL_BlitSurface()-el es SDL_Flip()-el megjeleniteni. Ha ugyanezt akarod csinalni forrasban levo koddal, akkor vagy Image, vagy Surface tipusura kell atalakitanod amihez pl jo kiindulasi alap, az alabbi linken levo http://docs.huihoo.com/sdl/1.2/guidevideo.html putpixel fuggveny.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Összekalapáltam egy kódot, just for fun:
http://boreger.toons.hu/progi/gimped_SDL_0.0.0.0.1.b.tar.gz

Annyi extra van benne, hogy a kép mentésénél kikapcsoltam a "glib_típusok_használata" és az összes többi szemetet. Ennyi.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Köszönöm! Erre voltam kíváncsi. Miért írtad a forrásban megjegyzésben azt, hogy csúnya kód és élesben ne használja senki? És jól láttam, hogy a Tux bűntény áldozata lett? A másik tipp, az xbm is tetszik. Csinos kis struktúrát készít a GIMP xbm esetében.
--
unix -- több, mint kód. filozófia.
Life is feudal

A pixelenkenti SDL rutinok hivasa rendkivul lassu. Nagyobb kepeknel, foleg ha mozognak (animacio, jatek)iszonyatosan megno toluk a gepigeny.
Sokkal elegansabb, ha a kepinformaciot szepen a atkonvertalja az ember, majd egy pointeratadassal atadja az SDL-nek.
Mivel te eleve forrásbol akarsz grafikus elemeket hasznalni, ezert az lenne jo, ha utanaolvasnal az SDL_Surface struktura felepitesenek es irnal egy kis progit, ami kepes az kimenetkent ilyen forrast generalni. Utana azt siman betudnad illeszteni a programod forrasaba.

A Tux azert lett lemeszarolva, mert hirtelen nem volt jobb otletem rajzolni es nem akartam az egesz tutoriallal egy oranal tobbet veszodni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Köszi! Pont erre gondoltam én is! A képeket a program elején tologatom be a saját surface-eibe és utána onnan dolgozik a program. Viszont azt észrevettem, hogy zabájla a processzort a program még akkor is, ha nyomorult eventre várakozik. Szegény Tux! Azt hittem már rég kész volt az a képed, csak előszedted a "raktárból".
--
unix -- több, mint kód. filozófia.
Life is feudal

Itt Hieana szerintem arra gondolt, hogy ne a progi tologassa be, hanem gyarts egy kis progit, ami eleve olyan forrasfajlokat general ki magabol, amiket csak #include-olni kell, es maris SDL Surface-kepes kepeid vannak.

A procizabalas nagyon sok mindentol lehet. Azt ugye tudod, hogy sima while(true) ciklussal nem illik varakozni? Valami muveletet kell vegezni benne, az if-es ellenorzesen kivul is (idoszamlalo novelese, valamik cserelgetese...), legalabbis regen ez meg igy volt. De en csak megszagoltam a SDL-t, sosem csinaltam benne semmit.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( turdus | 2009. 02. 02., h – 16:33 )

Simán megy.

A lementett képet include-olod, majd csinálsz egy új surface-t (a behúzott w,h változók alapján). Ezután memcpy-val bemásolod a a surface adatterületére a képet (ha jól emlékszem, surface->image, de lehet, hogy surface->data). Kész. Kicsit kell játszani a surface létrehozásakor, hogy ugyanolyan formátumban kezelje az adatokat, mint ahogy átmásolod (nincs alpha, rgb sorrend ilyenek), de ezt csak egyetlen egyszer kell végigjátszani, utánna copypaste. Rég csináltam, de jól működött.

Ha pixelenként akarod kezelni, akkor pedig használd azt a makrót, amit a GIMP belement, ez a soronkövetkező pixelt visszaadja egy p.r, p.g, p.b structba.

Csupán annyit szeretnék, hogy egy adott képet GIMP -> save as -> C source /vagy/ C header -ként mentek, hogy ne kelljen az SDL-es program mellett a könyvtárban lennie a képfájlnak is, hanem magában a programban ott van a kép és onnan használjam a programban.
--
unix -- több, mint kód. filozófia.
Life is feudal

Hat en attol azert erosen aggodok, hogy a SDL surface csak ugy ukmukfukk megenne eztet igy ebben a formaban. Azt gyanitom, van erre valami X libes fuggvenyke, ami egyfelol a betuket feloldja pixeladatokka, masfelol a konvertalt adatot visszakopni is kepes.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( lzrd | 2009. 02. 03., k – 15:02 )

Tulajdonképpen ahhoz akartam ezt a megoldást, hogy bárhonnan futtatható legyen egy icipici logikai játék. Most csak abból a könyvtárból lehet elindítani, ahol a képek is vannak hozzá. Valahogyan biztos, hogy meg lehet oldani, hogy tudjon arról a program, hogy hol keresse a képeket, de ezt még nem tudom hogyan kell leprogramozni. (rendszergazda vagyok, nem programozó.) Gondolom valamilyen függvény szolgál arra, hogy az aktuális könyvtár lekérdezhető legyen futásidőben, illetve be lehessen állítani, hogy hol vannak a képek. De ha később netán szeretnék csomagot készíteni belőle, akkor az még hátra van, hogy az elérési utak jó helyre legyenek beállítva, illetve netán még indító ikon is legyen az asztalon, a menüben. Ezekre van valakinek ötlete, hogy hogyan oldható meg? Tudom, mert csináltam már debian csomagot, hogy ott pontosan meg vannak adva a könyvtárak, ahova települ a cucc, de programozói szemmel hogyan látjátok a dolgot?
--
unix -- több, mint kód. filozófia.
Life is feudal

Amit írtam, az ilyen. Lemented headerben a képet, ami szerkesztéskor a tárgykódba kerül (tehát nem kell külön file). A betöltésnél meg tényleg csak azzal kell játszani, hogy milyen surface adatába másolod (egyezzen meg). Ha pl alpha-t bekapcsolod a surface-n, akkor tuti rosszul fog megjelenni, mert gimp alapból 3 csatornát ment (és arra is figyelj, hogy ne indexelt képet ments).

Nem tudom, Hiena ramutatott arra, hogy a xbm/glib_c tipusu kepekbol valo konvertalas koltseges is lehet. Abban szerintem igaza van, h ha eleve ugy teszi a kepeket a targykodba, hogy az mar eleve SDL_Surface, akkor ugyan a forditasi ido megno, viszont a futasi ido drasztikusan csokkenhet.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A neten találtam ezt: 


Uint32 getpixel( SDL_Surface * surface, int x, int y)
{
    int bpp = surface->format->BytesPerPixel;
    Uint8 *p = (Uint8 *) surface->pixels + y * surface->pitch + x * bpp;
    switch (bpp)
    {
        case 1:  return *p;
        case 2:  return *(Uint16 *)p;
        case 3:  if ( SDL_BYTEORDER == SDL_BIG_ENDIAN ) 
                     return p[0] << 16 | p[1] << 8 | p[2];
                 else
                     return p[0] | p[1] << 8 | p[2] << 16;
        case 4:  return *(Uint32 *)p;
        default: return 0;
    }
}

Amit visszaad Uint32 típusú dolgot, az okozhat különböző gépeken galibát, ha ezt akarom felhasználni a kép előállításakor?
--
unix -- több, mint kód. filozófia.
Life is feudal

A fenti függvénnyel sikerült fájlba juttatnom egy kép pixeleit:
Uint32 pikszelek[]={ 3484450, 1707009, 2428673, 2559232, .... 3282433, 3151106, 2165504,};
Ezek ugye Uint32 típusú értékek. Lehet programfutási hiba abból, ha ezeket töltöm vissza az alábbival? 


void putpixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
    {
    int bpp = surface->format->BytesPerPixel;
    Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;

    switch (bpp)
        {
        case 1:   *p = pixel;           break;
        case 2:   *(Uint16 *)p = pixel; break;
        case 3:   if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
                    p[0] = (pixel >> 16) & 0xff;
                    p[1] = (pixel >>  8) & 0xff;
                    p[2] = pixel & 0xff;
                    } else {
                    p[0] = pixel & 0xff;
                    p[1] = (pixel >>  8) & 0xff;
                    p[2] = (pixel >> 16) & 0xff;
                    } break;
        case 4:   *(Uint32 *)p = pixel; break;
        }
    }

Úgy értem, hogy biztosan sikerül 32 bites értékeket visszatölteni eltérő környezetben is, más bpp értéknél? A két függvény elég biztonságos konverziót biztosít ha a bpp 8, 16, 24?
Amennyiben
SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );
használatakor
SCREEN_BPP 32, akkor a case 4: elég a kódban, ugye?
És tutti, hogy az Uint32-t meg fogj aenni gond nélkül?
Ha a környezet nem lenne képes 32 bites pixelek megjelenítésére, akkor már maga az SDL_SetVideoMode dobna hibát, ha jól sejtem. Vagy van benne valami belső konverziós védelem, hogy ha a vas nem bírja a 32 bitet, akkor valami enyhébb képmegjelenítésre kapcsol automatice? (Én meg közben csak hiszem, hogy 32 biten ábrázolok egy pixelt és az Uint32 esetleges szükséges konverzió nélkül (lásd case 1-3:) nem lenne (jól) kirajzolva a kép?)
--
unix -- több, mint kód. filozófia.
Life is feudal

( lzrd | 2009. 02. 05., cs – 11:51 )

Végülis ez lett a befutó:
proba=IMG_ReadXPMFromArray(proba_xpm);
Köszönöm a segítséget mindenkinek!
--
unix -- több, mint kód. filozófia.
Life is feudal

Illetve ez is hasznos új infó volt, eltekintve attól, hogy most nem ezt kerestem: 


SDL_Surface *image;
SDL_RWops *rwop;
rwop=SDL_RWFromFile("sample.xpm", "rb");
image=IMG_LoadXPM_RW(rwop);
if(!image) {
    printf("IMG_LoadXPM_RW: %s\n", IMG_GetError());
    // handle error
}

--
unix -- több, mint kód. filozófia.
Life is feudal

( lzrd | 2009. 02. 12., cs – 15:13 )

Remekül funkcionál a kiválasztott módszer: "IMG_ReadXPMFromArray".
4.1-es g++ és windowson a dev-C++ alatt szuperül fordul. Ámde a 4.3-as g++ sikoltozik:
images.xpm:2980: warning: deprecated conversion from string constant to 'char*'
Miért lett deprecated az, amit korábban megevett?
Ha jól tudom, az IMG_ReadXPMFromArray char** paramétert vár. Márpedig az xpm szerintem az:
-- idézet egy GIMPpel létrehozott xpm fájlból: 


/* XPM */
static char * images_xpm[] = {
"96 130 2847 2",
"       c #000300",
".      c #000200",
"+      c #000100",
"@      c #000000",
"#      c #030000",
"$      c #040000",

...majd ilyesféle sorokból kétezernyolcszáznegyveniksz darab...
és a 96x130-as karakterscreen következik...

Miért kerül a képbe string típus? És milyen konverzió? Ha az .xpm fájl karaktermutatók tömbje, akkor ez tök jó argumentum kell, hogy legyen egy char** -t váró függvénynek, nem?
Tudom, hogy "csak" warning, de akkor is...
--
unix -- több, mint kód. filozófia.
Life is feudal

Itt most nem a C++-os std::string-ről van szó.

A probléma az, hogy a forrásban megadott stringek ("-jelek közötti karakterek) konstansok. A kódodban viszont char*-nak adod értékül.
Ha jól emlékszem C-ben ez megengedett, C++-ban meg nem...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

http://cplusplus.com/doc/tutorial/ntcs.html

E-szerint lehet karaktertömböt létrehozni idézőjelek közöt:
char myntcs[]="some text";

Ha jól tudom,
char * akarmi[]="ez konstans lesz";
Az xpm állományban szerintem konstan karaktermutató tömb jön létre.

A deklaráció pillanatában inicializálja is a változót a kód. E szerint jónak kéne lennie:
Please notice that we are talking about initializing an array of characters in the moment it is being declared, and not about assigning values to them once they have already been declared. In fact because this type of null-terminated arrays of characters are regular arrays we have the same restrictions that we have with any other array, so we are not able to copy blocks of data with an assignment operation.

Lehet a következő a gond?

In the expressions we have used in some examples in previous chapters, constants that represent entire strings of characters have already showed up several times. These are specified enclosing the text to become a string literal between double quotes ("). For example:
"the result is: "

Azaz, hogy ebben a formában önhatalmúlag stringnek veszi? Aminek a fenti persze ellent mond.

Finally, sequences of characters stored in char arrays can easily be converted into string objects just by using the assignment operator:

string mystring;
char myntcs[]="some text";
mystring = myntcs;

Az alábbi formára kéne átalakítani az xpm-et (persze karaktermutató tömbös formában)?
char myword[] = { 'H', 'e', 'l', 'l', 'o', '\0' };

4.1-es g++, dev-c++ miért ette meg? 4.3-as miért nem?

amit írtál, abból nekem az jön le, hogy 4.3-as g++ -tól már nem fogadja el ezt:
static char * kepem_xpm[]={
"elso karakter sorozat",
"masodik karakter sorozat"
};
és persze ezt sem:
char karaktertombom[]="az en karaktertombom ez";

Létezik ez?
--
unix -- több, mint kód. filozófia.
Life is feudal

"Azaz, hogy ebben a formában önhatalmúlag stringnek veszi? Aminek a fenti persze ellent mond."
Kétféle string van:
1: string osztály (std::string másnéven std::basic_string).
2: string literál (karakterek "-jelek között)
Az első most nem jön a képbe, ne is keverjük ide.
A második meg a C-ből jön. És itt a probléma gyökere.

Elméletileg a C++ szabvány két dolgot mond: (Azt hiszem az újabb C szabvány is ugyanilyen)

a) konstans adatra nem állíthatsz nem konstans mutatót (csak const_cast használatával), azaz: 


const int c=3;
const int* cp=&c;  //jo
int* p=&c; //hiba
int* p2=cp; //hiba

Ez gondolom elég logikus. Persze int helyett lehetne ott bármilyen típus, akár char is.

b) a string literálok ("-jelek közötti karakterek) típusa konstans karakterek tömbje.
Ez azért van így, mert emiatt string literálok fizikailag lehetnek olyan helyen a memóriában, ahol nem tudod őket írni. Plusz többször előforduló stringek csak egyszer lesznek lefoglalva (mert úgysem módosíthatod őket). Sőt a "Hello World" és a "World" stringek a memóriában átfedhetik egymást.

Tehát ha szigorúan veszed a szabványt, akkor: 


char karaktertombom[]="az en karaktertombom ez"; //hiba
char* karaktertombom2="az en 2. karaktertombom ez"; //hiba

Viszont ez a C++ szabvány 98-as.

Mivel rengeteg kód van, ahol van ilyen kezdeti értékadás, az meg ugye nem lenne jó, ha ezek egyszercsak nem fordulnának, ezért ez mégiscsak szabványos de "deprecated", azaz elavult.

Valószínűleg a 4.1 után rakták bele ezt az ellenörzést a g++-ba.

Két dolgot tehetsz:
a) nem foglalkozol a warninggal.
b) átírod az xpm forrását static const char* images_xpm-re.

"amit írtál, abból nekem az jön le, hogy 4.3-as g++ -tól már nem fogadja el ezt:
static char * kepem_xpm[]={
"elso karakter sorozat",
"masodik karakter sorozat"
};
és persze ezt sem:
char karaktertombom[]="az en karaktertombom ez";

Létezik ez?"

Irtó egyszerű, próbáld ki. Szerintem warningot kapsz.

http://www.possibility.com/Cpp/const.html

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az az érdekes, hogy 4.3-as g++ nem panaszkodott erre:
char karaktertombom[]="az en karaktertombom ez";

Nem adott warningot.
Viszont arra, hogy
static char * images_xpm[]={...
átírtam
static const char * images_xpm[]={... -ra, hibát dobott...
--
unix -- több, mint kód. filozófia.
Life is feudal

const char * images_xpm[]={... esetén g++ 4.1 -es is sikít:
g++ -o proba proba.cpp -lSDL -lSDL_image
proba.cpp: In function 'int main(int, char**)':
proba.cpp:25: error: invalid conversion from 'const char**' to 'char**'
proba.cpp:25: error: initializing argument 1 of 'SDL_Surface* IMG_ReadXPMFromArray(char**)'
ha kiszedem a const szót, akkor lefordul és működik is.
Kód: 


#include "SDL/SDL.h"
#include "SDL/SDL_image.h"
#include "proba.xpm"

const int SCREEN_WIDTH = 40;
const int SCREEN_HEIGHT = 40;
const int SCREEN_BPP = 32;
SDL_Surface *screen = NULL;
SDL_Surface *proba = NULL;

void apply_surface( int x, int y, SDL_Surface* source, SDL_Surface* destination )
{
    SDL_Rect offset;
    offset.x = x;
    offset.y = y;
    SDL_BlitSurface( source, NULL, destination, &offset );
}


int main( int argc, char* args[] )
{
    SDL_Init( SDL_INIT_EVERYTHING );
    screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );
    SDL_WM_SetCaption( "proba", "proba" );
    proba=IMG_ReadXPMFromArray(proba_xpm);
    apply_surface( 1, 1, proba, screen );
    SDL_Flip( screen );
    SDL_Delay( 5000 );
    SDL_FreeSurface( screen );
    SDL_FreeSurface( proba );
    SDL_Quit();
    return 0;
}

a proba.xpm: 


/* XPM */
static char * proba_xpm[] = {
"20 20 107 2",
"       c #F86565",
".      c #F12020",
"+      c #F01818",
"@      c #C73920",
"#      c #669D45",
"$      c #34C54C",
"%      c #26C443",
"&      c #21C33F",
"*      c #34C950",
"=      c #67D87E",
"-      c #CEFFDF",
";      c #FFFFFF",
">      c #F22D2D",
",      c #D73118",
"'      c #648226",
")      c #26B12D",
"!      c #20BB39",
"~      c #20C33E",
"{      c #28C445",
"]      c #E6FFE6",
"^      c #F11E1E",
"/      c #995819",
"(      c #31A72C",
"_      c #1EB52E",
":      c #1FBA36",
"<      c #A3E6AE",
"[      c #F01919",
"}      c #24B12D",
"|      c #1EB42E",
"1      c #1EB836",
"2      c #4E9229",
"3      c #1FB32E",
"4      c #52D26A",
"5      c #1EB62E",
"6      c #31A82C",
"7      c #20C33D",
"8      c #FFCFCF",
"9      c #D9402D",
"0      c #28C440",
"a      c #20C33A",
"b      c #20C336",
"c      c #28C437",
"d      c #67D85E",
"e      c #E6FFCB",
"f      c #FFFFFD",
"g      c #ADA9FF",
"h      c #7667ED",
"i      c #603DDE",
"j      c #5D2BCC",
"k      c #722BB5",
"l      c #A6378B",
"m      c #E1657A",
"n      c #FFA2A2",
"o      c #CEE7CE",
"p      c #34C94A",
"q      c #26C438",
"r      c #21C336",
"s      c #21C330",
"t      c #25C42D",
"u      c #33C52C",
"v      c #67D12F",
"w      c #CEF03E",
"x      c #FFF56F",
"y      c #FFFDC9",
"z      c #423AFF",
"A      c #342AFE",
"B      c #2F25FD",
"C      c #766FFF",
"D      c #D6D1FF",
"E      c #E6FFD3",
"F      c #A3DE65",
"G      c #67D136",
"H      c #51CC29",
"I      c #67D128",
"J      c #A2D828",
"K      c #E4EF28",
"L      c #FDEF28",
"M      c #FDEF31",
"N      c #FEF56C",
"O      c #2D24FD",
"P      c #352CFE",
"Q      c #E8E8FF",
"R      c #FFFFB5",
"S      c #FFF146",
"T      c #FDEF2A",
"U      c #FDEF3D",
"V      c #FFF77F",
"W      c #FEF034",
"X      c #FDEF29",
"Y      c #FDEF2F",
"Z      c #FFF469",
"`      c #FDEF2D",
" .     c #6059FF",
"..     c #FFFFEC",
"+.     c #FEF036",
"@.     c #FFFFD9",
"#.     c #FFF77D",
"$.     c #FFF144",
"%.     c #FEF030",
"&.     c #FEF03E",
"*.     c #FFFFB3",
"=.     c #FFF77B",
"-.     c #FFF463",
";.     c #FFF461",
">.     c #FFF574",
",.     c #FFFDA9",
"'.     c #FFFFE4",
"  . + + + + + + @ # $ % & & % * = - ; ; ",
"> + + + + + + , ' ) ! ~ ~ ~ ~ ~ { = ] ; ",
"^ + + + + + + / ( _ : ~ ~ ~ ~ ~ ~ * < ; ",
"[ + + + + + + ' } | 1 ~ ~ ~ ~ ~ ~ % = ; ",
"[ + + + + + + 2 3 | 1 ~ ~ ~ ~ ~ ~ & 4 ; ",
"^ + + + + + + 2 3 _ : ~ ~ ~ ~ ~ ~ & 4 ; ",
"> + + + + + + ' } 5 ! ~ ~ ~ ~ ~ ~ % = ; ",
"  . + + + + + / 6 : 7 ~ ~ ~ ~ ~ ~ * < ; ",
"8   > ^ [ [ ^ 9 # 0 ~ ~ a b b b c d e f ",
"g h i j k l m n o = p q r s t u v w x y ",
"z A B B A z C D ; E F G H H I J K L M N ",
"O O O O O O P C Q R S T L L L L L L L U ",
"O O O O O O O z g V W X L L L L L L L Y ",
"O O O O O O O A C Z ` L L L L L L L L T ",
"O O O O O O O B  .Z ` L L L L L L L L T ",
"O O O O O O O B  .V W X L L L L L L L Y ",
"O O O O O O O A C R S T L L L L L L L U ",
"O O O O O O O z g ..V +.X L L L L L M N ",
"O O O O O O P C Q ; @.#.$.%.T T Y &.x y ",
"z A B B A z C D ; ; ; ..*.=.-.;.>.,.'.f "};

--
unix -- több, mint kód. filozófia.
Life is feudal

Hát igen, a probléma ugyanaz.

A IMG_ReadXPMFromArray char**-ot vár.
Ami nyilvánvalóan marhaság, hiszen tuti, hogy nem módosítja a képadatokat, azaz const char** kéne legyen. Ez szimplán egy rosszul megtervezett lib.

Ezekután csak undorító megoldás jöhet szóba: 

proba=IMG_ReadXPMFromArray(const_cast<char**>(proba_xpm));

Vagy marad a warning...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Gondolom a 130-as sor ez: 

static char * proba_xpm[]

Ez legyen 

static const char * proba_xpm[]

Ekkor warning nincs.

Viszont ekkor kell a 

proba=IMG_ReadXPMFromArray(const_cast<char**>(proba_xpm));

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Köszönöm, így fordul és működik is, de ez mintha ellentmondana azzal, ami a cplusplus.com-on olvasható a tutorial alatt, nem?
Ott azt írja, hogy ha a deklaráció és inicializáció egyszerre történik az idézőjeles karakterlánc megadása által, akkor az a karakterlánc konstans lesz. Ezexerint külön a const szóval ki kell emelni, hogy konstans a dolog?
--
unix -- több, mint kód. filozófia.
Life is feudal

Akkor implicite lesz konstans, mert kodblokkbeli szovegre mutatsz ra. Errol szol a warning, hogy ezeket azert illik const-kent megjelolni, mert attol hogy konstans lesz, attol a c++ meg nem konstanskent fogja kezelni, hiszen maga a valtozo nem annak lett deklaralva.

Ezert ha atadod mas helyre, nem lesz ervenyes ra a const vedelem, es egy lehetseges segfault lesz a vege, ha barki kozvetlen irni akarja a valtozot (meg egy egyszeru upcase/downcase megvalositas is veszelyes lehet).

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

1.)
char karaktertombom[]="az en karaktertombom ez";

ez nem hibas. ez letrehoz egy tombot az irhato adatszegmensben(char[], ezt kertuk), aminek a megadott karakterlanc lesz a kezdoerteke. tehat a tomb az irhato .data szegmensben jon letre, a &karaktertomb irhato helyre mutat.
szoval ezzel nincs semmi gond.

2.)
char *karaktertombom="az en karaktertombom ez";

itt letrejon egy konstans karakterlanc a nem irhato adatteruleten, es a karaktertomb mutato megkapja annak a cimet. es jon a warning, mert a nem konstans mutatonkat konstans adatra mutattatjuk ra.

3.)
const char *karaktertombom="az en karaktertombom ez";

mint a 2.) csak itt mar nincs warning mint tr3w ramutatott, mert igy fasza.

- Use the Source Luke ! -