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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2192
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 < [44]
screat - Tag | 382 hsz       Online status #112183   2009.06.05 11:02 GMT+1 óra  
írd be a problémáidat a dbp topicba
még csak padawan...
Dont worry, be hippy - Fanni :)
   
Marclee - Tag | 285 hsz       Online status #112182   2009.06.05 10:55 GMT+1 óra  
Tudni tudok angolul csak éppenséggel nem megy olyan jól a szöveg értés meg valami förtelem nálam főleg angolul....Meg különösebben nincs szükségem tanárra aki mindent megmagyaráz (bár jól jönne de tudom hogy ez nem lehetséges) hanem inkább csak egy ember aki kb rám áldozna csak 1 órácskát és segítene azokon a probélmákon amikkel épp küszködök.
Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost.
Alphonse Elric

http://geeksworld.hu/
   
screat - Tag | 382 hsz       Online status #112181   2009.06.05 10:52 GMT+1 óra  
Ja értelek. Akkor nem szóltam.
Mindenféleképpen tanulj meg angolul, úgy is kelleni fog. Próbálkozz csak, úgy tanul az ember. Ilyen ember tényleg nem fog akadni, aki megtanítana, ami valóban egy hosszú folyamat.
még csak padawan...
Dont worry, be hippy - Fanni :)
   
Marclee - Tag | 285 hsz       Online status #112180   2009.06.05 10:48 GMT+1 óra  
Hello! Igen már nem egyszer néztem és ezeket mind elolvastam és gyakorlom is! De sok problémám van amire ezekben nem kapok választ ezért kezdtem ide írni!
Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost.
Alphonse Elric

http://geeksworld.hu/
   
screat - Tag | 382 hsz       Online status #112179   2009.06.05 10:42 GMT+1 óra  
a "föld" semerre nem forog, max. a Föld...
nos... nézted már az oldalt? szerintem nem, előbb legalább körülnézhettél volna.
Nade várj, segítek:
http://ilab.hu/jf/page.php?&id=69
http://ilab.hu/jf/page.php?&id=71
http://ilab.hu/jf/page.php?&id=70
Ezek után szerintem semmi panaszod nem lehet(ne)...
még csak padawan...
Dont worry, be hippy - Fanni :)
   
Marclee - Tag | 285 hsz       Online status #112178   2009.06.05 10:32 GMT+1 óra  
Szerinted mit csinálok?Folyamatosan próbálom fejteni az angol tutorialokat mert a magyarok semmi hasznosat nem mondtak eddig nekem. Amúgy meg azt csak azért írtam hátha valaki segítő kész lenne de amúgy folyamatosan keresem és fejtem a tutorialokat. Azért köszi!
Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost.
Alphonse Elric

http://geeksworld.hu/
   
Ashkandi - Törzstag | 1045 hsz       Online status #112177   2009.06.05 10:21 GMT+1 óra  
Szerintem senki nem fog a saját szabadidejéből megtanítani FPS-t írni. Az emberek nem "fossák" a szabadidőt, hogy akárkinek megtanítsanak egy több évig tanulandó dolgot. Persze lehet, hogy lesz valaki aki feláldozza magát, de én inkább folytatnám a tutorial olvasást a helyedben. Ezt most teljesen építő jelleggel mondom.

   
Marclee - Tag | 285 hsz       Online status #112173   2009.06.05 09:26 GMT+1 óra  
Sziasztok!Én még kezdő vagyok...(ezért vagyok ebben a topikban ) Dark Basic Pro-ban szoktam "alkotni" ha lehet annak mondani amit én csinálok!Az alapokkal már ismerkedte meg a parancsok egy kisseb részét is tanulgattam de az még mindig kevés hogy belekezdjek egy egyszerűbb kis FPS elkészítésébe, only multi playerrel mivel az szerintem könnyebb amiatt ,hogy nem kell megírni melyik bot mit csináljon és melyik pálya után melyik következzen. A segédleteket is olvasgatom de amit ott megtanultam az teljesen más fajta FPS-hez lenne jó.... Tudom a most következő szöveget lehet sok mindenki le fikázná és lehülyézne engem tehát ha ez a helyzet akkor inkább ne írjatok rá választ csak az aki normálisan tud válaszolni pls.
Tanárt keresek aki megtanítja nekem ,hogy "merről merre forog a föld" . Szóval az alapokat és olyanokat ami segíthetne az FPS játékkészítésben. Mert átnéztem már kismillió tutorialt és semelyik se jó mert vagy úgy írja le a dolgokat ahogy éppen nem tudom felhasználni vagy éppen angol. (nem vagyok valami nagy nyelv szakértő) próbálkoztam már a webforditas.hu val is de nem mentem vele sokra mivel a felét nem értettem. Ezért légyszi valaki tanítsa meg!Vagy mondjon valami részletes tutorialt!!! PLS!!
Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost.
Alphonse Elric

http://geeksworld.hu/
   
Bacce - Bacce | 1783 hsz       Online status #111461   2009.05.29 07:59 GMT+1 óra  
egyoldalú beszélgetőprogram az jó. notepad?
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
Eldor - Tag | 163 hsz       Online status #111448   2009.05.29 03:57 GMT+1 óra  
Köszönöm a segítségeket.
Ez alapján már el tudok indulni. Egy egyszerű ( vagy inkább egyoldalú ) beszélgetőprogramot már írtam is.

   
Asylum - Törzstag | 5463 hsz       Online status #111437   2009.05.28 14:41 GMT+1 óra  
azé nem megy a fork() mert az csak linux alatt van (unistd.h). winfos alatt van a CreateProcess(), viszont ez nem ugy müködik mint a fork(), sajnos. Pedig tökjo lenne, egész okos kis függvény csak akkor van baj mikor valamit elkursz és exponenciálsan sok processz jön létre, a rendszer meg széppppppeeeeeeen leeeeeelllaaaaaaasssssuuuuuuuuulllll....
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #111434   2009.05.28 14:37 GMT+1 óra  
Én pedig hozzátenném még, hogy az a tutor nagyon lowlevel, tehát minden szép és jó addig, amíg azt akarod, hogy kapcsolódjon, meg küldjön át 1-2 csomagot, de mondjuk ahhoz, hogy pl egy játékban, vagy bármilyen bonyolultabb alkalmazásban fel tudd használni, NAGYON sok mindent meg kell még hozzá írnod, és tul.képpen az az, ami nehéz a dologban. Hogy csak egy példát mondjak, UDP ugye nem garantálja, hogy megérkeznek a csomagok, ill. hogy sorrendben érkeznek-e meg. Egy játékhoz viszont ideálisabb, mint a TCP/IP, de az ilyen problémákat nagyon jól le kell kezelni...

   
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 | 163 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 | 163 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 | 163 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 | 163 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 | 163 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 | 163 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 | 5463 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 | 5463 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ő | 2524 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 | 163 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.
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] > 40 < [44]