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

Strony: [1] 2 3 4 5 ... 73
1
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 22:50:00 »
Skoro się zgadzamy, to czemu kilka postów wcześniej najeżdżałeś na korzystających z silnika?
Bo bardzo często te silniki są chyba źle używane i wychodzą z tego koszmarnie niezoptymalizowane produkcje. Jak widzę dopisek "Unity" od razu włącza mi się kontrolka - uwaga to może być crap. Niestety bardzo dużo jest takich gier "wyklikanych w Unity", robionych właściwie bez programisty.

Z komercyjnego punktu widzenia silników trzeba używać. Ale w celach hobbystycznych czy do małych projektów to nie zawsze. Czasem silnik to wielka wada wpływające negatywnie na samą grę.

2
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 22:46:55 »
No nie żeby coś, ale jak ktoś nie potrafi nawet własnego silnika napisać, to żaden programista :)
To najwyżej twórca gier w tworach takich jak Unity, czy tam inne gotowe silniki.
Ja traktuję takie Unity jak bardzo dobrą, skomplikowaną i złożoną aplikację z tekstowo-skryptowym interfejsem użytkownika. :)

Generalnie w komercyjnych, dużych projektach powinno się używać silnika, bo to jest jedyne logiczne rozwiązanie. Ale w małych projektach to już nie jestem tego taki pewien. Zbyt często widziałem projekty, które były strasznie nieoptymalne (pod względem prędkości i objętości), bo były pisanie z użyciem tych przerośniętych tworów. W małych, prostych projektach własny silnik potrafi rozjechać Unity na placek. :)
Kiedyś (w okolicach iPhona 4S/5) na innym forum ktoś pokazał swojego Tetrisa z klockami 3D. Był całkiem ładny ale zdziwił mnie dopisem, że wymagany jest iPhone 4. Zapytałem dlaczego to niby nie miałoby chodzić na wcześniejszych modelach iPhona: 3GS, 3G, a nawet 2G. Przecież nawet pierwszy model iPhona z 2008 roku przy renderowaniu takiej grafiki i takich obliczeniach nudziłby się i wyszłoby na pewno 30 FPS. No i dostałem wytłumaczenie, że to jest w Unity, a to ma swoje narzuty. Ufffff... Kilkadziesiąt sześcianów, proste warunki i wymagana tak potężna maszyna (nawet dzisiaj) jak iPhone 4. Śmieszne... Od tamtej pory zacząłem zwracać uwagę na produkcje korzystające z Unity. Prawie zawsze niosą za sobą większe wymagania. To koszt uniwersalności czy ten silnik to taki straszny crap? :)

3
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 22:37:37 »
Bzdura. Silnik poza szybkością osiągnięcia efektu i jakością osiągniętego efektu nijak się ma do zwiększenia stanu konta. Kiedy możliwości techniczne nie stanowią problemu, najważniejszy jest design i marketing produktu.
Oczywiście, że ma to wpływ na stan konta. Chyba jest różnica w sfinansowaniu gry bez silnika i sfinansowaniu gry z silnikiem. Stworzenie silnika kosztuje kuuuuupę czasu (więc i pieniędzy). Tam gdzie chodzi tylko kasę dzisiaj chyba nikt nie pozwoli sobie na klepanie silnika od podstaw.

4
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 21:19:44 »
Unity pozwala na zrobienie własnej fizyki, czy podsilnika voxelowego. I lepiej od tej strony ugryźć temat, niż robić własny silnik.
Chyba, że kogoś bawi robienie własnego silnika. Trudno komukolwiek zabraniać się bawić. :) Silniki są dla dzieci i dla zawodowców. Dzieci nie ogarniają takich tematów i silnik pozwala im cokolwiek zrobić. Natomiast celem zawodowców jest jak najszybsze skonwertowanie czasu/wysiłku/pomysłu na coś do zwiększa stan konta. I tu też silnik bardzo pomaga. :)

5
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 14:59:29 »
Ech, no cóż. Poczytaj o rzeczach takich jak octrees, podział na chunki, regeneracja chunków, ich meshing.. to wygląda mi na typowo voxelową grę, więc te rzeczy powinny się sprawdzić.
Myślisz, że dzisiejszy programista aplikacji (także dla urządzeń mobilnych) zawraca sobie takimi rzeczami głowę? :) Dzisiaj robi się tak:
LoadObject();
DrawObject();
i pchamy na AppStore czy GooglePlay, bo przecież dzisiaj wszystko jest tak szybkie, że takimi prymitywnymi zaganieniami nie ma się co przejmować. ;)

6
Bardzo możliwe, że tak będzie. Na szczęście ja tego już nie dożyje (Ty może tak). :)

7
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 10:27:05 »
Pytanie, czy fizykę 3D tylu sześcianów da się rozsądnie zoptymalizować ;) Przy tylu obiektach dobrze by było też sprawdzić rozdzielczość tekstur. Na sam kod wielkiego wpływu raczej nie ma, większość rzeczy robi tu silnik.
No tak, zewnętrzne silniki... Programista jest przy nich niepełnosprawny. Co za czasy...
Ale nawet jeżeli używa się cudzych rozwiązań to trzeba zbadać ich możliwości i dopasować pomysł i realizację do tych możliwości. Też mógłbym sobie założyć, że tu będzie 20 milionów złożonych obiektów i potem rozłożyć ręce, że nie jestem w stanie tego przyspieszyć, bo przecież taka ilość musi zarżnąć procesor czy kartę graficzną. Dla mnie to żadne tłumaczenie. Programowanie to nie tylko pisanie "ifów" mechaniki i logiki. Nawet w czasach gdy w kieszeniach mamy maszyny wielokrotnie szybsze od tych na których renderowano filmy "Toy Story" czy "Terminator 2". :)

8
Projekty zaawansowane / Odp: Drunk Tower
« dnia: Wczoraj o 10:07:36 »
To tak wolno działa podczas grania (na jakimś przeciętym urządzeniu z Androidem) czy tylko film ma tak mało klatek? Jeżeli tak wolno działa to polecam pobadać miejsca, które zjadają najwięcej procesora i trochę zoptymalizować kod, bo taka prędkość raczej nie zachęca do grania. A jeżeli to tylko film to warto zrobić lepszy, bo taka prędkość do ściągnięcia gry też nie zachęca.

9
Nie wydaje mi sie zeby sterowanie za pomocą oczu było komfortowe.
Zgadzam się. Po 10 minutach takiego wysilania gałek ocznych po pobiegłbym do szafy, wyciągnął choćby najstarszą mysz kulkową, podłączył i odetchnął z ulgą. :)

10
Projekty rozpoczęte / Odp: Symulacja Systemu Operacyjnego [Allegro5]
« dnia: Czerwiec 23, 2017, 00:09:31 »
A ja stworzyłem przeglądarkowy system operacyjny (CSS3, JS)...
https://cdn.pbrd.co/images/gh7vxacE.png
Fiu fiu.. No pięknie. Gratulacje! Nie ma tu już wpływów Gatesa ale za to Jobs dosłownie wylewa się z ekranu. ;)

11
Projekty rozpoczęte / Odp: Symulacja Systemu Operacyjnego [Allegro5]
« dnia: Czerwiec 23, 2017, 00:05:38 »
Jeżeli to działa sprawnie, szybko, stabilnie i ma zrobione jakieś sensowne API to szacun wielki. Doskonale zdaję sobie sprawę z tego jak ogromna jest to robota.

A tak zupełnie na marginesie - jesteś "wychowankiem" Windowsa? :) Tacy ludzie nie wyobrażają sobie, że UI systemu może wyglądać i być zorganizowany inaczej niż to pokazano wiele lat temu w Windows95. Gdybym ja poświęcił tak ogromną ilość pracy, wysiłku, czasu na zrobienie czegoś takiego to na pewno starałbym się zrealizować jakiś swój pomysł na UI systemu operacyjnego. Jest okazja żeby pokazać coś nowego, świeżego niż ten oklepany pomysł Gatesa. :)

12
Dźwięk / Odp: Synchronizacja efektow z muzyka
« dnia: Czerwiec 22, 2017, 23:43:36 »
Odświeżam wątek. Jest jeszcze kwestia wyświetlania efektów z jednakowym tempem na szybszych i wolniejszych komputerach. Aby to uzyskać można w jakiś sposób wykorzystać dane muzyki: czas trwania, tempo czy lepiej oprzeć to na pomiarach czasu za pomocą GetTickCount() i wyliczać współczynnik?
Muzyka odtwarza się zawsze w tym samym tempie. Jeżeli demo będzie działało też w stałym tempie niezależne od maszyny to wszystko będzie zsynchronizowane.

Wszystko co w demie zmienia się w czasie musi być przemnożone przez czas jaki upłynął od ostatniej aktualizacji.

Zamiast:
posX += speedrób coś  w stylu:
posX += (speed * deltaTime)
Ta deltaTime to jest czas jaki upłynął od ostatniego przeliczania sceny:
deltaTime = currentTick - lastTick
Generalnie ja bym unikał "pobierania" czasu w różnych miejscach programu. Robiłbym to w jedym miejscu i wyliczoną deltę podawał dalej do całego silnika. Wtedy w jedym miejscu masz władzę nad całym czasem upływającym w produkcji. Jeżeli to jest gra to podając deltaTime==0 robisz idealną pauzę. Zatrzymuje się absolutnie wszystko, z particlami włącznie. :) Tylko trzeba być konsekwentym i wszędzie używać tej jednej obliczonej wartości deltaTime - żadnych wyjątków. :)

13
Dźwięk / Odp: Synchronizacja efektow z muzyka
« dnia: Czerwiec 22, 2017, 23:37:17 »
Ja jeżeli coś takiego robię to przyjmuję założenie, że produkcja ma działać nawet z wyłączoną muzyką. Wobec tego żadne pobieranie danych z muzyki nie wchodzi w grę. Zrobiłem sobie jakiś tam timer do którego wrzucam "punkty" zawierające czas wystąpienia, klasę/metodę listenera (który zostanie wywołany gdy czas osiągnie ten punkt) i jakiś tag do dokładniejszej identyfikacji tego punktu (często ta sama metoda jest podana jako listener wielu punktów i trzeba te punkty jakoś rozróżnić). Dodatkowo tak wywołany listener w parametrze ma informację o tym jak bardzo dokładnie został wywołany. Zdarza się, że zostanie wywołany np. 35 millisekund za późno. Mając taką informację mogę w listenerze mogę wziąć tę informację pod uwagę, np. startując scenkę nie od pozycji 0 tylko 35 millisekund. To są detale ale nie zasnąłbym gdybym wiedział, że gdzieś tam się to odrobinę może rozjeżdżać (tak, to jest psychiczne:)).

Wszystko o czym tu piszę jest tylko i wyłącznie moją radosną twórczością. Żadnych bibliotek, wspomagaczy, ułatwiaczy. Bardzo proste C++ bez problemu kompilujące się pod: MorphOS, AmigaOS4, iOS, macOS, Windows, Linux, Android. Takie mam założenie. :) Chociaż to, że jest proste, nie oznacza, że zostało to szybko napisane. Wręcz przeciwnie - klepię to już 11 lat (tak, cierpliwość jest jedną z nielicznych moich mocnych stron). :D

14
OpenGL / Odp: Biblioteki openGL 1.1 a nowsze czy to istotne ?
« dnia: Czerwiec 22, 2017, 19:09:22 »
Mam za sobą właśnie demko na Amigę, uczę się ostro m68k (swoją drogą, najebiście przemyślana ta 32-bitowa architektura, w odróżnieniu od x86) i zamierzam jeszcze głębiej iść w programowanie Amigi, bo mi się to strasznie spodobało.
Skoro tak się w to wkręciłeś o olej tego archaicznego peceta i weź się za OpenGL na AmigaOS4, MorphOS, AROS albo ewentualnie AmigaOS3. :) Produkcje na tego pre-peceta nikomu nie są potrzebne, a środowisko amigowe będzie wniebowzięte gdy cokolwiek nowego powstanie. :)
  • AmigaOS4 - od niedawna jest pierwsza wersja OpenGL ES z shaderami ale działa tylko na baaaardzo drogiej AmidzeONE (PowerPC). Na tańszych modelach jest MiniGL.
  • MorphOS - standardowo w systemie jest TinyGL, a to jest mniej więcej odpowiednik OpenGL 1.4 i działa bardzo zgrabnie na starych Makach z PowerPC (do kupienia za grosze) albo Pegasosie G3/G4.
  • AROS - tu jest trochę nowocześniej i działa to na nielicznych intelowych PC. Problem w tym, że AROSa właściwie nikt nie używa pomimo tego, że jest darmowy.
  • AmigaOS3 - tu zabawa w OpenGL (StormMESA, MiniGL) ma sens tylko gdy do Amigi Classic ma się dołożoną kartę turbo z PowerPC i kartę graficzną z 3D (Permedia2, Voodoo 3, 4, 5) - koszt bardzo wysoki i trzeba nieźle się orientować żeby taką maszynę doprowadzić do względnego działania

Ja ostatnio zrobiłem dla MorphOSa coś takiego:
https://www.youtube.com/watch?v=taY6Y2dp9vY
Było to wystawiane na party Decrunch 2017 we Wrocławiu i ścigając się z czasem musiałem wystawić wersję alpha. W tej chwili staram się posklejać wersję finalną. Tu widać jakieś porównanie:
http://encore.ppa.pl/morphoza_progress/

15
Grafika 3D / Odp: Blender i światła w vertex colors
« dnia: Maj 13, 2017, 17:44:17 »
Działa! O to mi właśnie chodziło. Nigdy w życiu bym się do tej opcji nie dokopał. Zupełnie nie interesuje mnie rendowanie w Blenderze i do zakładki "Render" nigdy nie zaglądam.
Dzięki za pomoc!

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