|
|
Szerintem nem annyira éri már meg XNA-val foglalkozni. Ha jól tudom, a támogatása is megszűnt. Persze kérdéses, hogy mennyire érdekel a játékok lelki világa, az XNA ugyanis csak egy framework - keretrendszer -, tehát csak elég alap funkciókat kapsz meg vele: matematikai osztályok és függvények, contentek betöltése, és a többi. Viszont, ha már ennyire alap dolgok érdekelnek, akkor inkább a C++ és OpenGL/DirectX párosra szavaznék.
Ha a játékfejlesztés játéklogika programozás oldala jobban érdekel, akkor inkább ajánlanék egy kész engine-t. Ezekből elég sok van, de a személyes kedvencem a Unity, alap szinten nagyon gyorsan meg lehet tanulni használni, és szerintem elég kényelmes is.
Emellett pedig angolul sajnos - na jó, igazából nem sajnos  - meg kell tanulni, ha azt szeretnéd, hogy az informatikához érdemben közöd legyen.
|
|
|
Hello. Szerintetek megeri xna tanulo dvd-t venni..mert nem tudok sajnos anyira angolul.. ezsrt gondoltam erre. Kezdo vagyom szoval ha lehet epito valaszokat varok.elore is koszi
|
|
|
Ezt a hozzászólást Csongi30 módosította (2014.01.20 16:28 GMT+1 óra, ---)
|
|
|
Hali.
Lenne két visszatérő kérdésem.
1. Az olyan játékoknál mint a Terraria azok a zónák is el vannak tárolva, ami csak levegő? Ezt azért kérdem, mert ahogyan én elképzeltem hogy megcsinálok egy ilyen rendszert, annál problémát okozna, ha úgy lennének a tile darabkák eltárolva, hogy a levegő nincs külön mentve a memóriába, és valahol megsemmisül, vagy generálódik egy új tile, akkor index eltolódást okozna, ha kimenteném a tömbbe vagy gyűjteménybe (lehet nekem ez utóbbi lenne az ideális), ami éppen nincs loopolva, csak a memóriában tárolódik. Abban az esetben pedig ha a levegő is el van mindig tárolva, akkor mentéskor csak módosítani kell az adott tile darabka típusát és tulajdonságát, ettől még annak van helye mindenképp, tehát minden kis kocka terület egy előre lefoglalt hely és indexelt. Remélem jól kifejtettem, olyan ez mint ahogy van a 0 és 1, és ahol 0 van azt nem tárolnánk, csak az egyeseket, holott ez nem így van.
2. Hálózati játéknál szerintetek hogy oldották meg ezt az egészet ennyi elem esetén? Én azt gyanítom, hogy egy player mindig kap belépéskor egy nagyobb adagot egyszerre a világból, hogy ha kicsit mozog is egy irányba ne kelljen minden lépésnél újra tile-okat betöltetni a részére. De akárhogy nézzük sok ez. Abban a pillanatban, amíg meg nem kapja meg 1 player a részére szánt kicsi wolrd szeletet, addig másik játékosokkal nem is kommunikál a szerver, vagy pedig valamilyen break-elt hatással történik? Tehát a szerver ad neki valamit, majd felváltva foglalkozik a többi player-el is ne legyen nagy lagg? Valószínűleg a lidgreen network-ot fogom hálózati célból felhasználni, eddig ez tűnik legegyszerűbbnek, és gondolom hatékony is, ha már a MonoGame-vel alapból ezt ajánlják.
|
|
|
Idézet Pretender :
Igen, mindenképpen. Sokkal gyorsabb is, mint minden frame-ben újraszámolni. Illetve ha OOBB kell, akkor az nem írható le min-max értékekkel, mivel nem párhuzamos a tengelyekkel.
Megvilágosodtam...  az a problémám hogy az én BB generáló fn-em nem igazán alkalmas OOBB készítésére... nekiesek még 1x...
|
|
|
Valaki használja még rajtam kívül a MonoGame-t? Csak mert a nem hivatalos verzióval a 3.2-vel már lehetőség van DX-et Desktop környezetben is használni:
http://build.monogame.net/job/develop-win/lastSuccessfulBuild/artifact/Installers/Windows/
Itt már használhatóak a meglévő xnb kiterjesztésű fájlok hangoknál, tömörítve is (tehát nem csak a Best-et tudja használni, és nem kell nagy méretű wav fájlokkal szenvedni mint Desktop GL-nél). Persze a Content Pipeline végett kell egy normál XNA-s projektnek lennie. Már csak azért is jobb ebben dolgozni, mert észrevettem, hogy gyorsabban elindul az egész játék, stabilabbnak tűnik mint alap XNA-val, valamint a FixedTimeStep bekapcsolásával nem pörög 100%-on a proci. Elvileg DirectX11-et igényel, de nálam egy GF7300-al is elindult a játék ami csak 9-es, NetFramework4 és legfrissebb DX verzió mellett. Hogy XP-n működik-e azt nem tudom, én 7-et használok. Aki esetleg használja az jelezzen hogy mik a tapasztalatai.
|
|
|
Igen, mindenképpen.  Sokkal gyorsabb is, mint minden frame-ben újraszámolni. Illetve ha OOBB kell, akkor az nem írható le min-max értékekkel, mivel nem párhuzamos a tengelyekkel.
|
|
|
Igazából nekem csak az OOBB kellene... Lehet célszerűbb lenne a BB oknak a 8 csúcsát külön tárolni és azt transzformálni?
|
|
|
Nekem a vége nem tetszik, hogy a min,max pontokat transzformálod.
Úgy kellene, hogy a mesh adott vertexét transzformálod, és arra nézed meg a min,maxot, mert akkor megkapod, hogy a world matrixszal transzformált modell vertexeit mi az a legkisebb box, ami közrefogja. Ez azonban elég lassú lehet, ezért a következőt lehet csinálni:
A mesh betöltésekor identitáns mátrixszal kiszámolod a bounding boxot. A min, max meghatároz egy boxot, ami ugye leírható 8 csúccsal. Amikor a világban szeretnéd megkapni az AABB-t (azaz Axis Aligned Bounding Box), akkor a betöltéskor megkapott 8 csúcspontot transzformálod a world mátrixszal, és azok közül keresed meg a minimumot, maximumot.
Pseudo-kód:
Kód: vec3 localPoints[8];
vec3 worldPoints[8];
void load()
{
localPoints = BuildBoundingBox(mesh, Matrix.Identity);
}
void update()
{
computeWorld();
worldPoints = transform(localPoints, world);
min = vec3min(worldPoints);
max = vec3max(worldPoints);
}
Bizonyos esetekben ez a módszer pontatlanabb, mintha újraszámolnád, viszont kevés az olyan objektum a térben, ami csak 8 csúcspontból áll, tehát gyorsabb.
Illetve "melléktermékként" megkapod az OOBB-t (Object-Oriented Bounding Box)
|
|
|
A BuildBoundingBox fg ez lenne:
Kód: public BoundingBox BuildBoundingBox(ModelMesh mesh, Matrix meshTransform)
{
var meshMax = new Vector3(float.MinValue);
var meshMin = new Vector3(float.MaxValue);
foreach (var part in mesh.MeshParts)
{
var stride = part.VertexBuffer.VertexDeclaration.VertexStride;
var vertexData = new VertexPositionNormalTexture[part.NumVertices];
part.VertexBuffer.GetData(part.VertexOffset * stride, vertexData, 0, part.NumVertices, stride);
for (var i = 0; i < vertexData.Length; i++)
{
var vertPosition = vertexData[i].Position;
meshMin = Vector3.Min(meshMin, vertPosition);
meshMax = Vector3.Max(meshMax, vertPosition);
}
}
meshMin = Vector3.Transform(meshMin, meshTransform);
meshMax = Vector3.Transform(meshMax, meshTransform);
return new BoundingBox(meshMin, meshMax);
}
Amíg a fg hívásnál kihagyom a rotation-t tökéletesen megcsinálja:
http://sdrv.ms/1aYuwwA
Aztán ha szeretném forgatni a BB-ot is az eredmény a következő:
http://sdrv.ms/1aYuyV6
|
|
|
Milyen értelemben torzul el? Mit csinál a BulidBoundingBox függvény? Mármint így a neve alapján sejtem, csak hátha van valami hiba a kódban.
|
|
|
Sziasztok!
BoundingBox forgatásánál akadt egy kis problémám, Méretezni mozgatni gond nélkül tudom de amint forgatni szeretném eltorzul az egész bb.
BuildBoundingBox(mesh, boneTransforms[mesh.ParentBone.Index] * Matrix.CreateScale(20.0f) * Matrix.CreateRotationY(1.0f) );
Már próbáltam elég sok mindent de nem leltem megoldásra. Valakinek bármi ötlete?
|
|
|
Én egyszerűbben csinálnám, egy sima 2d tömbben kezelném az egész pályát, 1 v 2 byte per tile, ez a már említett Terraria szintű méretekben, vagy még nagyobban is működik. Ha borzasztóan nagy vagy végtelen méretű pályát szeretnél, akkor tényleg részekre kell bontani, és betölteni ha kell.
Most néztem Terraria-nál a large world: 'Large - 8400 blocks wide and 2400 blocks high, sky limit about 800-900 blocks above underground level'
Tehát 8400*2400 = 20.160.000 ~20 megabyte ha 1 byte per tile, 40 mega ha nem 255 hanem 64K tile kell. Ez nem sok memória manapság. Ha egyéb is kell, pl előreszámolt fények per tile, akkor egy még több is lehet, mondjuk RGBA 4 byte-tal még 80 mega. De ezzel sem sok.
Ebből kinézed azt a részt, ami látszik, és kirajzolod. Kiszámolod a bal felső sarok x,y (tile)koordinátáját a screen-nek, a jobb alsót is, és ebben a téglalapban van minden kis négyzet, ami látszik.
Én egy nagy dinamikus vertexbuffert használnék, 2 háromszög per négyzet, és a textúrakoordinátákat a tileindex alapján módosítanám, textúraatlaszból egy menetben lenne kirajzolva.
|
|
|
Volna egy másik kérdésem. Az még ok, hogy megoldani mit rajzoljon ki, ami csak a képernyő látható részébe esik (közben utánanéztem a Terraria 16x16pixeles négyzetecskéket használ). Azt is értem, hogy felosztani a területet több nagyobb zónára, és az aktuálissakat ami a player/képernyő meghatározott közelségében helyezkedik el, csak azt kezelje a ciklus. De hogyan és mivel tárolom el mindazt, amit nem használok éppen? Most úgy képzelem el, hogy minden a RAM-ban legyen (nem baj ha az sokat eszik), tehát nincs használatban a file-ban tárolás. Vagyis amiket használok, tehát a képernyőn látható, és egy picit a képernyőn kívül eső is benne van egy for ciklusban, de addig hol tárolódik a többi, és hogyan tudom betölteni azt a ciklusba amikor megközelítem a zónát? Tehát eltárolás RAM-ban valamint load/unload a ciklusban. Hiába értem az elméletet, ha nem tudom hogyan kódoljam ezt le. Valahogy így képzelem én:
http://kepfeltoltes.hu/130718/teruletfelosztas_www.kepfeltoltes.hu_.jpg
Idézet the best option (most large world games do this), is to split your terrain into regions. Split the world into chunks of, say, 512x512 tiles, and load/unload the regions as the player gets close to, or further away from, a region. This also saves you from having to loop through far away tiles to perform any sort of 'update' tick.
|
|
|
A DX az a sima XNA, a GL-es a Mono-val készült, és akk igen ezek szerint ott valami hiba van. Bár eleve nem értem hogy a Terraria játékot hogyan oldották meg, mert nem ColorMap-nak tűnik, hanem sok kis rectangle-k.
|
|
|
A dx-es is Mono-val készült, vagy az XNA? Mert lehet, hogy nem a GL/DX kérdéssel van a gond, hanem a Monoban van valami rosszul implementálva.
A sprite batch a háttérben VBO-kat (Vertex buffereket) gyűjtöget össze, és egy kupacban rajzolja ki (ha jól van megcsinálva). Ha ez a gyűjtögetés mondjuk rosszul van megcsinálva, akkor az gáz.
|
|
|
Nah ha két külön spriteBatch-ban rajzolok ki, akkor működik, tehát felosztom a képernyőt 2 részre, ami 300-on felülre esik, meg külön egy másikba ami 300-on alulra  Bár aki jobban ért hozzá elmagyarázhatná, hogy ezt miért csinálja a GL. Mitől tud a DX egy spriteBatch-en belül akár 1x1-es pixelenként is telerajzolni egy egész ablakot (ok ekkor a procit pörgeti nagyon már, de nem is ez a lényeg most), és a GL meg miért nem.
|
|
|
Az mitől van, hogy MonoGame OpenGL-el limitált a kirajzolandó textúra darabkák száma? Tudom ezt orvosolni, vagy sem? Egy amolyan Terraria alapú rendszert szeretnék megpróbálni felépíteni, de ez az eredmény: 800x600-as felbontáson 5x5 széles egy elem:
http://kepfeltoltes.hu/130717/DirectXvsOpenGL_www.kepfeltoltes.hu_.jpg
Én úgy szoktam ezt csinálni, hogy rakok egy 800x600-as rectanglet, és ha abba belelóg egy kisebb rectangle, akkor annak textúrája kirajzolódik, különben nem. És ahogyak haladnak ki a "láthatósági négyzetből" az emelek, úgy elkezdi kirajzolgatni azokat, amiket előtte nem, de csak OpenGL-el ilyen.
|
|
|
Így első projectnek egy 2D a célom, idővel persze 3, ha jól megy
|
|
|
Az attól függ mit szeretnél csinálni. 2D-t viszonylag könnyű vele készíteni, 3D-t azt nem tudom.
|
|
|
Értem köszi, igazából örülök ha magát a játékot felépítem a hangeffekt az csak a ráadás, de akkor erre majd odafigyelek
|
|
|
Blitz:
Ha már XNA-zol, akkor felhívnám 2 dologra is a figyelmed. Ha még nem jutottál a media lejátszáshoz (konkrétan Song és Video amelyek a MediaPlayer-t igénylik), akkor azt hadd a fenébe ne is tanuld sztem  Mégpedig azért, mert ha később komoly terveid lesznek, akkor kénytelen leszel átportolni pl. Mono-val (mivel hogy ez az XNA egyik alternatívája, maga az XNA már nem támogatott) a játékod, és ott nem biztos, hogy működni fognak a MediaPlayer-t igénylő Contentek...
A háttérzenék lejátszásához egyszerűen használd a SoundEffectInstance-t majd (a linkelt oldalon majd azt is megtalálod, pofon egyszerű használni). Amíg az egyszerű hangeffektusok lejátszásához elég a SoundEffect, addig a SoundEffectInstance-t úgy tudod kezelni mint (XNA alatt) a Song-ot, tehát félbe tudod szakítani, vagy ismételtetni ha befejeződik, stb. csak éppen nem kell hozzá a Media Player.
Maga a Videó (wmv) lejátszása pedig (még) nem működik Mono-val, erről ennyit írnak:
http://monogame.codeplex.com/discussions/434919
A MediaElement-et viszont nem tudom hogy kell használni. Vagyis ha már tanulod, akkor erre kettőre ne pocsékolj időt sztem XNA alatt.
|
|
|
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
|
|
|
De tetszik hogy ilyen segítőkészek vagytok :-) azt hittem majd csak leszóltok, hogy már itt elakadtam..a linket majd megnézem köszi
|
|
|
|
és akkor így tudsz ugynevezett részecskerendszert csinálni. pl robbanás effekt. kirajzolsz sok kicsi piros képet egy pontból kiindulva aztán forgatod elrepíted (eltolod) a darabokat. Az fain
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
|
|
|
Képet a spriteBatch objektummal rajzolhatsz ki, a spriteBatch.Draw eljárással. Ennek különféle paraméterei vannak, amikkel méretezheted, forgathatod vagy tükrözheted a képet.
|
|
|
és tényleg...ez eszembe se jutott volna, köszi  D
|
|
|
akkor jegyezd meg: a gép nem hibázik, azt csinálja amit beleírnak 
A hiba olyasmi, hogy egy nem publikusan deklarált tagot akarsz publikussá tenni. Pl egy privát osztályként (class Alma vagy private class Alma) deklarált objektumot nem tehetsz publikussá egy másik osztályba. Vagy valami elérésmódosító hibádzik.. Gondolom V Studioba nyomod az asszem nem írja ki a compile error számát. De most megtaláltam:
[url]http://msdn.microsoft.com/en-us/library/ha94aebs(v=VS.80).aspx[/url]
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
|
|
|
Kód: WindowsGame15.Sprite.Draw(Microsoft.Xna.Framework.Graphics.SpriteBatch)' is inaccessible due to its protection level
ez mit jelent? kezdő XNA-s vagyok, csak egy képet szeretnék kirajzolni és ezt a hibát adja ki. tutorial alapján csináltam(neki működött), szóval ugyanaz a kódja..mégse jó
|
|
|
@Pixi: Ha most épp engine választás előtt állsz, akkor akár megnézhetnéd az Ogre-t is, ami viszont támogatja az IOS, Android, WinRT stb. platformokat is ingyen.
|
|
|
Ez nagyon jó ha tényleg így van, mert én a .NET-et használom
|
|
|
Azon a platformon, amihez a Xamarin kell 300-2000 dolcsi a licensz díj, attól függően mire kell. Ahol Mono, vay .NET van feltűtetve elvileg ingyenes.
|
|
|
Ha már OpenGL...időközben megint előszedtem a MonoGame-t, és win7 alatt vs2010-el tudtam vele portolni Windows GL-re. (METRO-ra gondolom kell az újabb vs2012 és Win8 kombó) Ez gyorsabbnak tűnik mint a DirectX. Pontosan milyen licensze van a Mononak? Erről tudna valaki bővebben írni? És ha más enginet használok amiben ez integrálva van, akkor mégis hogy lehet olcsóbb, ha a mono framework-jét használja fel?
http://www.monogame.net/price
|
|
|
oda van írva, hogy crossplatform
|
|
|
de mit akar az ANX az opengl-tol? mikor directx-es
|
|
|
ez a függvény annyira népszerű lehet, hogy még az nvidiában se igazán merült fel a támogatása a termékpaletta fele esetében ezekszerint
de valójában ez arról a bizonyos szoftverről mond el sokmindent, ami ezt használni szeretné
amelyet jelen esetben úgy hívnak, hogy ANX
igazi programozói és mérnöki csúcsteljesítmény lehet, csak úgy süt belőle a megfontoltság, a minőség, és a teszteltség
bárcsak minden szoftver ennyire minőségi lehetne
|
|
|
Geri ezt kifejtenéd bővebben nekem?
|
|
|
|
Az egy katasztrofalis kartya, de amugy siman egy opengl fv-t nem talal (gondolom a kutya nem ellenorzi le h tamogatva van-e).
|
|
|
Kód: System.EntryPointNotFoundException was unhandled
Message=Unable to find an entry point named 'glColorMaski' in DLL 'opengl32.dll'.
Source=OpenTK
...
Ezt kapom az ANX framework alternatíva Debuggolásakor. References-hez hozzáadtam mindent, névtereknél is minden kicserélve, egyéb hibát nem jelez. Gyanítom, hogy a kártyám elavult (GF7300GT), mert a honlapon van egy ilyen rész, hogy:
Idézet
By swapping this systems you are no more limited to run your game using DirectX9 which XNA is using. ANX comes with a DirectX10 RenderSystem as a default. A DirectX 11, DirectX 11.1 and a OpenGL 3 RenderSystem is currently in development.
De azért jó lenne, ha valaki ezt megerősítené. Amúgy mit gondoltok jó alternatíva? Tudom, hogy még fejlesztés alatt áll, de folyamatosan fejlesztik.
|
|
|
Találtam egy kézzel foghatóbb leírást a "Mono to Win8 METRO"-val kapcs:
http://ballerindustries.com/2012/11/using-monogame-to-port-an-xna-game-to-windows-metro/
Viszont nekem Win7 van fent és VS2010, de azóta a BETA-n kívül már kijött Mono-ból a 3.0.1-es. Mi lehet az oka, hogy nálam nem jelenik meg a képen látható "MonoGame Game" se a "MonoGame Game (XAML), ehelyett van:
- MonoGame Android Projekt
- MonoGame Content Projekt
- MonoGame Linux Projekt
- MonoGame OUYA Projekt
- MonoGame Windows OpenGL Projekt
A 2.-nál a Content-nél írja, hogy "An empty MonoGame content project targeting one or more platforms." Most akkor ez lenne az így picit átcsinálva, vagy pedig feltétlenül Win8 és/vagy VS2012-őn belül jelennek meg az oldalon látható lehetőségek is?
|
|
|
A SlimDX csak egy managed wrapper a directX köré. Az XNA ennél valamivel többet adott, pl az asset managementet. Viszont annyival többet tud, hogy DX10 (és talán 11) is van alatta, így több eszközhöz férsz hozzá, csak alacsonyabb szinten. Ha managed környezetben akarsz fejleszteni, akkor egy lehetséges alternatíva, csak meg kell írni hozzá pár dolgot.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
Mi a helyzet a SlimDX-el? Ez mennyire hasonlít XNA-hoz, egyáltalán érdemes vele foglalkozni? Most csak úgy tekintsünk rá, hogy only 2D-s játék. Azt olvastam, hogy ez csak Windowson fut.
|
|
|
Idézet versio :
en semmit nem adok el androidon , ez ezer szazalek 
Talán nem én vagyok az egyetlen, aki ettől nem érzi rosszabbul magát...
|
|
|
Idézet Pixi :
És akkor mi van jelenleg a MonoDevelop-al? Használni még nem használtam csak érdekelne ezek után van-e jelenősége.
Mono az fizetős, olcsóbb használni egy enginet ahol ez integrálva van pl Delta Engine.
|
|
|
en semmit nem adok el androidon , ez ezer szazalek
|
|
|
Idézet versio :
az igenyek csak a gyerektablaknal szorult vissza, windows tablakon kicsit mas a szint, hidd el en a c# mellett allok, de amikor a rajzprogramom 3 akadassal indult el akkor muszaj volt visszaterni a c++-ra , amugy jatekot jelenleg nem is tudsz fejleszteni c#-vel, mert nincs hozza hivatalos 3d api, support es teszteles nelkuli third party cuccokkal meg csak amatorok szorakoznak
Amiről te írsz az a profi/hardcore réteg, ami egy kis szelete a piacnak. Amit én írok az pedig a döntő többség, az átlag. A Windows visszaszorul vállalati/fejlesztői szegmensbe, ami minket eladási szempontból már nem kell hogy érdekeljen. Ettől még persze lehet vs-el C#-bam fejleszteni csak a végeredményt már lehet hogy Androidon fogod eladni.
|
|
|
És akkor mi van jelenleg a MonoDevelop-al? Használni még nem használtam csak érdekelne ezek után van-e jelenősége.
|
|
|
az igenyek csak a gyerektablaknal szorult vissza, windows tablakon kicsit mas a szint, hidd el en a c# mellett allok, de amikor a rajzprogramom 3 akadassal indult el akkor muszaj volt visszaterni a c++-ra , amugy jatekot jelenleg nem is tudsz fejleszteni c#-vel, mert nincs hozza hivatalos 3d api, support es teszteles nelkuli third party cuccokkal meg csak amatorok szorakoznak
|
|
|
Legújabb project:
Smashed Potatoes
Legutóbb frissített project:
Smashed Potatoes
Friss kép a galériából:
|