játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5511
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2529

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] > 85 < [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [143]
Asylum - Törzstag | 5511 hsz       Online status #93861   2008.08.07 07:24 GMT+1 óra  
gl: explicit tipuskonverzio? (unsigned long)

amugy épp most jutott eszembe, hogy az elöbb leirt problémámra a figyelö tervminta lehetne egy megoldás.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93855   2008.08.07 05:24 GMT+1 óra  
Újabb láma kérdés:

Function overloadinggal szeretném elérni, hogy ha egy fgv paraméterül változót kap,a kkor az referenciaként adódjon át, ne érték szerint. De azt akarom, hogy konstans számokkal is meg lehessen hívni a függvényt, ezért így néz ki:

Kód:
void fgv(unsigned long szam)
{
...
}
void fgv(unsigned long &szam)
{
...
}

A két függvény törzsében a kód megegyezik.

De ha egy unsigned long típusú változóval hívom meg az fgv-t, akkor a fordító hibát dob, hogy nem tudja eldönteni, melyiket akarom meghívni.
(ambiguous call to overloaded function....)

Van vmi megoldás ilyen esetekre (azt leszámítva, hogy a referenciásat átírom pointeresre)?

   
gaborlabor - Moderátor | 4449 hsz       Online status #93851   2008.08.07 03:42 GMT+1 óra  
Vagy code::blocks

Amúgy TPG, nem írtad le feleslegesen, mert károm nem származott belőle, hogy elolvastam

Nálam is úgy lesz hogy van egy TextureManager osztály, és azon belül van a vector. Tehát nem lehet közvetlenül babrálni a vectort, hanem tagfüggvényeken keresztül lehet pl betölteni, törölni, és az lekezeli az egészet (pl nem tölti be kétszer ugyanazt a fájlt). Nem tudom, hogy jó lesz-e, most írom meg elsőre, de majd kiderül. 2D-s progihoz kell, nem kell material rendszer meg meshek sem, hanem kb csak Sprite objektumok (és leszármazottai) lesznek kapcsolatban a TextureManagerrel. Aztán vagy működni fog, vagy nem.

   
Asylum - Törzstag | 5511 hsz       Online status #93845   2008.08.06 19:31 GMT+1 óra  
egy gány szar
szedd le a régebbi, 4.9 es devcpp t azzal semmi gond nincs.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #93844   2008.08.06 19:09 GMT+1 óra  
Idézet
rooter :
Ezért megszeretném tudni hogy ki melyik dc változatot haználja és hogy honnan lehet hozzájutni,
előre is köszi!


Hmm, egyiket sem. Microsoft Visual C++ Express Edition 2005. A Dev C++ hoz képes méretileg egy monstrum, de nekem idáig semmi bajom nem volt vele, praktikus, kényelmes és szinte mindenhol támogatott.
Reality is almost always wrong. - House

   
rooter - Tag | 6 hsz       Online status #93843   2008.08.06 18:17 GMT+1 óra  
Hello új vagyok itt és a C++-ban is.
Az a problémám hogy b@z Dev C++ Alapok cikkjét bevittem a dev-c++ 5 betaba lefordítattam vele de hibát észlel, ezután bemásoltam inkább ,hogy hátha én gépeltem félre valamit, de sajnos nem.
Ezért megszeretném tudni hogy ki melyik dc változatot haználja és hogy honnan lehet hozzájutni,
előre is köszi!

   
TPG - Tag | 3402 hsz       Online status #93842   2008.08.06 18:01 GMT+1 óra  
Idézet
Asylum :
nálam ilyen ID alapu rendszer nem nagyon van, eddig nemis volt rá nagyon szükség.
annyiból biztos hasznosabb, hogy ha valami okból változik a tényleges memoriacim akkor nem válik érvénytelenné az összes többi pointer.


Egyrészt előny az amit írtál, ez a hülye biztosság egy foka. Az adott res-t én az adott osztálypéldányon keresztül tudom törölni, de ha arra a res-re más osztálypéldányok is hivatkoztak és ezeken a példányokon én nagy okosan műveletet akarok végezni, akkor nem fog rám szakadni az ég (ellenben egy érvénytelen mutatónál elég gáz ez), csak annyi történik hogy a log-ba pirossal és ERROR címszóval bekerül hogy adott ID-jű objektumon a műveletvégzés sikertelen volt ez miatt. A másik amiért jobban szeretem ezt a rendszert hogy egy kicsit elvontabb, nem különböztet meg res betöltést és már létező res-re kezelő osztálypéldány lekérését. A két művelet ugyan az, megmondom a managernek hogy x ID-jű cuccra szeretnék egy kezelőt, ő megnézi a betöltött res-ek közt hogy bent van-e, ha igen akkor visszadob egy kezelőt, ha nem akkor pedig megpróbálja betölteni (először az ismert pack-okból (a packok felderítése szintén automata, nem kell megadni hol vannak, annyi a feltétel hogy valahol a programkönyvtáron belül kell lenniük, az hogy azon belül hova és hogyan van elásva az mindegy), ha onnan sikertelen akkor a fáljrendszerből). Ha nem tudja betölteni akkor sincs gáz, visszadob egy érvénytelen kezelőt amin ha az ember dolgozni akar akkor jönnek a piros ERROR-ok a logba. Szóval egyrészt szerintem kényelmesebb, másrészt nekem még nem sikerült a rendszert felborítani, amilyen hibákat el tudtam képzelni azokat a tervezésnél figyelembe vettem, úgyhogy jelen állás szerint a piros ERROR-nál rosszabb nem történhet, a program normálisan futásképes marad még ha a programozó hülye is. Valószínű ettől függetlenül össze lehetne dönteni, de nekem gőzöm nincs hogy, ahhoz valószínű nagyon ügyesnek kell lenni.

Idézet
Asylum :
ha már ugyis feljött ez a téma..olyankor mi van, ha van két objektum, mindkettöben egy pointer egy meshre mondjuk, és az egyikre nyomok egy clonemeshfvf et (szal olyat ami felszabaditja), akkor a másikban még a régi obejktumra fog mutatni ami vagy felszabadult vagy nem (elég idegesitö).
Aztán ha a másikra is nyomok akkor kétszer van ugyanaz két különbözö cimen...ez viszont már kellemetlen. Erre van valami modszer?

egy lehetséges megoldás amit nem implementáltam még, hogy az összes többi másolatban is át kell irni a memoriacimet...de valahogy nem ez lenne a cél egy másolat esetén.


Központosítani kell az egészt. Jó mutatókkal dolgozni, én is szeretek, de szépen limitált környezetben kell őket használni és amennyire lehet osztályokba rejteni. Ha programszinten konkrétan a mesh pointereket használod abból bábeli zűrzavar fog keletkezni hamar, mivel ahogy írod ha valami olyat csinálsz ami miatt a mutatóval történik valami akkor ahhoz a kód más részeiben is alkalmazkodni kell. Ez egy idő és méret után lehetetlen feladat, csak annyit veszel észre hogy a mesh-en csinálsz valami ilyesmit aminek következményeként lesújt Zeusz haragja és neked meg gőzöd nincs merre keresd a döglött pointert. Ezért alkottam én is a saját rendszeremet, ott ilyen probléma nem fordulhat elő, a rendszer lekezeli.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5511 hsz       Online status #93841   2008.08.06 17:19 GMT+1 óra  
nálam ilyen ID alapu rendszer nem nagyon van, eddig nemis volt rá nagyon szükség.
annyiból biztos hasznosabb, hogy ha valami okból változik a tényleges memoriacim akkor nem válik érvénytelenné az összes többi pointer.

ha már ugyis feljött ez a téma..olyankor mi van, ha van két objektum, mindkettöben egy pointer egy meshre mondjuk, és az egyikre nyomok egy clonemeshfvf et (szal olyat ami felszabaditja), akkor a másikban még a régi obejktumra fog mutatni ami vagy felszabadult vagy nem (elég idegesitö).
Aztán ha a másikra is nyomok akkor kétszer van ugyanaz két különbözö cimen...ez viszont már kellemetlen. Erre van valami modszer?

egy lehetséges megoldás amit nem implementáltam még, hogy az összes többi másolatban is át kell irni a memoriacimet...de valahogy nem ez lenne a cél egy másolat esetén.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #93840   2008.08.06 17:08 GMT+1 óra  
Idézet
Asylum :
nálam ugy van megoldva, hogy a managerben is ott van egy pointer a texre (a vektorban), és az anyagban is (mert nálam nem az objektum tárolja a texet hanem az anyag, ffp nél egy ilyen default anyagot rak és arra aggatja rá), persze refcountolással, de a manager szabaditja fel ténylegesen.


Én nem pointereket tárolok le hanem egy apró struktúrákat. A vector elemeit közvetlenül lehetetlen elérni, viszont van erre egy osztály ami a vector egy adott elemének indexét tárolja (kezeli azt is ha törlök vagy hozzáadok a vektorhoz). Egy ilyen osztálypéldány függvényein keresztül lehet csak melót végezni a vektor egy adott elemén. Ilyen osztálypéldányt pedig a manager bármelyik elemre tud visszaadni, feltéve ha ismerjük a betöltött elem ID-jét (ami a fájl elérési útvonala hogy emberi legyen a dolog). Előnye ennek a rendszernek hogy igen nehéz elcseszni, a struktúra pedig általában alig nagyobb a pointernél.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5511 hsz       Online status #93839   2008.08.06 16:59 GMT+1 óra  
Idézet

Pedig tök jó lenne, mert így nem kéne számolgatnom, hogy melyik pályán mennyi textúrát fogok betölteni, hanem csak így bele lehetne dobálgatni, és az indexeket eltárolni h melyik objektumnak melyik kell....



nálam ugy van megoldva, hogy a managerben is ott van egy pointer a texre (a vektorban), és az anyagban is (mert nálam nem az objektum tárolja a texet hanem az anyag, ffp nél egy ilyen default anyagot rak és arra aggatja rá), persze refcountolással, de a manager szabaditja fel ténylegesen.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93838   2008.08.06 16:49 GMT+1 óra  
Igen, hát ismételten beigazolódott, ahogy már nem egyszer:
http://www.codinghorror.com/blog/archives/001079.html
Nagy igazság.

   
TPG - Tag | 3402 hsz       Online status #93837   2008.08.06 16:47 GMT+1 óra  
A vector értéket tárol el, szépen "bemásolja" a saját lefoglalt memórészébe. Ha nem így lenne akkor értelmetlenek lennének a MS-os vector példák.
Kód:
vector<int> vec;
vec.push_back(3);

Se referencia, se pointer nem tud mutatni egy ilyen konstansra (fordítási hibát dob élből). Megpróbáltam azt reprodukálni ami GL-nek nem ment de nem sikerült, a hasonló kód nálam működik.
Kód:
        int *teszt = new int;
(*teszt) = 4;
vector<int> TesztVetor;
TesztVetor.push_back(*teszt);
cout<<TesztVetor[0]<<endl;
delete teszt;
cout<<TesztVetor[0]<<endl;

Mindkét esetben 4-et ír ki. Szóval ott más lesz a probléma.

Szerk: Vazze, mire leírom már felesleges lesz.
Reality is almost always wrong. - House

   
gaborlabor - Moderátor | 4449 hsz       Online status #93836   2008.08.06 16:38 GMT+1 óra  
Gyáááááááá megvan, LOL, rájöttem!
mekkora szarláma vagyok hogy 3 óra kellett mire rájöttem!

amikor a bemásolandó ojjektumot létrehoztam, akkor a konstruktora létrehozta az OpenGL textúraazonosítót. (glGenTextures...)
aztán ezt jól be is másolta a vektorba, DE: amikor az ideiglenes ojjektumot töröltem, akkor a destruktor annak rendje és módja szerint törölte az OpenGL textúraazonosítót (glDeleteTextures...)

Lehet kiröhögni!

Ezt a hozzászólást gaborlabor módosította (2008.08.06 16:45 GMT+1 óra, ---)

   
gaborlabor - Moderátor | 4449 hsz       Online status #93835   2008.08.06 15:54 GMT+1 óra  
Értem, akkor úgy lesz, MAJD, ha működik egyáltalán.
Tehát akkor pointereket kell a vektorban tárolnom, és amikor már bentvan, akkor lefoglalni neki a területet + inicializálni. Oké, ez simán megoldható, de akkor megint az lesz, hogy amit bemásolok azt őrizgetnem kell.
De most komolyan, miért van ez így? Én nem értem.

Pedig tök jó lenne, mert így nem kéne számolgatnom, hogy melyik pályán mennyi textúrát fogok betölteni, hanem csak így bele lehetne dobálgatni, és az indexeket eltárolni h melyik objektumnak melyik kell....

   
Asylum - Törzstag | 5511 hsz       Online status #93833   2008.08.06 15:46 GMT+1 óra  
elvileg müködnie kéne de hadd kössek bele () ha igy csinálod akkor igencsak sokat fog másolgatni ugyanis vektorban a beszúr müvelet minden csak nem konstans (listában igen). Szóval inkább cTexture* okat pakolj bele és ugy hozzad létre.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93829   2008.08.06 14:30 GMT+1 óra  
na igen, az lenne jó, ha olyan lenne mint egy tömb. de most nálam úgy viselkedik, mintha csak referenciákat tárolna.
Nekem olyan kéne, ami ténylegesen objektumokat tárol. Elmentek bele néhány elemet, és akkor azok bent is maradnak, függetlenül attól, hogy mi történik azzal amit bele másoltam.

Kód:
//globálisak
vector<cTexture> vec;
cTexture *T;

// init-ben:
T = new cTexture();
vec.push_back(*T);
vec[0].CreateTexture("C:\\lena.png");
vec[0].Bind();
delete T;


Ezután, ha a vec 0. elemét akarom felhasználni, fehérséget kapok, mintha nem létező textúra lenne. Viszont ha kikommentezem a delete T; sort, akkor működik remekül.
De mire kell az még, mikor a push elméletileg lemásolja azt az objektumot, amit a new-val létrehoztam??
Mert ha nem másolja le, akkor tényleg nem ér semmit az egész

   
Asylum - Törzstag | 5511 hsz       Online status #93828   2008.08.06 14:22 GMT+1 óra  
intek vannak benne, az más kérdés, hogy a stacken vagy a heapen foglalodik le (szerintem a heapen). az std::vector lényegében olyan mint egy tömb..
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93827   2008.08.06 13:59 GMT+1 óra  
Hmm ez érdekes, de lehetséges. Én nem tudom...
De azt hittem, hogy pl. vector<int> A esetén az A-ban int-ek és nem int*-ok vannak.
De lehet hogy tényleg pointerek vannak benne, akkor viszont elméletileg az erase és a clear is el kell hogy végezze a felszabadítást, mert én az összes példakódban amit átnéztem, nem láttam olyat, hogy kézzel lenne felszabadítva az összes elem.

   
Matzi - Szerkesztő | 2529 hsz       Online status #93823   2008.08.06 13:49 GMT+1 óra  
A vektorban is pointerek tárolódnak, nem? Mert ugye akkor nyilván nem törölheted az eredetit. Fogod, létrehozod az ojjektumot, a pointert benyomod a vektorba, és nem semmisíted meg. Törölni meg úgy törlöd, hogy kiszeded a vektorbol, és egyesével megsemmisítgeted.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
gaborlabor - Moderátor | 4449 hsz       Online status #93821   2008.08.06 13:38 GMT+1 óra  
Arra gondoltam, hogy a textúrákat tárolhatnám egy STL féle vectorban.
Deklaráltam egy vectort a textúraobjektum típusával.
Úgy próbáltam, hogy létrehoztam egy ideiglenes objektumot, azt a push_back()-kel beszúrtam a vector végére, és utána a vector utolsó elemébe töltöttem képet fájlból.
De ilyenkor mi történik? Én azt hittem, lemásolódik az ideiglenes objektum, és akkor az szépen benne lesz a vektorban. De látszólag nem ez történik, hanem olyan mintha csak egy referencia tárolódna el, mert később csak akkor tudom a vektorban lévő textúraobjektumot használni, ha az ideiglenest (amit bemásoltam) nem törlöm. (Így meg kb semmi értelme sincs.)
Szóval hogy is van ez?
Először próbálkozok a vectorral, bocs a láma kérdésért.

   
misi - Törzstag | 971 hsz       Online status #93509   2008.08.02 09:14 GMT+1 óra  
Bocs Joga megelőztél, és igazad van, bár az a környezettől függ, hogy mi is az. .
   
Mystro - Tag | 60 hsz       Online status #93508   2008.08.02 09:04 GMT+1 óra  

kösz ezt nem először írtam el és így már minden működik, az egér esemény tényleg szebb lett

Ezt a hozzászólást Mystro módosította (2008.08.02 09:11 GMT+1 óra, ---)
   
Joga - Törzstag | 1791 hsz       Online status #93507   2008.08.02 09:04 GMT+1 óra  
ŐŐő
SDL_UpdateRect(background, menup.x, menup.y, 725, menup.y+70);
helyett
SDL_UpdateRect(background, menup.x, menup.y, 170, 70);
( ha jól számolom )
Szerk.: misié annyiban rossz, hogyha az egér például a menü mellett balra, vagy jobbra van, akkor nem hívódik meg a menu_esemeny(...);
(ಠ ›ಠ) Stewie!

   
misi - Törzstag | 971 hsz       Online status #93506   2008.08.02 08:59 GMT+1 óra  
Marhára nem tudom mi az az SDL, és nem is C++ -ozok. De csupán a a segítésakarásból megpróbáltam egy kicsit pofozni rajta:

Kód:
void menu_esemeny(int melyik, int mod)
{
//SDL_ShowCursor(1);
SDL_BlitSurface(image, NULL, background, NULL);

menup.x=555;

for(int i=0; i<5; i++)
{
menup.y=(i+3)*100;
if(i!=melyik)
{
SDL_BlitSurface(menu[i], NULL, background, &menup);
}
else if (mod==1)
{
SDL_BlitSurface(menu[i+5], NULL, background, &menup);
SDL_UpdateRect(background, menup.x, menup.y, 725, menup.y+70);
return;
}
}
SDL_UpdateRect(background, 0, 0, 0, 0);
}


Kód:
if ( event.type == SDL_MOUSEMOTION ) && (event.motion.x >= 555 && event.motion.x <= 725)
{
        if (event.motion.y >= 300 && event.motion.y <= 370) ) {menu_esemeny(0, 1);}
        else if (event.motion.y >= 400 && event.motion.y <= 470) {menu_esemeny(1, 1);}
        else if (event.motion.y >= 500 && event.motion.y <= 570) {menu_esemeny(2, 1);}
        else if (event.motion.y >= 600 && event.motion.y <= 670) {menu_esemeny(3, 1);}
        else if (event.motion.y >= 700 && event.motion.y <= 770)  {menu_esemeny(4, 1);}
        else {menu_esemeny(-1, 0);}
}


Bár igazából csak rendeztem ( tudásom szerint ). Vagy is konkrétan hibát nem találtam... Nem lehet hogy azok 6 tól felfelé nincsenek benne a List-ben?
   
Joga - Törzstag | 1791 hsz       Online status #93505   2008.08.02 08:55 GMT+1 óra  
Egyedül egy valamit látok rossznak, az SDL_UpdateRect() paraméterezését

Kód:
void SDL_UpdateRect(SDL_Surface *screen, Sint32 x, Sint32 y, Sint32 w, Sint32 h);

Szal utolsó két paraméternek nem a jobb alsó koordinátákat, hanem a szélességet és a magasságot jelenti

+ az egér esemény szerintem így szebb lenne:

Kód:
if ( event.type == SDL_MOUSEMOTION )
{
if(event.motion.x >= 555 && event.motion.x <= 725){

if (event.motion.y >= 300 && event.motion.y <= 370){
menu_esemeny(0, 1);
}
else if(event.motion.y >= 400 && event.motion.y <= 470){
menu_esemeny(1, 1);
}
else if(event.motion.y >= 500 && event.motion.y <= 570){
menu_esemeny(2, 1);
}
else if(event.motion.y >= 600 && event.motion.y <= 670){
menu_esemeny(3, 1);
}
else if(event.motion.y >= 700 && event.motion.y <= 770)){
menu_esemeny(4, 1);
}
else{
menu_esemeny(-1, 0);
}

}else{
menu_esemeny(-1, 0);
}
}
(ಠ ›ಠ) Stewie!

   
Mystro - Tag | 60 hsz       Online status #93504   2008.08.02 08:29 GMT+1 óra  
Hali

SDL-ben csinálok egy játékot. Ennek a kódnak azt kellene csinálnija hogy ha rámegy az egér az egyik menüpontra akkor másik képet rajzol helyette, de az 5 menüpontból csak az első 2-nél működik.
Kód:
void menu_esemeny(int melyik, int mod)
{
//SDL_ShowCursor(1);
SDL_BlitSurface(image, NULL, background, NULL);
for(int i=0; i<5; i++)
{
if(i!=melyik){
menup.x=555;
menup.y=(i+3)*100;
SDL_BlitSurface(menu[i], NULL, background, &menup);
}
}
if (mod==1)
{
menup.x=555;
menup.y=(melyik+3)*100;
SDL_BlitSurface(menu[melyik+5], NULL, background, &menup);
SDL_UpdateRect(background, 555, (melyik+3)*100, 725, (melyik+3)*100+70);
return;
}
SDL_UpdateRect(background, 0, 0, 0, 0);
}


Itt az egér esemény ( vagy mi ) :

Kód:
if ( event.type == SDL_MOUSEMOTION )
      {
        if ((event.motion.x >= 555 && event.motion.x <= 725) && (event.motion.y >= 300 && event.motion.y <= 370) ){ menu_esemeny(0, 1); }
else if ((event.motion.x >= 555 && event.motion.x <= 725) && (event.motion.y >= 400 && event.motion.y <= 470) ){ menu_esemeny(1, 1); }
else if ((event.motion.x >= 555 && event.motion.x <= 725) && (event.motion.y >= 500 && event.motion.y <= 570) ){ menu_esemeny(2, 1); }
else if ((event.motion.x >= 555 && event.motion.x <= 725) && (event.motion.y >= 600 && event.motion.y <= 670) ){ menu_esemeny(3, 1); }
else if ((event.motion.x >= 555 && event.motion.x <= 725) && (event.motion.y >= 700 && event.motion.y <= 770) ){ menu_esemeny(4, 1); }
else{ menu_esemeny(-1, 0);}
      }


Mit rontottam el?

Ui: a képek egy tömbben vannak 0-4-ig és 5-9-ig a képek amik az eredeti helyett jelennek meg.
   
TPG - Tag | 3402 hsz       Online status #93503   2008.08.02 08:19 GMT+1 óra  
Idézet
gaborlabor :
azért akarok konzolt, mert egyszerűbb implementálni, mint ilyen quake-szerű konzolt, persze release-ben nyilván az a jobb


A szabvány fentről lenyíló grafikus konzolt is egy nap alatt össze lehet rakni. Nem nagy meló, ha összeereszted valami scriptrendszerrel akkor meg akár menet közben is tudsz random függvényeket hívogatni konzolból.
Reality is almost always wrong. - House

   
gaborlabor - Moderátor | 4449 hsz       Online status #93502   2008.08.02 08:16 GMT+1 óra  
azért akarok konzolt, mert egyszerűbb implementálni, mint ilyen quake-szerű konzolt, persze release-ben nyilván az a jobb

   
Asylum - Törzstag | 5511 hsz       Online status #93501   2008.08.02 07:27 GMT+1 óra  
hát akkor meg azt ingame kéne megoldani mint a quake ben.
debugra amugy nemtom miért kellenek ilyen igények, hogy gombnyomásra nyiljon meg
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93495   2008.08.02 04:15 GMT+1 óra  
Igen, mert azt szeretném, hogy ne induljon rögtön konzollal, hanem én tudjam szabályozni, hogy most nyitok egy konzolt, irogatok bele, aztán bezárom stb, és persze a release-ben már egyáltalán nem lenne konzol használat.

   
Asylum - Törzstag | 5511 hsz       Online status #93490   2008.08.01 17:06 GMT+1 óra  
akkor nem értem a problémát. olyan fontos a winmain()?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93488   2008.08.01 16:41 GMT+1 óra  
Matzi: köszi!

Asylum: nehogy azt hidd, hogy nem használtam még console applicationt, sőt, eddig mindig mindent úgy írtam én is, és pont ebből lett elegem Csak most szükségem lenne rá elsősorban debugoláshoz. A lényeg, hogy megoldható

   
Asylum - Törzstag | 5511 hsz       Online status #93485   2008.08.01 15:02 GMT+1 óra  
baromi egyszerü: winmain helyett main()
de sztem már vagy 30 szor leirtam (ezexerint nemjáccotok a spacebanggal irgumburgum)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2529 hsz       Online status #93484   2008.08.01 14:51 GMT+1 óra  
Van console osztály, csinálsz egy olyat, van valami handler, amin keresztül el tudod érni. Baromi egyszerű, csináltam is egy kis csomagott valamikor , amivel lehet szinezni, meg gotoxy-ozni, szóval alapvető dolgokat, nem vészes.

Kód:
HANDLE console_handle; // konzol kezelő

void SetColor(int color){ // írási szín beállítása
SetConsoleTextAttribute(console_handle,color);
}

void StepBack(){ // visszalépés egy karakterrel a konzolon
CONSOLE_SCREEN_BUFFER_INFO Info; // konzol infó
GetConsoleScreenBufferInfo(console_handle,&Info); // lekérdezés
GotoXY(Info.dwCursorPosition.X-1,Info.dwCursorPosition.Y); // visszalépés
}

void GotoXY(int X, int Y){ // kurzor pozícionálás
COORD Coord; // koordináták..
Coord.X=X; // ..beállítása
Coord.Y=Y;
SetConsoleCursorPosition(console_handle,Coord); // pozicionálás
}

void GetConsole(){ // konzol előkészítése
console_handle= GetStdHandle( STD_OUTPUT_HANDLE); // kezelő megszerzése

COORD Coord; // konzol méret..
Coord.X=80;
Coord.Y=50;
SetConsoleScreenBufferSize(console_handle,Coord); // ..beállítása
}
void clrscr(){ // képernyő törlés
DWORD i;
COORD Coord;
Coord.X=0;
Coord.Y=0;
FillConsoleOutputCharacter(console_handle,' ',50*80,Coord,&i);// karakterek törlése
FillConsoleOutputAttribute(console_handle,15,50*80,Coord,&i);// színek törlése
GotoXY(0,0); // elejére pozicionálás
SetColor(15); // fehér színnel írunk
}
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
sheridan - Tag | 55 hsz       Online status #93480   2008.08.01 12:53 GMT+1 óra  
Idézet
gaborlabor :
Azt meg lehet oldani, hogy (ha van ms vs-ben egy win32 projektem) a program futásakor/futás közben a win32-es ablak mellett létrehozok 1 konzol ablakot is, amibe lehet irogatni?
Vagy ezt csak úgy lehet, hogy eleve console application a projektem típusa, és a win32-es ablakot hozom létre pluszba?



Szerintem alap win32 nem konzol projektként csak külön szálban lehet megoldani a dolgot. Nyitni egy új szálat, ami nyit egy konzolt, és azt kezelni valahogy, De azt már nem tudom, hogy lehet.

   
gaborlabor - Moderátor | 4449 hsz       Online status #93479   2008.08.01 12:49 GMT+1 óra  
Azt meg lehet oldani, hogy (ha van ms vs-ben egy win32 projektem) a program futásakor/futás közben a win32-es ablak mellett létrehozok 1 konzol ablakot is, amibe lehet irogatni?
Vagy ezt csak úgy lehet, hogy eleve console application a projektem típusa, és a win32-es ablakot hozom létre pluszba?

   
Mystro - Tag | 60 hsz       Online status #93299   2008.07.30 06:22 GMT+1 óra  
Nemtom hogy de megoldottam
   
Mystro - Tag | 60 hsz       Online status #93290   2008.07.30 04:18 GMT+1 óra  
a dll-eket bemásoltam a release exe mellé, mot nem konfigurációs hiba van hanem "A ***.exe hibát észlelt ezért leállt..."

ha /MT vagy /MTd-re állítom akkor :
1>cl : Command line error D8016 : '/MTd' and '/clr:pure' command-line options are incompatible
   
gaborlabor - Moderátor | 4449 hsz       Online status #93289   2008.07.30 04:14 GMT+1 óra  
vagy beállítod, hogy ne dll-ből használja
(multi-threaded dll helyett sima multi-threaded-re kell állítani a proj.settings/code generation/c++ alatt)

   
Asylum - Törzstag | 5511 hsz       Online status #93288   2008.07.30 04:09 GMT+1 óra  
igen: nem vitted magaddal a vs runtime ot (valahol a könyvátárban ott van, redist vagy vmi)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Mystro - Tag | 60 hsz       Online status #93286   2008.07.30 03:17 GMT+1 óra  
Hali

CLR windows form-mal csináltam egy programot de másik gépeken nem indul el mert a konfigurációja helytelen (release-ben is). Van vmi ötletetek?
   
bmateusz - Tag | 121 hsz       Online status #93242   2008.07.29 11:00 GMT+1 óra  
Köszönöm a felvilágosítást Mondjuk erre csak akkor van szükség, ha máshol is le akarod fordítani a projektet. Először projekt kéne

   
Asylum - Törzstag | 5511 hsz       Online status #93240   2008.07.29 10:25 GMT+1 óra  
nem csak a linkernek, az egész forditonak. Lényegében egy külön scriptnyelv szerüség amivel meg lehet adni, hogy mivel és hogyan történjen a forditás stb.
Merthogy ugye alapbol igy forditunk

gcc -o alma.o alma.cpp
gcc -o banan.o banan.cpp

linkelés:

gcc -o gyumolcs alma.o banan.o

nahát most ez egy 100 forrásfájlos projektnél enyhén szolva kinszenvedés...a makefileba csak leirod a fájlok nevét egyszer és a make megcsinálja
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #93239   2008.07.29 10:08 GMT+1 óra  
a makefile mondja meg a linkernek, hogy mit mivel hogyan, hogy a tárgykódból futtatható bináris legyen. állítólag nem árt, ha az ember tud szabványos makefilet írni kézzel, mert a legtöbb fejlesztőkörnyezet nem csak szabványos dolgokat használ, hanem egyedi kiegészítéseket stb.

   
bmateusz - Tag | 121 hsz       Online status #93238   2008.07.29 09:55 GMT+1 óra  
Én se felejtem el, de ez a Codeblocks nagyon bejött! Egyébként ismeri a .dev , .DevPak fájlokat is, így ha váltani akarsz, semmi gond.
Őszintén szólva nem tudom mire jó ez a makefile, de a Codeblocksban is van ilyen, a project/propertities-ben található.

   
Asylum - Törzstag | 5511 hsz       Online status #93236   2008.07.29 09:45 GMT+1 óra  
én nem felejteném el a devcpp-t, nemis azért használom mert olyan hüdeszuper, hanem mert lusta vagyok makefilet irni...igy viszonylag gyorsan tudom tesztelni, hogy g++ al is ugyanugy fordul-e a kód mint a gányolós msvc vel.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bmateusz - Tag | 121 hsz       Online status #93233   2008.07.29 07:18 GMT+1 óra  
Idézet
kiskami :
A Dev-C++-t szerintem nyugodtan el lehet felejteni, 3 éve nem adtak ki új verziót - halott a projekt. A másik kettő (sokkal) ügyesebb, okosabb, jobb.



Megfogadom a tanácsod Ez a Codeblocks jónak tűnik. A MSVC viszont túl sok helyet foglal

   
Sdmemory - Tag | 3 hsz       Online status #93231   2008.07.29 06:10 GMT+1 óra  
Kössz a válaszokat, de sikerült végül aktiválnoma a c++buildert úgyhogy azzal kezdem valszeg a könyv miatt. Amúgy magáról a könyvről van valakinek véleménye-tapasztalata?

   
gaborlabor - Moderátor | 4449 hsz       Online status #93223   2008.07.29 02:01 GMT+1 óra  
Én sem szeretem, de a devcpp-vel meg tudtam oldani, hogy pendrive-ra telepítve portable legyen, bárhol tudom használni.
VS-val szerintem ez halott ötlet lenne, code::blocks-szal meg még nem próbáltam.

   
kiskami - Tag | 265 hsz       Online status #93219   2008.07.28 23:35 GMT+1 óra  
A Dev-C++-t szerintem nyugodtan el lehet felejteni, 3 éve nem adtak ki új verziót - halott a projekt. A másik kettő (sokkal) ügyesebb, okosabb, jobb.
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] > 85 < [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [143]