játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
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:    2188
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] [16]
zeller - Törzstag | 464 hsz       Online status #162321   2011.09.02 15:01 GMT+1 óra  
az a >2 kivalthato lenne state-tel, csak eppen semmi ertelme nem lenne.

A patternek es az oo az atlathatosag es nem a teljesitmeny kedveert vannak.

c#-ba meg ne programozz c++-ban is van polimorfizmus.

   
borsi - Tag | 180 hsz       Online status #162320   2011.09.02 14:48 GMT+1 óra  
Rossz példát hoztam, és lehet, hogy amúgy sincs igazam. Még bev.progról annyi megmaradt a témában, hogy kerüljük a feltételes elágazásokat, mert meglehetősen költségesek főleg egy stream processzoron (GPU).

   
ddbwo - Tag | 1625 hsz       Online status #162319   2011.09.02 14:35 GMT+1 óra  
De ezen a címen semmi nincs. A problémájuk egy sima tömbbel kiváltható. De hülyeség a feladatjuk.

char betuk[101] (feltételezem az A-t elírta, különben ütközne az F-el)
először a betűket a tömbbe vázolják a megfelelő szám alapján. Ezek a lehetséges variációk.
amikor a szám, amire meg akarják kapni a betűjüket például 45, hívásnál a kövi jöhet ki:

char fokozat = betuk[45]

Vagyis a szabály alapján a kérdezet fokozat egyből 'F' lesz így. De ezt előtte be kéne írni minden lehetséges változatra, és azt sem tudom, hogy lehet-e kisebb nullánál. (már a lekérdezendő számuk)

if helyettesítő-nek jó, amennyiben ismertek a lehetséges változatok és számokról van szó.

// két dolog javítva, alszok még xd
+ najó, magnézium pótlás kell
+ ok, rájöttem, százalékot számolnak, abban nincs kevesebb 0-nál
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5444 hsz       Online status #162318   2011.09.02 13:50 GMT+1 óra  
Másold már be azt a sort a linkedböl ami teljesítményben jobb mint az if...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
borsi - Tag | 180 hsz       Online status #162316   2011.09.02 13:43 GMT+1 óra  
Ezt így nem lehet kiváltani, de nem is életszerű a példa. Viszont sokszor van, hogy egy if/else kiváltható többé-kevésbé komplex matekkal. Az átláthatóságnak nem tesz jót, viszont a teljesítménynek igen.
Egy példa: http://www.bleepingcomputer.com/forums/topic375886.html

   
ddbwo - Tag | 1625 hsz       Online status #162315   2011.09.02 13:40 GMT+1 óra  
Hát nem is tudom, a példák mindig metódusokban dolgoznak már, aztán visszalapozva pár oldalt meg kiderül, hogy a metódus sok-sok if - et takar.

Ha már megvannak a logiai dolgok, amiket csak le kéne ellenőrizni, van rá mód hogy csak egy if legyen. Múltkor épp ezt találtam ki.

Ha minden dolognak kell teljesülni... és és és alapján, ha a szorzat 0, valami nincs meg. Ha nagyobb, minden feltétel adott.
and_thing = 1*1*128*1*1*1*0*1*0*5*1.14*0*12*1*16*1*33*0 (= 0)

Ha vagy vagy vagy, elég az egyik feltétel, összeadásnál kiderül. Amennyiben bármelyik van, az összeg nagyobb, mint 0.
or_thing = 0+0+0+0+0+1+0+48+0+0+0+0+0+0 (= 49)

Ezzel ki lehet váltani az újboli if-ezést, de először mindenképpen ki kell számolni valami alapján a mért dolgokat, kivéve ha olyan tulajdonságok, amik amúgy is változnak logic step-enként. Ezeket újra lehet összegezni vagy szorozni, több lépcsőben is a végére kiderülhet amit akarunk.
Szép kis logic metódusok lehetnek belőle. De fogalmam sincs hogy számít-e.

De ezt is csekkolni kell a legvégén if el, és ott is csak egy bool jön ki.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5444 hsz       Online status #162313   2011.09.02 13:21 GMT+1 óra  
Ha ezt kiváltod nekem polimorfizmussal akkor elkezdek c#-ben programozni:

Kód:
if( a > 2 )
{
    // blabla
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #162308   2011.09.02 12:40 GMT+1 óra  
napokkal ezelott volt szo arrol, hogy a programozas == if-else.

Ehhez annyi jutott eszembe, hogy a felteteles elagazasok kivalthatoak
polimorfizmussal
state vagy strategy patternnel.
Mar ha eppen megeri.

Hatha valakinek ujat mondtam...

   
TomX - Törzstag | 223 hsz       Online status #152271   2011.05.19 15:34 GMT+1 óra  
Én még mindig 24 FPS párti vagyok. Ha ennél nagyobb folyamatosság kell, ott a motion blur.
   
gopher - Törzstag | 496 hsz       Online status #152269   2011.05.19 15:02 GMT+1 óra  
Az azért van, mert fix framerate-es a játék (jelenleg 77 FPS-en kéne mennie). Tudom-tudom sz.r, gány, blöáh, de most evvan

Ha Intel GMA-n futtatod a cuccot, akkor a be kell állítani az OpenGL driver-ét, hogy fullscreen-en se legyen vsync, nem veszi figyelembe az SDL beállításokat Ez miatt lehet átírom az egészet fix 60 FPS-re, hogy ezzel se legyen gond.

Szerk: Fix 50 lett, így most ablakos módban nem idegesítő a "tearing".

Ezt a hozzászólást gopher módosította (2011.05.19 19:45 GMT+1 óra, ---)
   
fpeti - Törzstag | 1290 hsz       Online status #152078   2011.05.16 01:03 GMT+1 óra  
Megnéztem az fps értékeket, nálam 1024x768-ban atom stabilan 75 fps volt 1280x1024-en pedig 60. De 640x480-on is csak 75, pedig 'screen_vsync = 0' beállítottam a config.ini-ben.
Mintha a játék is lassulna kisebb fps esetén, ez fura volt.
Szerintem elég gyors.

Idézet
Asylum :
Nem olyan szar az az intel gma, minden progim faszán fut rajta.


Néztem neten miket tudhat, annyira tényleg nem rossz, mint gondoltam:
playable games on Intel GMA 4500

Ezt a hozzászólást fpeti módosította (2011.05.16 01:51 GMT+1 óra, ---)
   
gopher - Törzstag | 496 hsz       Online status #152077   2011.05.15 23:59 GMT+1 óra  
Kipróbáltam: Soldier of Fortune mégsem fut normálisan, de az valami más lehet (hiába állítgatom a felbontásokat, minőséget), viszont a Halo (1), teljesen rendben fut, még 1600x900-on is (nagyjából).

A gond ott van (szerintem), hogy glColor/glTexCoord/glVertex-hez lett igazítva a kód, így jelenleg egy vertex adatot többször is átadok feleslegesen (az már csak hab a tortán, hogy olyat is kirajzolok, ami takarásban van). Szóval ez ilyen gány na Ahhoz pedig, hogy ne legyen az, eléggé hozzá kéne nyúlni, és igazából így is megfelel, a legtöbb gépen elfog futni (tegye fel a kezét, akinek mondjuk van PIII-asa és használja is). Szóval annyit nem ér meg, hogy tovább forszírozzam.

Ettől függetlenül, mindenkinek kösz a tanácsokat, a legközelebbi OpenGL-es projektnél már nem fogok használni ilyen ősrégi dolgokat ígérem

Szerk: azért jár rajta az agyam, de előbb inkább legyen meg az öt pálya fullosan, aztán ha lesz rá igény, még optimalizálok rajta.

Ezt a hozzászólást gopher módosította (2011.05.16 00:13 GMT+1 óra, ---)
   
Asylum - Törzstag | 5444 hsz       Online status #152074   2011.05.15 22:55 GMT+1 óra  
Nem olyan szar az az intel gma, minden progim faszán fut rajta.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1290 hsz       Online status #152073   2011.05.15 22:07 GMT+1 óra  
Nem is a poligonszámmal van a baj, inkább a fillrate (kirajzolt pixelek száma) lehet a ludas. Esetleg ha nagyon sok a drawcall, de 500 alatt nem érdemes foglalkozni vele. Sajnos az Intel gma-k nem arról híresek, hogy gyorsan rajzolnának a képernyőre (ha megnézed a neten, kb pong-ra tartják alkalmasnak kis túlzással a 4500-asat, pedig dx10-es kari - elvileg). Azaz felbontásfüggő a gépeden a sebesség - ahogy mondtad is, sokkal gyorsabb 1024x768-on, a 3szögek száma gondolom közben nem csökken.

Ahogy emlékszem a játékra, nem volt ott túl sok képernyő újraírás, a látótávolság nem túl nagy és elég messze vannak egymástól a falak, hogy ne irkálják többször újra a pixeleket. Szóval túl sokat nem lehet ezen javítani. (ha tényleg ettől van)

Annyit esetleg még megpróbálhatnál, ha még nincs, hogy a előröl hátrafelé rajzolsz (legközelebbi fallal kezdeni), akkor az ' early-z-test' még dobhat rajta valamit.
   
gopher - Törzstag | 496 hsz       Online status #152072   2011.05.15 21:20 GMT+1 óra  
Amúgy, majd neki fogok szerintem állni, mert lett végre egy full HD-s monitorom, és csak mozgatja a fantáziám, hogy menjen ezen is rendesen (és az X4500-as integrált videó nem kifogás, mert pl. Soldier of Fortune simán megy rajta, és abban szerintem egy nézetben van annyi poligon, mint nálam az egész pálya mindenestől)
   
Parallax - Tag | 579 hsz       Online status #152070   2011.05.15 20:33 GMT+1 óra  
Idézet
gopher :
No, hát csináltam egy TileVertexArray osztályt, ennek adogattam át az infókat, majd a végén egy glDrawArrays-zal kitettem. Nem túl sok változás történt. Persze, tudom, hogy miért, mert ugyanannyi infót adok át, rengeteg a redundancia

Persze önmagában ez se csodaszer, ha 100*100-as mátrixban 10 ezerszer hívsz meg mindent. Kicsit át csoportosítod, listákba rendezed és kész.

   
gopher - Törzstag | 496 hsz       Online status #152062   2011.05.15 19:29 GMT+1 óra  
No, hát csináltam egy TileVertexArray osztályt, ennek adogattam át az infókat, majd a végén egy glDrawArrays-zal kitettem. Nem túl sok változás történt. Persze, tudom, hogy miért, mert ugyanannyi infót adok át, rengeteg a redundancia, kb. így nem is fog érni semmit. Attól félek, így kellett volna kezdeni az elején (VBA, vagy inkább VBO), akkor rögtön más lenne a struktúra is, így most a sz.nak egy pofon

Egyébként ez most annyira nem is prioritásos, csak gondoltam, hátha lehet valamit gyorsan alkotni. 1024x768-on kb. 140-170 az FPS, szóval ezzel egyelőre megelégszem, inkább csinálom a negyedik pályát, meg a negyedik ellenfelet

Seeting: hát igen. Jelenleg abszolút nincs a sorrendre figyelve. Úgy vagyok vele, majd ha valakinél lassú lesz, akkor esetleg neki állok, de addig is legyen má' kész
   
Seeting - Törzstag | 2306 hsz       Online status #152055   2011.05.15 17:10 GMT+1 óra  
Az alpha blending miatt is sokat esik altalaban ha a fixed pipeline-t hasznalod. Ugy lehet ezt megoldani, hogy irsz egy pixel shadert, ami nem csinal semmit, csak atveszi a texel szinet, es igy (ha a texel alphas, akkor ) nem ignoralodik az atlatszo pixel (ami altalaban nagyon lassit), hanem felveszi a mogotte levo pixel szinet.

Persze ennek a modszernek az a hatranya, hogy oda kell figyelned a kirajzolas sorrendjere is.
   
Parallax - Tag | 579 hsz       Online status #152052   2011.05.15 16:42 GMT+1 óra  
Idézet
gopher :
Okés, értem én Akkor megpróbálkozok ezekkel a Vertex Array-okkal.


Van egy darab vertices tömb, mert minden tile egyforma. Van n textúra index és m tile pozíció. Akkor lesz elvileg összesen egy VertexPointer, n BindTexture és m Translate-Draw hívás. Így jónak kell lennie, mégha nem VBO-zol, vagy egyéb akkor is.

   
gopher - Törzstag | 496 hsz       Online status #152049   2011.05.15 15:55 GMT+1 óra  
Okés, értem én Akkor megpróbálkozok ezekkel a Vertex Array-okkal.
   
Parallax - Tag | 579 hsz       Online status #152026   2011.05.15 12:57 GMT+1 óra  
Idézet
gopher :
glBegin és glEnd csak egy van az egész tilemap kirajzolásánál). Ez így egész jó, viszont így is van amikor 70 FPS alá megy 1920x1080-as felbontáson (Intel X4500, dehát ezt a grafikát akkor is bírnia kéne ).


Még esetleg, ha valami modernebb módszert használnál még az is segíthetne. Így most minden egyes render ciklusban fölküldöd az egész adathalmazt folyamatosan. Vannak ilyenek, hogy glVertexPointer, glDrawArrays stb.

   
Joga - Törzstag | 1791 hsz       Online status #152013   2011.05.15 11:50 GMT+1 óra  
Szerintem az is segíthetne, ha az összefüggő területű azonos textúrájú dolgokat nem bontod tile-okra, hanem egybe rajzolod ki, GL_REPEAT-tel
(ಠ ›ಠ) Stewie!

   
gopher - Törzstag | 496 hsz       Online status #152012   2011.05.15 11:45 GMT+1 óra  
Üdv mindenkinek!

Elméleti kérdésem lenne. Van nekem a Damned Cemetery projektem. Ott tile-onként rajzolom a pályát. Odáig már eljutottam, hogy "view frustum culling", illetve mostmár az összes tile egy textúrán van (csak a textúra koordinátákat használom, glBegin és glEnd csak egy van az egész tilemap kirajzolásánál). Ez így egész jó, viszont így is van amikor 70 FPS alá megy 1920x1080-as felbontáson (Intel X4500, dehát ezt a grafikát akkor is bírnia kéne ).

A kérdésem az volna, hogy hogy tudnám ezt feljebb tornászni? A lényeg az volna, hogy tényleg csak azt rajzoljam ki, amit lát a játékos, ne azt, ami a view frustum-ban van. Raycasting szerűségre gondoltam, csak fordítva, szóval egy tile oldalának két szélétől indítana egy-egy sugarat a játékos felé, és nézné, hogy metszi-e valami. Ha mindkettőnél talált metszetet másik tile-al (és az magasabb, vagy ugyanolyan magasságú), akkor nem kell kirajzolni. Más ötlet? (mielőtt neki vágok)
   
Harsh - Tag | 238 hsz       Online status #144904   2010.12.13 09:35 GMT+1 óra  
.. én ezt nem vágom.. miért érnél vissza oda ahonnan indulsz? Tudtok linkelni valamit ezzel kapcsolatban? Tudtommal az univerzumnak van egy véges kiterjedése, ami még most is folyamatosan ráadásul gyorsulva tágul a sötét energia miatt, és kész slussz passz , nem látom, hogy hogy következik az, hogy visszaérnél ugyan oda ahonnan indultál.???

szerk: az általános off-ba is jó ha kapom a linket, csak hogy ne offoljuk a prog. elméletet..

Bacce: Válaszoltam az általános topicban, a továbbiakban oda folytatni ami oda illik, innen törlöm a nem ide illő hszeket. FYI

Ezt a hozzászólást Bacce módosította (2010.12.13 10:14 GMT+1 óra, ---)

   
glezmen - Törzstag | 381 hsz       Online status #144903   2010.12.13 09:21 GMT+1 óra  
Idézet
Asylum :
Nem végtelen, mert egy idő után visszaérsz oda ahonnan indultál. Olyan mint egy gömb felülete csak 3D-ben.



ez igaz, viszont olyan hatalmas ez a 'gomb', hogy fenysebesseggel haladva is megszunne az univerzum mire korbeernel
   
bit.0x8000 - Törzstag | 574 hsz       Online status #144891   2010.12.12 20:41 GMT+1 óra  
Amúgy szerintem a "brute force" megoldások helyett érdemes valahogy csalni, de úgy, hogy a "közönségnek" ne tűnjön fel a csalás, esetleg még az egyediséghez is hozzáadjon...
   
Matzi - Szerkesztő | 2519 hsz       Online status #144890   2010.12.12 20:21 GMT+1 óra  
A WoW pályáit szerintem kézzel heggesztik javarészt, amúgy is annyit kell rajta igazgatni, meg textúrázni, hogy onnantól már majdnem mindegy, hogy mennyit simogatják.

A csillagkapunál meg nincs végtelen sok kapu. Meg amúgy is csak oda mehetsz, ahol van kapu, és ahová beenged, amit játék szintjén lehet kiegészítgetni.

Idézet
Aki járatosabb a csillagászatban, esetleg kiszámolhatná, hogy egy olyan űreszközzel, ami a mi naprendszerünkön belül "kényelmes" mozgást tesz lehetővé (néhány perc alatt elérhetőek a külső bolygók is)
A nap 8 fénypercre van tőlünk, vagyis a fénysebesség kb ez a tempó, amit te szeretnél, a legközelebbi csillag meg 4 fényévre van, ha jól tudom.

syam:
A procedurális generálás jó is, de csak tölteléknek főleg, illetve elvégezheti a munka egy részét, esetleg némi control mellett kigenerálható belőle pár alap, amit ki lehet dolgozni. Magában az algoritmus sokat nem ér, legalábbis nem érdemes berakni, hogy mostantól minden pályát magától ő generáljon.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
bit.0x8000 - Törzstag | 574 hsz       Online status #144889   2010.12.12 20:20 GMT+1 óra  
Idézet
Pretender :
Az oke, de pl. ottvan a Csillagkapu: felfedeztek ilyen-olyan eszkozoket, vannak urhajoik, a pegazus galaxisba atruccannak, stb.


Ha csak olyan galaxisba lehet menni, ahol már van valamiféle kiépített kapcsolat (féregjárat, ilyesmi)?
   
Pretender - Törzstag | 2498 hsz       Online status #144888   2010.12.12 20:11 GMT+1 óra  
Az oke, de pl. ottvan a Csillagkapu: felfedeztek ilyen-olyan eszkozoket, vannak urhajoik, a pegazus galaxisba atruccannak, stb.

syam:
ismeros-ismeros, jo kis cucc

   
bit.0x8000 - Törzstag | 574 hsz       Online status #144887   2010.12.12 20:06 GMT+1 óra  
Idézet
Pretender :
Vegulis ebben is van igazsag. Bar akar megtehetne a jatekos azt is, hogy elindul, aztan megy es megy, nem tudom hogy lehetne megallitani. Az ur ugye elmeletben - jelenlegi allaspont szerint - vegtelen viszont a jatekban nincs vegtelen szamu bolygo es csillag/nap, az meg milyen dolog mar, hogy kimegy a nagy semmibe...?


Aki járatosabb a csillagászatban, esetleg kiszámolhatná, hogy egy olyan űreszközzel, ami a mi naprendszerünkön belül "kényelmes" mozgást tesz lehetővé (néhány perc alatt elérhetőek a külső bolygók is), annak mennyi időbe tellene elérni a legközelebbi naprendszert...
   
syam - Törzstag | 1491 hsz       Online status #144886   2010.12.12 20:01 GMT+1 óra  
Asylum - Törzstag | 5444 hsz       Online status #144884   2010.12.12 19:46 GMT+1 óra  
Szerintem a wow is valami hasonlo modszert használ. Legenerálják a terraint, aztán kézzel rárakják a falukat stb., esetleg javitgatják ahol kell. Miből gondolom ezt: még sose sikerült beakadnom.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #144882   2010.12.12 19:40 GMT+1 óra  
Idézet
Asylum :
Nem végtelen, mert egy idő után visszaérsz oda ahonnan indultál. Olyan mint egy gömb felülete csak 3D-ben.


Az elmeletem nekem is ez, megis lehulyeznek

syam:
es ez tenylegesen megvalosithato egy urhajos jatek eseteben is? Egyelore tekintsunk el attol, hogy le lehessen szallni a bolygora, tehat texturakat is generalni kell.

Nyilvan a legjobb mindig az, ha kezzel epiti fel az ember, de az rengeteg ido es munka, es folyamatosan csinalni is kell

   
Asylum - Törzstag | 5444 hsz       Online status #144881   2010.12.12 19:35 GMT+1 óra  
Nem végtelen, mert egy idő után visszaérsz oda ahonnan indultál. Olyan mint egy gömb felülete csak 3D-ben.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #144880   2010.12.12 19:34 GMT+1 óra  
A procedurális generálás elterjedőben van tekintve, hogy mekkora méretű helyszíneket lehet játékokban kezelni.
Az algoritmusok között vannak egyszerűbbek (fbm, fraktál, hiperfraktál, sejtautomata) és vannak a szabályokkal leírható rendszerek (egy jut eszembe Lindenmayer).
Természetesen ezek már nem beavatkozást igényelnek felhasználói oldalról, de utána már csak pár kattintás
Példa: CityEngine, ami az UE-ben is szerepel csakúgy, mint a SpeedTree, de szinte mindenre van már procedurális algoritmus.

Ha pályát akarsz generálni, akkor kb annyi a lényeg, h minden részlet bejárható legyen és minden elérhető legyen és persze artist control :]
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #144879   2010.12.12 19:32 GMT+1 óra  
Vegulis ebben is van igazsag. Bar akar megtehetne a jatekos azt is, hogy elindul, aztan megy es megy, nem tudom hogy lehetne megallitani. Az ur ugye elmeletben - jelenlegi allaspont szerint - vegtelen viszont a jatekban nincs vegtelen szamu bolygo es csillag/nap, az meg milyen dolog mar, hogy kimegy a nagy semmibe...?

   
Matzi - Szerkesztő | 2519 hsz       Online status #144878   2010.12.12 19:16 GMT+1 óra  
Az a baj a random contentel, hogy nem túl szórakoztató az esetek nagy részében. Nincs meg benne az a szándék, és munka, ami egy kézzel jól összeállított pályán / bolygón / akármin látszik. Ráadásul ismétlődhetnek, és valószínűleg érdektelen lesz az egész.
Bizonyos dolgokban segíthet a random generálás, de rengeteg munka kell bele így is úgy is. Például a diablo random pályái is csak azért voltak életképesek, mert nem a pályáról szólt a játék, így majdhogynem lényegtelen volt, hogy tervezett e vagy sem.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #144865   2010.12.12 16:45 GMT+1 óra  
Tetelezzuk fel a vicc kedveert, hogy urhajos (mmo)jatekot akarok. Ez a problema foleg mmo-nal jelentkezhet, de nem arthat single modban sem. Egy mmo jatekot az tart eletben, ha frissul a content, avagy nincs egy megszabott hatarvonal, amit nem lephet at a jatekos. En az utobbira (is?) szavaznek, es azon gondolkoztam el, hogy ezt hogy lehetne megvalositani.
- van az a lehetoseg, hogy parameterekkel leirni egy bolgyorendszert: bolygok szama, kulonleges tenyezok (pl. nebula, vagy akarmi), bolgyok tavolsaga, ellipszis, nap tipusa, stb., es ezeknek megfeleloen generalna egyet, a bolgyok meg veletlenszeruen lakhatoak / banyaszhatoak, stb.
- a masik dolog, hogy kezzel mindig hozzaadogatni bolgyogat / rendszereket.
Az elobbivel kicsit ugy randomabb az egesz, es a jatek elkeszulte utan kevesebb munkat igenyel talan. Azon gondolkoztam, hogy ez igy vajon jarhato ut, megvalosithato? (nem mintha lenne ilyen jatekom)

   
Matzi - Szerkesztő | 2519 hsz       Online status #136312   2010.06.20 15:38 GMT+1 óra  
Ha jól sejtem, akkor egy minimális súlyú feszítő fát kell neked generálnod. Tételezzük fel, hogy éllistával adjuk meg a végén a fát, hogy könnyebb legyen. Valami olyasmi lesz az algoritmus, hogy:

Kell két lista, egy a lehetséges éleknek (ListA), és egy a fa éleinek (ListB).

1) Egy listába (ListA) felveszed az elérhető csúcspontokat a hozzájuk vezető élekkel, illetve a kiindulási csúccsal együtt. Azokat nem számítva, amelyekben már jártál.
2) Megnézed melyik a legkisebb súlyú, és a kiindulási és a végpontot beleteszed a fa éllistájába (ListB)
3) Az összes olyan élet kiveszed a fenti listából (ListA), amelyeknek a vég csúcspontja az előbb bejárt pont
4) Az újonnan elért csúcsból megnézed melyik csúcsokba vezet él, és amelyekben még nem jártál, felveszed a listába (ListA).
5) Ha még van elem, akkor folytatod a 2-es ponttal, ha már nincs, akkor végeztél.

Mivel tudjuk, hogy egy fának n-1 éle van, ha n pontja van, így a ListB helyettesíthető egy n-1 elemű tömbbel. ListA kicsit keményebb dió, de ugye ha nincs dupla él és hurok él (azokat könnyű kiszűrni), akkor n*n él lehetséges, de ez leszűkíthető úgy ,hogy megszámolod hány él van a tömbödben. Legjobb ha listát használsz.

Amennyiben a feladat arra kérdez rá, hogy mennyi a legrövidebb idő végtelen bejáró emberrel (vagyis egyszerre cselekedhetnek), akkor a fa leghosszabb útját kell megtalálni, ami már nem vészes, mert kör tuti nincs benne.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
mocsok - Guests | hsz       Online status #136302   2010.06.20 13:24 GMT+1 óra  
Kéne egy kis elméleti segítség. Középsulis vagyok, nem nagyon vágom még a gráfokat, annyit tanultam róluk, hogy egyszer egy sima súlytalant szélességibejártam.
Most meg itt van nekem egy irányitott, súlyozott
Pascal.
Szépen feltöltöttem 2d-s tömbe az adatokat. Úgy kéne bejárni, hogy meg van adva, hogy honnan indulhat végtelen számú bácsi, és minél kevesebb idő alatt el kell jutni minden városba.
Tehát a tömböm: tömb[c1,c2]=x, ahol c1 a város ahonnan, c2 a város ahova x idő elmenni.
Egyszerre mehet persze több is. Valami tanács, ötlet, hogy hogy kéne megoldanom a problémát?

   
proof88 - Törzstag | 528 hsz       Online status #136232   2010.06.19 16:07 GMT+1 óra  
nem találtam adatbázis-elméletes topikot ... ezért ide írom:
bocs srácok, kicsit lámer vagyok , de van visual foxpro-s project, van egy adatbázis, benne sok-sok tábla, na most van egy nagy tábla, amiben ugye ki van jelölve 1-2 index, de most törölgetni kéne belőle, és a törölgetéshez olyan mező alapján kéne keresgélni, ami nem indexelt... össze-vissza próbálkoztam mindenféle lehetőséggel, hogyan lehetne gyorssá tenni, de mindenképp nagyon lassú így a törölgetés ... ezért kitaláltam azt, hogy létrehozok ama bizonyos mező alapján egy új indexfájlt, na így 1 mp alatt sikerült a törölgetés, és utána pedig törlöm azt az index fájlt ... a kérdésem az lenne, hogy szerintetek ez mekkora lámulás? Végeredményben működik ... és azon a bizonyos mezőn azért nincs indexelés, mert sosem kell. Csak most van rá szükség, egy olyan feladathoz, amit kb az ember félévente egyszer csinál ...

szerk.: ja és az index fájl létrehozása is kb 1 mp, szóval végeredményben nem értem, hogy miért telik olyan sok időbe az index nélkül keresgélni ... pedig próbáltam azt is bekapcsolni, hogy az egész táblát bufferelje, hogy lehetőleg ne rekordonként legyen lemezművelet ... úgy is lassú volt. Nem vártam végig sosem, de 13000 rekord alapján kellett volna keresni és kb 10 rekord/mp volt a sebesség, szóval durván 20 percbe telt volna a törölgetés, ami most index fájl létrehozással, utána törléssel ~ 2mp...

szerk.: ja és sajna egyelőre csak tanulgatom ezt az egész VFP-t, gondolom kihalóban van, de van egy nagy project, egy progi, amit csinált régen valaki, aztán másik ember vette át, és most én vagyok a 3., szóval necces ... gondolom ma már nem is olyan sok ember van, aki vágja a VFP-t.
   
Kuz - Törzstag | 4455 hsz       Online status #133498   2010.05.10 18:18 GMT+1 óra  
Bár még nem volt időm elmélyedni a lentebb írtakban, de az valóban segített, hogy mindent floatban számoltam, és egyedül a kirajzolásnál, ahol ugye rectangle-t kell a képernyőre pozícionálni, ott használtam (int)PosX, (int)PosY-t. Később persze megnézem ezt a precízebb mozgást, amit lentebb Asylum linkelt, mert a cikk jónak tűnt.
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???

   
fpeti - Törzstag | 1290 hsz       Online status #133278   2010.05.07 21:46 GMT+1 óra  
2d-ben az ilyesmi nagyságrendekkel egyszerűbb. Ha egyszerű fizika kell - csak mozognak objektumok, de nem pörögnek (lásd egy egyszerűbb Mario-klón) - akkor simán meg lehet azt csinálni, hogy float-ba gyűlik az elmozdulás, ha bármelyik tengelyen összejött több, mint egy egységnyi (pixel), akkor kell ellenőrizni (afféle movement-accumulator - ha ütközik, akkor lenullázzuk, ha nem, akkor csak a törtrész marad benn)
Ha rigidbody sim is kellene, akkor a legkönnyebb SAT-tal megcsinálni, ezzel lehet folytonos ütközésvizsgálatot is csinálni a polycolly.zip tutor nagyon jó - ha meglenne a weblapja, kicsit nehéz már megtalálni, de sat-ra sok tutor van c#-ban is.
   
Asylum - Törzstag | 5444 hsz       Online status #133264   2010.05.07 19:17 GMT+1 óra  
Vinyó akasztás: nyilván nem, de deaktiváláskor azért illik nem zabálni a cpu-t (Sleep(..)).
Másrészt ha a content betöltése nem játék közben történik akkor nem akasztja meg.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133257   2010.05.07 18:11 GMT+1 óra  
Matzi: jaaa, hogy te a fizikáról beszélsz! Hát én egy szót nem szóltam a fizikáról, de még az ütközésdetektálást is direkt csak mellékesen említettem meg, ugyanis lehet hogy Kuz-nak az egész csak arra kell, hogy a credits lista szépen scrollozzon....

gaborlabor: én meg már majdnem elkezdtem számolni Matzi felvetését, hogy hány tizezer vagy százezer fps kell, hogy előjöjjön amit írt... Egyébként QueryPerformanceCounter -t használok én is, meg ahogy néztem Asylum is.

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
gaborlabor - Moderátor | 4449 hsz       Online status #133256   2010.05.07 17:43 GMT+1 óra  
Idézet
HomeGnome :
Matzi
egy túl gyors gépnél akár azt is jelentheti, hogy megáll az objektum.

Mondasz valamit.. Esetleg lehetne egy feltétellel megvizsgálni, hogy ha túlságosan kevés idő telt el, akkor ne update-eljen, hanem görgesse tovább a maradékot. Bár nem tudom ez mennyire gyors gépen jönne elő, ha előjönne egyáltalán...


Normális időmérőt kell használni, ami akár nanoszekundumra pontosan megmondja, mennyi idő telt el 2 frame között (QueryPerformanceCounter...), ez soha nem lehet 0. Ezeket az időket kell összeadogatni, amíg annyi össze nem gyűlik, hogy kelljen fizikát is számolni.
A fizikát meg mivel amúgy is fix időközönként számolod, nem számít, ha több ezer fps-sel fut a program, akkor úgyis csak minden néhány századik frame-ben számolsz fizikát.

   
Matzi - Szerkesztő | 2519 hsz       Online status #133255   2010.05.07 17:23 GMT+1 óra  
Ha érdekel, akkor kifejthetem, a Savage Shapes 2-ben csináltam rendes fizikát, ott nincs ilyen gond.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133253   2010.05.07 17:05 GMT+1 óra  
Nem nagyon értem mit mondasz, de biztos igazad van az ütközésdetektálással kapcsolatban. A szerintem érdekes rész amúgy sem az, ha 3 fps-el megy, mert akkor ígyis-úgyis játszhatatlan a játék, hanem ha pl kikapcsolja a vsync-et, és mondjuk 200 fps -enként kell kiszámolni a pozíciót.

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Matzi - Szerkesztő | 2519 hsz       Online status #133249   2010.05.07 16:43 GMT+1 óra  
Az csak a gond, hogy a sok kerekítés miatt elromolhat, ráadásul ha túl gyakran mozgatsz, akkor a túl sok számítás nagyon lelassíthatja a játékot. Például ha mindig számolsz ütközésdetektálást, akkor az sokat elvesz, meg amúgy is jobb, ha fix időközzel számolsz. Igazából felesleges ennyit számolni, egy egyszerű interpoláció megoldja.

Az egész számokat meg kerülni kell.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133244   2010.05.07 16:37 GMT+1 óra  
Idézet
Asylum :
Vagy leállitod a timert... (én ezt csinálom).


Jogos! Le kell kezelni, ha az ablak elveszíti a fókuszt.
A timer leállítása abban az esetben is működik, ha mondjuk 2 másodpercre megakasztja a vinyó a folyamatot?..
Azt nem tudjátok véletlenül, hogy hogyan lehet lekérdezni, ha az egérrel vonszolom az ablakot? Csak mert szeretném akkor is deaktiválni a programot?

Matzi
Gondolj bele, a kerekítési hibák apró lépéseknél sok hibát eredményezhetnek,

Mint amikor először egész számokkal próbáltam, és csodálkoztam, hogy miért darabos a mozgás..

Matzi
egy túl gyors gépnél akár azt is jelentheti, hogy megáll az objektum.

Mondasz valamit.. Esetleg lehetne egy feltétellel megvizsgálni, hogy ha túlságosan kevés idő telt el, akkor ne update-eljen, hanem görgesse tovább a maradékot. Bár nem tudom ez mennyire gyors gépen jönne elő, ha előjönne egyáltalán...

Matzi
Például most 100nál van, egy lépés 20 egység, de két frissítés közé beékelődik három képkocka, 0.1nél 0.5nél és 0.9nél, akkor a három kirajzolásnál az aktuális pozíció 100+20*0.1 = 102, 100+20*0.5 = 110, és 100+20*0.9 = 118 lesz. Így a mozgás teljesen folyamatos. Ha kisebb a framerate akkor is segíthet, mert ha mondjuk a kirajzolás nem egyenletes időközönként történik, akkor ugrálhat, például jön egy frissítés 0.8nál (még a 0. lépés) aztán egy 2.1nél (ez már a második kocka, kettőt ugrott), majd egy 2.9nél (nem történt semmi), aztán megint 4.1 (megint két kockát ugrott!). Stb...

Ha jól értem, akkor én is ilyesmit írtam. (Fontos, hogy ne egész számokkal számoljunk. )
Megpróbálom lefordítani a Te példádat az én példámra:

kezdőpozíció: x=100;
lépés = 20 egység / 1 másodperc,
1 másodperc = 100 Játéklogikai Egység (tulajdonképpen ezt neveztem fArany-nak, de akkor a továbbiakban legyen JE ))
következésképpen a sebesség = 0,2 egység / 1 JE

1. update (abszolút idő = 0,1 sec; eltelt idő = 0,1 sec (= 10 JE))
x+=0,2 * 10 (JE) -> 100+2=102

2. update (abszolút idő = 0,5 sec; eltelt idő = 0,4 sec (= 40 JE))
x+=0,2 * 40 -> 102+8=110

3. update (abszolút idő = 0,9 sec; eltelt idő = 0,4 sec (=40 JE))
x+=0,2 * 40 -> 110+8=118

eddig stimmel, 3 fps esetén ez fog történni.
vegyük hozzá a frissítést 0,8 -nál:

3. update (abszolút idő = 0,8 sec; eltelt idő = 0,3 sec (=30 JE))
x+=0,2 * 30 -> 110+6=116

4. update (abszolút idő = 0,9 sec; eltelt idő = 0,1 sec (=10 JE))
x+=0,2 * 10 -> 116+2=118

aztán az ugrás:

5. update (abszolút idő = 2,1 sec; eltelt idő = 1,2 sec (=120 JE))
x+=0,2 * 120 -> 118+24=142

6. update (abszolút idő = 2,9 sec; eltelt idő = 0,8 sec (=80 JE))
x+=0,2 * 80 -> 142+16=158

7. update (abszolút idő = 4,1 sec; eltelt idő = 1,2 sec (=120 JE))
x+=0,2 * 120 -> 158+24=182

minden Update után jön egy Render is. Attól eltekintve, hogy ez marha kicsi fps, és ezért ugrálni fog a kép, de szerintem jól számolok, vagy nem? :?

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] > 9 < [10] [15] [16]