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]
Matzi - Szerkesztő | 2519 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 | 5444 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 | 5444 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 | 5444 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ő | 2519 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 | 5444 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 | 5444 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 | 5444 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 | 5444 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 | 5444 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 | 575 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 | 1336 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 | 575 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 | 528 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 | 5444 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 | 528 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 | 5444 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 | 5444 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 | 5444 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/
   
Omega - Tag | 70 hsz       Online status #127301   2010.02.05 09:04 GMT+1 óra  
Wolfee a folyamataid nem jók, építs saját kommunikációs eljárást, mert ez így nulla.
Minden féle képpen kell egy folyamat szálat fenntartanod, mert ez a mostani megoldásod ebben a formában nem használható, és informatikailg sem helyes. :-)

   
Asylum - Törzstag | 5444 hsz       Online status #127300   2010.02.05 05:44 GMT+1 óra  
Köhém...elöszöris tisztázzunk valamit:

TCP/IP != TCP

A TCP/IP az egy modell, olyan mint az ISO/OSI, a teljes hálózat felépitését meghatározza (5 réteg ld. google).
A TCP pedig a szállítói réteg egy protokollja, a jellemzöit gondolom nem kell mondani.

Majd ha hazaértem megnézem; a read-re jó hogy nem megy a kivételkezelés mivel C-s függvény (a kivételt valami más dobja).
Viszont a socket attól még nem kéne hogy érvénytelen legyen.
Másik: nem blokkoló socketeket érdemesebb lenne.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Wolfee - Törzstag | 1336 hsz       Online status #127295   2010.02.04 23:57 GMT+1 óra  
HB azért nem jó, mert blokkoló socketeket használok, és nem állhatok le válaszra várva, egy másodpercre sem.
kivételkezelés: ha a read-et try-catch blokkba teszem, és ...-t akarok elkapni, nnah akkor sem kapok el semmit
a leíróról meg nem tudom, hogyan tudnám megállapítani, hogy érvényes-e... ennek utánanézek mindenképp. ettől függetlenül várok még ötleteket
FZoli jóváhagyásával XD

   
Matzi - Szerkesztő | 2519 hsz       Online status #127293   2010.02.04 23:19 GMT+1 óra  
Hearthbeat? Ha x másodpercenként nem küld jelet, akkor döglött a kliens.
Mellesleg nem lehetne valahogy lekezelni, hogy a választ akkor várja, ha érvényes a leíró? Vagy valami kivételkezelés?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Wolfee - Törzstag | 1336 hsz       Online status #127292   2010.02.04 23:09 GMT+1 óra  
sziasztok

a következő problémával állok elétek, ó szoftvertervezés istenei:

adott egy linuxos cluster, amire egy meghatározott feladatot ellátó rendszert kell fejleszteni. minden gépen fut egy KLIENS program, és egy kiválasztott gépen fut pluszba egy MESTER program is. MESTER TCP/IP-n keresztül indítja, állítja le, illetve kéri fel adatszolgáltatsra KLIENS-t. a jelenlegi megvalósítás: MESTER elindul, elindul minden gépen KLIENS, KLIENS csatlakozik egy socketen keresztül MESTER-hez (mindenki ugyanazon a porton, MESTER-ben csak egy darab szerver socket van), majd MESTER kiadja az utasításokat. a problémám a következő: ha valamelyik KLIENS menetközben meghal, akkor arról MESTER nem kap jelentést. mivel KLIENS mindenképp [adatot_vár] állapotban van, mikor meghal, ezért MESTER még egy sztringet át tud nyomorítani a socketen, viszont amikor MESTER a választ várja rá, akkor már egy érvénytelen helyről akarunk olvasni (értelemszerűen, mivel meghal a file descriptor is), ezáltal a MESTER is lehal.

a kérdés adot: ti hogyan hidalnátok át a problémát.

ha valami nem világos, megpróbálom elmagyarázni jobban, csak az a baj, hogy nem mondhatok el túl sokmindent a projektről.
FZoli jóváhagyásával XD

   
Asylum - Törzstag | 5444 hsz       Online status #126666   2010.01.20 03:52 GMT+1 óra  
És az veszteségmentes tömörités?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Wolfee - Törzstag | 1336 hsz       Online status #126660   2010.01.19 19:30 GMT+1 óra  
Idézet
fpeti :
A byte a mosógépben összemegy


de csak 90 fokon
FZoli jóváhagyásával XD

   
fpeti - Törzstag | 1290 hsz       Online status #126659   2010.01.19 16:47 GMT+1 óra  
A byte a mosógépben összemegy
   
Wolfee - Törzstag | 1336 hsz       Online status #126658   2010.01.19 16:01 GMT+1 óra  
Idézet
kiskami :
Értem és felkeltettétek a kíváncsiságomat. Mondjatok nem 8 bit/bájt rendszert, amire játékot is érdemes fejleszteni manapság.


nnah hát ilyent speciel nem tudok mondani. de pl ha mosogép szoftvert programozol, akkor van rá esély, hogy nem 8bites lesz a bájtod...
FZoli jóváhagyásával XD

   
kiskami - Tag | 265 hsz       Online status #126653   2010.01.19 07:34 GMT+1 óra  
Értem és felkeltettétek a kíváncsiságomat. Mondjatok nem 8 bit/bájt rendszert, amire játékot is érdemes fejleszteni manapság.
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
gaborlabor - Moderátor | 4449 hsz       Online status #126643   2010.01.19 06:13 GMT+1 óra  
Amire néhányan gondoltok byte szó alatt, az az oktett (octet).

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] > 10 < [15] [16]