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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] > 40 < [44]
bmateusz - Tag | 121 hsz       Online status #111418   2009.05.28 10:56 GMT+1 óra  
Én is pont Beej tutorialját tanulmányozom, le lehet fordítani, le van írva a FAQ-ba hogy hogyan. Van ami nem megy persze pl. fork(), meg még jó pár függvény és struct. Meg kell keresni, mivel lehet helyettesíteni. A stream példát sikerült működésre bírnom, amit nem ismert fel, kikommenteztem, és csatlakozott! El se hittem
De a lényeg, meg lehet csinálni, csak kell hozzá pár #ifdef WIN32

szerk: Nekem érhetőbb az angol ha programozásról van szó, esetleg nézd meg azt is: http://beej.us/guide/bgnet/

   
Eldor - Tag | 162 hsz       Online status #111415   2009.05.28 10:40 GMT+1 óra  
Köszi a linkeket, már elkezdtem tanulmányozni.
Tudom úgy csinálni a kommunikációt a két számítógép között, hogy a forráskódot le lehessen fordítani WIndowsra és Linuxra is? A második link szerint nem lehet.

   
gaborlabor - Moderátor | 4449 hsz       Online status #111411   2009.05.28 09:30 GMT+1 óra  
Eldor - Tag | 162 hsz       Online status #111410   2009.05.28 09:21 GMT+1 óra  
Hello!

Találtam számomra egy újabb problémás dolgot.
Az érdekelne, hogy miként kommunikál két számítógép egymással interneten vagy LANon keresztül. Sajnos ezekről a dolgokról lövésem sincs. Tud valaki valami jó tutorialt C-ben, amiből meg tudom tanulni ennek legalább az alapjait? Jól jönne a játékomhoz.

Eldor

   
Eldor - Tag | 162 hsz       Online status #110098   2009.05.12 02:07 GMT+1 óra  
Köszönöm fáradozásaid. Sokat segítesz vele.

   
sirpalee - Tag | 1282 hsz       Online status #110090   2009.05.11 13:12 GMT+1 óra  
Eleg egyszeru, kuldenek peldakodot hozza, de sajnos csak telorol erem el a netet, es itt nem fogok tudni eleg kodot bepotyogni, de holnap melohelyrol feltoltok egy tutorialt.
raytraceisten és übermedic
   
Eldor - Tag | 162 hsz       Online status #110088   2009.05.11 12:37 GMT+1 óra  
Ez a megoldás már nagyon tetszik. Már csak az a probléma, hogy fogalmam sincs, miként lehet plugint írni Maya alá. De keresgélek neten, biztos találok hozzá valami használható tutorialt. Köszönöm a segítséget.

   
sirpalee - Tag | 1282 hsz       Online status #110082   2009.05.11 10:41 GMT+1 óra  
Jah ertem a felallast, ehez legegyszerubb gyorsan irni egy sajat exportert pl maya ala. Kb egy fel ora alatt megvan es hasznalhatsz olyan file felepitest amilyet csak szeretnel es emiatt az importer trivialis.
raytraceisten és übermedic
   
Eldor - Tag | 162 hsz       Online status #110081   2009.05.11 09:18 GMT+1 óra  
Köszönöm válaszod, de szerintem félreértettél, vagy, ami még valószínűbb: én nem voltam egyértelmű. Én a játékomba szeretnék beolvasni és feldolgozni valamilyen 3d-s fájlt ( OBJ, ASE stb. ), amit előzőleg valamilyen modellező programmal csináltam ( 3D Studio Max vagy Maya ). Ehhez kéne nekem valamilyen 3d fájlformátum felépítése, hogy tudjak rá írni egy feldolgozó programrészt, amit a játékomba beillesztek. Így, amit Mayával, vagy 3DSMax-al csináltam, be tudom rakni pályának, vagy csak egy tárgynak.

   
sirpalee - Tag | 1282 hsz       Online status #110077   2009.05.11 08:01 GMT+1 óra  
Eldor, nagyon könnyen lehet írni maya alá beolvasót, első körben a legegyszerűbb megoldás, hogy nem egy importer exportert írsz, hanem egy MPxCommand osztályból csinálsz egy egyszerű mel parancsnak kinéző cuccot, aminek egy paraméterrel meg tudod adni a beolvasni kívánt fájlt.

Aztán meg az MFnMesh::create (...) függvénnyel simán létre tudod hozni a mesh-t a maya-n belül is. Szerintem nem bonyolult, de ha meg akarod próbálni, össze tudok dobni neked egy skeleton forrást, amire megírhatod a beolvasó részt. És az automatikusan beöltődik maya alá stb...

Ránéztem googleben de inkább ASE exporter van maya alá.

Szerk : ilyen plugint találtam max alá forrással együtt, ezt át lehet ültetni bármibe.

http://images.autodesk.com/adsk/files/asciiimp.zip

Ezt a hozzászólást sirpalee módosította (2009.05.11 08:56 GMT+1 óra, ---)
raytraceisten és übermedic
   
Eldor - Tag | 162 hsz       Online status #110075   2009.05.11 07:14 GMT+1 óra  
Hello!

Tud valaki egy olyan leírást, aminek a segítségével tudok írni egy ase fájltípust beolvasó programrészt? Vagy, ha azt nem tudtok, de egy olyat tudtok, amit képes kezelni a Maya vagy a 3D Studio Max, akkor azt is megköszönöm.

Eldor

   
sirpalee - Tag | 1282 hsz       Online status #109873   2009.05.06 09:12 GMT+1 óra  
A larrabeet egyelore sehova sem sorolom, eloszor is lassam a devkitjet, aztan menjen. Tul sok az archotekturaban a buktato. Nagyreszt parasztvakitas az inteltol, mert egyelore iszonyu kuss van bizonyos parametereirol. A gpuban pont az a jo, hogy keves benne az altalanos memoriaeleres es emiatt az osszes szinkronizacio eszmeletlen gyors. Intel ezzel szemben mindent elerhetove akar tenni amivel ertekes sebesseget fognak veszteni. Lehet szabadabb programozasra, de a raytracingnel nem jelent hatranyt a gpu architektura, sot a sebesseg miatt iszonyu elonyt inkabb.

Persze ha lesz devkit beepitem en is a keretrendszerembe, es ha kaphato lesz ott fog csucsulni a fejleszto gepembe egy darab, de mivel az egesz szerkezet stream szeru feldolgozasra van optimizalva, valszeg a keaoibbiekben melle ralott dx11 es ati csucskartya megeszi reggelire, es ketszer korbefutja mire az egyaltalan felebred.

De ha nagyon sorolni akarom, akkor egy konnyen programozhato stream processing kartyanak neveznem.

En ugy latom felesleges larrabeere optimizalni mivel kepes stream szeruen is dolgozni es akkor mar nem koton magam egy olyan architekturahoz ami meg nem bizonyitott.
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #109872   2009.05.06 08:14 GMT+1 óra  
Persze, elsődleges az okos algoritmus (pl. ahogy mondod packet-ekbe szervezés) és a jó architekturális tervezés, erre kell a legtöbb időt szánni, ez tény. Az ASM-al való bíbelődés már csak hab a tortán és csak a fejlesztés későbbi szakaszában kap szerepet, amikor egyes amúgy már jól bevált és algoritmikusan jól optimalizált C++ kódokat megnézünk, hogy hogyan tudnánk lecserélni ASM-ra. ASM-al kezdeni az 'premature optimization' még nagy teljesítményigényű alkalmazásoknál is.


Idézet
Real time ray tracinghoz meg evekig nem lesz eleg a cpu, nem is a nyers ereje miatt, hanem a csigalassu memoriaja, es tul komplex felepitese miatt.


Kérdés, hogy pl. a Larrabee-t hová sorolod? GPU vagy CPU? Valahol a kettő között van A CPU-knál jóval erősebb lesz számítási teljesítményben. Ha tiszta számítási teljesítményben nem is fogja elérni a mai GPU-kat, a teljesen általános programozhatósága nagy előny. Ami kódot ma írok és többmagos CPU-n tesztelem, azt triviálisan fogom tudni portolni Larrabee-re, mert általánosan programozható x86, (igazából már eleve a Larrabee-t szem előtt tartva írom a progimat.) Kérdés, hogy az NVidia és ATI GPU-k milyen irányban fejlődnek, még az is lehet, hogy azok is elmennek az általánosan C-ben programozható in-order multi core irányba, és akkor azokra is tudok majd könnyen portolni.

Sőt igazából én olyan hibrid megoldásban gondolkodok, hogy ha a CPU elég izmos, és van elég szabadideje, akkor ő is besegíthet a renderelésbe. Egy ütemező szépen elosztja a renderelést (ray tracingnél nem nehét ez a párhuzamosítás) és a képernyő egy részét a Larrabee GPU, egy részét a többmagos CPU rendereli, ugyanazzal a C kóddal, legfeljebb kis különbségekkel, pl. a SIMD kicsit másképp működik Larrabee-n mint az SSE a CPU-n...

Ezt a hozzászólást nadam módosította (2009.05.06 08:23 GMT+1 óra, ---)
   
sirpalee - Tag | 1282 hsz       Online status #109871   2009.05.06 07:43 GMT+1 óra  
Reszben igaz, de itt is ugy tartom, hogy az sokkal tobbet tud szamitani ha van egy intrinsices, 85-90 on porgo ray traversal, viszont esszel van sugarkovetve (pontosabban minnel tobb sugarat egyszerre, nagyjaboli iranyok szerint csoportositva stb) minthogy raszanunk par honapot asm szintu optimizaciojara a rendszernek. De ebben az esetben is nem a cpuban kell gondolkozni, minek terheljunk szet egy 30 gflopsra kepes egyseget 8 giga / seces memoriaeleressel, mikot ott pihen a gepben egy 2,4 terraflopsos, 238 giga / seces memoriaeleressel rendelkezo 1600 processzoros szamito egyseg?

Real time ray tracinghoz meg evekig nem lesz eleg a cpu, nem is a nyers ereje miatt, hanem a csigalassu memoriaja, es tul komplex felepitese miatt.
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #109870   2009.05.06 06:15 GMT+1 óra  
Idézet
sirpalee :
Az asm szintű lemenést én ma már túlzásnak tartom (mármint a program egészére nézve), kisebb kódrészletekre meg ott vannak az instrinsic függvények, amik kb ugyanarra jók, csak 64 bit alatt is elérhetők (míg az inline asm nem).



Általában az ASM-ra lemenés szerintem is túlzás, hiszen egy SIMD instrinsic-ekkel teletűzdeltjól optimalizált C++ kódnál már nem könnyű (és nem is nagyon lehet sokkal) gyorsabbat írni, és fárasztó is. A ray tracing szerintem annyiból speciális, hogy ott egyetlen, viszonylag rövid kódrészlet, maga a ray traversal függvény (amikor meghatározzuk, hogy mit metsz a sugár) az annyira kritikus, hogy ott érdemes szerintem megnézni, hogy mit lehet kihozni a kézi ASM-ból. Igazából szerintem ez annyira fontos, hogy érdemes akár hónapokat tölteni azzal, hogy ennek az egyetlen függvénynek akár több változatát (C-ben is és ASM-ben is) is elkészítse az ember, és megvizsgálja, hogy melyik a legjobb.
Ez egy engine teljes kódjának elenyésző része, a többit elég C++-ban írni, bár ugyanazt a problémát ott is tervezem többféle algoritmussal is leimplementálni, hogy aztán kiválaszthassam a leggyorsabbat.)

Ezt a hozzászólást nadam módosította (2009.05.06 06:20 GMT+1 óra, ---)
   
sirpalee - Tag | 1282 hsz       Online status #109867   2009.05.06 05:01 GMT+1 óra  
Én is arra a területre gondoltam mint nadam, csak én ezzel foglalkozom munkahelyemen is, és nem elsősorban a valós idejű részével. Mi nem megyünk le asm szintre (még szerencse), viszont a memóriakezelés, foglalás tényleg fontos szerepet játszik, és sokat tud segíteni, hogy pontosan tudom mi történik, és ha nem tetszik valami lecserélem. A nagyon alacsony szintű, cache optimizációkkal (instruction, data) meg szerencsére nem kell kézzel foglalkozni, erre vannak nagyon jó kis profiler eszközök (mind intel mind amd részéről). Az asm szintű lemenést én ma már túlzásnak tartom (mármint a program egészére nézve), kisebb kódrészletekre meg ott vannak az instrinsic függvények, amik kb ugyanarra jók, csak 64 bit alatt is elérhetők (míg az inline asm nem). Kompromisszumok szempontjából szerintem a c++ ideális grafikai enginek fejlesztésére, mert egyrészt tud hardverközeliként működni (intrinsic, profiler stb), másrészt meg tervezési szinten is nagy mozgásteret enged. A managed nyelvek egyrészt vesztenek egy keveset tervezési szinten, de teljes egészében odavesznek alacsony szinten. Persze tudunk írni c++ kiegészítéseket c# alá, de annak van kb a legkevesebb értelme.

Üzleti fejlesztés, adatbáziskezelés, stb... Tökéletesen alkalmas, de a grafika más, és ezzel együtt az összes valós idejű, nagyon teljesítmény igényes megoldás.

ui : Lehet az egészet meg is írhatnám akár c#-ban, lehet gyorsabb lenne a fejlesztés, viszont nem férne bele a sebességvesztés. Nemcsak az, hogy 20 perc helyett 1 óra lenne mire leszámolódik egy képkocka (sokmagos, sokgiga ramos rendszeren), másrészt egy ilyen lassabb de gyorsabb fejlesztésű megoldás, több százezerrel megdobná évente a villanyszámlánkat . (azért egy renderfarm eszik rendesen, legutóbb két hét alatt 2000kwh-t ettek, pedig nem is ment egész nap, és itt nincs is olyan sok mag...) Inkább választom a nehezebb utat, és gyorsabb lesz, jobban örül a cég, és én is olyan dolgokat tanulok meg amit a managed elrejtene előlem. (ezért nem csodálkozom, hogy közel másfél éve nem voltam szabadságon, ha mégis, akkor is a melómat csináltam, és kb havonta van 3-4 nap amikor nem a munkámmal foglalkozom )
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #109865   2009.05.06 02:06 GMT+1 óra  
mark576:

Hogy mennyire mélyre kell leásni, az attól függ, hogy mi a feladat.
Amikor millió dollárok függenek attól (pl. real time multimédia eszközök), hogy az a piti kis dolog, ami minden egyes pixelre meghívódik az 100 vagy 200 nanoszekundumig fut, akkor bizony babrálni kell. Amikor valami egyszer fut le másodpercenként, akkor mindegy, hogy 100 vagy 200 nanoszekundumig fut.

Az adatbázis motort is ki kell valakinek fejlesztenie, és oda kell az alacsonyszintű tudás.

Pl. real time raytracing körökben, amivel most hobbyból foglalkozok, teljesen nevetséges lenne, ha valaki a 'kényelem' miatt .NET-et használna. Ilyen témákban a kényelem az utolsó szempont. Nemhogy a C++, de még az x86 ASM is túl magas szintű, mert eltakarja előled a belső pipelineokat és a cache kezelést (ok, a cache kezelésbe van minimális beleszólásod pl. prefetch utasításokkal). (A jó öreg 386 vagy méginkább egy oldscool RISC processzor az még egész alacsonyszintű volt.) Igazán komoly eredmény eléréséhez le kell menni a hardvertervezés szintre, de legalábbis a szoftver minden elemének az aktuális hadrver architektúrához kell idomulnia. Sokan legszívesebben a hardvert is módosítanák, csak azért nem teszik meg, mert üzletileg reménytelen saját hardvert elterjeszteni. De volt rá példa, hogy egyes cégek ezt megtették (pl. 3D raszterizáló kártyák elterjedése) és még lesz a jövőben is más témákban is (pl. ray tracing).

Mondom ezt úgy, hogy mindeközben a munkaheylemen Java-ban írok üzleti alkalmazásokat. A megfelelő célra a megfelelő eszközt. A lényeg, hogy ne a programozó tudása legyen a meghatározó az eszközök kiválasztásánál, hanem a feladat jellege.

Itt a JF-en nem hiszem, hogy ne lenne elég bárkinek ezek teljesítménye a projectkeikhez.
Miért kellene annyira kishitűnek lenni, hogy meg se próbáljunk olyasmiket csinálni, mint az ID software? Annyival hülyébbek volnánk, csak mert magyarok vagyunk? Az ID software most próbálkozik SVO raycasting-gal statikus scenekre. Én csak azért is SVO ray-tracinggel (nem castinggel) próbálkozok dinamikus scenekre. Nem baj ha nem lesz real-time még egy két évig, majd az lesz 2-3 év múlva, amikor 'kész' lesz. Kihívásmentes 'biztonságos' fejlesztésre ott van a munkehelyem, hobbynak valami izgalmas kell.

Amúgy ha már az optimalizáció szóba került: a jövőben a memória latency-k egyre nagyobb problémát jelentenek majd, mert ez nehezen skálázható, és egyre inkább multiprocessing elvű lesz minden hardver. Azok fogják leginkább megszívni, akik nem törődnek az adatszerkezetek memóriabeli jó elhelyezésével, memóriamanagemennttel, és az algoritmusok párhuzamosításával.

Ezt a hozzászólást nadam módosította (2009.05.06 02:27 GMT+1 óra, ---)
   
mark576 - Tag | 256 hsz       Online status #109862   2009.05.05 23:35 GMT+1 óra  
sirpalee:
Érdekes ez az elaprózás is, jó annak, aki megteheti. Nálunk a cégnél nem úgy megy, hogy minden kis apró hülyeséggel elkezdünk babrálni és lefoglaljuk az erőforrásokat ilyen piti kis dolgokkal. Én ugyan nem játékfejlesztéssel foglalkozok, de a szoftverfejlesztés az nem különbözik másutt sem. Régen még úgy voltak vele, hogy minek adatbázis motor, amikor úgyis gyorsabbra megírja kézzel magának. Aztán rájöttek, hogy nem csak gyorsabb, de hatékonyabb is a fejlesztés úgy. Ma már használunk .NET-et, entity framework-öt stb dolgokat, mert nincs se idő, se kapacitás ezekkel foglalkozni az mellett, hogy egyre látványosabb és gyorsabb programokat kell készíteni. Erre lehetne mondani, hogy ez most lassú, mert újabb absztrakciós rétegek kerültek be, de sok esetben épphogy gyorsabb ez a megoldás pl a hagyományos tárolt eljárásosnál, mivel ugyanarra a feladatra teljesen más, optimálisabb megoldást használ a rendszer. Ezeket a megoldásokat nem kell nekünk megírni, tesztelni,karbantartani, készen van. Régen még az ügyfél várt percekig egy több millió rekordos szűrésre, ma már ez azonnal kell. Nem lehet lassú a program és lehetőleg 3D csilli-villi legyen a grafikon is, meg minden, amit el lehet képzelni. Ezért mi most nem fogunk nekiállni DirectX-ben 3D diagramot fejleszteni amikor van rá kész optimális megoldás, fölösleges lenne. Szerintem játékokhoz is teljesen megfelelő a C#/Java is. Az előbbinél a dinamikusság miatt még külön script rendszert sem kell írni, alapból adott lesz a következő verzióban. Itt a JF-en nem hiszem, hogy ne lenne elég bárkinek ezek teljesítménye a projectkeikhez. Nyílván egy ID szintű cégnek nem lenne most még elég a jelenlegi JIT-es technológia /bár ha jól tudom ők is valami Java-szerű virtuális gépet fejlesztettek ki a játékokhoz/, de hol van itt ilyen? A mi cégünk se a Microsoft, hogy C-ben és spec#-ban fejlesszünk a nulláról mindent. Egy Azure, vagy Windows 8 szintű project max a vezető álmaiban van, nem a valóságban.
   
xanat - Tag | 489 hsz       Online status #109853   2009.05.05 14:00 GMT+1 óra  
jojo, a mesh megjelenites nem most lesz, foleg ha sajat x loadert akarok, meg ilyenek...
most ott tartok, h ki van irva szoveg a kepernyore, es kezeli a device lost-ot
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Asylum - Törzstag | 5441 hsz       Online status #109850   2009.05.05 13:45 GMT+1 óra  
"Hát maga megőrült, hát maga megőrült, hogy mindent kétszer mond, kétszer mond?"
/ Karinthy /

Xanat:

Például amikor azt mondod, hogy:

Kód:
device->CreateVertexBuffer(..., D3DPOOL_DEFAULT, ...);

// vagy
device->CreateTexture(..., D3DPOLL_DEFAULT, ...);

// vagy pl. mesh betöltésnél nem adod meg a D3DXMESH_MANAGED kapcsolót
// de egyébként le is lehet kérni a pool-t


akkor ezeket device lostkor releaselni kell, amit nem kell releaselni azok a vertex és pixel shaderek. Id+DFont-ra elég meghivni az OnLost/OnResetDevice() metódusokat (ID3DXEffectre szintén).

Épp erröl ment a duma a dx topicban, hogy a default eröforrásokat, hogy érdemes akkor tárolni, végül arra jutottunk, hogy a rendszermemóriában letárolok róla egy másolatot, és resetkor visszamásolom a videomemoriába.
Igy kapsábol writeonly lehet az eröforrás, söt sokkal hatékonyabban tudja kezelni a dx.

Eredetileg szóvolt virtuális memóriáról is, ezt én elvetettem; majd az oprendszer megoldja.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #109847   2009.05.05 12:07 GMT+1 óra  
szombatha az teljesen hamis allitas, hogy ezek a megoldas szempontjabol erdektelen dolgok. Minnel komplexebbe es bonyolultabba valik egy rendszer annal jobban szukseg lehet es van a teljes iranyithatosagra. Es ez kimondottan igaz a teljesitmenyspecifikus programokra, mint a grafikai alkalmazasok es jatekok ( ugye ezek illenek az oldal temakorebe de van kosmillio egyeb pelda ). Az onamitas, ha elegnel tartunk egy olyan rendszert ahol nem vagyunk kepesek mindent.

En is szembekerulok nap mint nap ezekkel a problemakkal a munkam soran, ahol minden egyes apro kis erdekessege elojon a komplexebb nyelveknek, ahol pontosab kell tudnom mindenrol mikor szabadul fel es hogyan. Szerencsere ez olyan terulet ahova meg egyaltalan nem szivargott be a managed (nem neveznem oket dinamikusnak, sot...) megoldasok egyike sem. Es jo sokaig nem is fog, fokent a sebesseguk, es a rugalmatlansaguk miatt ( hogy nem te iranyitasz mindent ).

Es a jatekfejlesztes is ilyen...

Irjon valaki teljesen jol mukodo es gyors profi render enginet (offline elsorban, de akar valos idejure is gondolhatnek) c# ban vagy javaban. Nem fog menni, mert nem arra vannak ezek a nyelvek kitalalva kitalalva.
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #109846   2009.05.05 11:17 GMT+1 óra  
Van ez a device lost dolog. Amikor device lost tortenik, akkor reset elott felszabaditom a "D3DPOOL_DEFAULT memoriaosztalyban letrehozott eroforrasokat" (majdnem pontos idezet Carlos elso konyvebol), ekkor jon a reset, majd ha ez sikeres volt, akkor ujra lefoglalom oket. Ilyen eroforras pl. egy Font ami egyelore nekem meg van jelenitve. Ezek a videomemoriaban lefoglalt dolgok. Mik tartoznak ide? (ez is lama kerdes, de nem hiaba ebbe a topicba irok )
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
szombatha - Tag | 97 hsz       Online status #109826   2009.05.04 11:27 GMT+1 óra  
a GC egy fát épit aminek aztán az egyensúlyára kinosan ügyel és statisztikát is gyárt. Ezek alapján dönt végül a takaritásról. Egyébként a c#-ben a string-et referenciaként kezeli és mégis "kivülről" olyan mintha érték szerinti lenne:

Kód:
string str = "Walaky";        // sehol egy new, de ez referencia.


Alábbi felvetéseken tényleg nem árt elgondolkodni, de ha az ember programozik, akkor nem árt ha a figyelmét nem azok a dolgok kötik le amelyek aztán a megoldás szempontjából teljesen érdektelenek. Ezért terjednek a dinamikus nyelvek ilyen gyorsan.

   
mark576 - Tag | 256 hsz       Online status #109824   2009.05.04 10:49 GMT+1 óra  
Idézet
szombatha :
Az csak technikai kérdés, hogy mikor és ki szünteti meg az adott objektum által lefoglalt területet. Programozástechnikailag nincs szükség érték szerinti változókra (mint az előbb emlitettem a python-t, vigan elvan ezek nélkül mégpedig nem is akárhogy), sőt ha a garbage-nek referenciákat kell takaritgatnia, akkor ez gyorsabb kódfutást eredményez, mivel a takaritást indeterminisztikusan, de batch-elve teszi és nem "kénytelen" az értékszerinti változókat egyenként takaritani. Persze ennek ára van: a memória. Előbb -utóbb a c#-ban is valszeg minden ref lesz.


Hmm nem rossz téma. Mondjuk windows-ban semmi sem determinisztikus. Talán a PLC az determinisztikus. C#-ban gondolom azért oldották meg így, mert a helyzettől függ, hogy a veremben, vagy a GC által felügyelt halmon kell e tárolni, elérni az objektumokat. Ezt se úgy kell elképzelni, hogy a GC egyfolytában csak dolgozik és minden belassul. Akkor cselekszik, amikor feltétlenül szükséges, akkor viszont defragmentál is, hogy legközelebb még ennyi dolga se legyen. Láttam olyan diploma munkát, ahol nagyméretű struct-okat írt a diplomázó mondván ettől majd gyors lesz a managed 3D engine. Valóban pár %-al marad csak el a "sima" directX-es megoldástól a portal motorja, sőt néha még gyorsabb is volt. Valószínű esetében nem nyomott sokat a latban az, hogy valójában éppen ezzel lassította a rendszert folyamatos blokkmásolásra kényszerítve. Vannak erre bűvös számok, hogy x érték felett inkább legyen az objektum referencia, az alatt érték, de ezt végül is helyzete válogatja. Annyi biztos, hogy nem véletlenül marad meg ez a "tradicíó". Tovább bonyolítja a helyzetet, hogy mi van akkor, ha egy struct-ba string-et rakok, vagy mi lesz a class-ban lévő int-ekkel!? El lehet ezen filozofálgatni, de a bevett szokásokon felül általában 1-2 jó profiler megmondja, hogy mi is a helyzet. Nem egyszer láttam már olyat, hogy a ToString() metódus nagyobb költséggel járt, mint az érték dobozolása. Nem minden fekete és fehér. Érdemes a CIL-t is tanulmányozni, de csak fanatikusoknak.

"A .NET minden típusa a System.Object nevű típusból származik, és ezen belül szétoszlik érték- és referenciatípusokra. A kettő közti különbség leginkább a memóriában való elhelyezkedésben jelenik meg. A CLR két helyre tud adatokat pakolni, az egyik a verem (stack) a másik a halom (heap). A verem egy ún. LIFO (last-in-first-out) adattár, vagyis az az elem amit utóljára berakunk az lesz a tetején, kivenni pedig csak a legfelső elemet tudjuk. A halom nem adatszerkezet, hanem a program által lefoglalt nyers memória, amit a CLR tetszés szerint használhat. Minden művelet a vermet használja, pl. ha össze akarunk adni két számot akkor a CLR lerakja mindkettőt a verembe és meghívja a megfelelő utasítást ami kiveszi a verem legfelső két elemét összeadja őket, a végeredményt pedig visszateszi a verembe"

"Általában egy értéktípus csak egy-négy bytenyi helyet foglal el, ezért kényelmesen kezelhetjük a vermen keresztül. Ezzel szemben egy referenciatípus sokkal nagyobb szokott lenni és a memóriában való megjelenése is összetettebb, ezért hatékonyabb a halomban eltárolni"

http://hu.wikibooks.org/wiki/C_Sharp_programoz%C3%A1s/V%C3%A1ltoz%C3%B3k
   
szombatha - Tag | 97 hsz       Online status #109819   2009.05.04 09:17 GMT+1 óra  
Idézet
Orphy :
Idézet
szombatha :
Tulajdonképpen nem értem miért léteznek még érték szerinti tipusok a c#-ban. Pl. a python-ban csak referencia van.



Van amikor az érték szerinti átadásra van szükség.
Az ún. value-type-ok C#-ban nem csak abban különböznek a reference-type-októl, hogy referenciaként viselkedik, hanem a memóriafoglalásban is: a value-type-okat pl a GC rögtön tudja kukázni, amint kikerülnek a scope-ból, mig ez a reference-type-okra nem feltétlenül igaz.



Az csak technikai kérdés, hogy mikor és ki szünteti meg az adott objektum által lefoglalt területet. Programozástechnikailag nincs szükség érték szerinti változókra (mint az előbb emlitettem a python-t, vigan elvan ezek nélkül mégpedig nem is akárhogy), sőt ha a garbage-nek referenciákat kell takaritgatnia, akkor ez gyorsabb kódfutást eredményez, mivel a takaritást indeterminisztikusan, de batch-elve teszi és nem "kénytelen" az értékszerinti változókat egyenként takaritani. Persze ennek ára van: a memória. Előbb -utóbb a c#-ban is valszeg minden ref lesz.

   
Orphy - Törzstag | 1893 hsz       Online status #109818   2009.05.04 09:04 GMT+1 óra  
Idézet
szombatha :
Tulajdonképpen nem értem miért léteznek még érték szerinti tipusok a c#-ban. Pl. a python-ban csak referencia van.



Van amikor az érték szerinti átadásra van szükség.
Az ún. value-type-ok C#-ban nem csak abban különböznek a reference-type-októl, hogy referenciaként viselkedik, hanem a memóriafoglalásban is: a value-type-okat pl a GC rögtön tudja kukázni, amint kikerülnek a scope-ból, mig ez a reference-type-okra nem feltétlenül igaz.
   
szombatha - Tag | 97 hsz       Online status #109817   2009.05.04 08:59 GMT+1 óra  
c#-ban (is) azért hívják referenciának a referenciát, mert valamely tárterületre referál. Ha nem mutat sehova, akkor null. Egyébként c#-ban az értéktípusok is vehetnek fel null értéket, na jó egy kis trükkel: pl.:

Kód:
int? valami = 5;
valami = null;


Ami valójában egy struktúra, olyan mintha ezt irtad volna:

Kód:
Nullable<int> valami = 5,
valami = null;


Tulajdonképpen nem értem miért léteznek még érték szerinti tipusok a c#-ban. Pl. a python-ban csak referencia van.

   
Orphy - Törzstag | 1893 hsz       Online status #109816   2009.05.04 08:56 GMT+1 óra  
Azért ez egy kicsit nehezebb téma, főleg azért, mert a * és az & jelek különböző szituációkban mást is jelenthetnek, igy könnyen összezavarhatják azokat, akik csak most ismerkednek ezekkel a nyalánkságokkal...
* - pointer, vagy a pointerben levő érték
& - referencia, vagy egy objektum memóriacime..

Xanat:
Anno én is elég nehezen értettem meg a pointereket, és a referenciákat, aztán amikor már jól ment, irtam gyorsan ide egy cikket. Ha érdekel a téma, olvasd el!

Itt megtalálod:
Kezdeti nehézségek - Pointerek, Referenciák
   
xanat - Tag | 489 hsz       Online status #109814   2009.05.04 08:45 GMT+1 óra  
mondjuk ezek nem rossz dolgok, amiket leirtal, csak meg kell tanulni hasznalni oket. En (akar hiszitek akar nem ) nem undorodok a c++tol, tanulom azt is. Szeretnek sokoldalu lenni
vegulis naggyabol megyeget is, csak meg ezzel van egy kis baj ez a referencia, meg pointer, meg ezazamaz. De emeszthetonek tunik. koszi.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Asylum - Törzstag | 5441 hsz       Online status #109811   2009.05.04 08:18 GMT+1 óra  
Az alapvető külöbnség a pointer és a referencia között, hogy olyan, hogy nullreferencia nem létezik, mindig egy létező objektumra mutat (ezzel szemben a c# -ban persze hogy van null nemisértem mért refernciának hivják).
Referenciáknak deklaráláskor értéket kell adni, az értékük utána már nem változik meg (az általuk MUTATOTT érték változhat).
Példa:

Kód:
int a = 10;
int b = 20;
int& ra = a;

ra = b; // a értéke 20 lesz; NEM b-re fog mutatni az ra


Tulajdonképpen úgy müködnek mint egy "alias" egy változóra, egy másik név. Más példa:

Kód:
const int& r = 10;


bizony ilyet is lehet. Rengeteget lehetne erröl mesélni. Ilyet is tudnak, hogy például egy temporáris értékre rá lehet állitani egy konstans referenciát, ezáltal az élettartamát meghosszabbítva. Például

Kód:
int f()
{
    return 10;
}

const int& rf = f(); // ha csak azt irnám, hogy f() akkor meg is semmisülne a visszatérési érték amint átlép rajta a program

std::cout << rf << "\n";


Temporárisra csak konstans referenciát lehet állitani.
Az új C++ szabványban pedig rátesznek erre még egy lapáttal, bevezették a jobbérték-referenciát.
Példa:

Kód:
int&& f()
{
    int a = 10;
    return a; // igen, LOKÁLIS változóra mutató refet adok vissza
}

int rf = f();
std::cout << rf << "\n";


és még egy csomó nyalnkságot lehet velük csinálni.
Majd javitson valaki ha hülyeséget irtam.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #109810   2009.05.04 07:14 GMT+1 óra  
Ami azt illeti pár feladattal a C#os módszer is megszokható. Nagyon a keze alá játszik az embernek, és sok mindent lehet rá mondani, de hogy érthetetlen lenne, azt nem igazán.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Kuz - Törzstag | 4455 hsz       Online status #109809   2009.05.04 07:07 GMT+1 óra  
Ezzel látod, hogy mit is csinálsz, C#-nál nem igazán. Itt könnyű hibázni, de tényleg azt csinálod, amit akarsz (hacsak el nem b@**od ), C#-nál meg, ha nem tudod mi zajlik a háttérben, akkor reméled, hogy az történik, aminek történnie kell. C#-nál amúgy van referencia, ami pont a jelölés hiánya miatt - inkább a kezdőknél - hibát szokott eredményezni, mert csodálkoznak, hogy a paraméterben átadott változó értéke miért változott meg.
Amúgy nem hiszem, hogy ez olyan nehezen megtanulható lenne. 1-2 rutinfeladatot meg kell írni, aztán már nem is lesz olyan idegen.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
xanat - Tag | 489 hsz       Online status #109808   2009.05.04 06:53 GMT+1 óra  
ja
latod, ezert jo a c# (meg az xna )
sot, olyan is van (bar nem hasznaljak), h. ***val
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Kuz - Törzstag | 4455 hsz       Online status #109807   2009.05.04 06:50 GMT+1 óra  
Tegyél hozzá még pl olyat is, hogy **val. Meg a tömbök, amiknek a neve, ha jól tudom alapból pointernel számít (?), és ki tudja még mik vannak ilyenekből.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
xanat - Tag | 489 hsz       Online status #109806   2009.05.04 06:47 GMT+1 óra  
azthiszem ertem. Ezt meg meg kell szokni. van siman val, *val, es &val. huh. koszi
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
eagle - Tag | 15 hsz       Online status #109804   2009.05.04 06:23 GMT+1 óra  
az hogy az &var a var nevű változó memóriacímére utal.

   
Eldor - Tag | 162 hsz       Online status #109803   2009.05.04 06:22 GMT+1 óra  
A &-t referenciának hívják. Itt egy példa ( magyarázni sajnos nem tudok ):
Kód:
void function1(int &var)
{
    var=5;
}

void function2(int *var)
{
    *var=5;
}

void main()
{
    int var1,var2;

    function1(var1);
    printf("%d\n",var1);

    function2(&var2);
    printf("%d\n",var2);
}


Ez a képernyőre mindkétszer az 5-öt fogja kiírni.
Tehát a lényege az, hogy eltakarja a programozó elől, hogy valójában a function2(var2) meghívással a var2 mutatóját adja át a függvénynek, aminek a tartalmára utána egyszerűen var2-vel tudsz hivatkozni.

   
xanat - Tag | 489 hsz       Online status #109801   2009.05.04 06:09 GMT+1 óra  
na itt egy lama kerdes. (c++)
ha a * a pointer jele, akkor a & az micsoda? Vagyis mi a kulonbseg?
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Marko - Tag | 35 hsz       Online status #109712   2009.05.02 07:58 GMT+1 óra  
Ok, közben rájöttem a megoldásra, más volt a baj.
Köszi all.

   
Marko - Tag | 35 hsz       Online status #109690   2009.05.02 06:55 GMT+1 óra  
Asylum: nincs megkötve a kezem, hogy 3D-s nek kell lennie a tömbnek, de most nagyon jól jönne a program további részeinél, ha meg tudnám valósítani.

Nem tudnád átírni a példádat tombkreal3D(int ***t) és tombfeltolt3D(int ***t) - re?
Bazi sokat segítenél.

szerk.: amúgy meg innentől már nem szívesen módosítanák az elképzeléseimen, mivel már csomó olyan dolog van ami erre épül és amiken órákat ültem

   
gaborlabor - Moderátor | 4449 hsz       Online status #109688   2009.05.02 06:46 GMT+1 óra  
(Ha meg az a házi feladata, hogy 3 dimenziós tömböket használjon, akkor hiába jobb az std::vector, nem használhatja azt.)

   
TPG - Tag | 3402 hsz       Online status #109687   2009.05.02 06:42 GMT+1 óra  
Idézet
Asylum :
Mért kell belekötni a makrókba. Rossz programozó az aki láma módon használja őket. Ennyi.
Jóislenne ha az összes makrót kidobnánk pl. a boost-ból. Szerintem vért izzadnál te is.


Jaja, sosem az eszköz a rossz attól hogy az ember nem tudja jól/jóra használni. Ilyenkor nem az eszközt kell bántani hanem a használóját kell kicserélni.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5441 hsz       Online status #109686   2009.05.02 06:36 GMT+1 óra  
Mért kell belekötni a makrókba. Rossz programozó az aki láma módon használja őket. Ennyi.
Jóislenne ha az összes makrót kidobnánk pl. a boost-ból. Szerintem vért izzadnál te is.

2-nél több dimenziós tömböknél már értelmesebb lehet az egészet széthúzni egy egydimenziós tömbbé (csak igy esetleg, de nem feltétlenül több számolást igényel).


Dinamikus tömbök átadása paraméterben. Elöször is megejgyezném, hogy a pointerek érték szerint adódnak át, tehát ha a függvényben akarod létrehozni a tömböt akkor még egy * kell.
Ha nem ott hozod létre akkor elég a normális. Példa:

Kód:
void tombkreal_ROSSZ(int* t)
{
    // rossz!!
    // ugyanis ha csak simán a pointert adnám át akkor
    // ebben a  függvényben a lokálisan létrejött t pointerre
    // hoznám létre a tömböt, és mivel a pointerek
    // érték szerint adódnak át ezért a hívó oldalon továbbra is NULL
    // pointer marad

    t = new int[10];
}

// helyesen
void tombkreal(int** t)
{
    (*t) = new int[10];
}

void tombfeltolt(int* t)
{
    for (int i = 0; i < 10; ++i)
        t[i] = rand() % 20;
}

int main()
{
    int* tomb = NULL;

    tombkreal(&tomb);
    tombfeltolt(tomb);
}

Ezt a hozzászólást Asylum módosította (2009.05.02 06:47 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #109685   2009.05.02 06:31 GMT+1 óra  
Ok, futásidőben változtatott méretű tömbökre, vagy úgy létrehozottakra meg inkább std::vector. Azért van ott az STL a c++ mellett.
raytraceisten és übermedic
   
gaborlabor - Moderátor | 4449 hsz       Online status #109684   2009.05.02 06:26 GMT+1 óra  
Azzal kezdte még tegnap, hogy futásidőben fog kiderülni a tömb mérete. Ebből következik, hogy az a 3 sor lesz az első amit kidob a példakódból. Egy pszeudokódban szerintem amúgy is belefér.

   
sirpalee - Tag | 1282 hsz       Online status #109683   2009.05.02 06:19 GMT+1 óra  
Idézet
gaborlabor :
konkrétan?



#define X 3
#define Y 3
#define Z 3

Például ez.
raytraceisten és übermedic
   
Marko - Tag | 35 hsz       Online status #109681   2009.05.02 06:12 GMT+1 óra  
Még 1 kérdés: az a[x][y] tömböt nem két ciklusban kellene feltölteni?
Így gondoltam:
Kód:
#define X 3
#define Y 3
#define Z 3

int ***a;
a = new int**[X];
for( unsigned short x = 0; x < X; x++ )
{
a[x] = new int*[Y];
}
for( unsigned short x = 0; x < X; x++ )  // itt iktattam be még egy x-beli for ciklust
     for( unsigned short y = 0; y < Y; y++ )
     {
         a[x][y] = new int[Z];
     }


Bár mondjuk, most mind2től elszáll a progi, úgyhogy más a baj, de nem lehet, hogy az a jó ahogyan én írtam?

   
gaborlabor - Moderátor | 4449 hsz       Online status #109680   2009.05.02 06:06 GMT+1 óra  
konkrétan?

   
sirpalee - Tag | 1282 hsz       Online status #109678   2009.05.02 05:56 GMT+1 óra  
Idézet
gaborlabor :
Kód:
...

(nem 100% hogy jó, de valami ilyesminek kell lennie)



Attól hogy még valaki a kezdő vok témakörbe írt, nem kell rossz programozási szokásokat mutatni neki...
raytraceisten és übermedic
   
Marko - Tag | 35 hsz       Online status #109672   2009.05.02 05:20 GMT+1 óra  
Idézet
gaborlabor :
Kód:
#define X 3
#define Y 3
#define Z 3

int ***a;
a = new int**[X];
for( unsigned short x = 0; x < X; x++ )
{
a[x] = new int*[Y];
for( unsigned short y = 0; y < Y; y++ )
{
a[x][y] = new int[Z];
}
}

(nem 100% hogy jó, de valami ilyesminek kell lennie)



Köszi, úgy néz ki jó lesz.

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] > 40 < [44]