halihó!
egy nagyon idióta kérdéssel fordulok hozzátok, csak tõlem is kérdezték és nem tudtam. na..
hogy lehet lekérdezni C++ban 1 mappa tartalmát?

Üdv: --==[B@z]==--

köff mindenkinek, már jó!
ez az srandos izé volt, csak azt nem értem, hogy eddig mért mûxött???

Üdv: --==[B@z]==--

Eh bien, jellemző, mire válaszolok addigra már meg is van oldva a kérdés Amúgy érdemes ilyenkor egy c++ referecia oldalon nézelődni, mert rendesebb helyeken a rand mellett megemlítik az srandot is, és már helyben is vagy.
Toma

"Ez nem bug, hanem feature!"

Hacker tippje jó volt, csak nem randomize (az Pascalban van pl.), hanem [url="http://www.cplusplus.com/ref/cstdlib/srand.html">srand[/url] kell neked!
Toma

"Ez nem bug, hanem feature!"

ctime-ot (time.h)-t includeolni el ne felejtsd!

Akkor tudsz valamit,ha tudod, hogy mit nem tudsz!

egy ilyet helyezz el elõtte: srand(time(NULL));
ez az idõhöz "viszonyítva" véletlenít

Akkor tudsz valamit,ha tudod, hogy mit nem tudsz!

próbáltam, de azt nem ismeri....

Üdv: --==[B@z]==--

Nem kellene elé vagy magába a tagfüggvénybe, egy randomize(); parancs?

Programozz ne háborúzz!!!

hi!
segíícsetek, mert már kezdem összefonni a szemöldököm...
mért nem mûxik nekem a rand?? elfogadja meg minden, de akárhányszor lefuttatom, mindig ua az eredmény...

int randn(int i)
{
return rand()%i+1;
}

includolva van az stdio, az iostream, meg sok minden (kiprószáltam úgyis, hogy az stdlib.h is includolva van, de akkoris ua)

Üdv: --==[B@z]==--

Idézet

---

Eagle_Lor írta:
A meredekségre a megoldás, hogy az y tengellyel bezárt szögbõl kiszámolod a az x tengellyel bezárt szöget. Ha az y tengellyel bezárt szög A akkor az x tengellyel bezárt szög B=90°-A lesz. A meredekség pedig m=tan(B), kivéve ha B=90°, mivel ilyenkor nincs meredeksége.

---

Hali!
Köff, majd kipróbálom...

Üdv: --==[B@z]==--

A meredekségre a megoldás, hogy az y tengellyel bezárt szögbõl kiszámolod a az x tengellyel bezárt szöget. Ha az y tengellyel bezárt szög A akkor az x tengellyel bezárt szög B=90°-A lesz. A meredekség pedig m=tan(B), kivéve ha B=90°, mivel ilyenkor nincs meredeksége.

Idézet

---

cs_adam írta:
A deklaráció azért nem megy, mert ez nem pascal.
A C++ többdimenziós tömbdeklarációja nem így mûködik.
Így mûködik: int array[d1][d2]...[dn];

Az egyenes meredeksége tangens alfa, ha alfa az egyenes és az x tengely által bezárt szög. Már persze ha erre a meredekségre gondolsz... Ebbõl és egy fix pontból ugyanis meg lehet határozni az egyenes egyenletét, és abba már csak be kell helyettesíteni.
fix pont: x0,y0
meredekség: m
egyenlet: y - y0 = m(x - x0)
Mondjuk nem tudom mirõl van szó, de úgy általánosan mûxik...

Cs.Ádám

---

HAli!
Jah, hüly vok pedig már olvastam errõl Innen láccik, hogy könyvbõl nem tok tanulni

Jah és nem az x tengellyel zárja be a szöget, hanem az y tengellyel
Szal nem tom, hogy joe


Üdv: --==[B@z]==--

A deklaráció azért nem megy, mert ez nem pascal.
A C++ többdimenziós tömbdeklarációja nem így mûködik.
Így mûködik: int array[d1][d2]...[dn];

Az egyenes meredeksége tangens alfa, ha alfa az egyenes és az x tengely által bezárt szög. Már persze ha erre a meredekségre gondolsz... Ebbõl és egy fix pontból ugyanis meg lehet határozni az egyenes egyenletét, és abba már csak be kell helyettesíteni.
fix pont: x0,y0
meredekség: m
egyenlet: y - y0 = m(x - x0)
Mondjuk nem tudom mirõl van szó, de úgy általánosan mûxik...

Cs.Ádám

Hali!
2 problémám van:
van egy deklarációm: int kozel [ 100,2 ];
és ezt írja ki :
[warning] left-hand operand of comma has no effect
ez meg mért van?

másik:
van egy vonalam (aminek nem tom a meredekségét) és az bezár egy szöget az y tengellyel. Azt a szöget tom. Ebbõl hogy lehet kiszámolni az egyenes meredekségét? Ki lehet az biztos, szal ezzel ne gyertek

Elõre is köff!


Üdv: --==[B@z]==--

Idézet

---

WToma írta:
Lehet hogy én nem látom át ami itt megy a szögfüggvényekkel, de: általában [ez itt egy kifejezés, konkrét szám]-1 az az 1/[kifejezés]-t jelenti, mert az egy hatványozás. Viszont függvények esetén a függvény inverzét (tehát azt a g függvényt, amire teljesül, hogy g(f(x))=x) szintén az f-1(x) jelöléssel adják meg.
Ezek szerint a tangens (tg vagy C-ben: double tan(double)) inverzét, az arkusztangenst (arctg vagcs C-ben: double atan(double)) szintén jelölhetjük tg-1(x)-szel, csak minek, ha egyszer van külön neve is.
És az is igaz, hogy a C/C++ szügfüggvények radiánban számolnak. A fok-radián átszámolást a következõk szerint lehet elvégezni:
rad=(fok/180)*pi;
fok=(rad/pi)*180;
Tehát. Ha te azt szeretéd megtudni, hogy mi az a szög fokban, aminek a tangense éppen 2, akkor:
szog_fokban=(atan(2)/pi)*180;
Ha azt akarod megtudni, hogy mi a tg(pi/6) reciproka, akkor akarmi=1/tg(pi/6);
Húdesokatírtampont.
Toma


ps. látom jólmegaszontam, mert nem lehet felsõ indexet csinálni. A fórummotor monjon le!(Módosította WToma 2005.04.07. 16:52-kor)

---

hali!
köff, majd kipróbálom

Üdv: --==[B@z]==--

Lehet hogy én nem látom át ami itt megy a szögfüggvényekkel, de: általában [ez itt egy kifejezés, konkrét szám]-1 az az 1/[kifejezés]-t jelenti, mert az egy hatványozás. Viszont függvények esetén a függvény inverzét (tehát azt a g függvényt, amire teljesül, hogy g(f(x))=x) szintén az f-1(x) jelöléssel adják meg.
Ezek szerint a tangens (tg vagy C-ben: double tan(double)) inverzét, az arkusztangenst (arctg vagy C-ben: double atan(double)) szintén jelölhetjük tg-1(x)-szel, csak minek, ha egyszer van külön neve is.
És az is igaz, hogy a C/C++ szügfüggvények radiánban számolnak. A fok-radián átszámolást a következõk szerint lehet elvégezni:
rad=(fok/180)*pi;
fok=(rad/pi)*180;
Tehát. Ha te azt szeretéd megtudni, hogy mi az a szög fokban, aminek a tangense éppen 2, akkor:
szog_fokban=(atan(2)/pi)*180;
Ha azt akarod megtudni, hogy mi a tg(pi/6) reciproka, akkor akarmi=1/tg(pi/6);
Húdesokatírtampont.
Toma


Na azért módosítottam megint, mert mos már lehet felsõ (sup html tag) és alsó indexet (sub html tag) csinálni.(Módosította WToma 2005.04.17. 10:47-kor)

Megnézetem és az atan nem azt jelenti, mint a tan-1.
a tan-1 az 1/tan.
ÉS nekem az a bajom, hogy ez a radiánból fokba átszámolás nagyon pontatlan. Elvileg 45-nek kéne kijönnie, ehelyett 57.8 vagy valami ilyesmi.... LOL

Üdv: --==[B@z]==--

---

Szia!

A radián számolásakor a pontosságot csak az határozza meg, hogy milyen pontos a pi amivel számolsz. De mondjuk akkor sem jöhet ki 45 helyett 57.8, szóval ott valami más probléma lesz.

A tan(45) az ugye 1.

Ami C++ban:

tan(45*pi/180)=1

az arcus tangensnél (ami nem egyenlõ az 1/tan-al) pedig atan(1)=45 nek kell kijönnie igaz?

Ez C++ban:

atan(1)/(pi/180)=45

Az 1/tan(1) a számológép szerint is 57.2

Remélem segítettem, de lehet, hogy elbeszélünk egymás mellett



(Módosította Bender 2005.04.07. 09:48-kor)

Idézet

---

Bender írta:
(Baz from the LKS írta:
Halihó!
Kössz mindenkinek ezt a lelkes segítséget!
Jó tudni, hogy vannak ilyen programozók!
Nah zsóval én tanulom könyvbõl az OOP-ot, nem sokat értek belõle, de nem is baj
Majd megértem
Nah, ahogy mondtátok, hogy nem egy fájl meg blablabla, akkor ezek szerint én oopot használok
Jó tudni
Mivel egy olyan project van most felvéve, ami számolgat és már 4 forrásfájlból áll !

Nekem az atan teljesen más eredményt hozott ki mint a számológépem! Pedig az a jó! Sõt még a sima tan is mást hozott ki!!!!! :aaa:



Üdv: --==[B@z]==--)Ez talán azzal lehet összefüggésben, hogy a tan és az atan is radiánban kezeli a szöget?

Tehát nem

tan(30)

hanem

tan(pi/180*30)

az atan-nál meg ugye az eredmény van radiánban, amit el kell osztani pi/180-al.(Módosította Bender 2005.04.04. 09:10-kor)(Módosította Bender 2005.04.04. 09:15-kor)

---

Hali!
Megnézetem és az atan nem azt jelenti, mint a tan-1.
a tan-1 az 1/tan.
ÉS nekem az a bajom, hogy ez a radiánból fokba átszámolás nagyon pontatlan. Elvileg 45-nek kéne kijönnie, ehelyett 57.8 vagy valami ilyesmi.... LOL

Üdv: --==[B@z]==--

Idézet

---

Baz from the LKS írta:
Halihó!
Kössz mindenkinek ezt a lelkes segítséget!
Jó tudni, hogy vannak ilyen programozók!
Nah zsóval én tanulom könyvbõl az OOP-ot, nem sokat értek belõle, de nem is baj
Majd megértem
Nah, ahogy mondtátok, hogy nem egy fájl meg blablabla, akkor ezek szerint én oopot használok
Jó tudni
Mivel egy olyan project van most felvéve, ami számolgat és már 4 forrásfájlból áll !

Nekem az atan teljesen más eredményt hozott ki mint a számológépem! Pedig az a jó! Sõt még a sima tan is mást hozott ki!!!!! :aaa:



Üdv: --==[B@z]==--

---

Ez talán azzal lehet összefüggésben, hogy a tan és az atan is radiánban kezeli a szöget?

Tehát nem

tan(30)

hanem

tan(pi/180*30)

az atan-nál meg ugye az eredmény van radiánban, amit el kell osztani pi/180-al.(Módosította Bender 2005.04.04. 09:10-kor)(Módosította Bender 2005.04.04. 09:15-kor)

Halihó!
Kössz mindenkinek ezt a lelkes segítséget!
Jó tudni, hogy vannak ilyen programozók!
Nah zsóval én tanulom könyvbõl az OOP-ot, nem sokat értek belõle, de nem is baj
Majd megértem
Nah, ahogy mondtátok, hogy nem egy fájl meg blablabla, akkor ezek szerint én oopot használok
Jó tudni
Mivel egy olyan project van most felvéve, ami számolgat és már 4 forrásfájlból áll !

Nekem az atan teljesen más eredményt hozott ki mint a számológépem! Pedig az a jó! Sõt még a sima tan is mást hozott ki!!!!! :aaa:



Üdv: --==[B@z]==--

Idézet

---

HomeGnome írta:
Nagyobb projecteknel (tobb ember, tobb ev, fizetnek erte), meg mas oprendszerre portolasnal, es foleg ha elore tudjuk hogy a kovetkezo termekben ujra fel lesz hasznalva a programkod, vilagos hogy jol atlathato rendszert szeretne az ember. De teszem azt, az ember elso, egyszeri garazsprojectes jatekanal, amit tenyleg csak sajat maganak ir, peldaul hacsak kepernyofelbontast szeretne valtani, maris OOP szemeleltet kovetel meg a DirectX.. Mig ugyanez a regi szep idokben csupan par utasitas volt asm-ben, es akkor is szulettek egy ember altal keszitett szinvonalas jatekok mindefele OOP mutatvanyok nelkul is.. Na mindegy, nem az OOP ellen vagyok, de ebbol a szempontbol tokeletesen meg tudom erteni B@z-t: az OOP feleslegesen van rankeroltetve.. (Rank, kicsikre!)

HomeGnome

---

Az OOP-nek nagy hibája az, hogy eleinte még a tanulási folyamatban (pláne, ha iskolában kötelezõ) az ember nem nagyon tudja mihez kötni, és ettõl borzasztóan tudja "nem érteni". Ilyen az SQL-is. Megtanítanak egy csomó módszert anélkül, hogy bárki értelmesen meg tudná fogalmazni, hogy tulajdonképpen hol jelenik meg ez a dolog, és mihez kapcsolódik miért. Talán ezért tûnik ez a kelleténél bonyolultabbnak vagy kötöttebbnek.

Pedig tulajdonképpen ezek egszerû szabájok, amiket azért találtak ki, hogy mindenkinek könnyebb legyen.

"A szabály nem arra való, hogy beléje börtönözd magad; legyen lakószobád, szabadon ki-be járhass, dolgod szerint.
A szabály semmit sem ér, ha elhatározás-szerûen viseled, ha komoran és konokul csörömpöl rajtad; a szabály akkor jó, ha érzéseidbe ivódik és finoman, hajlékonyan támogat."
(Weöres Sándor, bár Õ nem az OOP-re írta ezt, de erre is megfelel

Pl. az, hogy az ember lépten nyomon OOP-be ütközik, és ilyen módon rá van kényszerítve a technikára, az lehet bosszantó dolog is, ha azt látod benne, hogy "már megint el van bonyolítva valami szükségtelenül". De ugyanakkor ha jobban megfigyeled, akkor leírja magát és szinte kínálja magát egy jól megtervezett osztáj. Egybõl látod, hogy milyen kívülröl befolyásolható paraméterei vannak, milyen "gombok vannak a vezérlõpulton".

Persze mindezektõl nem lesz könnyebb felfogni az OOP-t eleinte, de biztosítok mindenkit arról, hogy ez olyasmi aminek késõbb örülni szokott az ember, hogy tudja. Kétségbe sem kell esni, ha az ember nem igazán ért valamit benne, mert ha elég idõt töltesz programozással, akkor ez magától rád ragad ígyis-úgyis.

De egyébként én is C++ könyvbõl próbáltam OOP-t tanulni annak idején (egyszerre a kettõt , és nagyon nem értettem. Szerintem ez valahol azért a könyvek hibája is. Fõleg a C könyvek nagyon gyengék ebbõl a szempontból. Szóval ezek nem olyan könyvek (szerintem) amiket ha elolvasol, akkor megtanulsz belõle programozni. Vagy legalábbis biztosan nem ez a legrövidebb út a programozni tudáshoz Ezek inkább akkor jók, amikor már csinálsz valamit, és felcsapod a 172-ik oldalt, hogy megnézd hogyan kell vonalat húzni.

Más nyelvekre vannak jobb könyvek is. pl.
a Baga Edit féle Delphi könyv az kiemelkedõen jó, vagy ha említhetek egy klasszikust, a Peter Norton féle Assembler könyv is nagyon jó volt. Persze ez utóbbiban még nem volt OOP

De lehet, hogy tud valaki jó OOP és/vagy C++ könyvet kezdõknek.. Tud?

Ahoy

Én az én nézõpontomból közelítem meg a dolgot:
Mi (2 programmer) nem programozunk objektum orientáltan. Egyrészt, mert ketten vagyunk. Másrészt, a több file, akárhogy is van, idegesítõ, hogy ugrálgatni kell köztük, mert az osztályok mindegyike máshol lakik. (Ezért rühelltem a MFC-t visual c++-ban). Harmadrész nem sz@rok magam alá azzal, hogy elrejtem magam és programozótársam elõl a változókat. Meg különben sem vagyok hajladndó minden változóhoz értékadó eljárást írogatni. Meg ha objektuok tervezésénél valamire nem gondol az Mber, akkor úgy megszíja mint a torkosborz, mert akkor nem látják egymást esetleg a klasszok, azt jönnek a kedves kis pointerekre mutató pointerek. Nálunk struktúrált programozás folyik, és az általánosabb parancsok, amik a kirajzolást végzik például, pascalos unitok módjára vannak belinkelve include-dal. Meg itt lehet olyat, hogy két azonos típusú rekord közé = jelet írok, és a cucc tudja mi a dolga. Nem kell operátorokat túlterhelni. Ha olyasmire van szükségem jön rá egy global eljárás oszt jóvan. Itt lát minden mindent. Gond még nem volt belõle. Mondjuk azt aláírom, egy idegennek sem ajánlom, hogy megpróbáljon eligazodni a fõ forrásfájlban. De nem is azért van.
No lényeg az, szerintem osztályok nálkül is lehet hatékonyan, viszonylag bonyolult játékprogramot írni. (Meg mondjuk a directx-es osztályok itt is megvannak, csak be vannak nyomva rekordokba, meg globalba, azt kussba vannak)
De az is igaz, hogy én nem vagyok túlképezve az objektum orientált progizásból, így a véleményem nem objektív. Csak pár tapasztalat.

ST Programmer

Mondtam én valahol ezt?
Tma

Okes, persze nem folosleges, de az ember a jatekprogramozast sztem nem 3d engine irasaval kezdi..

HomeGnome

Szerintem nem így van, mármint hogy kicsiknek fölösleges. Valóban fölösleges egy képernyõfelbontás-váltáshoz, de pl. ha magát a játékrendszert írod, akkor nagyon nagy segítséget jelentenek az osztályok, öröklõdés, virtuális függvények, stb. Egyértelmûvé teszik hogy mi mibõl hogyan következik. A DX-ben a nagyon erõs OOP-s kötõdés engem is zavar, fõleg látva, hogy más rendszer is lehet ugyanolyan jó (OpenGL). De pl. amikor egy játék grafikai megjelenítésén dolgozom (alias grafikus motor) azt már mindenképpen OOP-sre csinálom. Azt hiszem, pont ez zavar a DX-ben, hogy tulajdonképpen egy elõre elkészített objektumszerkezetet kell "lefordítani" a saját "nyelvemre", ahelyett, hogy utasításonkén építhetném föl.
Amúgy hogy valakinek bejön-e az OOP vagy sem, az gondolom háttér, gyakorlat, és személyes ízlés dolga. Nem csodaszer persze.

Nagyobb projecteknel (tobb ember, tobb ev, fizetnek erte), meg mas oprendszerre portolasnal, es foleg ha elore tudjuk hogy a kovetkezo termekben ujra fel lesz hasznalva a programkod, vilagos hogy jol atlathato rendszert szeretne az ember. De teszem azt, az ember elso, egyszeri garazsprojectes jatekanal, amit tenyleg csak sajat maganak ir, peldaul hacsak kepernyofelbontast szeretne valtani, maris OOP szemeleltet kovetel meg a DirectX.. Mig ugyanez a regi szep idokben csupan par utasitas volt asm-ben, es akkor is szulettek egy ember altal keszitett szinvonalas jatekok mindefele OOP mutatvanyok nelkul is.. Na mindegy, nem az OOP ellen vagyok, de ebbol a szempontbol tokeletesen meg tudom erteni B@z-t: az OOP feleslegesen van rankeroltetve.. (Rank, kicsikre!)

HomeGnome

Szerintem elég Bender jól megfogta a dolgot, csak egy kis adalékot szeretnék hozzátenni. Az OOP helyes használatakor nagy elõny, hogy másik platformra (új oprendszer, új gép stb.) nagyon megkönnyíti a program átírását.
Nem is olyan régen vállalkoztam rá hogy egy C++ programot Linuxról Windowsra portolok. Azonban miután belenéztem a kódva, sírva szaladtam a szoba másik felébe, ugyanis a main függvény több, mint 700 soros volt, és nem ez volt az egyetlen ilyen. Elvileg volt még valami objektumokba rendezés is, de ugye hiába hozunk létre objektumokat ha azoknak 100 adattagja és a konstruktoron kívül 1 db 500 soros tagfüggvénye van...
Nem hogy OOP-nek, még struktúrának is alig-alig volt nyoma a kódban. Szerencsére az egyetlen nem Windows kompatibilis rész a grafika volt, de mivel a kód legkülönbözõbb részeiben is elõfordultak glx hívások, az egésszel dolgozni nem volt egy nagy élmény.
Toma

Idézet

---

Baz from the LKS írta:
HY!
Akkor mi a lényege?
Olvasok most egy Cpp könyvet és benne van az oop, mindenféle barát, public, privát, protected függvénnyel, de nem látom az értelmüket...
Ez a bajom az egésszel..
SZal mit használunk ebbõl egy játékfejlesztés során és miért elengedhetetlen, hogy tudjuk?


Üdv: --==[B@z]==--

-=[Készül az M3 Underground, lehet jelentkezni a fejlesztéshez. A doksi elérhetõ: http://web.axelero.hu/andreas101/BKV.doc ]=-

---

Szia!
Az OOP erejét igazán akkor érzi meg az ember, amikor meglát egy programot, amit 6 ember ír 2 éve Szerintem mindenki megalkothatja a maga "OOP lényege" filozófiáját (most én is megpróbálom

A legnagyobb haszna szerintem ott van, hogy rákényszerít arra, hogy a funkciókat és a CSAK HOZZÁJUK TARTOZÓ adatokat rendben tartsad. Pl. ha játék fejlesztésrõl beszélünk, akkor a leg elemibb pl. mondjuk a grafikai megoldások és mondjuk a dinamikai számolások szétválasztása. Ezek jól szétválaszthatóak két egymással részben kommunikáló egészre. Elõnye az, hogy nem keverednek össze a szorosan a grafikai megoldáshoz tartozó adatok és megoldások (pl. egy textúra pointer, fényforrás beállítások, rajzolások s.t.b.) a szorosan a dinamikai számoláshoz tartozó megoldásokkal (pl. a gravitáció ereje, az objektum forgátónyomatéka, gyorsulás számolás s.t.b.) Egy ilyen struktúrált rendszerben hibát is sokkal kényelmesebb keresni, mert mindíg koncentrálhatsz az adott részre, és biztos lehetsz benne, hogy mondjuk a grafikai rutin kellõs közepén nem maradt ott véletlenül valami ami egy hibás gyorsulást ad az ûrhajódnak. Biztos lehetsz benne... feltéve, hogy privateként deklaráltad a változókat

Az kód újra hasznosítás nagyobb mutatvány, mert nagyon ritka az, hogy nem kell még is csak valamiért belepiszkálni az újrafelhasznált kódba, de ilyenkor is óriási segítség az, ha nem egy 12ezer soros programból kell függvényenként kimazsolázni egy adott funkció csoportot.

Meg amikor valakinek oda kell adni a kódot, akkor nem lesz rosszul amikor meglátja, hanem azt fogja csak gondolni, hogy "Hú, hála istennek, hogy csak ezt a függvényt kell meghívni" És te is nyugodtan alszol, mert tudod, hogy nem fog azzal tölteni 3 hónapot, hogy a levegõ sûrûségét jelzõ változóba próbálja bele erõltetni az úrhajó kóórdinátáit (és közben azon dühöng, hogy milyen bugos ez a vacak

Szumma szummárum olyasmi az OOP a programozásban mint amikor könyvtárokba válogatod mondjuk a (nem tudom miket szoktál könyvtárokba válogatni) szóval lehetne tulajdonképpen minden fájl egybõl a C:-n is, de még sincs ott, és nem is lenne jó, ha ott lenne

Én is utálok mindent amit nem én találtam ki, de néha érdemes az oriások vállára állni, és messzebb látni általuk

Abbahagytam

Bender

(Módosította Bender 2005.04.03. 05:59-kor)(Módosította Bender 2005.04.03. 06:00-kor)

HI

Ha arkusz tangensre gondolsz, akkor azt ezzel lehet :

double atan( double x );

A többi szögfüggvény ellentettjét is ehhez hasonlóan az asin, acos hívásokkal lehet meghatározni.

nagyy

Idézet

---

Regx3 írta:
Jaja, szerintem is az újrafelhasználhatóság, és az átláthatóság miatt jobb, mintha nem használnád.

---

Aha..
De még mindig, hogy mit tesz, azt nem tom..
Nem érdekelnek a mindenféle barát függvények, mert átgondolva, nem is annyira szükséges..
Nem több száz kódból fog állni a progi, tehát nem számít annyira a méret, akkor meg mért legyen privát a függvény...
Nah mind1, megtanulom, aztán ha majd kell akkor használom..
És még 1 kérdés:
Van ugye a tangens számítás: tan(1) vagy ilyesmi..
Mind1
De hogy lehet tangens -1-et számolni??
Nem ugynazt jelenti mint a tan(1)*-1, mert az hülyeség..
Szal hogy lehet c-ben ilyet számolni??


Üdv: --==[B@z]==--

Jaja, szerintem is az újrafelhasználhatóság, és az átláthatóság miatt jobb, mintha nem használnád.

Idézet

---

Baz from the LKS írta:
HY!
Akkor mi a lényege?
Olvasok most egy Cpp könyvet és benne van az oop, mindenféle barát, public, privát, protected függvénnyel, de nem látom az értelmüket...
Ez a bajom az egésszel..
SZal mit használunk ebbõl egy játékfejlesztés során és miért elengedhetetlen, hogy tudjuk?


Üdv: --==[B@z]==--

-=[Készül az M3 Underground, lehet jelentkezni a fejlesztéshez. A doksi elérhetõ: http://web.axelero.hu/andreas101/BKV.doc ]=-

---

Nem elengedhetetlen (ilyen mellesleg sztem nincs is...), de sok dologban tényleg nagy előny/segítség, akkor meg miért ne használnád???
Remélem a nálam sokkal okosabbak is írnak majd ide, mert én még nem használom olyan régóta az OOP-ot, de nekem az egyik legnagyobb előny, hogy a megfelelő tervezés után sok kódot nem kell töbször is megírni, és sokkal átláthatóbb, mint a nem OOP-os változat. Igazából én már mindenhol OOP-ot használok, ahol nagyobb projectekkel dolgozok, mert különben elvesznék a rengeteg kódban...

/ ShAdeVampirE /

HY!
Akkor mi a lényege?
Olvasok most egy Cpp könyvet és benne van az oop, mindenféle barát, public, privát, protected függvénnyel, de nem látom az értelmüket...
Ez a bajom az egésszel..
SZal mit használunk ebbõl egy játékfejlesztés során és miért elengedhetetlen, hogy tudjuk?


Üdv: --==[B@z]==--

-=[Készül az M3 Underground, lehet jelentkezni a fejlesztéshez. A doksi elérhetõ: http://web.axelero.hu/andreas101/BKV.doc ]=-

Ja, ez egy "user-defined" változótipus, nem objektum. Ilyet a Qbasic is tud.

Szia B@z!

Termeszetesen az objektumorientalt szemlelet ennel kicsit tobbet jelent. A lenyege, hogy az osszetartozo adatokat es fuggvenyeket egybezarjuk, ezek lesznek az osztalyok. Az erzekeny valtozokat elrejtjuk, es fuggvenyeken keresztul valtoztatjuk, ami biztonsagosabb es peldaul hibakezelest is beepithetunk. Aztan ott van az oroklodes, amely soran a gyermekosztalyokat uj tulajdonsagokkal ruhazhatjuk fel, es meg sokminden mast is jelent az OOP.. En azt javaslom inkabb olvass el egy konyvet a temarol, mert osszetettebb a dolog annal, minthogy az ember magatol rajojjon a lenyegre...

HomeGnome

HY!
Lehet, hogy most hülyének néztek, de mit is jelent az OOP azon felül, hogy ojjektum orientált programozás?
csak annyi, hogy lehet .x .y .z -lni?
PL:

class iranyok:
{
int x;
int y;
int z;
}
iranyok ellenor;

ellenor.x=10;

CSak ennyi???
Vagy van valami más lényege is?
Mert OK, ez sokkkal megkönnyíti a fejlesztést, de azért annyival nem, hogy mindenkit erre erõszakolnak rá...
lehetne így is, bár így sok lenne a deklarációs rész:

int ellenor_x;
int ellenor_y;
int ellenor_z;

Igaz így sokat kell írni, dehát miért találták ki a CTRL+C, CTRL+V megoldást....

Naszóval lécci magyarázzátok el....

Üdv: --==[B@z]==--

-=[Készül az M3 Underground, lehet jelentkezni a fejlesztéshez. A doksi elérhetõ: http://web.axelero.hu/andreas101/BKV.doc ]=-

Ohh, nem akar senki fejleszteni?
Senki nem ismeri a Dev C++ nyelvet?
Senki nem lelkes?
Üdv:

B@z from the Linuks Team

HY!
BÁRKI AKI AKAR SEGÍTENI NEKÜNK, OLVASSA EL EZT:
http://web.axelero.hu/andreas101/BKV.doc
By!

B@z from the Linuks Team

HY!
Már elkezdtem (papíron) azt a zizét írni..
Szal.
Hogy lehet valahogy max fájlból md3 fájlt csinálni?
Mert amikor exportálom 3ds-be, elveszti az animét.
Üdv:B@z

B@z from the Linuks Team

Idézet

---

Baz from the LKS írta:
Hy!
Akkor benne vagytok?
A filmet nem láttam, de már sokan mondták ezt.
Szal bevállalja, igen, vagy nem
Üdv

B@z from the Linuks Team

---

Én most nem, mert éppen mást csinálok. Mellesleg szerintem mielõtt a csapattoborzásba fogsz, ülj le egy kicsit a Word elé (opcionálisan OpenOffice etc. ) és írd le részletesen a gondolataidat errõl, az, hogy van egy jó alapötlet, még nem jelent semmit (saját tapasztalat).
Toma

Hy!
Akkor benne vagytok?
A filmet nem láttam, de már sokan mondták ezt.
Szal bevállalja, igen, vagy nem
Üdv

B@z from the Linuks Team

gedit+gcc+SDL+Opengl=Király progi
Jó látni hogy más is tevékenykedik Linux alatt.
Éljen TUX :ugral:

Helló

A Kdevelop jó döntés.
De egy egyszerû editor is megteszi.
Kate mcedit
Szintén érdemes kipróbálni az anjuta-t. http://anjuta.sourceforge.net/anjuta.php?page=home

Az opengl jó döntés.
A DirectX Mellet vagy helyett érdemes megismerkedni az sdl-el.
http://www.libsdl.org/
Hasonló a directx-hez,de amit ebben írsz meg az módosítás nélkül fut szinte mindenen.
Helló


Unger Gábor
unger_gabor@freemail.hu
[url]http://www.lgpg.linuxuser.hu(Módosította[/url] magic 2005.02.20. 00:47-kor)

Idézet

---

b3nc3 írta:
(WToma írta: )Hát ahogy látom te linux alatt nyomod. Nos én is így akarom. Eddig a kdevelopot sikerült letöltenem, de szivesen használnám a dev-c++t is, feltéve ha mondasz egy csomagnevet, uhum van, és nagyon király. Belöttem a videókarit, ugyhogy semmi akadálya, hogy átszokjak linuxra. Még nagyon kezdõ vagyok c++ terén, de ha jól tudom, akkor c++-ban lehet programozni openglt, és directx-et, nos engem leginkább talán ezek érdekelnének, de az alapok is persze, már amennyiben szükségesek hozzá. Megrendeltem egy könyvet, az a c++ nyelvrõl szól, remélem majd hasznát tudom venni. Ha tudsz ajánlani még könyvet, azt megköszönném. A windowsos c++ fejlesztésrõl nem a legjobbak a véleményeim. Érdekelnének azok a dev-c++-os pluginek is vagy mik. Remélem nem értettelek rélre.

Na, köszi az eddigi eligazítást!

---

látom mégis félreértettelek. Sebaj, szoval én linux alatt szeretnék megoldani pár programot, ugy vélem, hogy itt talán gyorsabb. bár dev-c++-nek van linuxos változata is, mégis egy kdeveloppal fogok sztem fejleszteni.

Idézet

---

WToma írta:

---

Hát ahogy látom te linux alatt nyomod. Nos én is így akarom. Eddig a kdevelopot sikerült letöltenem, de szivesen használnám a dev-c++t is, feltéve ha mondasz egy csomagnevet, uhum van, és nagyon király. Belöttem a videókarit, ugyhogy semmi akadálya, hogy átszokjak linuxra. Még nagyon kezdõ vagyok c++ terén, de ha jól tudom, akkor c++-ban lehet programozni openglt, és directx-et, nos engem leginkább talán ezek érdekelnének, de az alapok is persze, már amennyiben szükségesek hozzá. Megrendeltem egy könyvet, az a c++ nyelvrõl szól, remélem majd hasznát tudom venni. Ha tudsz ajánlani még könyvet, azt megköszönném. A windowsos c++ fejlesztésrõl nem a legjobbak a véleményeim. Érdekelnének azok a dev-c++-os pluginek is vagy mik. Remélem nem értettelek rélre.

Na, köszi az eddigi eligazítást!

"Nekem az lenne a kérdésem, ha c++-ban akarok (játékot) fejleszteni, akkor mit kell tanulnom, milyen programot kell használnom?"
Ez olyan, mint a "Hogyan kell házat építeni?" Kár, hogy éppen az a cikk nincs fönt Na mindegy, gonosz vagyok.

El?ször is: hogy milyen környezetet használsz, az csak rajtad múlik. Környezet alatt értve itt a hardvert?l az operációs rendszeren és a fordítótól át a kódszerkeszt?ig és a használt könyvtárakig gyakorlatilag mindent.
A ma elterjedt operációs rendszerek mindegyikéhez létezik C++ fordító, nem is egy. Úgyhogy az egyszer?ség kedvéért itt most fölteszem, hogy Windows alatt akarsz majd dolgozni, legalábbis eleinte.
A lehet?ségek tárháza még itt is nagyon széles. Csak néhány példa, a teljesség igény nélkül:

-Mivel ez egy Dev-C++ topik, talán ezt emelem ki els?nek. Helytelenül szokás fordítónak neveni, valójában egy kellemes kódszerkeszt?, ami fordítónak a mingw-t vagy a cygwin-t használja (mind a 2 gcc alapú fordító). Az ingyenességet és a nyílt forráskódot kedvel?k körében nagyon népszer?. Én is ezt használom. Könnyen használható, és a mingw fordítóhoz egyre több és több jól dokumentált könyvtár érhet? el. Plug-in-ek segítségével Delphi szer? vizuális felületszerkeszt?je is van. Ha ezt választod, akkor kiindulásként a http://www.bloodshed.net és az sf.net/projects/dev-cpp oldalakat nézd meg.

-Microsoft Visual C++: Windows alá a legrégebbi C++ fordítók egyike, szinte szabványnak számít a Windowsra való fejlesztésben. A C++ szabvánnyal már nem ilyen jó a viszonya. Az MSDN-en (msdn.microsoft.com) rengeteg info érhet? el hozzá. Szinte minden C++ könyvtárnak van Visual C++ verziója is. Hivatásos fejleszt?k körében nagyon népszer?, én annyira nem szerettem meg. Az új Visual C++ .Net verzióval .Net keretrendszerre is lehet vele fejleszteni.

-Borland C++ Builder: A Delphi C++-ban. Könnyen és gyorsan lehet vele grafikus felhasználói felületeket készíteni, valamint sok-sok el?re elkészített komponens jár hozzá, hálózattól az adatbáziskezelésen át Office dokumentumok kezelését segít? osztályokig. Küls? könyvtárak tekintetében nem áll olyan jól, mint az el?z? kett?, és a Borland beszüntette a fejlesztését. Utolsó verziója a 6.0. Jó helpje van, de kevés az online dokumentáció.

Magáról a C++-ról: ha már foglalkoztál vele, és érted az alapokat, akkor nagyon sokat lehet tanulni:
-más C++-ban írt játékok forrásából
-online tutorialokból
Ha még egészen kezd? vagy benne, elvileg akkor is meg lehet tanulni csak a netr?l, de nekem az igazi megértést és tudást a nyomtatott könyv használata adta.
Könyvek pl: Bruce Eckel: Thinking in C++ (ez online is elérhet?, ingyenes); Bjarne Stroustroup: A C++ programozási nyelv. (ez a C++ "Bibliája"

Toma

Idézet

---

WToma írta:
(Baz from the LKS írta:
HY!
Nem akartok segíteni egy BKV szimulátor írásában. A léynege az lenne, hogy mész egy ellenõrrel és megkeresed a lógókat.
Üdv

B@z from the Linuks Team)Akkor már inkább rögtön Kontroll gém
Amúgy nem rossz ötlet.
Toma

---

Nekem az lenne a kérdésem, ha c++-ban akarok (játékot) fejleszteni, akkor mit kell tanulnom, milyen programot kell használnom? Valaki leírná részletesen? Köszi!

Idézet

---

Baz from the LKS írta:
HY!
Nem akartok segíteni egy BKV szimulátor írásában. A léynege az lenne, hogy mész egy ellenõrrel és megkeresed a lógókat.
Üdv

B@z from the Linuks Team

---

Akkor már inkább rögtön Kontroll gém
Amúgy nem rossz ötlet.
Toma

HY!
Nem akartok segíteni egy BKV szimulátor írásában. A léynege az lenne, hogy mész egy ellenõrrel és megkeresed a lógókat.
Üdv

B@z from the Linuks Team

Hi!
Nem tudtok egy BSP loadert?
Üdv:B@z

B@z from the Linuks Team