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

Strony: [1] 2 3 4 5 ... 13
1
OpenGL / Odp: [OpenGL] TV noise - animacja
« dnia: Wrzesień 06, 2017, 21:56:50 »
Cytuj
Jednak jako, że jestem przeciwnikiem losowości w grach, proponuję zamiast tego ustawić ręcznie paręnaście wzorów (kolejności wyświetlania), a następnie wyświetlać je kolejno.
Kurcze. Czuję delikatnie sarkazm :D Powoli zaczynam sie gubić kiedy żartujesz, a kiedy serio :P

2
Grafika 3D / Odp: Teksturowanie dużych modeli
« dnia: Sierpień 22, 2017, 18:23:07 »
Grafiti to raczej decal dać, dobra jakoś, dosyć tanie i łatwo to zrobić ;)

3
Grafika 3D / Odp: Teksturowanie dużych modeli
« dnia: Sierpień 22, 2017, 08:59:39 »
Wielkość tekstury nie ma większego wplywu na wydajność, bardziej na pamięć (tej telefony nie maja za wiele) i czas wczytywania. Tekstury może nie są wrzucane co klatke, ale ma to spory narzut, chociażby z tego względu, że OpenGL nie pozwala na wielowątkowość przy kontakcie z GPU (chyba ze mapowanie). Nie ma sensu testowanie wydajności patdzac na FPS bo jeżeli coś innego jest wąskim gardłem to nie zobaczysz różnicy. Mip mapping to zarazem optymalizacja i poprawa jakości :D
Tak baaardzo sporadycznie to nie powiedziałbym. W UE widac doczytywanie sie wyższych poziomów podchodząc do obiektu (i wyobraź sobie że masz 50 tekstur 4k, co krok coś doczytuje) :D Poza tym czasy ładowania gry z teksturami 4k są dlugie, na telefonach okropne. Gdzies tam jako ciekawostke bodajże o Uncharted 4 podawali że poza postaciami nic nie ma tam tekstur wkększych niż 1k.
A na większe obiekty nawet i 4k dalej daje średnią jakość. Lepiej już dac więcej wierzchołków niż powiększać tekstury. No chyba, że gra składa się z pięciu domków. Bo do0óki masz duże rezerwy pamięci to da zobie rade.

4
Grafika 3D / Odp: Teksturowanie dużych modeli
« dnia: Sierpień 21, 2017, 20:55:02 »
@up
W życiu nie widziałem gorszej odpowiedzi :D Chyba nie słyszałeś o czymś takim jak "optymalizacja" :D Normalnie skalowanie załatwia za nas grafika bo mamy mip mapping, UE jedynie robi tak ze jak nie widzisz tekstury o najwyższej rozdzielczości to wyrzuca z karty najwyższy poziom. Ale trzeba pomysleć o tym że wrzucanie takich danych też zabiera czas.
Na budynkach zazwyczaj tekstury się powtarzają. I to nawet często. Po prostu stara sie to zakryć elementami otoczenia, mieszaniem kilku tekstur, np. z wykorzystaniem splat tekstury, albo korzysta się z kolorów wierzchołków, itd.

5
OpenGL / Odp: Deffered shading - różne metody oświetlenia / materiały
« dnia: Sierpień 14, 2017, 01:18:38 »
Zależy co chcesz osiągnąć. Naprawdę potrzeba Ci wielu typów oświetlenia? Z mojego doświadczenia wystarcza ich naprawde mało.

6
Poszukuję / Odp: Poszukuję grafika do gry karcianej (płatne zlecenie)
« dnia: Sierpień 10, 2017, 23:36:43 »
W szachach tez nie powinno być tur, tylko gracze powinni wykonywac ruch jednocześnie. Byłoby bardziej fair :D

7
OpenGL / Odp: QuadTree/LOD przy renderowaniu terenu
« dnia: Lipiec 23, 2017, 15:56:53 »
hmmm... nie rozumiem co masz na myśli i w czym widzisz problem. Więc od początku, wszystkie chunki mają identyczną wielkość (np. 32x32m), i możesz myśleć o nich jak o chunkach trzymanych w gridzie. LOD zmienia się na podstawie odległości od kamery (a przynajmniej większość tak robi). Chunki blisko Ciebie są bardzo szczegółowe, a im sa dalej, tym gorzej wyglądają (ale nie widać tego częśto ze względu na odległość). Skoro w zalężności od odległości od kamery, to bez zbędnego sprawdzania czegokolwiek wiesz który LOD ma dany chunk, i jaką permutację należy mu wybrać (bo wynika to z jego relatywnej pozycji względem kamery). Oczywiście można różnie to zakodzić, najprościej jest tak żeby LOD zmieniał się w zależności od odległości po składowej, czyli sprawdzam czy która składowa relatywnej pozycji jest większa i po tej ustawiam LOD. Albo który to jest chunk od głównego (ten na którym się znajdujesz), i wtedy wystarczy "przesuwać" permutacje. Nie wiem czy dobrze wytłumaczyłem.

8
OpenGL / Odp: QuadTree/LOD przy renderowaniu terenu
« dnia: Lipiec 23, 2017, 09:37:02 »
10 wierzchołków dla chunka terenu to strasznie mało, sugerowałbym stworzyć chunki 32x32 (33x33 wierzcholki). Jeżeli dalej chcsz wykorzystywać triangle fan, albo triangle strip to można wykorzystać glPrimitiveRestartIndex i zbudować taki chunk z kilku pasków.
Sposobów na pozbycie się dziór jest całkiem sporo. Najprostszy (i najgorszy chyba) to jest po prostu zrobienie dodatkowej obwódki dla każdego chunka która byłaby przesunięta mocno w dół (co powodowałoby zakrycie przerw). Inny sposób to to co opisane jest w pdf-ie który podlinkowałeś. Albo stworzyć permutacje dla boków dopasowanych do niższego poziomu szczegółowości, albo te do wyższego (co wydaje się lepsze, ze względu na mniejszą ilość permutacji). W tej metodzie wiesz z góry którą permutację wybrać. pierwszy chunk jest pełny, nastepnie obok Ciebie 8 chunków to 8 kolejnych permutacji. Dalej mamy 2 LOD a nastepnie permutacje 2 LOD.
Jest jeszcze kolejna metoda, seamless lod. Na podstawie kamery zbliżasz ustawienie wierzchołków 1LOD do wierzchołków 2LOD, a kiedy osiągniesz taki chunk wyglądający w pełni jak 2LOD to zaczynasz wyświetlać faktycznie drugie LOD.

9
Szkółka / Odp: [SDL2] SDL2_gfx instalacja
« dnia: Lipiec 15, 2017, 18:42:55 »
Z SDL.h krzyczy pewnie dlatego, że potrzebuje SDLa żeby być zbudowana. A to jak budowac to zależy od tego na jakim systemie kompilujesz, no i jeżeli windows to czy Visual, czy MinGW. Bez błędów, które Ci wyrzuca także ciężko wróżyć co jest nie tak.

10
Szkółka / Odp: [SDL2] SDL2_gfx instalacja
« dnia: Lipiec 15, 2017, 10:21:23 »
hvghv

11
Projekty zaawansowane / Odp: [Tic-80] 3 seconds Climber
« dnia: Lipiec 13, 2017, 19:27:29 »
Zmotywowałeś mnie do pokonania rekordu :D 19s i obraną przeze mnie drogą wszystko prawie jest idealnie wykonane na taki czas.

Przydałoby się naliczanie milisekundowe i poziomy różne :D

12
Projekty zaawansowane / Odp: [Tic-80] 3 seconds Climber
« dnia: Lipiec 13, 2017, 17:32:54 »
W 3s chyba nie da rady :D Mi zajęło 31s :D Ciekawy pomysł :)
Trochę nie do końca dobrze działają te 3s wspinaczki.

EDIT:
25s, chyba niżej to max. 1s mógłbym zejść :D Trzeba speed runerów co bugi znajdą odpowiednie :D

EDIT2:
21s :D
Po kilkunastu zginieciach znika jeden bloczek na mapie i da się poza mape wyskoczyć. (a nawet na nią wejść)
Da się "latać" po suficie.

13
OpenGL / Odp: Problem z oświetleniem lamberta
« dnia: Lipiec 12, 2017, 21:32:24 »
Assimp chyba od dłuższego czasu stoi w miejscu, więc raczej nie bedzie nowej wersji :D Ja używałem assimpa na MinGW.

14
Narzędzia / Odp: Inkscape
« dnia: Lipiec 11, 2017, 14:29:30 »
No no, nie tak szybko. Da się narysować sporo sensownego pixel artu za pomocą myszki.
No no. Da się rysować sporo sensownego pixel artu telefonem, tym bardziej takim niedotykowym.

15
Językoznawstwo / Odp: Rust
« dnia: Lipiec 07, 2017, 08:29:59 »
Ciężko mówić o jakimś języku "konkurencja dla C++", bo C/C++ jest najlepszy tylko w pewnym zakresie oprogramowania. Są różne języki pod różne zastosowania. Chyba że chodzi Ci o następce C++ w jego najlepszych "terytoriach" :D
Rust ponoć jest szybki, i naprawdę bezpieczny, do tego ma sporo bajerów. Chyba najbardziej brakuje teraz w C++ wygody, język jest szybki, ale w wielu miejscach przestarzały (chociaż trzeba przyznać, że nie jest on podstawą do generowania najlepszego asma, są różne inne podejścia co do działania wielu rzeczy).
Ja jeszcze kojarze Dlang (bo sam w nim teraz kodze), i też jest niejako konkurencją dla C++ w jego zastosowaniach (chociaż póki co małą, jeżeli chodzi o zainteresowanie programistów, ale z roku na rok wiekszą). D ma dużo rzeczy których brakuje w C++, ale mimo podobieństw (bardzo podobna składnia) w niektórych sprawach ma inne podejscie. Ogromnym plusem są niesamowicie rozbudowane i proste template-y, szybkosc kompilacji, importy (to akurat tylko wygoda), slices, ranges itd. W każdym razie, w większosci zapewnia to szybsze programowanie (bez utraty wydajności), mniej błędów (język lepiej wykrywa i informuje o błędach aplikacji), większe bezpieczeństwo.
Rust ma wiele rzeczy podobnych do D, ma całkiem inną składnie co może być dla niektórych problemem, ale ponoć też jest bardzo szybki i w wielu rzeczach lepszy niż C++, chociaz sam osobiście go nie używałem to nie mogę o tym zapewnić. Ale w pewnym gronie ludzi i w pewnych zastosowaniach może być używany pomyślnie zamiast C++.

Strony: [1] 2 3 4 5 ... 13