játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5468
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:    2193
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] [16]
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 | 530 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 | 1295 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 | 5468 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ő | 2524 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ő | 2524 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...)
   
Matzi - Szerkesztő | 2524 hsz       Online status #133234   2010.05.07 15:27 GMT+1 óra  
Azért erre több lehetőség is van. Úgy érdemes csinálni, hogy mindig fix lépést tegyen a frissítés. Gondolj bele, a kerekítési hibák apró lépéseknél sok hibát eredményezhetnek, egy túl gyors gépnél akár azt is jelentheti, hogy megáll az objektum. Szóval fix lépés kell, és a két lépés közötti időt pedig a két lépés közötti intervallum interpolációjához kell felhasználni.

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...

A continous collision detection egyébként is fontos, egyenes vonalú mozgásokra meg körre, pontra, szakaszra és egyenesre nagyon egyszerű, a többire megoldható. De ha elég kicsi a lépésköz, általában nem jön elő a dolog.
A másik lehetőség, hogy kihúzod az objektumodat a kezdő és végpozíció között, és ha metszi a másik tárgyat, akkor ütköztek (vagy ütközhettek). Ehhez elég pár szakasz-szakasz ütköztetés.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5468 hsz       Online status #133228   2010.05.07 15:07 GMT+1 óra  
Idézet
HomeGnome :
Oké, biztos hogy nem tökéletes a megoldásom, de ami igazából "bekavar", az a fogalmazásom. Azért megpróbálom leírni mire is gondoltam.
Szóval, vegyük például a következő esetet: a játéklogika 100 Hz-en fut, viszont lassú a gép, és csak 10 fps -t jelenít meg. Két Render között 0,1 másodperc telik el, a példámban szereplő fArany értéke tehát 10 (másodperc x 100). Magyarul két Render között 10 játéklogikai egység telt el. Tegyük fel, hogy van egy űrhajónk x=100 pozícióban, szélessége 30 egység, sebessége 5 egység. Az új pozíciója x+=sebesség(5)*fArany(10) , vagyis x(új)=150. De mi van akkor, ha x=110-es pozícióban volt egy 20 egység széles akna? Az űrhajó új pozíciójával és az akna (fix) pozíciójával elvégzem az ütközésdetektálást, de nem fedik egymást, nincs ütközés... A játékban az űrhajóm gyakorlatilag "átment" az aknán... Na ezért jegyeztem meg, hogy pl ha az fArany 10, akkor egy ciklussal 10x kell lefuttatni az űrhajó pozíciójának kiszámolását és az ütközésdetektálást. (És mindezt még a Render előtt.)
Nem állítom, hogy az én megoldásom a legjobb, vagy fizikai szimulációt is így kell csinálni, de egyszerű mozgásokra szépen működik, és független lesz az fps-től.
Az általad linkelt cikkben még volt egy érdekes meglátás, arra az esetre, ha pl. a felhasználó ALT+TAB -al 10 percre otthagyja a programot. Ekkor (az én példámra vetítve) az fArany 60000 lenne , ami hatalmas "ugrást" jelentene a játékban, aminek semmi értelme. Megoldás, hogy maximalizáljuk az fArany-t, például az említett cikk által javasolt 0,25 másodpercre (fArany max 25 legyen)...



Vagy leállitod a timert... (én ezt csinálom).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133224   2010.05.07 14:52 GMT+1 óra  
gaborlabor: köszi, nem tudtam, hogy neve is van a jelenségnek, majd utánaolvasok.
Annyira végül is nem akartam belemenni az ütközésdetektálásba, hiszen csak a vsync-től független, folyamatos mozgás megvalósítása volt a kérdés.

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
gaborlabor - Moderátor | 4449 hsz       Online status #133222   2010.05.07 14:42 GMT+1 óra  
HG: az a jelenség a tunneling, megoldása pedig a "continuous collision detection", ami nem kimondottan triviális minden esetben...

   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133220   2010.05.07 14:37 GMT+1 óra  
Oké, biztos hogy nem tökéletes a megoldásom, de ami igazából "bekavar", az a fogalmazásom. Azért megpróbálom leírni mire is gondoltam.
Szóval, vegyük például a következő esetet: a játéklogika 100 Hz-en fut, viszont lassú a gép, és csak 10 fps -t jelenít meg. Két Render között 0,1 másodperc telik el, a példámban szereplő fArany értéke tehát 10 (másodperc x 100). Magyarul két Render között 10 játéklogikai egység telt el. Tegyük fel, hogy van egy űrhajónk x=100 pozícióban, szélessége 30 egység, sebessége 5 egység. Az új pozíciója x+=sebesség(5)*fArany(10) , vagyis x(új)=150. De mi van akkor, ha x=110-es pozícióban volt egy 20 egység széles akna? Az űrhajó új pozíciójával és az akna (fix) pozíciójával elvégzem az ütközésdetektálást, de nem fedik egymást, nincs ütközés... A játékban az űrhajóm gyakorlatilag "átment" az aknán... Na ezért jegyeztem meg, hogy pl ha az fArany 10, akkor egy ciklussal 10x kell lefuttatni az űrhajó pozíciójának kiszámolását és az ütközésdetektálást. (És mindezt még a Render előtt.)
Nem állítom, hogy az én megoldásom a legjobb, vagy fizikai szimulációt is így kell csinálni, de egyszerű mozgásokra szépen működik, és független lesz az fps-től.
Az általad linkelt cikkben még volt egy érdekes meglátás, arra az esetre, ha pl. a felhasználó ALT+TAB -al 10 percre otthagyja a programot. Ekkor (az én példámra vetítve) az fArany 60000 lenne , ami hatalmas "ugrást" jelentene a játékban, aminek semmi értelme. Megoldás, hogy maximalizáljuk az fArany-t, például az említett cikk által javasolt 0,25 másodpercre (fArany max 25 legyen)...

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Asylum - Törzstag | 5468 hsz       Online status #133208   2010.05.07 13:47 GMT+1 óra  
Lehet, hogy csak én értem félre, de ha azt mondod, hogy "bekavar", akkor ez még mindig nem jó.
Az óra az fix, az mindig ugyanolyan idöközönként váltsa ki a Tick eseményt, és akkor BIZTOS, hogy nem fog bekavarni.
Az egyetlen kérdéses eset az az, amikor a framerate kisebb mint az update rate...akkor persze az update rate automatikusan szinkronizálni fog a frameratehez (hacsak nem külön szálon futnak). Ezt az esetet kéne részletesebben tesztelni...ha valaki meg tudná nézni egy olyan gépen a multetrist ahol 10 fps-nél lassabban fut az jó lenne.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133188   2010.05.07 11:00 GMT+1 óra  
Ja, és az időmérést innen vettem (meg amit írtam az is le van írva ): Timing and FPS
és inicializáláskor meghívom:
Kód:
InitGameTime(); // játékidő kezdete
gAktTime=GetGameTime();

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #133187   2010.05.07 10:37 GMT+1 óra  
Ilyesmivel én is szenvedtem, mire józan paraszti ésszel rájöttem, hogy tulajdonképpen nagyon egyszerű a megoldás.
Szóval ha jól emlékszem az a lényeg, hogy ne a vsync-hez szinkronizáld a mozgást, hanem a két update metódus között eltelt idővel kalkulálj. (És természetesen a pozíciót float-ban tárold, ne pedig int-ben, mint én idióta )..
Szóval én valahogy így csináltam:
Kód:
float gGlobalSpeed=1.0f/100;  // játéklogika 100 Hz

ez nálad ugye 60, de végeredményben mindegy.
Az Update metódust pedig nem másodpercenként 100x hívom meg, hanem minden Render metódus elején.
És akkor az Update elején lekérdezem az eltelt időt:
Kód:
gLastTime=gAktTime;
gAktTime=GetGameTime();
fArany=(gAktTime-gLastTime)/gGlobalSpeed;

ebből kapok egy arányszámot (fArany), hogy a gGlobalSpeed-hez képest mennyi az eltelt idő. Ha pontosan 1/100 másodperc telt el (amennyin fut a játéklogika), akkor az fArany 1 lesz, ha csak fele annyi idő, akkor 0,5 lesz, ha pedig mondjuk 2x annyi idő, akkor 2.
(Na most itt még lehet bonyolítani, mert ha mondjuk megakad a gép, és túl sok idő telik el 2 Update között, akkor az fArany túl magas lesz, és ez pl. ütközéseknél bekavarhat. pl 2 űrhajó "átmegy" egymáson, vagy ilyesmi. Ezt én úgy oldottam meg, hogy ha fArany nagyobb mint 1, akkor többször futtatom le az Update magját, még mielőtt renderelne. Például ha az fArany 5,5 akkor 5x lefuttatom fArany=1 -el, és 1x fArany=0.5f -el...)
Szóval ha van egy objektumod, akkor annak is van egy sebessége, pl.:
Kód:
float gObjectSpeed=3.5f;  // objektum sebessége

ezt most meg ne kérdezd, hogy konkrétan milyen gyors..
És akkor az egyenes vonalú egyenletes mozgást könnyű kiszámolni:
Kód:
gObjectPosY+=(gObjectSpeed*fArany);

Nálam valahogy így működik a dolog, remélem azért sikerül valamit kihámozni belőle...

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Kuz - Törzstag | 4455 hsz       Online status #133179   2010.05.07 00:21 GMT+1 óra  
Kösz a linket, holnap átnézem, mert ma már nem fog az agyam.
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???

   
Asylum - Törzstag | 5468 hsz       Online status #133178   2010.05.07 00:08 GMT+1 óra  
Huh? Ennek semmi köze a vsynchez...kitalálom: xna? Ott láttam utáljára ilyen bugyuta implementáciot Olvasd át ezt

Az régi dummyfw is már ezzel müködik de az ujban még jobban láthato lesz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kuz - Törzstag | 4455 hsz       Online status #133177   2010.05.06 23:47 GMT+1 óra  
Elvileg fix időközönként frissítek, hiszen az Update metódus 1 mp alatt 60x hívódik meg. De akkor átgondolok valami értelmes interpolálást. Amúgy annyira mindenképpen rugalmasnak kell lennem, hogy a settingsben kikapcsolható a vsync, tehát semmi nem garantálja sem a fix 60fpst, sem azt, hogy 60-nál nem lesz kevesebb.
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???

   
Matzi - Szerkesztő | 2524 hsz       Online status #133176   2010.05.06 23:33 GMT+1 óra  
Az attól függ. Ha valamiféle fizikát számolsz benne, akkor érdemes úgy csinálni, hogy (mivel a fizika fix léptékű, hogy a köztes lépésekben interpolálsz. Például másodpercenként 30 mozgás ciklus megy le, de 80FPS-ed van, akkor kb minden 3. képkockánál lenne elmozdulás. Ezért elmented az előző állapotot, és a köztes lépésekben aközött végzel interpolációt. Így a köztes framek sem lesznek üresek, és folyamatosabbnak fog tűnni.

A másik lehetőség, hogy nincs sub pixel accuracy, és így mindenképpen pixelenként mozog a cucc (java-ban ez van a 3d gyorsítás ellenére is), ezzel szerintem sokat nem lehet kezdeni, ha az eszköz nem képes rá.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5468 hsz       Online status #133175   2010.05.06 23:31 GMT+1 óra  
Mire gondolsz pontosan? Mitöl darabos?
Ha fix időközönként updateled az y-t, akkor rajzoláskor az elözö és az aktuális pozicio között lineárisan kell interpolálni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kuz - Törzstag | 4455 hsz       Online status #133173   2010.05.06 23:16 GMT+1 óra  
Egy 2D-s játéknál, ahol fentről-lefelé esik egy objektum, hogy lehet azt megoldani, hogy szép folyamatosnak tűnjön a mozgása? Nálam iszonyatosan darabosnak hat az egész. Van erre valami szép képlet, hogy a PosY-t hogy kell jól számolni?
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???

   
Germo - Tag | 40 hsz       Online status #129026   2010.03.14 10:46 GMT+1 óra  
Úgy látom RedDwarf-ot se használ senki. Egyenlőre én se. Inkább egy sokkal egyszerűbb socketes chat programból kezdek kiindulni a szerverprogramozás terén. Nem szeretnék abba a hibába esni, hogy egy fizetős programot használjak erre a célra, mint a smartFox-ot, amivel már van tapasztalatom.

Van valakinek java-s szerverprogramozás terén tapasztalata?

Az első kérdésem, hogy milyen adatbázist kapcsoljak mellé. A VPS-emen csak limitált memóriával rendelkezek (256Mb) azaz ebben kellene elférnie mindennek (egyenlőre). Ha 200-300 online felhasználóig elég lesz, akkor azt már jó eredménynek tekintem.
A végtelenbe és tovább!
   
Asylum - Törzstag | 5468 hsz       Online status #129022   2010.03.14 03:44 GMT+1 óra  
Rájöttem: azt már az elején sejtettem, hogy a texel -> pixel leképezéssel lesz valami gáz, ezért megprobáltam sima elöre transzformált vertexekkel. Ezeknél minden downsample-hoz át kell méretezni a quadot is, de 0.5 -el el is kell tolni balra fel (vagyis -0.5 el).

Az engineben viszont párhuzamos vetitést használok, mégpedig ugy, hogy a quad (és a viewport) végig ugyanakkora.
Ekkor -0.5 * scale -al kell eltolni, vagyis pl. ha a negyedére akarom csökkenteni akkor -1 el, ha a nyolcadára akkor -2 -vel.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5468 hsz       Online status #128793   2010.03.11 21:53 GMT+1 óra  
Senki nem tudja? Nem irtatok még blur-t?...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5468 hsz       Online status #128600   2010.03.07 21:33 GMT+1 óra  
Az mitől lehet, hogy a gaussian blurom jobbra lefelé tolódik el állandoan (és balra fel egyáltalán nem süt át a fény)?
A súlyok és offsetek tök jók..nemis lehet nagyon elrontani...
Lehet, hogy a downsample/upsample-ben van a hiba? Ti hogy csináljátok?

Söt igy belegondolva szinte biztos, hogy az upsample-ben van a gáz, hiszen egy kisebb képet "nagyit fel" egy nagyobba igy eltolodnak a dolgok.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5468 hsz       Online status #128521   2010.03.06 17:50 GMT+1 óra  
Valahol a driver szinten mindenképpen az van, hogy végignyálazza a billentyüzet tömböt és az alapján küld vagy nem küld WM_KEYPRESS eseményt.

A dinputnak az az "előnye" hogy ezt te csinálhatod meg és esetleg 600 winapi hivást megkerülsz.
Én a winapit használom, de dinputos implementáciom is....volt (van is csak a bill rész ki van szedve).

Valahogy igy néz ki:

Kód:
// ...

case WM_KEYDOWN:
    instance->KeyboardState.Key = (qbyte)wParam; // ezt nyomta le uccsonak
    instance->KeyboardState.KeyTable[wParam] |= 0x80; // táblában update
    instance->keydown(instance->KeyboardState); // eseménykiváltás
    break;


Elöny: nem ágazok el engine szinten a gecibe, a user ágaz el
Hátrány: külön letárolom ami már létezik (gombok állapota); esemény...


Ha a dipnuttól kéred el, akkor egyszerübb mert

Kód:
dinput->GetKeyboardState(...);

// user szinten:
if( inputhandler->Table[DIK_<valamibill>] & 0x80 )
    // blabla


Ez lényegesen gyorsabb, viszont egy csomó hülyeségre neked kell gondolni, pl. alt + print screen stb.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
dvorgaz - Törzstag | 576 hsz       Online status #128519   2010.03.06 17:13 GMT+1 óra  
Listeneres megoldással az lenne a baj, hogy az inaktív objektumok is kezelik az inputot, tehát pl. játék közben inventory megnyit, a játék közben áll, de a játékos karakter továbbra is feldolgozza az inputot, és mikor visszalépsz a játékba, hirtelen ellő pár rakétát meg elpazarol néhány tárgyat, attól függően, hogy mit nyomkodtál míg az inventory-ban turkáltál.
   
Wolfee - Törzstag | 1337 hsz       Online status #128513   2010.03.06 16:49 GMT+1 óra  
én a listenerre szavaznék, de én még sosem írtam ilyent
FZoli jóváhagyásával XD

   
dvorgaz - Törzstag | 576 hsz       Online status #128512   2010.03.06 16:31 GMT+1 óra  
Van valami ötletetek, hogy lehetne egy praktikus inputkezelő osztályt implementálni c++ban?
Pl. melyik jobb, ha az inputot használó osztályok mindig lekérdezik az inputkezelőtől, hogy mi van lenyomva, vagy a kezelő hívjon meg valami keypressed függvényt a beregisztrált objetumokon ( tehát valami listener-szerű dolog), ha gombnyomás van?
Vagy például az egyes objektumok konkrét billentyűket figyeljenek, vagy játékbeli akciókat (pl. reload, fire), és az inputkezelő alakítsa át pl. a bal egérgomb lenyomást fire akcióvá?
   
Germo - Tag | 40 hsz       Online status #128373   2010.03.04 11:49 GMT+1 óra  
Van valkinek tapasztalata a Red Dwarffal, vagy az elődjével a DarkStarral kapcsolatban ?

http://www.reddwarfserver.org/

Vagy egy Unity vagy egy Flash klienssel szeretnék rákapcsolódni.

Ezt a hozzászólást Germo módosította (2010.03.04 12:14 GMT+1 óra, ---)
A végtelenbe és tovább!
   
preston_marlowe - Tag | 8 hsz       Online status #128372   2010.03.04 11:21 GMT+1 óra  
Idézet
Pretten :
preston_marlowe: Amit te írsz az egyenes. 3 új primitív van: tri patch, quad patch, poliline. .Kontrol pontokkal lehet megadni a görbéket.



Nem tudom miért vitatkozol velem.

Amúgy 32 új típus van. Ebből egyik sem polyline.

Kód:
typedef enum D3D11_PRIMITIVE_TOPOLOGY
{
    D3D11_PRIMITIVE_TOPOLOGY_UNDEFINED = 0,
    D3D11_PRIMITIVE_TOPOLOGY_POINTLIST = 1,
    D3D11_PRIMITIVE_TOPOLOGY_LINELIST = 2,
    D3D11_PRIMITIVE_TOPOLOGY_LINESTRIP = 3,
    D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST = 4,
    D3D11_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP = 5,
    D3D11_PRIMITIVE_TOPOLOGY_LINELIST_ADJ = 10,
    D3D11_PRIMITIVE_TOPOLOGY_LINESTRIP_ADJ = 11,
    D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST_ADJ = 12,
    D3D11_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP_ADJ = 13,
    D3D11_PRIMITIVE_TOPOLOGY_1_CONTROL_POINT_PATCHLIST = 33,
    D3D11_PRIMITIVE_TOPOLOGY_2_CONTROL_POINT_PATCHLIST = 34,
    D3D11_PRIMITIVE_TOPOLOGY_3_CONTROL_POINT_PATCHLIST = 35,
    D3D11_PRIMITIVE_TOPOLOGY_4_CONTROL_POINT_PATCHLIST = 36,
    D3D11_PRIMITIVE_TOPOLOGY_5_CONTROL_POINT_PATCHLIST = 37,
    D3D11_PRIMITIVE_TOPOLOGY_6_CONTROL_POINT_PATCHLIST = 38,
    D3D11_PRIMITIVE_TOPOLOGY_7_CONTROL_POINT_PATCHLIST = 39,
    D3D11_PRIMITIVE_TOPOLOGY_8_CONTROL_POINT_PATCHLIST = 40,
    D3D11_PRIMITIVE_TOPOLOGY_9_CONTROL_POINT_PATCHLIST = 41,
    D3D11_PRIMITIVE_TOPOLOGY_10_CONTROL_POINT_PATCHLIST = 42,
    D3D11_PRIMITIVE_TOPOLOGY_11_CONTROL_POINT_PATCHLIST = 43,
    D3D11_PRIMITIVE_TOPOLOGY_12_CONTROL_POINT_PATCHLIST = 44,
    D3D11_PRIMITIVE_TOPOLOGY_13_CONTROL_POINT_PATCHLIST = 45,
    D3D11_PRIMITIVE_TOPOLOGY_14_CONTROL_POINT_PATCHLIST = 46,
    D3D11_PRIMITIVE_TOPOLOGY_15_CONTROL_POINT_PATCHLIST = 47,
    D3D11_PRIMITIVE_TOPOLOGY_16_CONTROL_POINT_PATCHLIST = 48,
    D3D11_PRIMITIVE_TOPOLOGY_17_CONTROL_POINT_PATCHLIST = 49,
    D3D11_PRIMITIVE_TOPOLOGY_18_CONTROL_POINT_PATCHLIST = 50,
    D3D11_PRIMITIVE_TOPOLOGY_19_CONTROL_POINT_PATCHLIST = 51,
    D3D11_PRIMITIVE_TOPOLOGY_20_CONTROL_POINT_PATCHLIST = 52,
    D3D11_PRIMITIVE_TOPOLOGY_21_CONTROL_POINT_PATCHLIST = 53,
    D3D11_PRIMITIVE_TOPOLOGY_22_CONTROL_POINT_PATCHLIST = 54,
    D3D11_PRIMITIVE_TOPOLOGY_23_CONTROL_POINT_PATCHLIST = 55,
    D3D11_PRIMITIVE_TOPOLOGY_24_CONTROL_POINT_PATCHLIST = 56,
    D3D11_PRIMITIVE_TOPOLOGY_25_CONTROL_POINT_PATCHLIST = 57,
    D3D11_PRIMITIVE_TOPOLOGY_26_CONTROL_POINT_PATCHLIST = 58,
    D3D11_PRIMITIVE_TOPOLOGY_27_CONTROL_POINT_PATCHLIST = 59,
    D3D11_PRIMITIVE_TOPOLOGY_28_CONTROL_POINT_PATCHLIST = 60,
    D3D11_PRIMITIVE_TOPOLOGY_29_CONTROL_POINT_PATCHLIST = 61,
    D3D11_PRIMITIVE_TOPOLOGY_30_CONTROL_POINT_PATCHLIST = 62,
    D3D11_PRIMITIVE_TOPOLOGY_31_CONTROL_POINT_PATCHLIST = 63,
    D3D11_PRIMITIVE_TOPOLOGY_32_CONTROL_POINT_PATCHLIST = 64,
} D3D11_PRIMITIVE_TOPOLOGY;

   
Pretten - Tag | 74 hsz       Online status #128371   2010.03.04 11:00 GMT+1 óra  
preston_marlowe: Amit te írsz az egyenes. 3 új primitív van: tri patch, quad patch, poliline. .Kontrol pontokkal lehet megadni a görbéket.

DarkNessy: Ha a VistaLogo-t meg lehet, akkor biztos halálfejet is.
   
preston_marlowe - Tag | 8 hsz       Online status #128370   2010.03.04 09:33 GMT+1 óra  
Idézet
Pretten :
D3D11-ben alapból van spline primitív is.



Nincs.

[SPOILER]
Ha te esetleg a Line Adjacency struktúrára gondolsz, az már dx10-ben is volt. Sőt én most opengl2.0 alatt használom.
[/SPOILER]

   
Pretender - Törzstag | 2498 hsz       Online status #128357   2010.03.03 22:24 GMT+1 óra  
meg lehet vele in engine csinalni pl. egy piros-zold negyzetracsos halalfejmintazatu gombot?

   
Pretten - Tag | 74 hsz       Online status #128353   2010.03.03 21:32 GMT+1 óra  
DarkNessy: Egyszer nézz meg egy WPF alkalmazást Expression Blend-el. Ott minden vektoros, gombok, ablak, színezés stb. D3D11-ben alapból van spline primitív is.
   
Pretender - Törzstag | 2498 hsz       Online status #128350   2010.03.03 21:09 GMT+1 óra  
proof88:
Nem mondtam, hogy bonyolult, inkabb olyan..furanak tunik A flash jopofanak tunhet, de en megelegszek egy egyszeru kis menuvel is

Asylum:
Es az nekem megis mit valtoztatna? Az oke, hogy az "alakjat megrajzolom" in engine ugymond, de textura az akkor is kell bele, meg u.abba a pozicioba akkor is kell rakni (avagy abszolut nem ertem, h megis mi a francra gondolsz. )

   
proof88 - Törzstag | 530 hsz       Online status #128349   2010.03.03 21:06 GMT+1 óra  
Hát nem tudom, hogy a scale-ezés miért olyan bonyolult vagy hülye megoldás... Egyébként pl Crysis menüje flash, de van is hozzá API asszem (fizetős), amivel a flash-t tudod textúrába renderelni.
   
Asylum - Törzstag | 5468 hsz       Online status #128346   2010.03.03 20:52 GMT+1 óra  
Van: vektorgrafika.
Bézier görbék, spline-ok.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #128345   2010.03.03 20:44 GMT+1 óra  
Mostanaban jatszottam tobb jatekkal is, es mindnel megfigyeltem, h lehet barmekkora a felbontas a menuelemek mindig ugyanakkorak, es mindig ugyanott vannak. Azon gondolkoztam, hogy ezt hogy csinaljak, mert en is meg akarom csinalni (termeszetesen) minden elem a menuben textura (kirajzolva: spirte)
Igy hirtelen ket dolog is eszembe jutott:
- elkeszitik a legnagyobb beallithato felbontashoz a texturat ugy, hogy akkora legyen, amekkoranak latni szeretnek a kepernyon, es a kisebb felbontasok eseten pedig scale-zik (ahol scale < 1.0f)
- egy-egy elemet tobb felbontasban keszitenek el, es mindig a megfelelot toltik be. pl: button_800_600, button_1024_768.
Mindketto eleg nyomorult megoldasnak tunik (foleg az utobbi eleg -> ), szoval van-e valami mas lehetoseg? (a masik nyilvan a meret mellett a pozicio, hogy mindig ugyanott legyenek)

   
M4 - Tag | 187 hsz       Online status #128256   2010.03.01 10:08 GMT+1 óra  
Köszi, van tűzfal, asszem mindkettőn avg. Akkor majd kipróbálom.

   
proof88 - Törzstag | 530 hsz       Online status #128201   2010.02.27 17:59 GMT+1 óra  
csak ha mind2 gépnél az mshome van megadva munkacsoportnak (vagy másnak), akkor megy. Felügyeleti eszközök > Szolgáltatások > Biztonsági központot letiltod és leállítod, Windows tűzfalat szintúgy, majd restart. Ossz meg egy mappát és azt el kell érned a másik gépről, és fordítva. Tűzfalad van?
   
M4 - Tag | 187 hsz       Online status #128192   2010.02.27 13:50 GMT+1 óra  
Hali, össze lehet-e kötni két windows xp-t úgy, hogy az egyik kábellel a másik vezeték nélkül kapcsolódik a routerre? Javás socket-tel tudtam fájlt küldeni, de lassú volt. Asszem az internetes feltöltési sebességem miatt. Mshome-ot próbáltam, de nem ment.

   
bit.0x8000 - Törzstag | 574 hsz       Online status #127698   2010.02.17 17:25 GMT+1 óra  
Idézet
Asylum :
Valaki nem tud egy hatékony algoritmust csúcsok törlésére egy gráfból?
Valószínűleg élek szerint lineárisnál nincs gyorsabb.



Én hasonló helyzetben először azt szoktam átgondolni, hogy nem-e tudunk valami plusz információt a gráfról vagy az implementációjáról, aminek a segítségével "csalhatunk".
   
Asylum - Törzstag | 5468 hsz       Online status #127682   2010.02.17 12:16 GMT+1 óra  
Valaki nem tud egy hatékony algoritmust csúcsok törlésére egy gráfból?
Valószínűleg élek szerint lineárisnál nincs gyorsabb.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5468 hsz       Online status #127462   2010.02.09 20:08 GMT+1 óra  
Storno...sikerült...de azért...lol

Kód:
([^\]]*((\][^\]])|(\]\][^>]))*[^\]]*)*
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5468 hsz       Online status #127461   2010.02.09 19:48 GMT+1 óra  
Valaki foglalkozik itt flex-el?
Tele van már vele a tököm...a következö dolgot szeretném matchelni:

Kód:
<![CDATA[
    valami
]]>


probálkoztam többféleképpen is, de pont az erre specializálódott dolgok nem müködnek -.- például:

Kód:
"<![CDATA["                   // ez még oké
{CHAR}*("]]"/[^\>])?{CHAR}*   // ez lenne a közepe, de hibát dob rá
                              // nem ismeri fel a / jelet pedig a
                              // help is irja
"]]>"                         // ez meg a vége


Valakinek van ötlete?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] > 10 < [15] [16]