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 - Krzysiek K.

Strony: 1 ... 3 4 5 6 [7] 8 9 10 11 ... 865
91
Cytuj
Czy sa jakies przydatne wzorce do gamedevu (oprócz Singletona)? Jak powinna wygladac struktura klas silnika i ich zależności?
Zdecyduj się, czy mówimy o gamedevie, czy o silnik-devie. Bo jak zaczniesz pisać silnik, w szczególności z podejściem by kod wyglądał, a nie tylko działał, to praktyka pokazuje że gry już raczej nie napiszesz. :)

92
Cykliczne Warsztatowe Compo / Odp: "Zrozumieć programowanie" - compo!
« dnia: Listopad 04, 2015, 10:30:49 »
Cytuj
Zdajemy sobie sprawę że rasteryzacja na liczbach całkowitych rządzi się swoimi prawami wobec czego nasze testy będą uwzględniały dopuszczalną (nie)dokładność.
Rasteryzacja czego? Może za dużo swego czasu się bawiłem na OI i ACM, ale mi to wygląda jak typowe zadanie na miotłę i z dodatkiem wektorów na liczbach całkowitych wyznaczenie oświetlenia wygląda że można zrobić o O(1) względem liczby pikseli.


Co do określenia całego zadania widzę tu jeszcze jedno ważne pytanie:
- czy piksel zasłania sam siebie? (tj. czy wszystkie blokujące piksele mają być nieoświetlone, czy zewnętrzna warstwa pikseli jednak ma być oświetlona?)

93
Projektowanie kodu / Odp: Brak pamięci statycznie alokowanej
« dnia: Listopad 02, 2015, 01:44:36 »
Cytuj
Wyobraźmy sobie teraz, że dostajemy do zaimplementowania pewną nową funkcjonalność. Akurat tak się składa, że wymaga ona głównie dublowania potrzebnej pamięci statycznej (jeżeli mamy tablicę stu elementową pewnych struktur danych, zmieniamy ją na tablicę dwustu elementową). Wszystko idzie spoko, do czasu, gdy okazuje się, że ta pamięć się nam skończyła (za dużo pamięci statycznej nam jest potrzebne).

Czy macie może jakieś podpowiedzi / uwagi jak sobie z tym problemem poradzić?
Podzielić, co jest potrzebne w którym momencie w zależności np. od trybu pracy i zapakować w struktury, po czym zapakować wszystko w unię. Ewentualnie, jeżeli chcemy mieć to nieco bardziej po ludzku, zarezerwować całą zamienialną pamięć w jednej tablicy, a resztę globalnych deklarować w stylu "MyStruct &foo = *(MyStruct*)&MEM[FOO_OFFSET];". Tak czy inaczej można w ten sposób uzyskać dowolny statyczny podział pamięci z reusowaniem czego się chce.

Cytuj
Czy może ulegać fragmentacji, przez co tracę dużo pamięci?
Co najwyżej przez alignment danych, przez co wiele nie stracisz.

Cytuj
3. Zdaję sobie sprawę, że ułożenie parametrów w strukturach ma znaczenie ponieważ występuje wyrównywanie parametrów (tak zwany padding) - co zresztą można kontrolować poleceniami do kompilatora - ale generalnie to chyba za mała "strata" żeby tutaj jakoś bardzo walczyć.
Zależy ile tych struktur potem będzie. Jeżeli w strukturze siedzi bajt z intem, to 3/8 pamięci to padding i taką samą proporcję nieużytków będzie miała też dowolnego rozmiaru tablica tych struktur.

94
Dźwięk / Odp: Plugin VST - Budowa, propozycje
« dnia: Listopad 01, 2015, 18:31:06 »
Cytuj
@Krzysiek K: Ciekawy artykuł, właśnie o coś takiego mniej więcej mi chodziło. Spróbuję też pokombinować, jak mówisz ADSR na Mooga.
ADSR do filtrów to podstawa. A na dobrą sprawę sam Decay, bo najczęściej po prostu filtrem się jedzie w ten czy inny sposób o pewną wartość w dół (jadąc w górę brzmi jak kaczka). Oczywiście jeśli chcesz robić dubstepy, to to nie wystarczy.

Cytuj
1) pokombinować z samym szumem, tak filtrować go i "tentegować" żeby uzyskać jakieś ciekawe brzmienia.
Żeby w ogóle uzyskać konkretny ton to musisz go mocno przefiltrować, a wtedy ci wyjdzie najczęściej po prostu gwizd, bo zostanie tylko ton podstawowy z szumem w pewnym paśmie i zero harmonicznych. Można by próbować składać N filtrów by dodać te harmoniczne, ale tym sposobem wyjdzie brzmienie raczej organowe, bo harmonicznych będzie za mało (chyba że zrobisz naprawdę naprawdę dużo filtrów). Można by coś pomyśleć tu o filtrach grzebieniowych, ale one przepuszczają bardzo dużo pomiędzy pasmami i najprawdopodobniej wyjdzie więcej szumu niż tonu. Podsumowując - można się pobawić, ale nie wiązał bym z tym wielkich nadziei.

Cytuj
3) pokombinować z "customizowalną" tablicą routingową.
Myślę, że to najszybciej dało by wymierne efekty.

95
Dźwięk / Odp: Plugin VST - Budowa, propozycje
« dnia: Listopad 01, 2015, 17:08:32 »
Cytuj
Znacie może jakieś przykłady schematów połączeń typowych syntezatorów VST? Albo jakiś tutorial (tylko nie podstawowy a bardziej advanced / na wyższym poziomie abstrakcji)?
Typowy właśnie zrobiłeś. :) Brakuje Ci tylko dodatkowego ADSR na Cutoff od Mooga.

Za to na poziomie advanced, sporo informacji można znaleźć w necie. Przykładowo, artykuł o Massive, ale nie sądzę, byśmy w życiu wszystkie takie featury zakodowali.

Z rzeczy bardziej przyziemnych i fixed całkiem fajnie sprawdził mi się układ w moim syntezatorze do 4k. Próbki możliwości:
- https://www.youtube.com/watch?v=wIxgGYtgCbA
- https://www.youtube.com/watch?v=mhJy705g9Vk
- https://www.youtube.com/watch?v=RAMdZhQXMWc

Tutaj pojedynczy instrument to do 4 niezależnych oscylatorów z których każdy ma do wyboru szum, sinusa i piłę oraz parametry Volume, Transpose, Detune, Cutoff i Resonance (filtr typu bandpass regulowany przez Resonance od całkowitego all-passa do wąskiego peak potrafiącego zrobić gwizd z szumu). Każdy z pięciu parametrów ma własną niezależną dwupunktową envelopkę (start/nachylenie/koniec) i własny LFO (sinus o regulowanej szybkości i amplitudzie).

Całość ostatecznie wygląda tak: link


Cytuj
Chodzi mi o już wyższy poziom abstrakcji, nie na poziomie sygnału, ale na poziomie połączeń poszczególnych bloków - czyli jak połaczyć ze sobą LFO, Filtry (jakie np.?), Oscylatory, VCA, Apregiator, efekty, jak można coś ciekawego uzyskać, żeby miało to ciekawy zestaw brzmień.
Ja zacząłem niedawno coś tam dłubać przy nowym syntezatorze i zdecydowałem się na pełną swobodę połączeń (interfejs w stylu Massive). Mając na stałe połączone modulacje może być ciężko Ci uzyskać niektóre efekty.

A arpeggiator sobie daruj, podobnie jak echo i reverb w samej wtyczce, chyba że chcesz ją sprzedawać - to są efekty które włączają w presetach chyba wyłącznie po to, żeby się zareklamować brzmieniem, a które zawsze trzeba po zmianie presetu ręcznie wyłączać (może poza delay/reverb jeśli akurat potrzebujesz, nie żal ci CPU, a reverb jest naprawdę porządny). :)

96
Audio / Odp: Program do tworzenia muzyki
« dnia: Październik 29, 2015, 15:29:38 »
Od siebie mogę także polecić FL Studio. O ile wiem, to SoS też go używa. Program płatny, ale też jest to jedyny komercyjny DAW, który ma opcję dożywotnich aktualizacji (inne DAWy każą sobie płacić co wersję). Można też ściągnąć demo i męczyć do skutku, bo o ile nie pozwala zapisywać, to nie ma limitu czasowego.

97
Design / Odp: brainboosterowy crack - RPG logiczne
« dnia: Październik 22, 2015, 22:21:13 »
Cytuj
Krzysiek K., ok, pogoogluje za Ciebie żeby Ci wyjaśnić jaki błąd popełniłeś..
Wiem jaki popełniłem - za słabo zaznaczyłem że sobie tylko żartuję. :)
Portal 1/2 jest na tyle dobry, że taki wynik absolutnie mnie nie dziwi.

98
Design / Odp: brainboosterowy crack - RPG logiczne
« dnia: Październik 22, 2015, 21:39:49 »
Cytuj
Zajmuje pierwsze miejsce w rankingu Steam, co chyba mówi samo za siebie
[rzut okiem jaka firma stworzyła Portal (2)]
[rzut okiem jaka firma stworzyła Steam]

... tak, mówi samo za siebie. ;)

99
Screen byśmy poprosili.

100
OpenGL / Odp: Renderowanie wielu okien i rwanie klatek
« dnia: Październik 16, 2015, 15:23:34 »
Cytuj
co myślisz o optymalizacji ilości wywołań wglMakeCurrent? Wg. mnie sama zmiana HDC jest narzutem używania tej funkcji wiele razy przy jednym obrocie pętli.
Myślę że trzeba by podejść do problemu bardziej kompleksowo i poszukać jakiegoś artykułu opisującego jak takie rzeczy powinno się robić w OpenGL.

Cytuj
Krzysiek K. masz jakieś pomysły co może rwać okna? wg. mnie pierwszy raz słyszałem o takim podejściu żeby renderować na jednym procesie kilka okien z osobnymi HWND, czyli również HDC.
To jest akurat standardowe podejście - już w samym WinAPI masz wspólną pętlę i kolejkę komunikatów dla wszystkich okien aplikacji.

EDIT: A co do rwania, to rwać pięknie potrafią właśnie wątki. Swego czasu napisałem kawałek kodu który w jednym wątku renderował (OpenGL ES), a w drugim generował dane w tle. Trzeba się było mocno namęczyć z liczeniem delty, bo proces potrafił siedzieć trzy pełne klatki w wątku generującym, a potem natychmiast przełączyć się na wątek renderujący by z marszu trzy klatki wyrenderować (a dokładniej, zbuforować polecenia GPU). Efekt - było to 60 FPS, ale co z tego, skoro 2 na 3 delty wychodziły zero i animacja wyglądała jakby miała 20 FPS. :)

101
OpenGL / Odp: Renderowanie wielu okien i rwanie klatek
« dnia: Październik 16, 2015, 12:14:16 »
Cytuj
Przeczytaj cały akapit - "Jeśli Twój target nie obsługuje 3+- ok, jesteś rozgrzeszony". Dalsza część tego konkternego akapitu skupia się na tym drugim przypadku.
Chodziło mi o to, że VBO i shadery były dostępne nawet na kartach które nawet nie obsługiwały OpenGL 2.0 (po części dlatego, że specyfikacji OpenGL 2.0 jeszcze nie było).

102
OpenGL / Odp: Renderowanie wielu okien i rwanie klatek
« dnia: Październik 15, 2015, 21:04:09 »
Cytuj
Używając trybu bezpośredniego (glBegin/glEnd/...) zajeżdżasz kartę graficzną
A skąd wniosek że używa? Ja z VBO i shaderów korzystałem w OpenGL 1.1 (przez rozszerzenia), a samo VBO weszło do core chyba gdzieś w okolicach OpenGL 1.4 lub 1.5.

103
OpenGL / Odp: Renderowanie wielu okien i rwanie klatek
« dnia: Październik 15, 2015, 14:01:05 »
To jest chyba bolączka kart graficznych, że mają problem z rysowaniem na kilku osobnych oknach jednocześnie. Może lepiej zrobić jedno okno + kilka viewportów albo zmienić kartę graficzną coś na w stylu Quadro;)
Bolączka? Przecież narysowanie do konkretnego okna to tylko kopiowanie quada z jednego obszaru do drugiego.

Przykładowo:
- w DirectX 9 - metoda Present (wołana na koniec renderowania klatki) pozwala wybrać do jakiego okna (nawet tylko fragmentu) ma być skopiowany obraz,
- w DirectX 10+ - dla każdego okna tworzy się osobny swap chain (bufor) i renderuje się niezależnie

W OpenGL akurat nie powiem jak to można wydajnie rozwiązać, bo używam głównie OpenGL ES.

Jeśli działa za wolno, to najprawdopodobniej problem jest w niewłaściwym użyciu API.

104
OpenGL / Odp: Rewolucja pomiędzy OpenGL 2 / 3
« dnia: Październik 06, 2015, 21:54:19 »
Cytuj
A grafiki 3D niech uczą Ci, którzy są autorami publikacji na SIGGRAPH.
Ci u których "real time" zaczyna się od 1 FPS? ;)

Cytuj
Ale Krzysiek, sam sobie odpowiedz: po co robić Ponga w nowych technologiach?
To jest właśnie esencja pytania retorycznego, które zadaję w poprzednim poście.
I nie tylko Ponga, ale praktycznie każdą grę którą jest w stanie zespół indie napisać.


A co do samych releasów kolejnych wersji OpenGL (nie dotyczy ES), to myślę że oczekiwania i efekt najlepiej obrazuje poniższy filmik. ;)
https://www.youtube.com/watch?v=7O4V7JfeTSU

105
OpenGL / Odp: Rewolucja pomiędzy OpenGL 2 / 3
« dnia: Październik 06, 2015, 13:34:24 »
Cytuj
Nie "na oczko starszym API" tylko API ktore jest totalnie inne w zalozeniach.
Ile by w tym prawdy nie było, nie przejdzie to jako odpowiedź na pytanie zwykłego usera "dlaczego pong nie działa na moim rocznym laptopie"?

Ja w swoim nieco starszym mam combo Intel SandyBridge + Radeon 6770M (o ile dobrze pamiętam) i pod DirectX 11 nawet wynalazki typu teselacja i compute shadery śmigają aż miło, więc czemu ja i inni podobni użytkownicy mieli by cierpieć za to że Intel & AMD & HP wspólnie się lenią i nie wypuścili chyba żadnej aktualizacji driverów grafiki od 3 lat.

Moim zdaniem jeśli chcesz iść w wynalazki typu DX12/Mantle/Vulcan/itp, to tylko gdy:
- piszesz silnik/grę AAA gdzie rzeczywiście pokażesz że to coś daje,
- kodujesz prodkę demoscenową gdzie działać ona musi tylko na compomaszynie i youtube
- ew. piszesz jakiś tutorial/inne demo

Oczywiście jest to moja opinia na tą chwilę. Jak API się upowszechnią i spopularyzują na tyle, że kompatybilny sprzęt będzie można kupić w Biedronce, to zdanie oczywiście się zmieni.

Strony: 1 ... 3 4 5 6 [7] 8 9 10 11 ... 865