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

Strony: [1] 2 3 4 5 ... 86
1
OpenGL / Odp: GLSL, Vertex Shader, in struct
« dnia: Marzec 31, 2016, 18:56:46 »
A Interface Blocków używać (jako wejścia vertex shadera) nie mogę, bo standard nie pozwala, w tym właśnie problem d;
Nie zauważyłem, że mowa o VS.

Ale szczegółów ani źródła historii nie kojarzę, pamiętam, że ktoś coś takiego pisał właśnie tu na Warsztacie, więc można traktować jako plotę albo poszukać samemu. :P
Ja do dziś pamiętam, jak przechodziłem z Cg na GLSL i gdzieś mi została funkcja mul i szukałem dlaczego na AMD mi się wywala, bo przy przepisywaniu nie zwróciłem uwagi, że mul jest w Cg/HLSL, ale w GLSL jest po prostu operator *. Nvidia po prostu w sterownikach używa kompilatora Cg, który obsługuje i GLSL i Cg (za pomocą Cg Toolkit też możesz kompilować GLSL do asm z tego co pamiętam).

2
OpenGL / Odp: GLSL, Vertex Shader, in struct
« dnia: Marzec 30, 2016, 23:58:59 »
Używaj glslangValidator to będziesz miał mniej tego typu problemów https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/

PS. zamiast struktury użyj Interface Block https://www.opengl.org/wiki/Interface_Block_%28GLSL%29

3
Szkółka / Odp: Directx vs OPenGL - Które wybrać??
« dnia: Wrzesień 07, 2014, 00:06:53 »
Każde API ma swoje zalety (przykładowo OpenGL z MultiDrawIndirect (możesz generować co ma być rysowane... w compute shaderze na GPU itp), Sparse Buffers, Bindless Textures (AMD i Nvidia) itp). DirectX ma trochę mniejsze możliwości, ale za to ma kompilator shaderów (w OpenGL kompilator jest w shaderze i nie wiesz jak zoptymalizuje i czy nie ma jakiegoś bug'a) i lepszą jakość sterowników (chociaż i w OpenGL mocno się poprawiło).
Jednak jeśli chcesz wybrać API na przyszłość to żadne z nich. Obecnie oba przechodzą mocną przebudowę (Dx12 i OpenGL Next) i niewiele pozostanie z tego co jest teraz. Jeśli myślisz o przyszłości (w perspektywie ponad rok) to bliższe nadchodzącym API są AMD Mantle (AMD zaoferowało Khronos, żeby brało z API do OpenGL Next co chcą) czy Apple Metal.

A są tacy co nie mają styczności z windowsem ?
Więcej niż myślisz ;p

Dodam że ucze się też programować dla unreal engine 4.2 i tam też korzystają z directX 11 lub 10
UE4 na innych platformach używa też OpenGL 4.x.

4
Produkcja / Odp: Steam Greenlight a podatki
« dnia: Sierpień 02, 2014, 12:59:49 »
W USA go nei ma ale na steam jest napisane że ceny zawierają ten podatek.
W USA też jest (tzn. jest podatek obrotowy... czyli prawie to samo). Różnica jest taka, że w USA masz podawane ceny netto (dopiero przy kasie masz do zapłacenia więcej niż na metce - uproszczenie, bo każdy stan może mieć inną stawkę podatkową), a w europie masz cenę podaną brutto (z wliczonym podatkiem) i płacisz przy kasie tyle co widziałeś na półce. Fakturę vat nie wystawiasz za każdy egzemplarz - to nie ty sprzedajesz, a Steam (oni też sprzedają "na paragon", a nie fakturę).

PS. możesz się zorientować czy czasami dochodowy nie możesz sobie obniżyć jako właściciel praw autorskich i twórca (50% kosztów uzyskania jak muzycy, aktorzy, kabareciarze, malarze...).

5
Tworzenie silników / Odp: Silnik z DirectX i OpenGL
« dnia: Kwiecień 17, 2014, 21:58:17 »
Niestety nie ma domyślnie w OpenGL ES 2.0.
Tak, jest dopiero od OpenGL ES 3.1 (jako rozszerzenie w nowych PowerVR, Intelach i Tegra4)... jednak zdaje się w temacie mowa o OpenGL, a nie OpenGL ES?

6
Tworzenie silników / Odp: Silnik z DirectX i OpenGL
« dnia: Kwiecień 16, 2014, 20:49:21 »
Przykładowo w OpenGL przed użyciem musisz Vertex Shader i Fragment Shader zlinkować w Program. W DirectX 10 VS i PS możesz swobodnie wymieniać kiedy chcesz, ale za to Input Layout musi być dopasowany do Vertex Shadera (czego z kolei nie ma w OpenGL).
O ile z sensem posta się zgadzam, to raczej kiepski przykład. Separate Shader Objects jest w OpenGL 4.1, ale jako rozszerzenie jest praktycznie wszędzie czyli od GeForce 8k, Radeon HD2k i Intel HD Graphics (przynajmniej od Sandy Bridge), więc tu akurat nie byłoby wielkiego problemu ;p.

7
OpenGL / Odp: OpenGL 4 - nie obsługująca karta graficzna.
« dnia: Grudzień 09, 2013, 06:47:22 »
@up: Jeśli martwić się o stare sterowniki to HD4k mają OpenGL 2.1 pod Catalyst 8.8, bo są to karty starsze niż OpenGL 3.0

8
OpenGL / Odp: OpenGL 4 - nie obsługująca karta graficzna.
« dnia: Grudzień 08, 2013, 06:33:45 »
ATI to natomiast inna bajka, seria HD 48xx wspiera OpenGL ~3.2 i DirectX ~10 może 10.1
Radeon HD48xx (czyli R700) wspiera OpenGL 3.3 (tak jak i HD2k i HD3k) i trochę nowszych rozszerzeń.
http://www.g-truc.net/doc/OpenGL%20matrix%202013-11.pdf

9
Dźwięk / Odp: OpenAL prawie zastrzelone przez Creative - Alternatywy?
« dnia: Listopad 27, 2013, 20:35:22 »
Jeżeli chodzi o żyjące pozostałości po OpenAL to OpenAL Soft się nasuwa (http://kcat.strangesoft.net/openal.html), który będąc implementacją stricte softwarową, pamiętając czasy hardwarowego odtwarzania dźwięku (Sound Blasterów, itp.), raczej kojarzy się z krokiem wstecz.
Microsoft z Windowsem Vista zdaje się zabronił sterownikom hardwareowego przetwarzania dźwięku (jedynie trickami był dostępny, tylko z OpenAL, tylko przy komercyjnym Rapture3D OpenAL z tego co pamiętam) i dźwięk w DirectX też jest stricte softwareowy, jak i w każdej innej wspomnianej bibliotece, dlatego możesz spokojnie użyć OpenAL Soft, a jeśli będziesz chciał wykorzystać sprzęt to kupisz licencje Rapture3D.

10
Szkółka / Odp: [OpenGL ES] Shader, nie działa
« dnia: Luty 24, 2013, 23:48:16 »
@Rokuzo: Nie wiem jakie to GPU i jak się zachowuje dlatego zwróciłem uwagę na to (nie pamiętam w specyfikacji czegoś w stylu ochrony tego typu rozbieżności i czy aby nie będzie tak, że .x z drugiego wierzchołka nie stanie się .w pierwszego).

@flexi: Bardziej gDebugger i OpenGL ES (androida tu nie mieszaj, bo to sprawa typowo z błędami w kodzie OpenGL ES, więc można testować to pod PC). Jeśli nie to możesz użyć w zależności od posiadanego sprzętu Nvidia PerfHUD ES/Nsight Tegra, Adreno Profiler, narzędzia z PowerVR SDK czy od ARM dla Mali.

PS. to nie jest na 100% problem NDK, czy OpenGL ES - do testowania używam urządzeń z Tegrą, Mali, PowerVR SGX i Adreno i nigdzie nie spodlałem się z takim zachowaniem. Jedyne co w shaderach błędne wypomniałem, reszta wygląda ok, więc błąd zapewne w kodzie tworzenia bufforów, przekazywania atrybutów, rysowania... jednak wróżkami tu nie jesteśmy.

Wina nie musi leżeć w samym kodzie shadera. GLSL w wersji ES 2.0 jest bardziej czuły/niewybaczający różnych uproszczeń, skrótów. Przy np. PC->Android zdarza się kilka rzeczy poprawiać.
Nie zawsze (zależy od implementacji) znalazłem kilka konstrukcji w shaderach, które działały na Tegrach, a nie powinny (w specyfikacji takie działania były zabronione, przez co na przykładowo Adreno shader zachowywał się zupełnie inaczej).

11
Szkółka / Odp: [OpenGL ES] Shader, nie działa
« dnia: Luty 24, 2013, 17:15:22 »
...
attribute vec4 vertex;
attribute vec2 texcoord;
...
Texcoordy wysyłam tak samo, jak vertexy tylko zamiast floaty po 3 pakować to pakuje po 2.
To dlaczego w shaderze chcesz brać po 4 float na vertexy? Zmień vec4 na vec3. OFC wtedy
gl_Position = p_matrix * mv_matrix * vec4(vertex, 1.0);

12
Platformy mobilne / Odp: SDK a NDK dla Androida
« dnia: Grudzień 18, 2012, 09:02:34 »
@up: jest to jednak spora wiekszosc, która moze i dzis jest mniej istotna na rozwinietych platformach, ale kilka lat temu byla to grupa docelowa bo nikt powazny nie interesowal sie malymi nowymi platformami, ktore nie musialy wcale osiagnac sukcesu.

13
Platformy mobilne / Odp: SDK a NDK dla Androida
« dnia: Grudzień 17, 2012, 19:28:35 »
O tym że programiści języka N-poziomowego jak zwykle uważają programistów języka (N+1)-poziomowego za "niedzielnych". No bo w końcu jak to tak.. w C? Bez asemblera? :P
Zupełnie nie - nie rozmawiamy o programistach języka X (bo tu bym się zupełnie nie zgodził) tylko programistach na platformę X i nie wszystkich, ale sporej większości.

14
Platformy mobilne / Odp: SDK a NDK dla Androida
« dnia: Grudzień 17, 2012, 14:42:05 »
Platformy zarabiają na 1% najpopularniejszych aplikacji, których developerów stać na dobrych programistów. No i iOS nie ma GC, chociaż zarządzanie pamięcią jest w nim dużo łatwiejsze niż w C++.
Tak, jednak w ObjC na iOS masz Automatic Reference Counting, czyli i tak spore ułatwienie dla niedzielnych względem C/C++.

15
Platformy mobilne / Odp: SDK a NDK dla Androida
« dnia: Grudzień 17, 2012, 14:10:47 »
Czemu właściciel platformy miałby w ogóle brać pod uwagę niedzielnych programistów dla których problemem jest crashowanie i zarządzanie pamięcią? :)
Bo aplikacji takich programistów w mobilnych sklepach jest ponad 90% i wszystkie by się wywalały ;p (i dlatego też biblioteki GUI dla PC jak QT mają własne GC, bo nie wierzą swoim użytkownikom).

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