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] [45] [46]
Pretender - Törzstag | 2498 hsz       Online status #191371   2013.02.19 19:46 GMT+1 óra  
Nem mutogathatok én meg mindent amit csinálok

Én nekem nincs bajom a C#-al, amíg arra használják, amire való. Az ilyen kössük keresztbe jobbra balra aztán fentről lefelé, és még tegyünk rá 8 hurkot dolog, hogy menjen egy amúgy natív szinten elérhető valami, az nem az igazi

A C++ egyetlen csúnyasága a header. Persze ez lehet valahol jó is, hogy gyorsabban megtalálhatsz valamit, de ez az includeolgatás meg forward deklarálgatás nem az igazi. Egyébként pedig a delete-n kívül a legtöbb elem megtalálható mindkettő nyelvben. Engem személy szerint nagyon idegesít, hogy C#ban nem mondhatom azt, hogy delete. Csak tudom én, hogy mikor akarom letörölni

Az nem tetszik annyira, hogy a GC majd kitörli, ha megtelt a memória, vagy ha éppen ráér.

   
bolyzsolt - Törzstag | 607 hsz       Online status #191370   2013.02.19 19:19 GMT+1 óra  
Szerintem pont te vagy az, aki szájkaratézol. MaNiAc önerőből továbbvisz egy projektet, ami önmagában is említésre méltó szerintem, annak ellenére, hogy valószínűleg soha nem fogom használni a Tao-t. Ez a kötekedés csak a soha véget nem érő C#/C++ vita egyik apró megnyilvánulása, semmi több. Pretender erre rátett még egy lapáttal a másik topicban, de én azért szívesen megnéznék tőle vagy tőled olyan C#-os projektet, amit azért hagytatok abba, mert a VM sebessége kevésnek bizonyult a nagyszabású 3D-s grafikai elképzelésetekhez.

MaNiAc is írta, hogy nem Crysist kell C#-ban fejleszteni. Pretender pedig azt írta, hogy 2D-hez valószínűleg tökéletesen elég. Én látatlanban is fogadni mernék rá, hogy kis/közepes grafikai szintű 3D-s játékokhoz is elég lenne a VM ereje, de nem tudom bizonyítani, úgyhogy ezt vehetjük feltételezésnek. Viszont akár ha csak 2D grafikához elég gyors, akkor mi értelme van kötekedni? Lehet, hogy tényleg egy kalap sz*r a C#, bűnlassú meg monnyonle (természetesen nem az), de attól még miért baj, hogy van egy ilyen projekt is?

A nyelv meg kinek a pap, kinek a papné. Én pl. nagyon bírom a C#-ot, talán nem véletlen, hogy a Unity-be is integrálták. Egy 2D-s platformernél lazán bevállalnék 500 helyett 200 FPS-t, ha C#-ban fejleszthetném le és nem kellene C++-al és a natív programozás minden gusztustalan apró részletével szenvedjek, kezdve a memóriafoglalásoktól a headereken át a fordításig

   
Parallax - Tag | 574 hsz       Online status #191357   2013.02.19 07:21 GMT+1 óra  
Szájkarate?

Idézet
MaNiAc :
Ad1) Aki linuxon játszik, az már hozzászokott, hogy libEZ-t és libAZ-t mindig telepíteni kell - hála az égnek, ez mostanra nevetségesen könnyű (lásd: Gentoo, Ubuntu, etc)


Its great that people are enthusiastic about Linux as a gaming platform but there are not many people who are interested in paying for a game and that seems to be the reality.

Idézet
MaNiAc :
Hát igen, gondolom pl. egy Parallel.For() meg ilyenek komoly akadályt gördítenek az ember elé!


Akinek gondot okoz az is, hogy mivel fejlesszen valószínűleg a Parallel library a legelső, amivel fejleszteni fog egy kirakót, ami egyébként C++ nál is ugyanúgy elérhető.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #191354   2013.02.19 06:24 GMT+1 óra  
Idézet
Parallax :Meg lehet csinálni, csak saját magadnak fölösleges managed trükközésekkel és a natív-managed közötti kommunikációval szenvedni pluszban.

Azt is kell nézni, hogy ki használ linuxot játékra és azok közül ki fog külön a .NET telepítésével bajlódni a játékod miatt.

Ad1) Aki linuxon játszik, az már hozzászokott, hogy libEZ-t és libAZ-t mindig telepíteni kell - hála az égnek, ez mostanra nevetségesen könnyű (lásd: Gentoo, Ubuntu, etc)

Ad2) A "managed trükközéssel szenvedés"-t már jó esetben megcsinálta helyetted más - minden nagyobb libraryhoz létezik ingyenes binding.

Idézet
Parallax :A játékfejlesztéshez szükséges infrastruktúrát ígyis-úgyis meg kell írni, ha saját engine-t fejlesztesz, itt már a nyelv és a framework/futtatórendszer sokszor inkább akadályoz, minthogy segít.

Hát igen, gondolom pl. egy Parallel.For() meg ilyenek komoly akadályt gördítenek az ember elé!
Dare to imagine!
http://www.insaneidea.hu
   
Bukta - Tag | 308 hsz       Online status #191206   2013.02.10 12:21 GMT+1 óra  
Ezt nyeljétek le:
Kód:
if (...) {
  if (notFound) {
       y = 0;
       do { ...y--; } while (...);
  }
}
else if () {  }
else { }
x = 0; y = 0;

asd
Akartam többet is írni, de én qrtam el. Szokás szerint megint akkor jövök rá mikor már írtam
Jobb lesz ha most magambaszállok. No comment

Ezt a hozzászólást Bukta módosította (2013.02.10 12:32 GMT+1 óra, ---)
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
LBandy - Tag | 271 hsz       Online status #191029   2013.02.02 16:36 GMT+1 óra  
Szerintem ha érdemi segítséget vársz akkor egy kicsit konkrétabban... Egy kódrészlet, és az arra vonatkozó hiba, ez alapján gyorsabban fogsz választ kapni.
   
Sorenke - Tag | 72 hsz       Online status #191025   2013.02.02 14:48 GMT+1 óra  
Hello, van olyan a Fórumozók között aki írna egy kis segítséget ---> a user control-hoz
Olyan gondom lenne hogy ezekkel a "user control" cserélgetésével próbálnék egy menürendszert létrehozni.
Mindig ilyen hibákat add:
- nem szerepel a névtérben
- kiad egy csomó ütközés problémákat (kétszer próbálja létrehozni, és kifagy)
- nem engedi külön osztályba definiálni a user control-t
help me

   
Parallax - Tag | 574 hsz       Online status #189973   2013.01.01 11:43 GMT+1 óra  
Idézet
versio :
azert egy c# + directx 11 + AMP rendszerre "egybol" valtanek a c++-rol , a fejlesztes sokkal kenyelmesebb es gyorsabb


SharpDX Ez a leggyorsabb megoldás, "csak" 1.5/2.0-szer lassabb, mint a C++. Egyszerű API hívások, nincs benne a sebességben fizika, AI implementáció, semmi.

Fejlesztési szempontból teljesen mindegy, mert a szintaktikája ugyanaz.

   
versio - Tag | 659 hsz       Online status #189893   2012.12.30 16:11 GMT+1 óra  
azert egy c# + directx 11 + AMP rendszerre "egybol" valtanek a c++-rol , a fejlesztes sokkal kenyelmesebb es gyorsabb
   
Parallax - Tag | 574 hsz       Online status #189890   2012.12.30 14:34 GMT+1 óra  
@Bukta: A C#-os fejlesztés semmivel nem gyorsabb, mint a C++ fejlesztés. Azokon a területeken hatékony, ahol nem kell foglalkozni memória kezeléssel, sem a futási sebességgel, és ahol az adatkezelés (SQL) a szűk keresztmetszet. A játékfejlesztéshez szükséges infrastruktúrát ígyis-úgyis meg kell írni, ha saját engine-t fejlesztesz, itt már a nyelv és a framework/futtatórendszer sokszor inkább akadályoz, minthogy segít. Még ügyvitelben is lehet jókat szívni, amikor le kell nyúlni alapvető ablak kezelési műveletek miatt a windows API-ig, az OpenGL, DirectX stb meg még ennél is összetettebb. Meg lehet csinálni, csak saját magadnak fölösleges managed trükközésekkel és a natív-managed közötti kommunikációval szenvedni pluszban.

Azt is kell nézni, hogy ki használ linuxot játékra és azok közül ki fog külön a .NET telepítésével bajlódni a játékod miatt.

   
Tibsy - Tag | 307 hsz       Online status #189877   2012.12.30 09:39 GMT+1 óra  
itt egy kis oktató anyag C# -kezdöknek Hun!
Hun c#
   
Bukta - Tag | 308 hsz       Online status #189463   2012.12.13 12:48 GMT+1 óra  
Jaaaaah szal linuxon so van a dll helyett. Na ezt nem tudtam. És akkor a c++ nem tud linuxon dll-eket használni meg winen so-t. Szal ezért akarsz interfészeket használni. Jó akko ezt értem. De viszont ha c#ba írnám az egészet akkor a .netes dlleket (assembly) a mono runtime, meg a win clr-je már tudná használni. Akk ja 2 megoldás van. Az interfészes meg a tiszta c#. Am nekem nem kell winform, wpf, gtk# vagy gtk+ vagy bármi más, nekem csak azé kell a c# mert az ő a saját dll-jeit tudja mindenhol használni. A .net BCLje tökéletesten elég a rapid fejlesztéshez. Jó akkor már csinálom is az engine-t és majd megmutatom mi lett belőle.
M4: a haxe-ét meg inkább legközelebb megtanulom, most nem akarok megint uj nyelvet tanulni.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
M4 - Tag | 187 hsz       Online status #189455   2012.12.13 11:27 GMT+1 óra  
De ha zavar az interfész lassúsága, megcsinálhatod hogy többször implementálod, pl a saját Canvas osztályod, és azt a változatot használod, amire épp fordítasz. Aztán még inline-olhatja is a függvényt a rendszer.

Megemlíteném, hogy mit találtam platformfüggetlenséghez, mikor keresgéltem régebben:
A haxe.org olyan nyelv, amit sok nyelvre le lehet fordítani. pl flash, javascript, php stb. PHP miatt kezdtem el tanulgatni (javasoknak egyszerű, még nem nagyon próbáltam, de jónak néz ki, meg a netes hsz-ek is jónak mondják.

   
Pretender - Törzstag | 2498 hsz       Online status #189452   2012.12.13 08:33 GMT+1 óra  
A c# akkor is a .net frameworkre épül. Dll meg nincs unixon, ott so van. Hogy szerzel azokból a dll-ekből egy so-t, ha nem fordították unix-ra? Hogy használsz winspecifikus dolgot unixon? Egyáltalán minek erőlteted a c#-ot, ha c++ hívásokat akarsz belőle?
Pont a lényegét akarod elhagyni a c#-nak, a "gyorsabb fejlesztést", mert sok minden benne van (a .net frameworkben), van hozzá winforms meg minden, de ez _csak_windowson_.

Ismételten mondom, ha nagyon szopatni akarod magad a platformfüggetlenséggel, akkor nem kell kb. egyetlen #ifdef sem a kódba (legalábbis ebből a célból), pont ezért mondtam az interface-t... az engine fogja az absztrakt osztályt (interface-t), és azoknak a függvényeit hívja. Ami persze virtual, szóval egy tök másik függvény fog lefutni, de az minket nem érdekel.

Van pl. 3 projected:
- Engine:
Mondjuk egy statikus library, ebben vannak az interface definíciók, meg az ezeket felhasználó kód.
- UnixApp:
Ebben az so-ban (! tehát ez so-ba fordul ígyis-úgyis) használhatsz unix specifikus dolgokat, illetve itt implementálod az Engine interface-jeit, amit aztán "öntudatlanul" fog hívni az Engine, ha ezt az so-t töltöd be neki.
- WinApp:
Az UnixApp-hoz hasonló, csak ez dll-be fordul, és Windows specifikus dolgokat használhatsz.

   
Bukta - Tag | 308 hsz       Online status #189451   2012.12.13 08:21 GMT+1 óra  
Hmm. Azt vágom mi az interfész, csak hogy mit mért írjak bele az lesz nehéz kitalálni. De arra majdcsak rájövök. A natív hivás lehet h szívás, de majd próbálom úgy csinálni, hogy ne nagyon legyen az. Legalább lesz tapasztalatom ilyen téren is. Azt lehet, h beszopat és nem fog összejönni, de majd mindent átgondolok.
"C#-al továbbra sem fogsz tudni platformfüggetlen kódot gyártani, csak úgy mondom."
Meglátjuk. Nem tudok rá semmi konkrétat mondani. Az alapgondolat az h ami mono runtime-vel lefut az a wines clr-en is fut. Az OpenTK.dll-t meg a többi dll-t meg átmásolom, ha nincs fenn a másik gépen. Ha meg c++-ba írnám akkor meg unixra és winre is külön -egybe fordítási feltételekkel #if #asd... - kéne fordítani.
Habár jó kérdés, hogy a fordítókat be lehet-e állítani, h milyen os-ra fordítson? Akár kódba akár kattintgatva. Me ugye az x86 és az x86_64 beállítható, de unix és win alatt más a futtatható fájl szerkezete és nem mind1, h *.exe a kimenet vagy standard unix futtatható fájl.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Pretender - Törzstag | 2498 hsz       Online status #189446   2012.12.13 06:56 GMT+1 óra  
A másik meg, hogy még egy Stringet sem olyan egyszerű átpasszolni. Ráadásul tényleg nagyon ocsmány kód lesz a végeredmény. Én is próbálkoztam ilyesmivel akkor, amikor a c++ enginehez egy értelmesebb winformos editort akartam csinálni. Nem jó ötlet...

   
versio - Tag | 659 hsz       Online status #189426   2012.12.12 21:27 GMT+1 óra  
en is gondolkodtam a c# -bol c++ hivasokra, de akkora szopas mint az allat
hogy adsz at egy pointert, mi mikor szunik meg , olyan katyvasz lesz az egesz es olvashatatlan , hogy a vegen azt mondod inkabb legyen full c++
   
Pretender - Törzstag | 2498 hsz       Online status #189418   2012.12.12 19:48 GMT+1 óra  
"De sztem C# lesz mert abból tudok C++ hívásokat végezni, ha kell"
Jaj-jaj, nem tudom miért komplikálod...

C#-al továbbra sem fogsz tudni platformfüggetlen kódot gyártani, csak úgy mondom.

Az interface meg arra jó, hogy van egy ilyened (pl. java)
Kód:
interface Cica {
    Cica create();
    void simogat(int a);
}

neked innentől nem kell ismerned a konkrét megvalósítást, hanem az interface függvényeit hívogatod.

   
versio - Tag | 659 hsz       Online status #189402   2012.12.12 13:10 GMT+1 óra  
ja kerem , tokeletes megoldas az nincsen

esetleg meg az unity, az mind 3 platformal kompatibilis, viszont fizetos, de csodat ne varj ettol se, mivel a windows gepek kb 10-szer gyorsabbak , es dx11 gpu-val rendelkeznek, egy iosre irt optimalizalt jatek, a hulladek kategoriaba tartozna metron
   
Bukta - Tag | 308 hsz       Online status #189401   2012.12.12 12:58 GMT+1 óra  
ahhoz képest hogy ezek milyen jók egész lassúak tök jó lett ez a html5 új dolgokat lehet vele csinálni, szebb, nem kell js minden esetben meg minden. De ugy látszik ezek nem játéra valók. Az űrben nem tudtam irányítani a pajzsot pontosan me lement az fps ugy szemmel mérve 17-22re A tankos azé ment egy ideig, de aztán gondolt egyet és bezárt a chromium lapja
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
versio - Tag | 659 hsz       Online status #189400   2012.12.12 12:33 GMT+1 óra  
M4 - Tag | 187 hsz       Online status #189399   2012.12.12 12:22 GMT+1 óra  
"html5 + javascript"
De ehhez le kell tölteni egy új böngészőt. Meg szerintem böngészőbe nem kéne programot fejleszteni, de ez magánvélemény.

   
Bukta - Tag | 308 hsz       Online status #189398   2012.12.12 12:22 GMT+1 óra  
M4: ezt nem tudtam, de logikus az igaz. De ami final meg ami static az nem hogy csak nem virtuális... szal a java az elavult sztem nem programoztható rendesen, visszatartja a belőlem kitörő vezérlési algoritmusokat
Matzi: Igazad van, de mégse. Ubuntu van a gépemen, de haveroknak win és jó lenne ha mind1iken futna. Sőt lehet hogy úgy lesz h én ubuntun ő meg winen fejleszti ugyanazt. A sebesség meg igenis számít, ahhoz hogy a kód lassú legyen nagyon béna algoritmus kell, annyira meg már talán nem vagyok béna.
De legyen úgy. Mind1 a sebesség. De nekem ne nyomjanak a kezembe olyan béna vezérlésszegény nyelvet mint a java. Am tudom h ebből nem lesz pénz nem azért csinálom

És igen az lesz amit mondasz. Ha C# akkor OpenTK ha meg C++ akkor meg sima OpenGL. Aztán ha nem tetszik majd nyergelek. De sztem C# lesz mert abból tudok C++ hívásokat végezni, ha kell. És akkor mind2 nyelvet taposom.
Neki is állok az OpenTK-hoz a legelejéről

versio: azért nem vészes annyira a felügyelt kód sebessége. Okosan kell csinálni. Pl azt vettem észre h az osztály szintű változóktól gyorsabb sokkal, de ez helyzettől függ.

Ezt a hozzászólást Bukta módosította (2012.12.12 12:27 GMT+1 óra, ---)
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
versio - Tag | 659 hsz       Online status #189397   2012.12.12 12:08 GMT+1 óra  
a java gyorsabb mint a c# tesztek szerint, bar a kulonbseg marginalis, a problema inkabb az akadasokkal van, amikor bekapcsol a carbage collector , vagy a JIT elkezd forditani, megakad a program egy pillanatra, ez engem annyira idegesitett hogy attertem c++-ra
   
versio - Tag | 659 hsz       Online status #189396   2012.12.12 12:04 GMT+1 óra  
ha kis fostaliga gemet akarsz irni , arra tokeletes az ios platform , az openglES-t ovodasok is konnyen megertik , annyira egyszeru, az objective c meg nem hiszem hogy gondot okozna a c# utan

ha viszont tenyleg multiplatform dolgot akarsz irni akkor erdemes elgondolkozni a html5 + javascript megoldason, ezt a visual studio is tamogatja, ,igaz kb 10-szer lassabb mint a c++ , de kompromisszumok nelkul eselytelen dontest hozni
   
Matzi - Szerkesztő | 2519 hsz       Online status #189395   2012.12.12 11:45 GMT+1 óra  
Bukta:
Pontosan miért is válogatsz ennyire? Ezeknek a kérdéseknek a 90%a valószínűleg évekig nem fog előbukkanni nálad. Kit érdekel, ha nem platformfüggetlen a kód, amit írsz? Egyből el szeretnéd adni talán, mert más okod nagyon nem lehet rá. Kit érdekel, ha lassabb, mint lehetne? Amíg nem írsz optimális kódot, addig úgyis lassú lesz valamennyire, a fő, hogy nálad fusson.

Válassz ki valamit, ami most neked szimpatikus, úgyis idő lesz míg rendesen megtanulod, aztán ha nem tetszik, akkor átnyergelsz egy másikra. Tökéletes meg úgysincsen, hiába keresed.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
M4 - Tag | 187 hsz       Online status #189394   2012.12.12 11:43 GMT+1 óra  
Javaban van JIT. Androidon egy ideig nem volt, de most már ott is van.
(Ha a függvény final vagy static akkor nem virtuális.)

   
Bukta - Tag | 308 hsz       Online status #189393   2012.12.12 11:23 GMT+1 óra  
A java csak virtuális függvényeket (késői kötés) használ ami tény h lassabb. Meg a C# elméletileg csak első futáskor fut lassan, pontosan nem tudom most, hogy ez hogy van asszem a JITter más. (Pontosabban ugy tudom h a java interpreterje nem használ futás közbeni optimalizációt magyarul nem JIT hanem interpreter. De aztán lehet van hozzá JITter is.) De az tuti, hogy a .net-es clr gyorsabb mint a java runtime e. Ezt más is igazolta 1-2 fórumon.


Am igen a C# ms függő, de azért ott van a mono is, habár ott is be van rakva az mscorlib.dll-hez a system.dll vagy melyik. Az xna-ról nekem is ez a véleményem, ezért keresek mást. Az interfészes megoldást nem igazán vágom, hogy ott most milyen dolgok platformspecifikusak. Natív (közvetlen os-t) nem igazán fejlesztettem. A C++ megy, de pl a system32.dll user32.dll meg ezeket még nem használtam. Linuxon meg nem is tudom mi felel meg a dll-eknek (Tul sokat szövegelek A lényeg az utolsó bekezdés. )


Meg van még ez a c#. Nem kéne neki sok h tényleg teljesen platformfüggetlen legyen -ha tényleg nem az. Nincs senki aki ezt így megoldotta? Nem pont az ms hanem valaki független. Csak bele kéne nézni a belébe.
Meg hallottam olyanokat, hogy a monoba nincs entity framework. Ez most hogy lehet? Én a managed kódot ugy képzelem el, hogy magas szinten megírunk mindent (winform, wpf, wcf...) és az lefordul IL-re. És akkor csak a clr-t kellene megírni os függőre. Most akkor mi az hogy nincs entity? Az nem IL-re fordul vagy mi? Oké, hogy a ms be akar pénzelni azt tudom. De ugye jól látom a felügyelt kód lényegét? Mert mindjá írok egy virtuális futtatókörnyezetet meg egy nyelvet hozzá aztán elmehetnek a sunyiba mindenhol lefutna faxa lesz
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Pretender - Törzstag | 2498 hsz       Online status #189392   2012.12.12 06:35 GMT+1 óra  
Nincs egy kis confused állapot itt?
- Ha C#-ban írsz egy kódot, akkor az Microsoft terméken kívül (hack nélkül) más OS-en nem fog futni (.net framework)
- Az XNA-t ideje lenne elfelejteni
- Ha több platformot akarsz, akkor Java / C++ és OpenGL, nagyon más választásod nincs.
- A Java és a C# "gyorsaságban" kb. egy szinten áll, szóval nem is értem, h mire gondolsz az alatt, hogy a Java a "leglassabb OOP nyelv" . A különbség annyi, hogy a Java kód (ha nem használsz platformspecifikus dolgokat) olyan class fileokat generál neked fordítás után, amit tetszés szerinti platformon el tudsz indítani, feltéve, ha van rajta java runtime environment. Ettől függetlenül nem szeretem a Java-t (bár van néhány egész okos megoldás benne)
- A platform-independenciát egyszer kell csak megcsinálni (interface-k erre nagyon jók), onnantól pedig lehet a saját, kényelmes kódunkat használni anélkül, hogy érdekelne minket, hogy az most éppen Win, vagy Unix, vagy egyéb hívásokat intéz.

   
LBandy - Tag | 271 hsz       Online status #189390   2012.12.12 00:42 GMT+1 óra  
Én az elmúlt négy napban ezt a tutorialt rágtam át:
http://arcsynthesis.org/gltut/, meglehetősen hasznos és jól adja át a szemléletet, a tutorialok mellé pedig ad FreeGLUT és Unofficial OpenGL SDK-t (c++ mindkettő ) , szóval kiindulási alapnak ha nem sürget az idő szerintem nagyon is jó. Mivel nekem napokon belül elkészítendő határidős projektem van végül az SFML lib-et használom a grafikához, ami szintén teljes opengl használatot enged, csak egy csomó egyéb macerától megkímél.
   
versio - Tag | 659 hsz       Online status #189389   2012.12.11 22:30 GMT+1 óra  
Bukta: teljesen felesleges tobb platformon nyomulni , egyet valassz es arra fejlessz, ha bejon a jatek felvehetsz egy rabszolgat, aki atirja majd a jatekodat masik platformra, tok feleslegesen szopatod magad, szerintem vagy az ios vagy a metro az idealis, en speciel a windows mellett dontottem , de ennek technologiai okai vannak
   
Lord_Crusare - Törzstag | 1287 hsz       Online status #189388   2012.12.11 22:18 GMT+1 óra  
Idézet
Bukta :
aha csak az a 3.1es változat. Am nem mondom h teljesen ki van lőve az xna, de inkább az opengl valami wrapperelt változatát vagy tisztán opengl és c++ használnék. Mert az opengl és a directx örök.



A második linkelt game az XNA 4.0-t használja, ott is ugyanúgy van shader, mint eddig. Nem tudom honnan ered ez a legenda...

   
Bukta - Tag | 308 hsz       Online status #189387   2012.12.11 21:41 GMT+1 óra  
Akkor megnézem azt az allegrát vagy miaz Meg van opengl jegyzetem is majd azt is megnézem és van vmi OpenTK az is esélyes még.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
kernel_panic - Tag | 117 hsz       Online status #189386   2012.12.11 21:33 GMT+1 óra  
Idézet
Bukta :
Am nem mondom h teljesen ki van lőve az xna, de inkább az opengl valami wrapperelt változatát vagy tisztán opengl és c++ használnék.


Akkor Allegro5 - ott OpenGL-ben azt csinálsz, amit akarsz, viszont megkímél az olyan szívásoktól, mint ami pl. az UTF karakterek használatával jár...

   
kernel_panic - Tag | 117 hsz       Online status #189385   2012.12.11 21:27 GMT+1 óra  
Idézet
Bukta :
Arról a két SDLről meg nem is hallottam még.


Azok olyan alantas feladatokat végeznek el, mint a bemenetkezelés, ablak kérése az OS-től, meg ilyesmik.

Idézet
Bukta :
Az OGRE az valami game engine ahogy látom.


3D grafikai engine igazából...

Idézet
Bukta :
És nekem nem engine kell, inkább az alapoktól indulok, más tákolmányait nem szeretem.


Jah, nem mondtad, hogy csak tanulni szeretnél, és nem játékot fejleszteni...

   
Bukta - Tag | 308 hsz       Online status #189384   2012.12.11 21:21 GMT+1 óra  
aha csak az a 3.1es változat. Am nem mondom h teljesen ki van lőve az xna, de inkább az opengl valami wrapperelt változatát vagy tisztán opengl és c++ használnék. Mert az opengl és a directx örök.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Lord_Crusare - Törzstag | 1287 hsz       Online status #189383   2012.12.11 21:13 GMT+1 óra  
Idézet
Bukta :
Mármint nem lehet benne írni egyedieket, csak ilyen beépítettek vannak.



Már hogyne lehetne egyedieket írni. Pl ez a projekt is XNA-s, meg ez is, és tele van direkt ezekhez a játékokhoz írt shaderekkel.

   
Bukta - Tag | 308 hsz       Online status #189382   2012.12.11 21:04 GMT+1 óra  
Lord_Crusare: Mármint nem lehet benne írni egyedieket, csak ilyen beépítettek vannak.
kernel_panic: Isten óvjon a javatól. Az a lehető leglassabb oop nyelv. A c# meg jól mondod, kezd visszaesni az xna, silverlight nincs már win8ba, wp8ba. (De c# van win8 alatt csak nem jatekfejlesztésre.) Arról a két SDLről meg nem is hallottam még. Az OGRE az valami game engine ahogy látom. És nekem nem engine kell, inkább az alapoktól indulok, más tákolmányait nem szeretem. Egy olyanra gondoltam, hogy a natív OpenGL-t hívogatom c# (mono)-val.

Ezt a hozzászólást Bukta módosította (2012.12.11 21:17 GMT+1 óra, ---)
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
kernel_panic - Tag | 117 hsz       Online status #189381   2012.12.11 21:04 GMT+1 óra  
@Bukta:
1. Java+OpenGL ?
2. Ha jól tudom, a C# szénája most nem áll túl jól, pl. az MS tudomásom szerint a WP-nél is visszatért a C++-hoz (mint "default" fejlesztői nyelv).
3. Az egyik legismertebb az SDL, de az Allegro5, illetve az OGRE3D tud olyat is, hogy back-end-ként Win-en Direct3D-t használ, máshol meg OpenGL-t. Mondjuk az is hozzátartozik a dologhoz, hogy ehhez minden célplatformon külön be kell lőni ezeket - viszont ha ez megvan, a saját kódod módosítás nélkül fordul mindegyiken.

   
Lord_Crusare - Törzstag | 1287 hsz       Online status #189380   2012.12.11 19:32 GMT+1 óra  
Idézet
Bukta :
XNA kilőve [...] mert nincsenek benne shaderek.



He?! Már hogyne lennének!

   
Bukta - Tag | 308 hsz       Online status #189379   2012.12.11 18:53 GMT+1 óra  
Valaki igazítson útba pls! Az a helyzet, hogy olyan frameworkkel akarok fejleszteni, ami windowson és linuxon meg még talán ioson is van. Asszem ez az OpenGL. DirectX csak ((win)e)n van tehát kilőve. A kérdések:
1. Van-e olyan framework OpenGL-be ami "minden" oprén ugyanaz? Tehát írok egy gamét linuxra akk az ugy matt lefut windowson is.
2. Melyik az amelyik az (1.) pontnak eleget tesz -és C#os? Tao || SharpGL || OpenTK || ...
3. Ugyanaz mint a 2. kérdés csak C++-szal.
4. Leginkább az érdekel amelyik nem valami szakadék széli (kihaló félben van), hanem közel ál az igazi OpenGL-hez

XNA kilőve (habár asszem az is Tao-t használt a monoba) me már a win se támogatja és mert nincsenek benne shaderek.
5. Habár az is érdekel hogy linuxon az xna mikor valami opengles cuccot használt akkor winre átrakva meg dx-et használ -(csak a release mappát átrakba)?
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Pixi - Tag | 205 hsz       Online status #189232   2012.12.04 11:29 GMT+1 óra  
Nemén O.o Egyik hogy nem is tudok ennyire angolul, másik én platform játék kedvelő vok, meg van még mit tanulnom programozásból.

   
Bukta - Tag | 308 hsz       Online status #189229   2012.12.03 21:34 GMT+1 óra  
Nem találjátok ki mit találtam. Pyxis 2 os .net micro frameworkkel. Tök nagy. Pixi nem te csináltad?
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Pixi - Tag | 205 hsz       Online status #189095   2012.11.29 11:11 GMT+1 óra  
Na a replacenél külön adom meg neki a "meg" és a "vett" szavakat, és ilyenkor minden esetben lecseréli azt szóköztől függetlenül (pont ezt is akartam), így még helyesen is jön ki a tájszólás hogy "mögvöttem" vagy "mögvötted" mert mi tényleg így ejtjük (ilyenkor pl. a vet egy t-vel helyes maradhat még, ezekre oda kell figyelni tudom) Abban az esetben, ha bizonyos szavakban nem cserélődhet az e ő-re, olyankor adok meg teljes szavakat, hogy ha egy szó része máshol is előfordul, akkor ne cserélődjön.

szerk: bár a fenti példák is szerintem sok szavaknál bekavarhatnak, sok szöveggel kell tesztelni, ez egy olyan dolog amit nem lehet gyorsan működésre bírni, mivel előbb átalakítható egy kész szövegben valami tájszólássá, mint hogy most én fejből listát írjak az egészről, az úgy nem fog menni, nem jut eszembe úgy mindegyik.

   
Pretender - Törzstag | 2498 hsz       Online status #189091   2012.11.29 08:30 GMT+1 óra  
Biztos van valami hasonló dolog a stringstream-hez c#-ban is. Ezzel a legszebb, fogod, elkezded bufferelni az adatot, és szőközönként kapsz egy stringet. Ezáltal nem kell mindig átnézni az újat, hanem szavanként haladsz.
Bár ez abban az esetben nem az igazi, ha csak teljes match érdekel minket. Erre gondolok:
Kód:
"meg" -> "mög"
"megvettem" -> nem változik

Ha viszont nem csak "full match" érdekes, akkor nyugodtan végigmehetünk a stringen szóközönként, mint c++ban a stringstreammel:
Kód:
std::stringstream ss("alma korte barack, szilva! korte megint?");
std::string tmp;
while (ss >> tmp) {
    // ...
}

Ekkor viszont nem az igazi a map, mert trükközni kell azzal, hogy az adott szó egy részére is keressük az elemet. (lásd fent)

   
M4 - Tag | 187 hsz       Online status #189090   2012.11.29 08:18 GMT+1 óra  
Igaz, de replace-nél az egész szövegre végzi a cserét, és egy új nagy string-et csinál (de ez nem biztos, mivel a string immutable, szóval ezt nem tudom) és az egész szöveget végignézi, és ezt minden replace-re.
Split-nél meg egy új string tömböt csinál és aztán készíthetjük a végső string-et. Split helyett stringtokenizert használnék, de azt nem találtam c#-ban.
De ha a szavak száma nem változik, akkor a kapott string tömböt is módosíthatjuk, majd string.Join-nal összefűzhetjük.

   
Pretender - Törzstag | 2498 hsz       Online status #189089   2012.11.29 06:25 GMT+1 óra  
Azt mondom én is Tehát az még rosszabb is, mint a replace, nem?

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #189087   2012.11.28 20:41 GMT+1 óra  
Konkrétan egy string tömböt

   
Pretender - Törzstag | 2498 hsz       Online status #189083   2012.11.28 16:16 GMT+1 óra  
A Split is új string(ek)et hoz létre, nem?

   
M4 - Tag | 187 hsz       Online status #189073   2012.11.28 12:02 GMT+1 óra  
Pixi: A C# nem tudom hogy optimalizál szóval lehet hülyeséget írok, de a replace létrehoz egy új string-et, mindegyik replace. És nem tudom ezt milyen hatékonyan teszi...
Szóval én úgy csinálnám, hogy string.Split()-tel felbontanám a szöveget, majd szavanként transzformálnám, és közben a transzformált string-eket StringBuilder-rel összeraknám.

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