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 - Pan Hania

Strony: [1] 2 3 4 5
1
Szkółka / Odp: GL_POINTS wyświetlane jako kwadraty
« dnia: Sierpień 06, 2016, 00:27:07 »
Gdybys tak zrobil to bys mial slideshow a nie Real Time graphics. Takie rozwiazanie jest kompletnie niewydajne, tworzysz iles warstw tlumaczacych abstrakcje API ktore nie maja nic wspolnego z GPU. Jednoczesnie enkapsulujesz te calle starego API translatorem wiec nie da sie zrobic z nimi niczego bezposrednio pod dany HW. OpenGL na Vulkanie mozna "napisac raz" ale bedzie to droga przez meke z milionem hakow, a na koncu i tak okaze sie ze milion gier zle uzywa OpenGL "bo na NV dziala" i trzeba bedzie dodac kolejne miliony "fixow" pod nie.

Okej, okej, powiedzmy że udało Ci się mnie przekonać że jednak nie powinienem w najbliższym czasie aplikować do nVidii na stanowisko programisty sterowników.

Choć zastanowiłbym się czy na pewno zależy nam na żyłowaniu wydajności dla starych API. W końcu robimy to tylko po to żeby nadal mieć wsparcie dla starego kodu (jest jakieś eleganckie polskie tłumaczenie dla legacy code?), więc dzisiejsze karty graficzne, które w końcu są o kilka rzędów szybsze, powinny im sprostać nawet pomimo kilku warstw pośredniczących. Dodatkowo, znacząca różnica w wydajności byłaby też subtelną zachętą dla osób takich jak OP z tego wątku aby nie korzystać ze starego API.

A żeby nie ciągnąć tematu w nieskończoność to sobie sam odpowiem: nie, nie możemy sobie na to pozwolić bo wtedy przychodzi AMD ze swoimi mniej eleganckimi ale szybszymi sterownikami i śmieją się że u nich Quake 3 chodzi w 900 FPS a u nas tylko w 300.

2
Szkółka / Odp: GL_POINTS wyświetlane jako kwadraty
« dnia: Sierpień 05, 2016, 01:49:35 »
Dlatego szczerze polecam nawet nie udzielać odpowiedzi na pytania dotyczace deprecated API. To jedyny sposób żeby zmusić ludzi do nauczenia się właściwego korzystania z biblioteki. Jeżeli ktoś już musi samemu pisać w OpenGL zamiast używać jakiegoś frameworka, to oczekuje od niego aby poświęcił czas i używał go właściwie albo wcale. To nie jest personalny przytyk - po prostu szanujmy swoj czas na wzajem, promujmy poprawne wzorce.

Ech, a moim zdaniem lepsze od nieudzielania odpowiedzi byłoby pokazanie przykładu na zasadzie "zobacz jakie to jest proste do zrobienia przy użyciu nowego API". Bez zachęty początkującym ciężko się przebić przez to rysowanie pierwszego trójkąta - no bo przecież jakim cudem ten nowy OpenGL jest niby taki fajny skoro zamiast napisać 4 linijki trzeba się nagimnastykować i poznać działanie kilkunastu (jak nie więcej) dziwnych wywołań oraz ogarniać dodatkowy język? My wiemy że ten klif na który trzeba się wspiąć jest tylko jeden a jak już się jest na górze to wszędzie płaska równina, ale z dołu tego nie widać.

I dlatego reszta wywodu niestety nie jest prawdziwa. To nie jest robota "na raz", to są osobo-miesiące implementacji wstępnej a potem utrzymanie. HW sie zmienia z kazda generacja kart, np. to co kiedys bylo Fixed Function teraz moze byc emulowane w shaderach, etc. W rezultacie wspieranie glBegin/glEnd i innych zaszlosci z czasów gdy renderowano jednokolorowe trójkąty jest ciągłą udręką a nie czyms cos sie zrobi raz i zapomni.

Ja to widzę tak (a jak wspominałem, zielonego pojęcia o tym nie mam więc dużo nie widzę): klepiemy sterownik tylko i wyłącznie do nowego API OpenGL oraz mamy warstwę tłumaczącą stare wywołania na nowego w razie czego (powiedzmy na OpenGL 3.2). Lata mijają, sprzęt się zmienia, trzeba dostosować sterownik ale warstwa tłumacząca się nawet o linijkę nie zmienia bo ani specyfikacja OpenGL 3.2 się nie zmieniła ani ta od starych OpenGLi, oczywiście po warunkiem że jest napisana w 100% zgodnie ze specyfikacją (w takim świcie niestety nie żyjemy, ale czy jest to aż tak bardzo nieosiągalne...?). Lata mijają, wychodzi Vulkan, od tego momentu piszemy sterownik tylko i wyłącznie do Vulkana, robimy warstwę tłumaczącą wywołania nowego OpenGL na Vulkan. Obsługę prastarego w tym momencie OpenGL mamy za darmo (poprzez złożenie dwóch tłumaczy).

W każdym razie Microsoft ma to swoje ANGLE i jakoś działa. Choć faktem jest że OpenGL ES 2.0 ma chyba najkrótszą specyfikacją ze wszystkich OpenGLi więc jego emulacja jest stosunkowo prosta.

To nie jest robota "na raz", bo za każdym razem ktoś wyciągnie jakąś aplikację np. z kategorii workstation (CADy), która MUSI działać, a np. w nieprawidłowy sposób używa API (bo "na nvidii działa").

To prawda. Ale tylko dowodzi że syf w sterowniku zawsze był i zawsze będzie, tego się nie da wyplewić i już. Więc jakbyście z tym nie walczyli to i tak nie wygracie bez względu na to czy uda wam się na tym forum kogokolwiek przekonać (czego mimo wszystko szczerze życzę!).

3
Szkółka / Odp: GL_POINTS wyświetlane jako kwadraty
« dnia: Sierpień 03, 2016, 15:41:52 »
Szansa ze bedzie ono ZLE obslugiwane przez sterowniki NV,AMD,Intela rosnie zamiast malec z kazdym ich updejtem. A rosnie dlatego ze to API z przed 25 lat i ciagle jego utrzymywanie w sterownikach jest coraz ciezsze. Sam fakt ze uzywasz glBegin swiadczy o tym ze prosisz sie zeby Twoj kod crashowal (sterownik musi ten szit buforowac samemu i emulowac wewnetrznie odpowiednikami VBO).

Nie mam zielonego pojęcia o tym w jaki sposób pisze się sterowniki do kart graficznych, ale chyba aż tak bym nie przesadzał - emulacja starych API OpenGL za pomocą wywołań z nowszych wersji wydaje się być czymś stosunkowo trywialnym, przynajmniej w porównaniu do złożoności tego sterownika "właściwego". Jeżeli goście z nVidii mają czas i chęci na optymalizacje poprzez wciskanie "ifów" pod kątem konkretnych gier, to nie widzę czemu taka warstwa tłumacząca miałaby być jakimkolwiek problemem. Szczególnie że jest to zadanie w zasięgu osoby nawet bardzo pobieżnie zaznajomionej z OpenGL (takiej jak ja). Jasne, pewnie trzeba pamiętać o bardzo wielu kruczkach w specyfikacji ale ogólnie to jest robota "na raz" i nie wiem czemu wsparcie by miało być gorsze z każdą aktualizacją.

4
Cytuj
MINIMUM:
Processor: i3 or faster
Memory: 4 GB RAM
Czemu gra która wygląda spokojnie jak coś co powinno ruszyć na przeciętnym PCecie 20 lat temu ma takie wymagania? Czy to narzut związany z Unity? Każda gra na tym silniku ma teraz taką koszmarną wydajność? Pamiętam że jeszcze jakieś 6 lat temu na moim, leciwym już wtedy, laptopie z Celeronem 1.6 GHz i 512MB RAMu na pokładzie, to pierwsze, proste trójwymierowe gierki robione przez amatorów w Unity śmigały aż miło.

5
Projekty rozpoczęte / Odp: Another Castle - prosty tower defense
« dnia: Lipiec 18, 2016, 22:04:33 »
Gra mi się zwiesiła - tzn. nie że się wysypała tylko doszło do pata i jednostki po prostu stoją gapiąc się na siebie:



Ach, a przyciski nieraz nie łapią mi kliknięcia, strasznie to irytujące.

6
Szkółka / Odp: Dziedziczenie wielokrotne w C++
« dnia: Lipiec 31, 2014, 16:38:02 »
Oprócz interfejsów używam wielodziedziczenia jeszcze do... hm, nie wiem jak to opisać tę kategorię klas. Różne takie przydatne klasy, które same w sobie są bez sensu ale można po nich dziedziczyć :)
Mixiny?

Dzięki za opinie. Przekonaliście mnie, że nie skończę w kryminale jak użyję dziedziczenia wielokrotnego. :)
Też kiedyś miałem mózg wyprany bezsensowną nienawiścią do wielodziedziczenia. Na szczęście się ogarnąłem i teraz nie potrafię bez tego żyć - to jest niezastąpione narzędzie (przynajmniej w języku takim jak C++) do unikania duplikacji kodu. A za jakąkolwiek duplikację kodu już kryminał jak najbardziej się należy.

7
Szkółka / Odp: O projektowaniu kodu
« dnia: Grudzień 21, 2013, 14:48:09 »
Zazwyczaj używam "!" ale fakt że jest ono dość wąskie i nie był bym aż tak krytyczny, z "-" jest o tyle łatwiej że po pierwsze jest to dość szeroki znak a po drugie zawsze można zrobić "a - b" i tak ciasno nie pisać, nie wiem czy da się zrobić coś takiego z !.  A nawet jak by się dało to dość dziwnie by to wyglądało. "! isObject".

Dlatego też dla osób którym jest zbyt "wąsko" albo nie przepadają za "znaczkowatą" naturą języka jest takie coś. U siebie dla rozróżnienia stosuję te aliasy do operacji logicznych (not, or, and) a symbole do operacji bitowych.

8
Myślałeś też o trochę grubszym API, które np. eliminowałoby część canvasowego boilerplate'u + dodawało czytelności? (...)
Ja bym tutaj proponował podejście używane przez jCanvas czyli ustawianie parametrów przy pomocy obiektów (haszy, JSONów czy jakkolwiek się na to w JavaScripcie mówi). Używałem tego jakiś czas temu i bardzo przyjemne, założenia w sumie dosyć podobne do Twojej biblioteki.

9
C++ / Odp: Zapodaj Ficzer
« dnia: Wrzesień 16, 2012, 17:34:50 »
Nie przesadzajcie tak z tą wydajnością. Większość czasu i tak się siedzi gapiąc na kod i szukając błędu niż go klepiąc więc mi takie ciekawostki się podobają. Skoro już mam się wściekać na kawałek tekstu że coś tam nie działa to niech przynajmniej ładnie wygląda i w jakiś sposób umila mi ten czas :D A kwestia ładności to już faktycznie sprawa czysto subiektywna.

10
C++ / Odp: Zapodaj Ficzer
« dnia: Wrzesień 15, 2012, 16:00:40 »
(Mi w językach brakuje unikodowych keywordów: jak w pythonie jest keyword lambda, to dlaczego nie mogę zamiast niego napisać λ?)

Te nowsze albo fajniejsze języki już powoli wprowadzają te rzeczy, np. takie cuda w Haskellu albo operator strzałki w Scali który to jest po prostu synonimem dla zrobienia pary. Chyba tylko po to aby inicjalizacja albo aktualizacja map ładniej wygląda. Ogólnie w Scali jest o tyle spoko, że operator to po prostu metoda a metoda może mieć unikodowe znaki, więc wszystkie chwyty dozwolone. Niby takie pierdoły dość niewygodne w pisaniu ale kod ładniej wygląda i super rzecz do robienia DSLi :D

11
Allegro / Odp: Strzelanie pociskami, jak?
« dnia: Lipiec 17, 2012, 13:20:28 »
myVec.resize(myVec.size() - 1);
Jak już tak optymalizujemy to nie lepiej użyć std::vector#pop_back()?

I chyba std::vector#back() zamiast std::vector#last() ;)

12
Szkółka / Odp: [Algorytmy] Wybór struktury
« dnia: Lipiec 10, 2012, 12:51:36 »
Znasz może jakieś dobre źródło z którego tą wiedzę mógłbym zaczerpnąć?
http://was.zaa.mimuw.edu.pl/?q=taxonomy/term/15
Ogólnie to polecam całą serię Wykładów z Algorytmiki Stosowanej, do wszystkich są nagrania wideo.

-edit-
Widzę że ten link wypluwa Google po wpisaniu frazy "drzewo przedziałowe". Serio nie dałeś rady sam tego wpisać?

13
Platformy mobilne / Odp: Nauka programowania
« dnia: Czerwiec 23, 2012, 13:39:58 »
Niestety za bardzo przypomina matematykę. :D Porównaj:
(...)
-- pipe taki jak w F#
(|>) = flip ($)
main = [1..10] |> map (*3) |> filter (<25) |> show |> putStr

- brak algebry typów; nie możesz napisać "funkcja przyjmuje obiekt implementujący interfejs X oraz Y"
Nigdy tego na razie nie potrzebowałem ale jak o tym teraz pomyślę to faktycznie brzmi jak bardzo pożądana funkcjonalność, aż dziw że tego nie ma.

- brak preconditions i postconditions (jak to jest po polsku?)
Wykładowca nazywał to prekondycjami i postkondycjami, co uważam za gwałt na języku. A przecież przedwarunek i powarunek brzmi tak swojsko.

Tak, to chwalone "operowanie na nieskończonych sekwencjach" to nie tylko fibonacci. :D
Oczywiście, nie zapominajmy o eratostenesie ;)

14
Platformy mobilne / Odp: Nauka programowania
« dnia: Czerwiec 23, 2012, 12:32:58 »
- Na bazie powyższego: Linq, do jasnej anielki! Nawet bez tego cukru składniowego, jako suche .Select(), .Where() itp. Jak comprehensions z funkcyjnych, tylko fajniejsze. (btw: pypy install pipe :))
Czy fajniejsze to bym się mocno kłócił, składnia wyrażeń listowych w Haskellu jest przepiękna <3

Z rzeczy, które wg mnie są skopane: interfejsy, ale ich jeszcze nie widziałem zrobionych dobrze :).
Co masz konkretnie na myśli mówiąc, że są "skopane"?

2) w czym się taki generator różni od range'a który zwraca kolejne elementy?
Z reguły to tego range napiszesz tak, że zwraca całą tablicę, którą potem iterujesz; generator robi to na bieżąco (jak w językach leniwych) więc jesteś do przodu z pamięcią.

15
Platformy mobilne / Odp: Nauka programowania
« dnia: Czerwiec 22, 2012, 20:16:11 »
wyrzuć VS, całą dokumentację i tony innych narzędzi i taki język nie będzie mógł konkurować z Pythonem, Ruby czy nawet D
Python i Ruby są fajne do bardzo szybkich prototypów i stron internetowych ale brak statycznego typowania jest niemiłosiernie irytujący. Z kolei D to już prawie C# tylko natywny, co kto lubi - osobiście preferuję maszyny wirtualne (w przypadku programowania gier to może być trochę głupie, ale nigdy nie celowałem w zaawansowane silniki 3D).

Strony: [1] 2 3 4 5