Biblioteka graficzna w C, prosta, szybka, przenośna Opcje

[Kokocky]

C dopiero się uczę bazując na tym co umiem z PHP i JS. Szuka jakiejś szybkiej i przenośnej biblioteki do wyświetlania grafiki, cały obraz będzie przetwarzany wcześniej więc potrzebna będzie mi tylko opcja pomalowania piksela o podanym x i y jakimś kolorem. Bawiłem się biblioteką allegro, jednak samo pomalowanie piksel po pikselu ekranu 1280 na 1024 trwało ~2s, a gdzie tu jeszcze obliczyć jakieś akcje w 3d.
Macie jakieś propozycje?

[l0ud]

Jeżeli chodzi o biblioteki ze wsparciem sprzętowym to poza Allegro istnieje SFML (oparte na OpenGL) - dobrze napisany program będzie działał na Windowsie, Linuxie i Macu. Bardzo dobre na początek
Istnieje jeszcze bardzo popularne SDL które jest typowo software'owe, ale za to ma porty na niemalże wszystko (urządzenia przenośne, konsole etc).

Myślę że problem nie wynika jednak ze słabej wydajności biblioteki, a ze złego podejścia pisania kodu. Rysowanie piksel po pikselu to tragiczna wydajnościowo metoda. Może napisz co chciałbyś osiągnąć?

[Kokocky]

Ogólnie to piszę silnik, renderowania modelu 3D do obrazu 2D. Zdaje sobie sprawę, że można użyć np. wspomnianego openGL, ale ja wolałbym napisać coś własnego od podstaw. Mam mniej więcej rozplanowane jak miało by przeliczać wraz z oświetleniem, ale bez odbitego światłą. Przed wyświetleniem mam juz przygotowany cały obraz w postaci dwuwymiarowej tablicy. Może dało by się jakoś zapisać do zmiennej tablicę jako obraz i potem wyświetlić jako grafikę.
Ogólnie to całość bazuje na moich pomysłach, po prostu lubię stworzyć coś z niczego.

[Mephistofeles]

Nikt normalny nie pisze bibliotek, bo wolałby mieć własne OpenGL ;/.

[Crozin]

@Mephistofeles: to raczej wygląda jak projekt 4fun, a nie normalne przedsięwzięcie. Chyba że się mylę... wtedy wykorzystanie gotowych bibliotek jest jedynym sensownym rozwiązaniem.

[Mephistofeles]

Pewnie tak, ale nawet dla zabawy imho nie warto się przejmować takimi rzeczami i lepiej jest zająć się innymi aspektami.

Ten post edytował Mephistofeles 22.11.2010, 22:08:48

[kryzz]

Może CUDA od NVIDI Ciebie zainteresuje ?

Ten post edytował kryzz 22.11.2010, 22:21:15

[Mephistofeles]

A CUDA nie służy przypadkiem do obliczeń GPGPU?

[l0ud]

Trzeba było z góry napisać że piszesz software'owy raytracer i nie wiesz jak wyświetlić wynik.

Pierwszy z tym pomysłem nie byłeś : http://www.gamedev.pl/search.php?q=raytracer&where=all

W skrócie musisz znaleźć funkcję umożliwiającą wrzucenie tablicy pikseli do jakiejś bitmapy/tekstury którą później wyświetlisz na całym ekranie.

W SFML2 jest taka szybka funkcja, sf::Image::UpdatePixels (wspomniane na forum: http://www.sfml-dev.org/forum/viewtopic.php?t=1772 ) jednak SFML2 jest wciąż wersją rozwojową tej biblioteki i musiałbyś skompilować ją samemu (co takie straszne nie jest, ale w połączeniu z brakiem konkretnej dokumentacji dla prawdopodobnie dla Ciebie byłoby za trudne)

Nie wierzę, że nie ma takiej funkcji w allegro
Zapytaj na forum.gamedev.pl , tam ludzie zajmują się takimi rzeczami

Ten post edytował l0ud 22.11.2010, 23:08:42

[Theqos]

Trzeba było z góry napisać że piszesz software'owy raytracer i nie wiesz jak wyświetlić wynik.

Raczej rasterizer http://www.youtube.com/watch?v=2vNrdQe3xx0

Pisałem coś takiego i pod SDL śmigało, zacznij od podstaw http://www.lazyfoo.net/SDL_tutorials/ a potem to już czysta matma

[l0ud]

Raczej rasterizer

To już zależy w jak sposób chce to wszystko generować W każdym razie fakt, że output obrazu to najprostsza rzecz ze wszystkiego, a całość pewnie i tak nie będzie miała zabójczej wydajności.

[kryzz]

A CUDA nie służy przypadkiem do obliczeń GPGPU?

http://pl.wikipedia.org/wiki/CUDA_%28informatyka%29
W dużym skrócie, CUDA służy do przerzucenia obliczeń na GPU. Przykładowo Photoshop od wersji CS4(na bank w 5) wykorzystuje CUDA http://www.nvidia.pl/object/adobe_photoshop_pl.html
btw można znaleźć plugin(lub kod w C) do GIMP'a aby wykorzystywał technologie CUDA, ale nie jestem pewien na 100%

[Mephistofeles]

Ja wiem do czego służy CUDA, ale CUDA wyświetlania grafiki nie przyspieszy (a przynajmniej nie do tego służy), od tego są inne narzędzia, w końcu karta graficzna nie bez powodu jest nazywana graficzną, a takie obliczenia to nowość.
W Photoshopie jest wykorzystywane pewnie do przetwarzania obrazu, a nie do jego wyświetlania, od tego jest OpenGL (w PS).

[kryzz]

Jak nie przyśpieszy ?
CUDA jest obsługiwana od GeForce 8400 GS w górę i jest już od dwóch lat, więc nie przesadzajmy że to taka nowość.
GeForce 8800 GTX posiada 128 niezależnych procesorów strumieniowych po 1.35 GHz każdy, więcej daje nam to obróbkę 10 240 pikseli na procesor, a nie jak w przypadku zwykłego CPU, który musi obrobić 1 310 720 pikseli. Teoretycznie w tym przypadku stworzenie tekstury piksel po pikselu wyniesie ~31ms

[Mephistofeles]

Jemu chodzi o samo rysowanie gotowej tekstury na ekranie, nie o jej przygotowanie.

[Zyx]

Wykorzystywanie Nvidia CUDA obecnego w karcie graficznej do sprzętowego przyspieszenia programowo zaimplementowanych operacji graficznych. A myślałem, że nic mnie już dziś nie zdziwi. Znasz przysłowie "Nie ucz ojca dzieci robić"? To ja to sparafrazuję: "Nie ucz karty graficznej grafiki renderować".

Kokocky -> właśnie dlatego tego typu operacje są wbudowane w karty graficzne. Czysty programowy renderer nigdy nie osiągnie Ci choćby ułamka wydajności oferowanej przez normalną kartę graficzną oraz biblioteki, które potrafią korzystać z jej zasobów. Ponadto wyobrażam sobie, jak to zaimplementowałeś:

Kod

for i := 1 to width do
   for j := 1 to height do
     putpixel(i, j, kolor);

Tymczasem jak już naprawdę chcesz, by procesor Ci wypełnił określony obszar pamięci jednolitą zawartością, to od tego masz taką fajną funkcję memset(), albo jeszcze lepiej - taką fajną instrukcję procesora.


Ten post edytował Zyx 23.11.2010, 18:33:02

[kryzz]

Zyx > to było do mnie ?
Pisałem o obróbce pikseli i stworzeniu z tego tekstury, nie o wyświetleniu.

Rzuciłem tylko pomysł, nie zmuszam autora do skorzystania z tego

[Theqos]

Wykorzystywanie Nvidia CUDA obecnego w karcie graficznej do sprzętowego przyspieszenia programowo zaimplementowanych operacji graficznych. A myślałem, że nic mnie już dziś nie zdziwi. Znasz przysłowie "Nie ucz ojca dzieci robić"? To ja to sparafrazuję: "Nie ucz karty graficznej grafiki renderować".

Ale to nie jest nic dziwnego. Sprzętowa implementacja ma to do tego, że jest mało elastyczna. No i zależna od sprzętu Czyli mamy rożne "cuda" zależne od tego czy jest to karta ATI, Nvidii czy Intela. To trochę jak ze sprzętowym dekodowaniem video, działa super wydajnie o ile obsługuje nasz format. Po coś w końcu to CPU wymyślono. Dlatego w nowych kartach graficznych coraz więcej jest programowalnych układów. Powoli można na nich uruchamiać raytracing w czasie rzeczywistym.

Już nie wspomnę, że wiele można się dzięki temu nauczyć

[Zyx]

Theqos -> matko, wiem, że w kartach graficznych są różne shadery, które da się programować, ale tu nie rozmawiamy o shaderach, tylko o uczeniu karty graficznej wyświetlania grafiki OD ZERA (czyli: co to jest wierzchołek, co to jest piksel, itd.) przy pomocy Nvidia CUDA, takiej technologii...

[kryzz]

Theqos -> matko, wiem, że w kartach graficznych są różne shadery, które da się programować, ale tu nie rozmawiamy o shaderach, tylko o uczeniu karty graficznej wyświetlania grafiki OD ZERA (czyli: co to jest wierzchołek, co to jest piksel, itd.) przy pomocy Nvidia CUDA, takiej technologii...

Ty rozmawiasz o uczeniu karty graficznej wyświetlania grafiki od zera przy pomocy CUDA.
Ja pisałem o wykorzystaniu CUDA do bezpośredniej obróbki pikseli w pamięci karty graficznej, czyli do czego ta architektura została stworzona.