játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5512
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2529

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
Csaba42 - Törzstag | 946 hsz       Online status #23918   2006.08.03 06:29 GMT+1 óra  
Idézet
gaborlabor :
Amik most az egérmozgáshoz voltak rendelve azok régebben a nyílbillentyűkhöz voltak, és úgy működött rendesen.
felfele nyíllal feljebb fordult a kamera, lefelével lefelé, jobbra nyíllal elfordult jobbra, balrával balra, a w-a-s-d -vel pedig lehet haladni. Ez így egy működő koncepció volt mindenféle szempontból, és nincs is teli számításokkal. Szal ezért gondoltam hogyha már ezt kibővítettem akkor megmaradok ennél és csak a nyílbillentyűk szerepét átadom az egér mozgásának.


Az sosem jó, ha az egér mozgását úgy akarod megvalósítani, mint a billentyűzetét, valahogy "másabb" lesz a mozgás. Ezt én is egyszer megcsináltam (igaz, DDrawban), de nem volt az igazi, de legalább egy kicsi blur-ös effektet hagyott maga után mozgás közben . Utána rátaláltam egy jó kis megoldásra, onnantól kezdve azt használom.

   
gaborlabor - Moderátor | 4449 hsz       Online status #23911   2006.08.03 05:54 GMT+1 óra  
Matekból hát szóval izé... nem vagyok rossz belőle voltam már versenyen is de mondjuk inkább úgy hogy még képzetlen vagyok mivel mégcsak a középsulit nyomom. Azokkal a fügvényekkel már énis találkoztam.
De amúgy az, hogy az én progimban a számítások, forgatások, stb jó, az 100%, mivel azt sem én irtam teljesen Volt egy példaprogram valahol a neten, abban ugy lehetett mozogni mint a doom2-ben. én csak annyit irtam át benne hogy oldalazni is lehessen meg hogy a kamerát felfelé is el lehessen mozgatni és akkor az előremozgásnál felfelé is emelkedjen, szóval mindig a kamera nézőpontja felé haladjon. az úgy működik, hogy mikor elfordulok, akkor eltárolom az elfordulás nagyságát, aztán valami sinussal meg cosinussal variál és azt hozzáadja a nézőpont megfelelő koordinátájához. ezt csak annyival egészítettem ki hogy a függőleges forgáshoz létrehoztam 2 új változót és a vizszintes alapján megirtam. rövid, és még nekem is érthető, szal nem szivesen válnék meg ettől a megoldástól. itt van a kód:
Kód:
void orientMe(float ang1)
{     
    lx = sin(ang1);     // Forgáshoz kell
    lz = -cos(ang1);    // Forgáshoz kell
    ly = sin(angle2);   // Forgáshoz kell

    lxx = sin(ang2);    // Oldalazáshoz kell
    lzz = -cos(ang2);   // Oldalazáshoz kell
}


void moveMeFlat()
{
    // ELŐRE - HÁTRA     
    if (deltaMove < 2, vagyis 1, vagy -1)
    {
        x = x + deltaMove*(lx)*0.1*speed_elorehatra;
        z = z + deltaMove*(lz)*0.1*speed_elorehatra;
        y = y + deltaMove*(ly)*0.1*speed_elorehatra;
    }
   
    //ez az én kiegészítésem
    // OLDALAZÁS - BALRA
    if (deltaMove == 2)
    {
        x = x + 1*(lxx)*0.1*speed_oldalazas;;
        z = z + 1*(lzz)*0.1*speed_oldalazas;
    }
    // OLDALAZÁS - JOBBRA
    if (deltaMove == 3)
    {
        x = x + -1*(lxx)*0.1*speed_oldalazas;
        z = z + -1*(lzz)*0.1*speed_oldalazas;
    }
}


Aztán a renderelő függvény elején meghívom ezeket:
Kód:
moveMeFlat();
angle += deltaAngle;
angle2 += deltaAngle2;
orientMe(angle);

//és elhelyezem a "kamerát"
glLoadIdentity();
    gluLookAt(x, y, z,
      x + lx,y + ly,z + lz,
  0.0f,1.0f,0.0f);


És így mozgok:
Kód:
void keyboardfunc(unsigned char key, int x, int y)
{
    switch(key)
    {
               
        case 27              :   exit(0);             break;  // esc
        case 97              :   deltaMove = 2;       break;  // a -balra oldalazás
        case 100             :   deltaMove = 3;       break;  // d -jobbra oldalazás
        case 119             :   deltaMove = 1;       break;  // w
        case 115             :   deltaMove = -1;      break;  // s
       
    }
}

void keyboardupfunc(unsigned char key, int x, int y)
{
   
    switch(key)
    {
        case 97              :    deltaMove = 0;       break;
        case 100             :   deltaMove = 0;       break;
        case 119             :   deltaMove = 0;       break;
        case 115             :   deltaMove = 0;       break;
    }
}


Amik most az egérmozgáshoz voltak rendelve azok régebben a nyílbillentyűkhöz voltak, és úgy működött rendesen.
felfele nyíllal feljebb fordult a kamera, lefelével lefelé, jobbra nyíllal elfordult jobbra, balrával balra, a w-a-s-d -vel pedig lehet haladni. Ez így egy működő koncepció volt mindenféle szempontból, és nincs is teli számításokkal. Szal ezért gondoltam hogyha már ezt kibővítettem akkor megmaradok ennél és csak a nyílbillentyűk szerepét átadom az egér mozgásának.

   
Csaba42 - Törzstag | 946 hsz       Online status #23910   2006.08.03 05:20 GMT+1 óra  
Egyébként, ha szabad egy megjegyzést: a 3D.exe-dben az egér mozgása lemarad a valós mozgás mögött, a kurzor egy adott pályán tud csak mozogni átlósan (vagy csak én nem tudtam irányítani rendesen ). Ezek a fg-ek, amiket ide bemásoltam (régi gerzSonka forrkódból, ami meg állítólag gamedev-es, én nem tudom, de ha működik, és megérti az ember a lényeget, vajmi keveset számít, honnan való ), elég bonyolult matematikai egyenleteket használ (legalábbis első látásra), de ha jó vagy matekból, akkor hamar elsajátíthatod!

   
Csaba42 - Törzstag | 946 hsz       Online status #23909   2006.08.03 05:14 GMT+1 óra  
Igaz, kiegészítő függvények:
Kód:
struct CVektor
{
public:
CVektor() {}
CVektor(float X, float Y, float Z)
{
x = X; y = Y; z = Z;
}
CVektor operator+(CVektor vVector)
{
return CVektor(vVector.x + x, vVector.y + y, vVector.z + z);
}

CVektor operator-(CVektor vVector)
{
return CVektor(x - vVector.x, y - vVector.y, z - vVector.z);
}
CVektor operator*(float num)
{
return CVektor(x * num, y * num, z * num);
}
CVektor operator/(float num)
{
return CVektor(x / num, y / num, z / num);
}
float x, y, z;
};

CVektor m_vPosition;
CVektor m_vView;
CVektor m_vUpVector;

CVektor Cross(CVektor vVector1, CVektor vVector2)
{
CVektor vNormal;
vNormal.x = ((vVector1.y * vVector2.z) - (vVector1.z * vVector2.y));
vNormal.y = ((vVector1.z * vVector2.x) - (vVector1.x * vVector2.z));
vNormal.z = ((vVector1.x * vVector2.y) - (vVector1.y * vVector2.x));
return vNormal;
}

float NormalVek(CVektor vNormal)
{
return (float)sqrt( (vNormal.x * vNormal.x) +
    (vNormal.y * vNormal.y) +
    (vNormal.z * vNormal.z) );
}

CVektor Normalize(CVektor vVector)
{
float magnitude = NormalVek(vVector);
vVector = vVector / magnitude;
return vVector;
}
void RotateView(float angle, float x, float y, float z)
{
CVektor vNewView;
CVektor vView;

vView.x = m_vView.x - m_vPosition.x;
vView.y = m_vView.y - m_vPosition.y;
vView.z = m_vView.z - m_vPosition.z;

float cosTheta = (float)cos(angle);
float sinTheta = (float)sin(angle);

vNewView.x  = (cosTheta + (1 - cosTheta) * x * x) * vView.x;
vNewView.x += ((1 - cosTheta) * x * y - z * sinTheta)  * vView.y;
vNewView.x += ((1 - cosTheta) * x * z + y * sinTheta) * vView.z;

vNewView.y  = ((1 - cosTheta) * x * y + z * sinTheta) * vView.x;
vNewView.y += (cosTheta + (1 - cosTheta) * y * y)      * vView.y;
vNewView.y += ((1 - cosTheta) * y * z - x * sinTheta) * vView.z;

vNewView.z  = ((1 - cosTheta) * x * z - y * sinTheta) * vView.x;
vNewView.z += ((1 - cosTheta) * y * z + x * sinTheta) * vView.y;
vNewView.z += (cosTheta + (1 - cosTheta) * z * z)      * vView.z;

m_vView.x = m_vPosition.x + vNewView.x;
m_vView.y = m_vPosition.y + vNewView.y;
m_vView.z = m_vPosition.z + vNewView.z;
}

Ez kissé bonyolult, de mindenképpen müxik! De ha gondolod, írhatsz saját Cross, Normalize, és RotateView függvényeket, bár ehhez tényleg erős matek kell (ami pl. nálam nem kimondottan lelhető fel ).

   
Csaba42 - Törzstag | 946 hsz       Online status #23908   2006.08.03 05:10 GMT+1 óra  
Idézet
Csaba42 :
Kód:
void CCamera::SetViewByMouse()
{
POINT mousePos;
int middleX = SCREEN_WIDTH  / 2;
int middleY = SCREEN_HEIGHT / 2;
float angleY = 0.0f;
float angleZ = 0.0f;
static float currentRotX = 0.0f;

GetCursorPos(&mousePos);

if( (mousePos.x == middleX) && (mousePos.y == middleY) ) return;

SetCursorPos(middleX, middleY);

// Kiszámoljuk az elfordulás szögét, amit radiánban (valós számként) tárolunk.
// A radián alapja a pi! A pi értéke 180 fok, amely radiánban 3,14! Ez kapcsolatba
// hozható a kör kerületével. Ennek következtében pi/2 = 90 fok, stb. Így tárolunk
// szögeket valós számként.
angleY = (float)( (middleX - mousePos.x) ) / 1000.0f;
angleZ = (float)( (middleY - mousePos.y) ) / 1000.0f;

currentRotX -= angleZ;

if(currentRotX > 1.0f)
currentRotX = 1.0f;
else if(currentRotX < -1.0f)
currentRotX = -1.0f;
else
{
CVektor vAxis = Cross(m_vView - m_vPosition, m_vUpVector);
vAxis = Normalize(vAxis);

RotateView(angleZ, vAxis.x, vAxis.y, vAxis.z);
RotateView(angleY, 0, 1, 0);
}
}



Erre gondoltam

   
gaborlabor - Moderátor | 4449 hsz       Online status #23907   2006.08.03 05:10 GMT+1 óra  
Idézet
Csaba42 :
Tudtommal az OpenGL koordinátarendszreében a bal alsó az origó.



Már kicsit belegabalyodtam ezekbe a koordinátákba, de asszem énis ezt mondtam. OpenGL-ben a 0,0 a bal alsó, GLUT-ban meg a bal felső.

   
Csaba42 - Törzstag | 946 hsz       Online status #23906   2006.08.03 05:10 GMT+1 óra  
Idézet
gaborlabor :
Idézet
Csaba42 :
Nálam ugyanúgy viselkedik, mint az előző.


Az érdekes. És az egérkurzor hogy viselkedik, mert nálam az is elég furcsán. Mindegy, mostmár nem csodálkozok azon hogy ez nem müxik rendesen. Az előző postod után csoda hogy egyáltalán megmozdul.
Akkor majd ujrairom a mouse függvényt, és megírom a fejleményeket!


Még régebben bedobtam egy egérkezelő függvényt, próbáld meg azt átalakítani, és használni!

   
Csaba42 - Törzstag | 946 hsz       Online status #23905   2006.08.03 05:09 GMT+1 óra  
Idézet
gaborlabor :
Csak azt nem értem, hogyha flfelé mozog, akkor miért az x értéke változik meg, miért nem az y?


Bocsi, én írtam el, valóban az y változik, és az x nem

   
gaborlabor - Moderátor | 4449 hsz       Online status #23904   2006.08.03 05:09 GMT+1 óra  
Idézet
Csaba42 :
Nálam ugyanúgy viselkedik, mint az előző.


Az érdekes. És az egérkurzor hogy viselkedik, mert nálam az is elég furcsán. Mindegy, mostmár nem csodálkozok azon hogy ez nem müxik rendesen. Az előző postod után csoda hogy egyáltalán megmozdul.
Akkor majd ujrairom a mouse függvényt, és megírom a fejleményeket!

   
Csaba42 - Törzstag | 946 hsz       Online status #23903   2006.08.03 05:08 GMT+1 óra  
Idézet
gaborlabor :
Amúgy nem lehet hogy az ablakrelatív koordinátákban a 0,0 az nem a bal alsó sarok, hanem a bal felső sarok? Csak mert van egy loading függvény ami a program elején lefut és beállítja a kurzort középre. (SetCursorPos(middleX, middleY) És mikor elindul a program, akkor az egérkurzor a bal felső sarokban van.


Tudtommal az OpenGL koordinátarendszreében a bal alsó az origó.

   
gaborlabor - Moderátor | 4449 hsz       Online status #23902   2006.08.03 05:06 GMT+1 óra  
Idézet
Csaba42 :
A realítv koordináta az nem egyenlő az abszolút koordinátával! Az utóbbi a bal felső sarokban van (OpenGL ablakban azt hiszem a jobb alsó az origó), míg relatív esetén ha nem mozog az egér, akkor az x és y értéke 0. Így ha felfelé mozog a kurzor, az x érzéke megváltozik (y nem, de csak akkor ha pontosan felfelé, ami elég nehéz megvalósítani ).

Más szóval: ha x!=0 és/vagy y!=0, akkor mozog az egér, a mozgás sebessége adva van x-ben és y-ban, az irány az előjel. Ugyanilyen pl. DInputban is az DIMouse->SetProperty(DIPROP_AXISMODE, DIPROPAXISMODE_REL); beállítás.

Legalábbis, legjobb tudásom szerint így vagyon, de ha keverek valamit, nyugodtan szóljatok rám.



Hoppá. Tudtam én hogy itt lesz a gubanc ezekkel a koordinátákkal. Tehát az abszolút 0,0 koordináta az a bal felső sarok. Gondolom a GLUT miatt, mert OpenGL-ben a bal alsó sarok a 0,0 GLUT-ban meg a bal felső. (ha jól emléxem).
Akkor valszeg azzal van a gond, hogy ha nem mozog az egér akkor az értéke 0,0. Csak azt nem értem, hogyha flfelé mozog, akkor miért az x értéke változik meg, miért nem az y?
"ha x!=0 és/vagy y!=0, akkor mozog az egér"
Asszem ez alapján kell ujrairnom a mouse függvényemet. De azért nézd meg az előző postomat is.
Köszi szépen, már most sokat segítettél!

   
Csaba42 - Törzstag | 946 hsz       Online status #23901   2006.08.03 05:06 GMT+1 óra  
Nálam ugyanúgy viselkedik, mint az előző.

   
gaborlabor - Moderátor | 4449 hsz       Online status #23900   2006.08.03 05:02 GMT+1 óra  
Itt valami nem stimmel
Most meg nem is reagál a mozgatásra, egészen addig, amég le nem nyomom valamelyik gombot. Akkor meg megbolonul és folyamatosan forog, átlósan ide-oda.

A függvény prototípusa:
Kód:
void mouse(int button, int state, int x, int y);


A main függvényben:
Kód:
glutMouseFunc(mouse);


És a mouse függvény:
Kód:
void mouse(int button, int state, int x, int y)
{
    //Ha középen van
    if (x == middleX && y == middleY)
    {
        deltaAngle = 0;
        deltaAngle2 = 0;
    }
   
    if (x < middleX)
    {
        deltaAngle = -0.01f*speed_forgas_w;
    }
   
    if (x > middleX)
    {
        deltaAngle = 0.01f*speed_forgas_w;
    }
   
    if (y < middleY)
    {
        deltaAngle2 = 0.01f*speed_forgas_h;
    }
   
    if (y > middleY)
    {
        deltaAngle2 = -0.01f*speed_forgas_h;
    }
    SetCursorPos(middleX, middleY);
}


Itt van az exe is, nézd meg, hogy viselkedik.
3D.exe
Amúgy nem lehet hogy az ablakrelatív koordinátákban a 0,0 az nem a bal alsó sarok, hanem a bal felső sarok? Csak mert van egy loading függvény ami a program elején lefut és beállítja a kurzort középre. (SetCursorPos(middleX, middleY) És mikor elindul a program, akkor az egérkurzor a bal felső sarokban van.

   
Csaba42 - Törzstag | 946 hsz       Online status #23897   2006.08.03 04:43 GMT+1 óra  
A realítv koordináta az nem egyenlő az abszolút koordinátával! Az utóbbi a bal felső sarokban van (OpenGL ablakban azt hiszem a jobb alsó az origó), míg relatív esetén ha nem mozog az egér, akkor az x és y értéke 0. Így ha felfelé mozog a kurzor, az x érzéke megváltozik (y nem, de csak akkor ha pontosan felfelé, ami elég nehéz megvalósítani ).

Más szóval: ha x!=0 és/vagy y!=0, akkor mozog az egér, a mozgás sebessége adva van x-ben és y-ban, az irány az előjel. Ugyanilyen pl. DInputban is az DIMouse->SetProperty(DIPROP_AXISMODE, DIPROPAXISMODE_REL); beállítás.

Legalábbis, legjobb tudásom szerint így vagyon, de ha keverek valamit, nyugodtan szóljatok rám.

   
gaborlabor - Moderátor | 4449 hsz       Online status #23894   2006.08.03 04:28 GMT+1 óra  
Köszi a segítséget! Mindjárt lekódolom, és meglátjuk hogy működik. De amúgy a mouse függvény az elvileg nem lehet hibás, mert ugynezek voltak a nyílbillentyűkhöz is rendelve.
Na, mindjárt meglátjuk. Addig is egy kérdés:
Az ablak relatív koordinátákban hol van a 0,0 ? Az ablak közepén, vagy a bal alsó sarokban?

   
Csaba42 - Törzstag | 946 hsz       Online status #23884   2006.08.03 03:27 GMT+1 óra  
Hmm, ez valóban nem az igazi. Az a lényeg, hogy késik a kurzor mozgása az egér valós mozgásához képest. Ajánlom a glut függvényét használni, vagy legalábbis ezzel hívd meg a
Kód:
void mouse(int x, int y);

függvényed:
Kód:
glutMouseFunc(void (*func)(int button, int state, int x, int y));

A függvényt specifikálja, amely egy egér gomb lenyomásakor illetve elengedésekor hívódik meg. A button callback paraméter a GLUT_LEFT_BUTTON, GLUT_MIDDLE_BUTTON illetve a GLUT_RIGHT_BUTTON egyike. A state callback paraméter a GLUT_UP és a GLUT_DOWN szimbolikus konstansok egyike. Az x és y callback paraméterek az egér pozícióját jelzik az egér esemény megtörténtekor (ablak relatív koordinátákban). Az int main()-be kerüljön a glutMouseFunc(mouse); bejegyzés, az egérkezelő függvényed prototípusa pedig ilyen legyen:
Kód:
void mouse(int button, int state, int x, int y);

Ebbe helyezd el a void mouse(int x, int y); függvényed törzsét, és tájékoztass a fejleményekről .

   
gaborlabor - Moderátor | 4449 hsz       Online status #23881   2006.08.03 02:57 GMT+1 óra  
Csaba42:
Itt van az exe:
3D.exe

És itt van a kód is, hogy most hogyan van megoldva:
Kód:
//Időzített függvény, ami 20 ms-enként lekérdezi az egér pozicioját
//és meghívja a mouse függvényt
void timer1(int value)
{
    glutTimerFunc(20, (timer1), 1);
    GetCursorPos(&MousePos);
    mouse(MousePos.x, MousePos.y);
}
...
//mouse függvény
void mouse(int x, int y)
{
    //Ha középen van
    if (x == middleX && y == middleY)
    {
        deltaAngle = 0;
        deltaAngle2 = 0;
    }
   
    if (x < middleX)
    {
        deltaAngle = -0.01f*speed_forgas_w;
    }
   
    if (x > middleX)
    {
        deltaAngle = 0.01f*speed_forgas_w;
    }
   
    if (y < middleY)
    {
        deltaAngle2 = 0.01f*speed_forgas_h;
    }
   
    if (y > middleY)
    {
        deltaAngle2 = -0.01f*speed_forgas_h;
    }
   
    //A kurzort visszahelyezzük középre
    SetCursorPos(middleX, middleY);
}


Szerintem nézd meg az exét, hogy hogyan működik. Nem igazán tudom hogy mi, de valami furcsa rajta... Talán az hogy a függőleges forgás lassabb mint a vízszintes és azért ilyen furcsa?

   
Birmacher - Törzstag | 516 hsz       Online status #23870   2006.08.03 01:27 GMT+1 óra  
nem ezt akartam, azt már megoldottam, viszont most kipihenve és belegondolva nem tom mér tettem fel a kérdést, na mind1, azér köszi

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #23859   2006.08.02 23:14 GMT+1 óra  
Ezt akartad kerdezni tegnap este MSN-en? Ha igen, a valaszom:

Elsore nem nagyon vagtam le, mi köze lenne a display listnek a bump maphez. De ha a bump maped nem annyiban merül ki, h rahuzol egy texturat + egy masikat, s a ketto blendelese kiemeli az eleket, hanem pl. shaderrel csinalod full dinamikusra, amit befolyasol a per-pixel feny, etc. akkor tenyleg nem lehet... Szerintem.
Dare to imagine!
http://www.insaneidea.hu
   
Birmacher - Törzstag | 516 hsz       Online status #23841   2006.08.02 15:52 GMT+1 óra  
Nehe tutorban olvastam, hogy Bump Mappingnél nem használható Display List ez igaz?

   
gaborlabor - Moderátor | 4449 hsz       Online status #23556   2006.07.31 17:50 GMT+1 óra  
Ok, holnap, vagyis még ma megpróbálom minél jobban helyrerázni a kódot, aztán majd bemásolom ide.
Ja, egy kis gond már most is van. Az egérkezelő függvényt a
glutPassiveMotionFunc()-kal akartam először kezeltetni. Viszont ha ez
Kód:
glutPassiveMotionFunc(mouse) ;

benne volt a main függvényben, akkor a program főablaka, vagyis a teljes képernyős megjelenítés meg sem jelent, csak a konzol ablak.
Ezért az egér kezelését kénytelen voltam ideiglenes úgy megoldani, hogy van egy időzített függvény, ami 20 ezredmásodpercenként meghívja a mouse(int x, int y) függvényt. A 20 ms nem lehet túl sok, mert kipróbáltam hogy billentyűzetet is így kezelek és az megy rendesen. Aztán megpróbáltam úgy is, hogy az időzített függvényt kidobtam, és helyette a renderelő függvény elején hívom meg a mouse(int x, int y) függvényt. Ez meg még rosszabb, mert nagyon szaggat az egérkezelés.
A legjobb az lenne, ha meg tudnám csinálni, hogy a glutPassiveMotionFunc() kezelje az egérkezelő függvényt.

   
KergeDelfin - Törzstag | 667 hsz       Online status #23553   2006.07.31 17:23 GMT+1 óra  
Hát csak akkor láttam utoljára ilyet, amikor ezt tesztképpen 90-re állítottam. ^o)
Igen, furcsán viselkedik és lassan követi az egér mozgását. Jó lenne ha tudnál kódot is másolni, mert csak tippelgetni tudok/tudunk, az meg nem elég jó
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
gaborlabor - Moderátor | 4449 hsz       Online status #23550   2006.07.31 17:15 GMT+1 óra  
Jó is hogy felvetetted, mert ezt még nem értem teljesen. Valami oylasmit olvastam azzal a parméterrel kapcsolatban, hogy az az a szög, amekkorát a felhasználó zár be a monitorral. Ha mondjuk képzeletben húzok egy vonalat köztem és a monitor közepe között, akkor az a vonal 90°-ot zár be a monitorral. Viszont ha köztem és a monitor egyik széle között húzok egy vonalat, akkor az a szög lehet akár 45°-os is. Azért nem értettem, mert láttam példaprogramot amiben 90 volt, meg láttam olyat is amiben meg 45. Ezt tisztázhatná valaki egy kicsit.
De te honnét gondoltad, hogy nálam 90-re van állítva? Mert 45-ön van:
Kód:
gluPerspective(45, w / h, 0.01, 1000);


Úgyhogy nem ezzel van a probléma. Nálad is olyan furcsán viselkedett az egérlezelés? Úgy tűnik, mintha az átlós mozgásra érzékenyebb lenne mint a függőleges vagy vízsszintes mozgatásra, pedig elvileg nem lehetne ilyen.

   
KergeDelfin - Törzstag | 667 hsz       Online status #23549   2006.07.31 16:58 GMT+1 óra  
gluPerspective első paramétere (Field of View) mekkorára van állítva?
90 fok az egy picit sok, állítsd át mondjuk 45-re.
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
gaborlabor - Moderátor | 4449 hsz       Online status #23547   2006.07.31 16:36 GMT+1 óra  
Újabb fejlemények. Rájöttem mitől volt a függőleges irányú forgás darabossága. Abban nem az egérkezelő volt a hibás, hanem azt az egész részt én rontottam el úgy hogy van. Azt kompletten újraírtam a vizszintes forgás alapján. Ezután a darabosság megszűnt, normálisan forog minden irányba. Viszont ez az egérkezelési módszer nem tutti, vagy csak az én függvényem rossz, mert néha nagyon belassul tőle a program, néha meg rakoncátlankodik.
Kódot azért nem rakok be, mert annyira gány az az egész a sok átirogatástól, vagdosástól, hogy még énis alig igazodok ki rajta.
Inkább nézzétek meg az exét, ha kipofoztam a kódot, majd rakhatok be azt is.
3D.exe

   
gaborlabor - Moderátor | 4449 hsz       Online status #23545   2006.07.31 16:04 GMT+1 óra  
Na, asszem sínen vagyok. Ahogy az előző hsz-emben irtam, ugy most lekódoltam és a lényege müxik. Bár a kamrea forgatása lassú mégis darabos, de legalább müxik és az egérrel lehet irányítani. Már bevezettem néhány változót, amikkel a sebességeket lehet állítani, de még nem sikerült belőnöm úgy hogy normálisan lehessen irányítani. Remélem ez már csak apróbb munkálatokat fog igényelni.
Köszönöm az ötleteket és a segítséget!

   
gaborlabor - Moderátor | 4449 hsz       Online status #23544   2006.07.31 14:54 GMT+1 óra  
igen, tudom, a spectator móddal kapcsolatban igazad van, azért irtam utána, hogy mire is gondolok. (bár asszem cs1.6-ban nincs ütközésvizsgálat olyankor, a pályáról is ki lehet "repülni".
Megpróbálom ugy megoldani, hogy a program legelején az egérkurzort elhelyezem a képernyő közepére. Ezután ciklikusan megvizsgálom hogy az x és az y mennyivel változott meg, és ennek megfelelően járok el, végül pedig visszahelyezem középre az egérkurzort, és kezdődik előlről. Ennek igy müködnie kell, remélem meg tudom oldani.
Köszi a segítséget!

   
KergeDelfin - Törzstag | 667 hsz       Online status #23542   2006.07.31 14:47 GMT+1 óra  
Ütközésvizsgálat van, legalábbis a JK2-ben - spectator módban is (Q3 motor)
A DirectInputnak semmi köze az itt felvetett kérdéshez Főleg mert ez az OpenGL topic
De amúgy beast is írta, a legegyszerőbb ha minden egérmozgás lekezelésekor megnézed mennyi az elmozdulás a képernyő közepéhez, ehhez asszociálsz egy megfelelő szöggel történő elforgatást (egérérzékenység, stb figyelembevételével), forgatsz, az egérkurzort pedig visszadobod középre és kezdődhet a móka elölről.
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
gaborlabor - Moderátor | 4449 hsz       Online status #23540   2006.07.31 14:30 GMT+1 óra  
Köszi mindenkinek!
Csaba42: A feladat azon része mr meg van oldva. De mondjuk az sem elég jó első ránézésre, mert én kezdetnek olyan progit szeretnék írni ami olyan mint mikor egy fps-ben spectator vagy, vagy be van kapcsolva a fly meg a falonátjárás. Szóval nincs ütközésdetektálás és gravitáció. Kezdetben azt gondoltam, meg tudom irni magamtól, de ahogy belekezdtem, felismertem a buktatóit. A legtöbb szívás azzal volt, hogyha a FEL nyilat lenyomva a nézőpontot megemeltem (mintha felfelé néznél) és úgy nyomtam le a W-t, akkor már nem csak előre kellett mennie, hanem felfelé is, tehát a center felé kell haladnia mindeképp. Ehhez kell itt is az elfordulási szöggel kalkulálni. A lényeg, hogy találtam egy példaprogit, amiben úgy lehetett mozogni mint a doom2-ben. Azt sikeresen megbuheráltam úgy, hogy legyen benne oldalazás is, ne csak forgás, és megcsináltam azt is, hogy a fel-le nyilakkal az előbb említett függőleges irányú elmozdulás is lehetséges legyen. Annak a programnak is az a lelke, hogy az elfordulási szögekkel és sinussal és cosinussal számolgat. Tehát már mindem megvan ami a mozgást és nézelődést illeti:
W - előre
A - oldalazás balra
S - hátra
D - oldalazás jobbra
FEL - nézés felfelé
LE - nézés lefelé
BALRA - forgás balra
JOBBRA - forgás jobbra.
Na, ezek közül kéne nekem a fel, le, jobbra, balra gombok akcióit átírnom egérre, és kész is lennék.
Dinputtól meg nem azért idegenkedek, mert nem szeretem a directx-et, de úgy gondolom, hogyha eddig mindent megoldottam a directx és directinput nélkül, akkor valahogy biztosan meglehet oldani az egérkezelést is, csak lehet hogy kicsivel nehezebb.

   
beast - Törzstag | 1241 hsz       Online status #23524   2006.07.31 13:08 GMT+1 óra  
De ha jól elolvastad, akkor látod, hogy a középpontól (width/2, height/2) való elmozdulással alapszik. Ha mozgatod az egeret, akkor csak pár pixeles elétrésekkel dolgozik, majd megint a képernyő közepére dobja a kurzort. NIncs semmi 1023->0. Vagy mi a kérdés?
Amúgy sztem ez nem GerzSonka saját kódja, inkább gametutorialos...

   
Csaba42 - Törzstag | 946 hsz       Online status #23521   2006.07.31 13:03 GMT+1 óra  
Én arra gondoltam, hogy amint eléri vmelyik határt, 0-zod az adott számot (pl.: 1023->0), és veheted ezt is mozgásnak. Persze, ez csak egy futó gondolat volt, talán nem is működik (bevallom, OpenGLben nem vagyok otthon).

Kód:
void CCamera::SetViewByMouse()
{
POINT mousePos;
int middleX = SCREEN_WIDTH  / 2;
int middleY = SCREEN_HEIGHT / 2;
float angleY = 0.0f;
float angleZ = 0.0f;
static float currentRotX = 0.0f;

GetCursorPos(&mousePos);

if( (mousePos.x == middleX) && (mousePos.y == middleY) ) return;

SetCursorPos(middleX, middleY);

// Kiszámoljuk az elfordulás szögét, amit radiánban (valós számként) tárolunk.
// A radián alapja a pi! A pi értéke 180 fok, amely radiánban 3,14! Ez kapcsolatba
// hozható a kör kerületével. Ennek következtében pi/2 = 90 fok, stb. Így tárolunk
// szögeket valós számként.
angleY = (float)( (middleX - mousePos.x) ) / 1000.0f;
angleZ = (float)( (middleY - mousePos.y) ) / 1000.0f;

currentRotX -= angleZ;

if(currentRotX > 1.0f)
currentRotX = 1.0f;
else if(currentRotX < -1.0f)
currentRotX = -1.0f;
else
{
CVektor vAxis = Cross(m_vView - m_vPosition, m_vUpVector);
vAxis = Normalize(vAxis);

RotateView(angleZ, vAxis.x, vAxis.y, vAxis.z);
RotateView(angleY, 0, 1, 0);
}
}

Ez persze nem az enyém, GerzSonka tulajdona, de hátha segít!

   
gaborlabor - Moderátor | 4449 hsz       Online status #23518   2006.07.31 12:42 GMT+1 óra  
DInputot, ha eddig mellőztem (billentyűzetkezelés müxik rendesen glut-tal), nem most fogom elővenni. Igen, énis igy oldanám meg glut-ban. Az aktuális mousecoordot azt le tudom kérdezni, mozgatásnál ezt vehetjük a réginek. Ehhez viszonyítva meg tudom állapítani hogy az egér új x, és y koordinátája nőtt vagy csökkent. Egészen addig amíg el nem érem az ablak határait, vagyis teljes képernyős módnál az 1023 és a 767 a max, és ha onnét húzza tovább, azt is kezelni kéne valahogy. Még dolgozok rajta. Ha bárkinek eszébe jut valami, ne habozzon írni.

   
Hacker - Törzstag | 567 hsz       Online status #23465   2006.07.31 05:35 GMT+1 óra  
DirectInput . GLUT-vel eléggé nehéz lesz, de nem megoldhatatlan. Csak tudni kell a régi mouse coord-ot és az újjal összehasonlítani és úgy mozgatni. Vagyis én így oldanám meg DirectInput nélkül.
No [img] !
Programozz ne háborúzz!!!!

   
gaborlabor - Moderátor | 4449 hsz       Online status #23453   2006.07.31 04:48 GMT+1 óra  
Na, sikeresen megoldottam a mozgást a 3d-s térben, minden irányba, mint egy fps játékban. Csak most még billentyűzettel lehet irányítani. A forgást át szeretném írni, hogy egérrel lehessen irányítani.
Valamelyik GLUT-os egérkezelő függvényre gondoltam. Azt kéne meghatározni, hogy az egér melyik irányba mozdult el, a kurzor ablakbeli relativ pozicioja és a gombok lenyomva tartása nem lényeges. Ti melyik függvénnyel/módszerrel oldanátok meg?
THX

   
gaborlabor - Moderátor | 4449 hsz       Online status #22914   2006.07.26 12:01 GMT+1 óra  
Igen, pont erre gondoltam énis mikor belegondoltam és rájöttem, hogy én ezt nemtudom megcsinálni. Szerintem a középiskolás matek az a minimum a 3d-hez, csakhogy én még azon sem vagyok ám túl...
Addigis maradnak másoktól ellesett megoldások. De mint mondtam abban a példaprogiban nem tűnt olyan bonyolultnak. Asszem 1-2 sin() meg cos() függvény az alapja az egésznek.

   
KergeDelfin - Törzstag | 667 hsz       Online status #22904   2006.07.26 10:59 GMT+1 óra  
Trigonometriára szükséged lesz mindenképpen, ajánlatos körbenézni a gömbi koordináták háza táján ha mouselookot akarsz csinálni.
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
gaborlabor - Moderátor | 4449 hsz       Online status #22889   2006.07.26 08:53 GMT+1 óra  
Megnéztem a progi kódját, és ahogy elnéztem elég bonyolult matematikai számításokkal oldja meg a mozgatást. Egyenlőre nem siekrült teljesen átlátnom az egész működését, de persze nem várok csodát 30 perc alatt. Viszont a LightHouse3d-n találtam egy hóemberes példaprogramot, ami ugyanazt csinálja, csak sokkal rövidebb, egyszerűbb, és átláthatóbb számításokat/megoldásokat használ. Valszeg abból fogok kiindulni, de azért köszi a segítséget és a linket!

   
gaborlabor - Moderátor | 4449 hsz       Online status #22883   2006.07.26 07:10 GMT+1 óra  
THX a lot! Letöltöttem, még csak az exe-t néztem meg, de nagyon tetszik, pont ilyenre gondoltam!
Beleásom magam a kódba, hátha sikerül megtalálnom benne a nekem fontos részt. Köszi mégegyszer!

   
beast - Törzstag | 1241 hsz       Online status #22871   2006.07.26 04:35 GMT+1 óra  
Szerintem ezt nézd meg, hátha találsz valami érdekeset benne!

   
gaborlabor - Moderátor | 4449 hsz       Online status #22869   2006.07.26 04:28 GMT+1 óra  
Köszi a választ! A mozgást nagyjából sikerült megoldanom. Viszont az egérrel már nem volt könnyű dolgom. Úgy próbáltam megoldani, hogy a program legelején a
Kód:
GetCursorPos(&mouse);

kóddal lekérdezem az egér x és y koordinátáját és azokat a mouse.x és mouse.y-ban tárolom,
és a glut-os mousefunc()-kal pedig megvizsgálom, hogy ez egér új pozicioja hogyan tér el az indulási koordinátáktól és ez alapján a center-t módosítom, mintha forogna a kamera:
Kód:
void mousemove(int x, int y)
{
    if (mouse.x < x)
    {
        centerx -= 3;
    }
    if (mouse.x > x)
    {
        centerx += 3;
    }
}

Elvileg működnie kéne, de nem tökéletes, mert néha akdozik, néha az ellenkező irányba forog, néha pedig nem is reagál a mozgatásra. Ezt majd még talán meg tudom oldani valahogy, de van egy ennél nagyobb gondom is.
Ha pl az egérrel a "kamerát" elforgattam kicsit jobbra meg kicsit felfelé, és utána nyomom le az előre nyilat, akkor már nem csak az eyez -t kell módosítanom, mert a "kamera" már nem a negatív z tengely irányába néz. És erre nem tudtam még rájönni, hogy hogyan számítsam ki, hogy az eyex,eyey,eyez közül melyiket és hogyan kell módosítanom, hogy a szem pozíciója úgy mozduljon el, hogy a center felé halad, ahová nézek. Tehát hogy olyasmi legyen, mint mikor egy fps-ben spectator vagy és tudsz menni akármerre.

Ha bárki tudna segíteni, annak nagyon örülnék!
Köszi.

   
KergeDelfin - Törzstag | 667 hsz       Online status #22710   2006.07.24 13:36 GMT+1 óra  
****** cenzúrázva, én voltam figyelmetlen
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
KergeDelfin - Törzstag | 667 hsz       Online status #22709   2006.07.24 13:34 GMT+1 óra  
Nem csak az eyex, eyey, eyez-t kell módosítani, hanem a center-eket is.
A gluLookAt-re úgy gondolj, mint egy kamerára, ahol meg van adva az a pont, ahol van a kamera, és az as pont, ahová néz. Hogyha pl a center a kamera előtt van, te mozgatod előre a kamerát, de a centert nem, akkor amint a kamera túljut a centeren, megfordul, és már nem jó az egész.
Persze az opengl-ben nincs kamera, illetve mindig a (0,0,0) pontban van, tehát nem a nézőpont változik a gluLookAt-tel, hanem a színtér lesz eltolva, forgatva, stb.
Ore wa... yurusaretaintadomo... un... Ore wa yurusaretai...

Isles of Tranquility - Ecco fanoknak kötelező
   
gaborlabor - Moderátor | 4449 hsz       Online status #22676   2006.07.24 08:30 GMT+1 óra  
Hy all! Első 3d-s progimat szeretném megírni, de akadt néhány problémám. Olyan progit szeretnék irni, ami egy-két egyszerű objektumot, pl kockát rajzol ki, és a nyilak segítségével tudom a kamerát, azaz a nézőpontot mozgatni, úgy mint az FPS játékokban.
A rajzoló függvényem csak egy kockát rajzol ki:
Kód:
glBegin(GL_QUADS);
        //szemközti oldal
glVertex3f(0, 0, 0);
glVertex3f(5, 0, 0);
glVertex3f(5, 5, 0);
glVertex3f(0, 5, 0);
        //jobb oldal
glVertex3f(5, 0, 0);
glVertex3f(5, 0, -5);
glVertex3f(5, 5, -5);
glVertex3f(5, 5, 0);
        //bal oldal
glVertex3f(0, 0, 0);
glVertex3f(0, 5, 0);
glVertex3f(0, 5, -5);
glVertex3f(0, 0, -5);
        //alsó oldal
glVertex3f(0, 0, 0);
glVertex3f(5, 0, 0);
glVertex3f(5, 0, -5);
glVertex3f(0, 0, -5);
        //felső oldal
glVertex3f(0, 5, 0);
glVertex3f(5, 5, 0);
glVertex3f(5, 5, -5);
glVertex3f(0, 5, -5);
        //hátsó oldal
glVertex3f(0, 0, -5);
glVertex3f(5, 0, -5);
glVertex3f(5, 5, -5);
glVertex3f(0, 5, -5);
glEnd();


A látóteret a gluPerspective()-vel akartam specifikálni, mert a glFrustum-mal nem siekrült úgy, hogy meg is jelenjen a kocka (nem találtam normális leírást, vagy működő példát). Tehát a látóteret így állítom be:
Kód:
glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluPerspective(90.0f, 4/3 , 0.01f ,1000.0f);


Ezzel megjelenik egy négyzet, úgy, hogy a bal alsó sarka a képernyő közepén van. Úgy terveztem, hogy a kameramozgást a gluLookAt()-tel fogom megoldani, de ehhez megintcsak elég szegényes leírást találtam. Próbálkoztam többféleképpen, de nem sikerült úgy megoldanom, hogy a kockát a képernyő közepén lássam szemből. A kameramozgást pedig úgy próbáltam megoldani, hogy a rajzoló függvény elején ottvannak a
Kód:
glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    gluLookAt(eyex, eyey, eyez, centerx, centery, centerz, upx, upy, upz);

sorok, és a billentyűzetkezelő függvényben módosítom a az eyex, eyey, eyez értékeket, de ezt sem sikerült megoldanom úgy, hogy a mozgás megfelelő legyen (pl néha forgás lett, néha meg nem abba az irányba ment amerre szeretném stb).
Ehhez szeretnék segítséget kérni, hogy a gluPerspective-et és a gluLookAt-et hogyan specifikáljam az elején, és hogy mely változókat hogyan módosítsam az egyes mozgásokhoz.
A segítséget előre is köszönöm!

   
gaborlabor - Moderátor | 4449 hsz       Online status #21577   2006.07.13 08:36 GMT+1 óra  
Kipróbáltam amit mondtál. Az idlefunc-ot teljesen kivettem és a glutPostRedisplay-t beirtam a renderelő függvény végére. Valószínűleg nem azzal volt a baj. Az eredmény:
- A program általánosságban hozzányúlás nélkül 10 fps-sel kevesebbel megy mint eddig. Most igy 130-cal ment átlagban.
- A jelenség továbbra is fentáll, csak azzal a különbséggel hogy most nem 300-ra ugrik fel az fps, hanem csak 260-ra.

Ez jelenség nem is igazán probléma nálam, mert müködik igy is a program. Viszont sehogy nem fér a fejembe, hogy hogy képes megduplázódni az fps érték. Meg ha egyszer tud menni 260-300 FPS-sel, akkor alapból miért nem megy annyival?

   
cs_adam - Tag | 11 hsz       Online status #21570   2006.07.13 07:06 GMT+1 óra  
Egy GLUT-ot használó (és működő) alkalmazás (nevezetesen a lib3ds példa programja) a DisplayFunc vége:
...
glutSwapBuffers();
glutPostRedisplay();
...
Szerintem ha ezeket berakod a DisplayFunc végére te is, és az Idle-ben nem renderelsz, akkor komoly esély van rá hogy megjavul.
   
gaborlabor - Moderátor | 4449 hsz       Online status #21569   2006.07.13 06:52 GMT+1 óra  
Az IdleFunc-kal kapcsolatban lehet hogy igazad van, de ezt nem magamtól vettem hogy ott rendereltetem ujra. Rengeteg tutorialban és leirásban láttam, hogy a glutIdleFunc()-ban ez áll:
glutPostRedisplay(); vagyis ujrarajzoltatja a képernyőt. Leggyakrabban ezt azért nem használják számításokra, mert ez akkor hívódik meg ha a proci "ráér", és így minden gépen más sebességgel futna a program, a proci órajelétől függően, ezt meg senki nem akarja. Kipróbáltam hogy nem használo az IdleFunc-ot, úgy meg nem frissíti a képetm tehát 1 FPS-sel megy és nem frissül a tartalom. Ezért gondolom kell az oda. Még mindíg azt furcsállom hogy miért ugrik meg az fps érték.

   
cs_adam - Tag | 11 hsz       Online status #21559   2006.07.13 05:19 GMT+1 óra  
A figyelmetlenségért elnézést kérek.
Ha teljes képernyős, és átváltasz, akkor nincs már hova rendereljen. Ezért továbbra is fenn tartom hogy akkor nem kéne renderelnie, legfeljebb off-screen bufferekre.
Nem emlékszem sokra a glut használatából, de a glutIdleFunc() mintha kisebb számításokra lenne, és nem további renderelésre. Talán éppen ez a gond. Próbáld meg hogy ott nem renderelsz semmit, csak a DisplayFunc-ban.
   
gaborlabor - Moderátor | 4449 hsz       Online status #21532   2006.07.12 15:54 GMT+1 óra  
Köszi, értem mire gondolsz. Csakhogy zárójelben ott van hogy Fraps-szel mérve. Tehát az értékek valószínűleg reálisak.
Nekem nem tűnik furcsának hogy inaktív állapotban is renderel. Nem a tálcán van csak inaktiv mert átváltok a konzol ablakra. Viszont a glutIdleFunc() miatt amikor "ráér" akkor renderel ujra. És a helyzet továbbra is ez, függetlenül a program összetettségétől és méretétől.

   
cs_adam - Tag | 11 hsz       Online status #21508   2006.07.12 13:03 GMT+1 óra  
Eleve értelmetlen fps-ről beszélni, ha inaktív, hiszen nem kéne rajzolnia semmit. Ha mégis rajzol, akkor kezdd itt a javítgatását a proginak. A 80-90 fura, mert ha rendes program inaktív állapotban nagyon hamar végigér a main loop-on, és a 80-90 helyett nagyságrendekkel magasabb érték kéne. A felgyorsulásra azt javaslom nézd meg FRAPS-szel, vagy valami megbízható cuccal, hátha csak az fps számlálód rossz.
   
gaborlabor - Moderátor | 4449 hsz       Online status #21359   2006.07.10 14:55 GMT+1 óra  
Hi. Van egy dolog, amit már régóta nem tudok megérteni, és kicsit furcsállom.
Van egy win32 console application projektem, és abban irtam az opengl-es progit. GLUT-ot használ alakozáshoz, és teljes képernyős módhoz. Ez a progi átlag 140-150 FPS-sel megy (Fraps-szel mérve). Ha alt+tabbal átváltok a console ablakra, akkor látom, hogy a háttérben lévő teljes képernyős ablak kb 80-90 FPS-sel megy. És azt nem értem, hogy miért van az, hogy mikor visszaváltok alt+tabbal, akkor a megszokott 140-15 FPS helyett felugrik 290-310-re, és úgy is marad egészen a kilépésig. Szal nekem ez egy kicsit furcsa. Miért lesz attól gyorsabb hogy átváltok róla, aztán meg visszaváltok? Tudtok erre valami magyarázatot?
Köszi!

   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]