Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Bielos

Strony: [1] 2 3
1
OpenGL / Odp: Główny render gry
« dnia: Wrzesień 06, 2013, 00:45:30 »
Witam.
Deasemblacjuję pewną gierkę.

Sorry za offtop ale muszę:
Połamałem sobie oczy próbując to rozczytać :D

2
Szkółka / Odp: Logika silnika, plan
« dnia: Lipiec 24, 2013, 00:30:30 »
Oj no żartowałem z tym PHP :D
Pewnie, że nie pracują na jednym skrypcie.

Myślę, że jednak kolega miał na myśli SQL (no chyba, że się mylę).

Na pewno tak jak wspomniał Xirdus musisz się zastanowić co tak naprawdę chcesz pisać. Skoro miałeś raczej mało doczynienia z C++ może na początek wystarczy coś konsolowego(nikt nie powiedział że nie da się zrobić tam czegoś fajnego ;-) ) lub prosta gierka 2D w jakimś frameworku (tu nie będę nic polecał bo się nie znam). No i myślę, że jak chcesz się zaprzyjaźnić z C/C++ i ogólnie aplikacjami nie Webowymi to warto zmienić podejście. Pisanie czegoś "tak jak w php" nie jest dobrym pomysłem.

Co do organizacji kodu to tak jak wspomniałem to od Ciebie zależy, jak będzie dla Ciebie czytelniej. Na pewno upychanie wszystkiego do jednego pliku/klasy nie jest dobrym pomysłem.

Cytuj
BTW, czemu wyedytowałeś część o PHP zanim zdążyłem ją skomentować?
Stwierdziłem jednak, że to co napisałem jest baaardzo złe i wywaliłem :D

3
Szkółka / Odp: Logika silnika, plan
« dnia: Lipiec 24, 2013, 00:10:02 »
Funkcje gry:

-. Baza danych (chciałbym tam umieszczać wszystko na temat gry, użytkownika, jak w php)
-. Ustawienia gry i save'y w plikach

1. Main menu (+ profil użytkownika)

2. Wybór mapy
- Wyświetlenie dostępnych map, załadowanie save'a


Za dużo myślisz technologiami WEB. Fuuu :D Widać to po pomyśle z bazą danych. Po co robić zapytania, bawić się w jakąś bazę, skoro wszystko możesz trzymać w pliku, save, nawet TXT zwykłym. Nikt Cię niczym nie ogranicza. Chyba w tym przypadku baza danych to jest najgorsze co można zrobić.

3 pliki i gra 3D? łololo. No tak, w webowych 3 pliki wystarczą na wszystko. No ale to ma być gra a nie strona internetowa. Właściwie zacznijmy od tego co wiesz na temat programowania poza PHP ? :D

To są dwie różne dziedziny, inne podejście do programowania aplikacji. W webowych wystarczy layout, connect z bazą i wszyscy szczęśliwi :D

Ok, to przykładowo, weźmy silnik Irrlicht: 182 osobnych plików klas.
Ogre ma jakieś 250 (no tak mniej więcej podaje).

Nawet prosta gra 2D troszkę tego powinna mieć (wczytywanie save, postać, wyświetlanie grafiki, przetwarzanie I/O, logika)

Zabierasz się za pisanie w C++ więc masz pełne pole do popisu. Jak narysujesz grafikę (czy DX, opengl, czy jakiś framework typu ogre) i jak będziesz pobierał komunikaty od usera (np z klawiatury) zależy tylko od Ciebie. Wybierasz co Ci pasuje w danym momencie. Sposób zapisu danych też jest dowolny (własny format, txt i coś tam jeszcze). Co do rozplanowania to robisz tyle klas i plików ile będzie dla Ciebie czytelne. Na pewno upakowanie wszystkiego do jednego pliku (szczególnie że zwykle robi się jedna klasa = jeden plik) nie jest dobrym pomysłem. Chodzi o to żebyś się później mógł w tym odnaleźć :D

4
Może sprawdź tym: http://developer.amd.com/tools-and-sdks/heterogeneous-computing/codexl/

Jeszcze jest to: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition ale chyba nie działa jeszcze na Windows 8 (przynajmniej tak piszą w wymaganiach. Nie miałem jeszcze przyjemności używać)

EDIT:: offtop: ktoś się orientuje kiedy NSIGHT wyjdzie w końcu dla Visuala 12? Chciał bym się pobawić, bo jak widzę te screeny to strasznie kusi.

5
Glm ma wszystkie patenty związane z macierzami. Plus jeszcze masz kwaterniony jako glm::quat więc możesz obracać do woli.

glm::mat4 mat(1); //macierz jednostkowa

mat = glm::lookAt(position, look , glm::vec3(0,1,0));

// (...)

mat = glm::perspective(45.0f, aspect, 0.1f,100.0f);

// (...)

mat = glm::translate( mat, glm::vec3( translateX, translateY,0.0f))

I inne takie bajery. Musisz załączyć glm\gtc\matrix_transform.hpp i już śmigasz jak chcesz z macierzami.

EDIT: W manualu http://glm.g-truc.net/glm-0.9.4.pdf na stronie 12 masz napisane jakie funkcje z GLM zastąpiły te deprecated ze starego GL, może to Cię naprowadzi ;-)

6
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 09, 2013, 19:21:56 »
Wzorowałem się na kilku silnikach open source pisząc kod (czy to dobrze, czy nie dobrze, nie wiem. Działa, singletonem nie męczę siebie i kodu :D ) Problem jest tylko w tych parametrach GLFW, a właściwie w jednym. Jak nie znajdę odpowiedzi to będę kombinował ze zwalnianiem VBO, to chociaż u mnie działa poprawnie :D

7
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 09, 2013, 17:33:25 »
Oki, naprawiłem to troszkę. Już nie przekazuje pointera z Device do Drivera i nie ma funkcji init(). Wszystko robi się w konstruktorze. Dalej mam 2 konteksty według gDebuggera. Tak jak wspominałem wcześniej bez tego:

glfwOpenWindowHint(GLFW_WINDOW_NO_RESIZE, GL_TRUE);
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_COMPAT_PROFILE);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR,3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR,3);

Jest tylko jeden :)

@UP, czyli jak proponował byś to zrobić? :)

EDIT: wykomentowanie tej linijki powoduje, że wszystko wraca do normy i jest jeden context (no ale wracam do punktu wyjścia, czyli czepia się o VA :D ):
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_COMPAT_PROFILE);

8
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 09, 2013, 17:11:18 »
Hmm, wychodzi na to, że niby mam wszystko dobrze.

Najpierw leci obiekt typu Window z czymś takim w konstruktorze:

if(!glfwInit())
{
std::cout << "Error!" << std::endl;
}

glfwOpenWindowHint(GLFW_WINDOW_NO_RESIZE, GL_TRUE);
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_COMPAT_PROFILE);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR,3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR,3);

this->width = width;
this->height = height;

if( !glfwOpenWindow(this->width,this->height,0,0,0,0,0,0, GLFW_WINDOW))
{
glfwTerminate();
}

A później dopiero robię obiekty typu Driver w którym jest coś takiego:

if(glewInit() != GLEW_OK)
{
std::cout << "Error! Problem with glew Init" << std::endl;
}

Więc wychodzi na to, że kolejność jest poprawna.

Jeszcze dodam jakiś kod na szybko:

window::GlWindowDevice device(1024,768);
video::OpenglDriver driver;

device.setWindowTitle("lol");

driver.initDriver(&device);

Wszystko związane z robieniem okienka dzieje się już w konstruktorze Device, natomiast glewInit() wywołuje dopiero w initDriver.

9
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 09, 2013, 15:20:02 »
@Xender Używam GLFW+GLEW :) Gdzie mam czegoś takiego szukać? ;-)

Ja odpalam po prostu funkcje glfw i gl.

Chodzi o to? :

glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

Jak to dodawałem to gDebugger pokazywał mi, że mam 2 konteksty i wszystko się sypało. No chyba, że coś źle robię.

EDIT: dałem coś takiego:

glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR,3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR,3);
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_COMPAT_PROFILE);

Zaraz po glfwInit a przed glewInit (i przed glfwOpenWindow) i teraz w ogóle wszystko się sypie i dostaje error, że jest problem z glewInit. Na dodatek wszystko, co rysowało się dotychczas nagle przestaje.

Z tego co jest napisane w manualu GLFW to robię to dobrze, czyli ustawiam te parametry po glfwInit a przed glfwOpenWindow.

Gdy używam gDebugger z tym kodem to nagle się okazuje coś takiego:

Cytuj
OpenGL Render Context 1 Created
Checking for memory leaks - Context 1 deleted
No memory leaks were found

OpenGL Render Context 1 Deleted
Debug String: Detected error: The debugged process asked for an extension function pointer (wglGetPixelFormatAttribivARB) from one render context, but called this function pointer in another render context (context #0)

Debug String: Detected error: The debugged process asked for an extension function pointer (wglCreateContextAttribsARB) from one render context, but called this function pointer in another render context (context #0)

OpenGL Render Context 2 Created

Dlaczego coś takiego się dzieje? Jak kiedyś ogarniałem GLFW z tutoriala to właśnie też takie rzeczy mi się działy, więc pozbyłem się tej części kodu i działało git (ok, wiem, że nie jest to może dobra praktyka no ale działało :D )

10
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 09, 2013, 14:24:41 »
W takim razie proszę, aby ktoś wyjaśnił mi co to jest profil compatibility i jak mam tego użyć aby móc korzystać z VA :)

11
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 08, 2013, 23:11:52 »
gDebugger pokazuje, że wywołanie dla danych testowych wyglądających tak:

float temp[] =
{
0.0f,0.0f,0.0f,
0.0f,1.0f,0.0f,
1.0f,1.0f,0.0f
};

Wygląda tak:
Cytuj
glVertexPointer(3 , GL_FLOAT , 0 , 0x001EFD34)

W kodzie używam jeszcze glBindBuffer ale po każdym drawCallu zwykle odłączam go za pomocą
glBindBuffer(GL_ARRAY_BUFFER, 0)

EDIT: @UP wytłumacz mi proszę co i jak bo nie rozumiem, co mam zrobić :)

12
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 08, 2013, 21:45:45 »
Napisałem już sobie to i owo do renderowania GUI za pomocą vertex array. Całą resztę chcę rysować z VBO (tzn modele etc).
Pojawił się pewien problem, gdy wywołuje glVertexPointer() aby narysować coś z vertex array to nic się nie rysuje a gDebugger wyrzuca błąd

Cytuj
OpenGL Error: glVertexPointer - GL_INVALID_OPERATION

Do tego komentarz:

Cytuj
The specified operation is not allowed in the current state. The offending function is ignored, having no side effect other than to set the error flag.

Nie znalazłem takiego błędu w dokumentacji.

Wydaje mi się, że wywołuje go prawidłowo, czyli:

glVertexPointer(3, GL_FLOAT, 0, &vArray[0]);

Co to znaczy?


EDIT: Jeszcze dodaje całość funkcji rysującej:

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(vArray->getVertexSize(), GL_FLOAT, 0, &vArray[0]);

//glDrawArrays(GL_TRIANGLES,0, vArray->getSize());

glDisableClientState(GL_VERTEX_ARRAY);

Gdzie vArray to obiekt klasy opakowującej zwykłą tablicę dynamiczną, którą chciałem móc łatwo rozszerzać etc. Oczywiście operator[] jest przeciążony tak aby zwracał to co trzeba.

13
Szkółka / Odp: [opengl] Vertex Buffer update
« dnia: Czerwiec 08, 2013, 12:17:02 »
Czyli z tego co rozumiem, to dobrym pomysłem będzie rezerwowanie np powiedzmy miejsca na 100 wierzchołków. W kodzie robię np jeden button w pozycji powiedzmy (0.5,0.5,0) i go wrzucam do tego sporego VBO. Reszta to śmieci. Robięc drawCall rysuje tylko na przedziale gdzie znajdują się normalne dane, i gdy dodam kolejny button wrzucam go z odpowiednią transformacją no i przesunięty tak aby w VBO znajdował się za tymi pierwszymi danymi.

Takie coś jest ok?

14
OpenGL / Odp: Zarządzanie geometrią z wykorzystaniem VAO+VBO
« dnia: Maj 31, 2013, 01:02:41 »
Gdy już wypełnisz VBO możesz podpiąć shader w CG, GLSL czy czym tam wolisz i za pomocą tak napisanego programu działać bezpośrednio na pojedynczych wertexach w ramach pipeline. Możesz na przykład wczytać mesh do VBO a później tylko dokonywać jego transformacji za pomocą shadera. Trzymać możesz macierz modelu, jakieś kwaterniony etc.

15
OpenGL / Odp: Zarządzanie geometrią z wykorzystaniem VAO+VBO
« dnia: Maj 31, 2013, 00:39:58 »
Możesz sobie wczytać mesh loaderem własnym bądź pakietem w stylu assimp http://assimp.sourceforge.net/

Ładujesz to do stl vector jak Ci pasuje. Wypełniając VBO danymi możesz tam wpuścić to co masz w vectorze spokojnie. Wtedy twoje glBufferData wygląda tak przykładowo:

Cytuj
std::vector<glm::vec4> temp;

glBufferData(GL_ARRAY_BUFFER, temp.size() * sizeof(glm::vec4), &temp[0], GL_STATIC_DRAW);

Strony: [1] 2 3