09.02.2021 12:53
[#1]
[C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
Cześć,
Czy jeśli koduje program, w którym tworze bufor "unsigned char", który będzie przechowywał
jakąś grafikę zapisaną jako RGBRGBRGB.. i każdy R,G,B (0-255)
to czy przy otwieraniu okna i screena mogę wybrać tylko te 24bpp?
Czy ekrany 16 bpp 32bpp też wyświetlą tą grafikę, czy musze dostosować kod do różnych trybów? Czy system sam to ogarnie?
Czy jeśli koduje program, w którym tworze bufor "unsigned char", który będzie przechowywał
jakąś grafikę zapisaną jako RGBRGBRGB.. i każdy R,G,B (0-255)
to czy przy otwieraniu okna i screena mogę wybrać tylko te 24bpp?
Czy ekrany 16 bpp 32bpp też wyświetlą tą grafikę, czy musze dostosować kod do różnych trybów? Czy system sam to ogarnie?
09.02.2021 13:15
[wyróżniony]
[#2]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
05.03.2021 23:43
[#3]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@michal_zukowski, post #2
Czy można rysować bezpośrednio po Bitmapie w pamięci?
Czy tylko wchodzi w grę używanie funkcji systemowych rysujących po Rastporcie
i WritePixelArray?
Bo jak użyłem P96 WritePixelArray żeby mi mój bufor wywaliło na ekran, to strasznie wolno
to szło :( Wrzucanie po jednym P96 WritePixel też raczej raczej odpada
Przy czym zaznaczam, że mówię o RTG, sprawdzam to na winuae, ale domyślnie
miałoby się odpalić na np. Vampierzu..
Najlepsze rozwiązanie dla mnie byłoby:
- mieć swoje dwa bufory (unsigned char) RGBA (4bajty)
- przy inicjalizacji dać na nie wskaźnik z strukturze Bitmap
(ale nie wiem jak wyglada struktura Bitmap dla RGBA, jest w niej tylko wskaźnik do starych Planes[8])
- w kodzie niezależnym od platformy uzupełniam sobie bufory
Ogólnie zależy mi na kawałku Amigowego kodu, który w możliwie najszybszy sposób wyświetli bufor na ekranie
w trybie double buffer.. bo generalnie skupiam się właśnie na wyrenderowaniu informacji do bufora, a potem chce tylko wyświetlić..
Mam:
- screen 320x256x24
- na nim pełne okno backdrop
- i jeszcze powiązane ze screen dwa ScreenBuffer do double bufferingu
Rutyna od NovaCodera, którą on stosuje w swoich portach:
http://eab.abime.net/showthread.php?p=783535
A tu dość obszerny wątek o grafice CGX i rożne propozycje double buffer w tym ten powyżej,
link
Czy tylko wchodzi w grę używanie funkcji systemowych rysujących po Rastporcie
i WritePixelArray?
Bo jak użyłem P96 WritePixelArray żeby mi mój bufor wywaliło na ekran, to strasznie wolno
to szło :( Wrzucanie po jednym P96 WritePixel też raczej raczej odpada
Przy czym zaznaczam, że mówię o RTG, sprawdzam to na winuae, ale domyślnie
miałoby się odpalić na np. Vampierzu..
Najlepsze rozwiązanie dla mnie byłoby:
- mieć swoje dwa bufory (unsigned char) RGBA (4bajty)
- przy inicjalizacji dać na nie wskaźnik z strukturze Bitmap
(ale nie wiem jak wyglada struktura Bitmap dla RGBA, jest w niej tylko wskaźnik do starych Planes[8])
- w kodzie niezależnym od platformy uzupełniam sobie bufory
Ogólnie zależy mi na kawałku Amigowego kodu, który w możliwie najszybszy sposób wyświetli bufor na ekranie
w trybie double buffer.. bo generalnie skupiam się właśnie na wyrenderowaniu informacji do bufora, a potem chce tylko wyświetlić..
Mam:
- screen 320x256x24
- na nim pełne okno backdrop
- i jeszcze powiązane ze screen dwa ScreenBuffer do double bufferingu
Rutyna od NovaCodera, którą on stosuje w swoich portach:
http://eab.abime.net/showthread.php?p=783535
A tu dość obszerny wątek o grafice CGX i rożne propozycje double buffer w tym ten powyżej,
link
06.03.2021 00:03
[#4]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #3
Nigdy nie wiesz jaki format ma ekran. Czy bigendian czy littleendian. Jaka jest głębia, jaki pixelformat. Do WPA() masz widzę RECTFMT_RAW wtedy masz najmniejszy narzut ale ekran musi byc zgodny z wrzucaną bitmapą. Możesz tez oczywiscie pobrac adres startowy ekranu i tam blitować, ale nie wiem ile jestes w stanie na tym ugrać. 68k po prostu może być za wolne na 24bity/pełny redraw w 25fpsów.
Ostatnia aktualizacja: 06.03.2021 00:03:38 przez michal_zukowski
Ostatnia aktualizacja: 06.03.2021 00:03:38 przez michal_zukowski
06.03.2021 00:09
[#6]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #5
Musiałby się kiero wypowiedzieć, ale dla RTG bitmapa/ekran może siedzieć/siedzi bezpośrednio w pamięci karty graficznej więc raczej lepiej narysować w buforze i kopiować. Natomiast ponad wszelką wątpliwość nie zaleca się odczytu pamięci z karty graficznej bo będzie zawsze wolno.
06.03.2021 00:12
[#7]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #5
Ja doradzę, że P96_WritePixelArray() rysuje z pamięci więc konieczny jest transfer do pamięci graficznej Amigi. Dlatego ta funkcja może nie być zawsze optymalna w działaniu.
Dużo lepiej jest przygotować sobie BitMapy w pamięci graficznej za pomocą AllocBitMap() i kopiować w jej obrębie - wtedy Blitter na karcie graficznej powinien zająć się kopiowaniem.
Podobnie masz w przypadku AGA. Jak dane są w formacie graficznym AGA w pamięci graficznej - wtedy wyświetlanie jest błyskawiczne bo dane są brane bezpośrednio z tej pamięci i wyświetlane lub - kopiowane z pomocą Blittera Amigi.
Funkcja AllocBitMap() ma parametr Friend BitMap, który ustaw na taką BitMapę, do której chcesz mieć najszybszy dostęp w procesie kopiowania.
Dużo lepiej jest przygotować sobie BitMapy w pamięci graficznej za pomocą AllocBitMap() i kopiować w jej obrębie - wtedy Blitter na karcie graficznej powinien zająć się kopiowaniem.
Podobnie masz w przypadku AGA. Jak dane są w formacie graficznym AGA w pamięci graficznej - wtedy wyświetlanie jest błyskawiczne bo dane są brane bezpośrednio z tej pamięci i wyświetlane lub - kopiowane z pomocą Blittera Amigi.
Funkcja AllocBitMap() ma parametr Friend BitMap, który ustaw na taką BitMapę, do której chcesz mieć najszybszy dostęp w procesie kopiowania.
06.03.2021 00:33
[#8]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@michal_zukowski, post #4
Wiadomo, że cudów z prędkością nie ma, natomiast nie da się ukryć, ze na Warpie czy Vampiorze nawet wymagające tytuły chodzą bardzo przyzwoicie, natomiast Gunnar od Vamira pokazywał mi jakieś demko co zrobli i przy 640x400x24 mieli 90fps
link
więc tam raczej nie ma wąskiego gardła jeśli chodzi o przepustowość..
link
więc tam raczej nie ma wąskiego gardła jeśli chodzi o przepustowość..
06.03.2021 00:37
[wyróżniony]
[#9]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #5
Jestes na dobrej drodze.
Najszybsze bedzie narysowanie ramki w pamieci fast, od razu w formacie takim jak ekran docelowy (mozesz to sprawdzic uzywajac GetCyberMapAttr(BitMap, CYBRMATTR_PIXFMT);)
Formatow jest kilkanascie, pewno kilka najpopularniejszych wystarczy obsluzyc.
Nastepnie kopiujesz swoja ramke do baseaddres.
A na koniec:
Jesli masz ekran, to to wlasciwie wystarczy (no chyba, ze chcesz miec doublebuffering), jesli rysujesz w okienku, najlepiej zaalokowac offscreenowa bitmape w taki samym formacie jak public screen na ktorym otwierasz okno a nastepnie zrobic BltBitMapRastPort - jesli bitmapy beda w tym samym formacie blt bedzie dosc szybki. Jesli dobrze pamietam to mozesz zaalokowac bitmape w fast mem, pod warunkiem ze nie bedziesz jej wyswietlal bezposrednio (ale moge sie mylic, 20 lat minelo).
Najszybsze bedzie narysowanie ramki w pamieci fast, od razu w formacie takim jak ekran docelowy (mozesz to sprawdzic uzywajac GetCyberMapAttr(BitMap, CYBRMATTR_PIXFMT);)
Formatow jest kilkanascie, pewno kilka najpopularniejszych wystarczy obsluzyc.
TAG_ITEM(tags[0],LBMI_BASEADDRESS,(LONG)&baseAddress); TAG_ITEM(tags[1],LBMI_PIXFMT,(LONG)&pixelformat); TAG_ITEM(tags[2],LBMI_BYTESPERROW,(LONG)&bytesPerLine); TAG_ITEM(tags[3],LBMI_BYTESPERPIX,(LONG)&bytesPerPixel); TAG_ITEM(tags[4],TAG_DONE,0); VOID *handle = LockBitMapTagList(bitmap,tags);
Nastepnie kopiujesz swoja ramke do baseaddres.
A na koniec:
if(Handle) UnLockBitMap(Handle);
Jesli masz ekran, to to wlasciwie wystarczy (no chyba, ze chcesz miec doublebuffering), jesli rysujesz w okienku, najlepiej zaalokowac offscreenowa bitmape w taki samym formacie jak public screen na ktorym otwierasz okno a nastepnie zrobic BltBitMapRastPort - jesli bitmapy beda w tym samym formacie blt bedzie dosc szybki. Jesli dobrze pamietam to mozesz zaalokowac bitmape w fast mem, pod warunkiem ze nie bedziesz jej wyswietlal bezposrednio (ale moge sie mylic, 20 lat minelo).
06.03.2021 00:51
[#11]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #10
Nie bardzo rozumiem pytanie, pytasz jak zaalokowac bitmape? czy jak skopiowac dane z twojego bufor a gdzie rysujesz do bitmapy?
to drugie przy pomocy lockbitmap/copy(moze z konwersja na odpowiedni format)/unlockbitmap.
Mam gdzies kod do lokacji customowych bitmap, musze poszukac.
edit:
W sumie prostsze niz pamietalem:
Bitmapa w odpowiednim formacie (pixelformat pobrany z Display->screen) friend bitmap ustawiony na bitmape ekranu, na ktory bede na koncu blitowal, bmf_minplanes jest wymagane przez cgfx przy alokowaniu bitmap.
Ostatnia aktualizacja: 06.03.2021 01:08:05 przez lef
to drugie przy pomocy lockbitmap/copy(moze z konwersja na odpowiedni format)/unlockbitmap.
Mam gdzies kod do lokacji customowych bitmap, musze poszukac.
edit:
W sumie prostsze niz pamietalem:
Display->custombitmap = AllocBitMap(Display->userWidth, Display->userHeight, Display->depth, BMF_CLEAR | BMF_DISPLAYABLE | BMF_MINPLANES | BMF_SPECIALFMT | SHIFT_PIXFMT(pixelformat), Display->screen->RastPort.BitMap);
Bitmapa w odpowiednim formacie (pixelformat pobrany z Display->screen) friend bitmap ustawiony na bitmape ekranu, na ktory bede na koncu blitowal, bmf_minplanes jest wymagane przez cgfx przy alokowaniu bitmap.
Ostatnia aktualizacja: 06.03.2021 01:08:05 przez lef
06.03.2021 01:21
[#12]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@lef, post #11
Tzn jesli mamy systemowa Bitmapę (np. powiazaną ze screenem, oknem lub screen bufferem)
to jak tam przenieść mój bufor który zawiera już wygenerowaną grafikę.
Czy można jakoś memcpy żeby było szybko. tym WritePixelArray, albo tym Lockiem..
Generalnie to nowośc dla mnie, ale też nie zależmy żeby jakoś wnikać w bardzo szczegółowe niuanse,
bo skupiam się na szybkim działaniu samego silnika renderującego, który jest niezależny platformowo,
a ta wartswa systemowa, np AmigaOS to mieści się głównie w main.c i ma za zadanie po prostu
utworzyć, screen, okno, i możliwie jak najszybciej wyświetlać to co wygenerowałem..
to jak tam przenieść mój bufor który zawiera już wygenerowaną grafikę.
Czy można jakoś memcpy żeby było szybko. tym WritePixelArray, albo tym Lockiem..
Generalnie to nowośc dla mnie, ale też nie zależmy żeby jakoś wnikać w bardzo szczegółowe niuanse,
bo skupiam się na szybkim działaniu samego silnika renderującego, który jest niezależny platformowo,
a ta wartswa systemowa, np AmigaOS to mieści się głównie w main.c i ma za zadanie po prostu
utworzyć, screen, okno, i możliwie jak najszybciej wyświetlać to co wygenerowałem..
06.03.2021 01:38
[wyróżniony]
[#13]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #12
No to dostales wyzej odpowiedz: LockBitmap daje ci informacje o bitmapie i adres pamieci, gdzie mozesz swoje dane skopiowac. Jak je skopiujesz to juz twoja sprawa. jesli masz dokaldnie taka szerokosc/wysokosc i pixel format swojego buffora jak bitmapy - to memcpy() moze byc. jak masz inne wymiary, inne pixerperline albo inny pixelformat - to musisz po drodze konwrsje jakas zrobic. jak juz zrobisz - unlock bitmap i gotowe.
06.03.2021 01:46
[#14]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@lef, post #13
Dzięki za info..
Możliwe też że sama ta emulacja RTG pod winuae jest jakaś nietaka, wybrałem UAE ZorroIII,
skompilowałem jeden przykład ze stronki który podałem wcześniej, i tak robią właśnie
tak, że wrzucają do bufora a potem WritePixelArray, ale pod emulatorem działa to masakrycznie nawet jak dam male okienko, chyba poproszę kogoś z grupy vampirowej
o test i nagranie filmiku :) zebym miał odniesienie
Możliwe też że sama ta emulacja RTG pod winuae jest jakaś nietaka, wybrałem UAE ZorroIII,
skompilowałem jeden przykład ze stronki który podałem wcześniej, i tak robią właśnie
tak, że wrzucają do bufora a potem WritePixelArray, ale pod emulatorem działa to masakrycznie nawet jak dam male okienko, chyba poproszę kogoś z grupy vampirowej
o test i nagranie filmiku :) zebym miał odniesienie
06.03.2021 10:15
[#15]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #14
Tak na szybko w ramach testu to teoretycznie można po prostu zrobić memcopy do bitmapy okienka. Rozwiązanie nadające się tylko do szybkiego testu ale... powinno działać jeśli dane w buforze mają format ekranu na którym sie okienko wyświetla.
Jeśli WPA musi po drodze konwertować kazdy pixel to nic dziwnego że szybko nie jest.
BTW. Twój testowy program wyświetla w okienku tylko jakieś śmieci.
Ostatnia aktualizacja: 06.03.2021 10:20:27 przez pisklak
Jeśli WPA musi po drodze konwertować kazdy pixel to nic dziwnego że szybko nie jest.
BTW. Twój testowy program wyświetla w okienku tylko jakieś śmieci.
Ostatnia aktualizacja: 06.03.2021 10:20:27 przez pisklak
07.03.2021 01:29
[#17]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #16
Hej jeszcze raz,
Udało mi się ogarnąć to bezpośrednie kopiowanie do karty,
na winuae jest nieco szybsze niż WritePixelArray, poniżej szczegóły kodu, używałem Picasso96API.
Poł dnia mi zeszło, najpierw kopiowałem do BitMap->Planes to wywalało, ale skoro to tablica wskażników
to sprawidzłem BitMap->Planes[0] i to było to..
Tutaj link do nowego testu z licznikiem fps + żródła w C, może Ktoś będzie chciał zerknąć jakby coś: http://mstanisz.website.pl/tmp/other/AMIGA_TESTS_P96.zip
test trwa 10 sekund, sa dwie wersje 320x256x32 i 640x512x32
Udało mi się ogarnąć to bezpośrednie kopiowanie do karty,
na winuae jest nieco szybsze niż WritePixelArray, poniżej szczegóły kodu, używałem Picasso96API.
int* my_buf = (int*)malloc(Width * Height);
...
APTR my_lock = p96LockBitMap(screen->RastPort.BitMap, NULL, 0);
memcpy(screen->RastPort.BitMap->Planes[0], my_buf, Width* Height);
p96UnlockBitMap(screen->RastPort.BitMap, my_lock);Poł dnia mi zeszło, najpierw kopiowałem do BitMap->Planes to wywalało, ale skoro to tablica wskażników
to sprawidzłem BitMap->Planes[0] i to było to..
Tutaj link do nowego testu z licznikiem fps + żródła w C, może Ktoś będzie chciał zerknąć jakby coś: http://mstanisz.website.pl/tmp/other/AMIGA_TESTS_P96.zip
test trwa 10 sekund, sa dwie wersje 320x256x32 i 640x512x32
08.03.2021 13:01
[#18]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #17
Hej, czy może Ktoś z Was zerkał na ten test lub sam kod?
Miałem jedną odpowiedź id użytkowania Vampira, że program nie mógł otworzyć screena.
W paczce jest kilka wersji łącznie z wariantem best mode.
Zastanawiam się czy obejście WritePixelArray i kopiowanie wprost do pamięci karty
w sposób który podałem to ostateczność, czy można to jeszcze jakoś usprawnić?
Na WinUAe testowałem również bez użycia Lock Bitmap i działało, ale to winuae więc wszytko się może zdarzyć.
Macie jakieś pomysły albo wskazówki jak poprawić kod, albo go "ugeneralnić" mam na myśli tylko otwieranie screena + wyswietleni na ekran. Niby się uparłem na te 32bity ale 24 też podobnie działają,
pewnie też cały integer przysyłają na pixel.
Miałem jedną odpowiedź id użytkowania Vampira, że program nie mógł otworzyć screena.
W paczce jest kilka wersji łącznie z wariantem best mode.
Zastanawiam się czy obejście WritePixelArray i kopiowanie wprost do pamięci karty
w sposób który podałem to ostateczność, czy można to jeszcze jakoś usprawnić?
Na WinUAe testowałem również bez użycia Lock Bitmap i działało, ale to winuae więc wszytko się może zdarzyć.
Macie jakieś pomysły albo wskazówki jak poprawić kod, albo go "ugeneralnić" mam na myśli tylko otwieranie screena + wyswietleni na ekran. Niby się uparłem na te 32bity ale 24 też podobnie działają,
pewnie też cały integer przysyłają na pixel.
08.03.2021 14:24
[#19]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #18
Hej,
Podales do OpenScreen pixel format (r8g8b8a8) - jesli ktos nei ma zdefiniowanego ekranu o takim formacie to nie uda sie otworzyc. Ja mam 32 bitowe w formacie bgra na przyklad.
Jesli masz modeid nie musisz ustawiac pixelformatu przy otwieraniu ekranu, albo jak nie masz modeid - podaj depth.
Cokolwiek nie zrobisz, na koncu i tak bedziesz mial otwarty ekran w 32 bitach, ale ekran moze byc w dowolnym ze wspieranych przez p96 formatow. Masz 2 mozliwosci; albo poprawisz swoj kod renderujacy, tak zeby umial renderowac od razu w formacie ekranu, albo (co jest latwiejsze, ale moze meic wplyw na wydajnosc) napiszesz sobie konwersje pomeidzy formatami i skonwertujesz swoje rgba32 do formatu ekranu.
Oraz: Jak piszesz na RTG to lepiej chyba uzywac cgfx niz p96: p96 ma emulacje cgfx, wiec program uzywajacy API cgfx uruchomi sie na obu RTG, a taki uzywajacy P96 tylko na P96.
Podales do OpenScreen pixel format (r8g8b8a8) - jesli ktos nei ma zdefiniowanego ekranu o takim formacie to nie uda sie otworzyc. Ja mam 32 bitowe w formacie bgra na przyklad.
Jesli masz modeid nie musisz ustawiac pixelformatu przy otwieraniu ekranu, albo jak nie masz modeid - podaj depth.
Cokolwiek nie zrobisz, na koncu i tak bedziesz mial otwarty ekran w 32 bitach, ale ekran moze byc w dowolnym ze wspieranych przez p96 formatow. Masz 2 mozliwosci; albo poprawisz swoj kod renderujacy, tak zeby umial renderowac od razu w formacie ekranu, albo (co jest latwiejsze, ale moze meic wplyw na wydajnosc) napiszesz sobie konwersje pomeidzy formatami i skonwertujesz swoje rgba32 do formatu ekranu.
Oraz: Jak piszesz na RTG to lepiej chyba uzywac cgfx niz p96: p96 ma emulacje cgfx, wiec program uzywajacy API cgfx uruchomi sie na obu RTG, a taki uzywajacy P96 tylko na P96.
08.03.2021 14:34
[#20]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@lef, post #19
dzięki za info. będę ogarniał..
a co do CGFX i P96, to tak owszem.. ale myślałem że jak mam zainstalowane sterowniki P96 to automatcznie to zadziała z programem napisanym w cgx
natomiast musiałem dodatkowo zainstalować biblioteki cgx, troche mialem z tym problemu,
no i gdzieś też z kolei czytałem że nie powinno się instalować i P96 i CGX.. chyba że coś źle robię?
więc na razie żeby było łatwiej zostałem przy p96..
czyli jesli uzytkownik Vampa albo Warpa jeśli chciałby uruchomić mój program napisany pod CGX musiał by sobie zainstalować dodatkowo cały pakiet CGfx? bo też są różne pakiety na aminecie w dodatku bez instalek
Ostatnia aktualizacja: 08.03.2021 14:35:53 przez mateusz_s
a co do CGFX i P96, to tak owszem.. ale myślałem że jak mam zainstalowane sterowniki P96 to automatcznie to zadziała z programem napisanym w cgx
natomiast musiałem dodatkowo zainstalować biblioteki cgx, troche mialem z tym problemu,
no i gdzieś też z kolei czytałem że nie powinno się instalować i P96 i CGX.. chyba że coś źle robię?
więc na razie żeby było łatwiej zostałem przy p96..
czyli jesli uzytkownik Vampa albo Warpa jeśli chciałby uruchomić mój program napisany pod CGX musiał by sobie zainstalować dodatkowo cały pakiet CGfx? bo też są różne pakiety na aminecie w dodatku bez instalek
Ostatnia aktualizacja: 08.03.2021 14:35:53 przez mateusz_s
08.03.2021 14:52
[#24]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@lef, post #21
tzn. w GCC od BEBBO są includy cgx i moge normalnie pisac, ale po kompilacji podczas uruchamiania programu mam komunikat że nie znaleziono biblioteki CGXsystem czy coś takiego, stąd moje pytanie, dopiero jak poinstalowałem biblioteki do systemu z paczki cgx to podziałało..
Ostatnia aktualizacja: 08.03.2021 14:53:21 przez mateusz_s
Ostatnia aktualizacja: 08.03.2021 14:53:21 przez mateusz_s
08.03.2021 15:39
[#25]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #24
To wina stuba do autootwierania bibliotek. Probuje otwierac CyberGfx.library, a powinien cybergraphics.library. Wydaje mi sie, ze to dlatego, ze nazwy biblitek sa generowane na podstawie proto i nazwy bazy biblioteki.
Jak sobie zdefiniujesz baze biblioteki i otworzysz cgfx sam, wszystko bedzie dzialalo.
Jak sobie zdefiniujesz baze biblioteki i otworzysz cgfx sam, wszystko bedzie dzialalo.
08.03.2021 15:53
[#26]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@lef, post #23
Nie wiem, jak programuje dla amigaosu to korzystam z amigaosu. Bebbo zrobił crosskompilatory wiec nie korzystam (tzn. jak mnie wystarczającą wkurzy ADE/GG to pewnie albo zrobie crosskompilator 68k na morphosa albo faktycznie zainstaluje to coś od bebbo).
Ostatnia aktualizacja: 08.03.2021 15:53:34 przez michal_zukowski
Ostatnia aktualizacja: 08.03.2021 15:53:34 przez michal_zukowski
11.03.2021 02:07
[#28]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #27
Spotkaliście się może z takim problemem? To chyba BUG w RTG.library moim zdaniem..
Napisze chyba do icompu, tylko sprawdzę jeszcze z wersją 3.01
Okazuje się i sprawdzałem to na P96 i CGX, że teoretycznie nie da się "poprosić"
funkcji BestMode i OpenScreen o otworzenie okna w trybie 32 bit mimo że mamy taki tryb na liście.
Upewniłem się za pomocą tego programiku z linku (to jest przykład requestera z devkit p96)
https://we.tl/t-uCQgJqU3fp
Próba otwarcia takiego okna np. 320x240x32 skutkuje że OpenScreen zwraca błąd.
W sensie jeśli on dostanie parametr "32". I nie działa to nie tylko na WinUAE ale i na Vampirach,
bo mi różne osoby mówiły.
Ale tu się zaczyna najlepsze.. i dobrze pokazuje to załączony programik.
Jeśli wybierzemy z gotowej listy np. 640x480x24 to otrzymujemy wynik: 640x480x24 i ID $50031200
ale tu uwaga, jesli otworzymy tryb z listy 640x480x32 to otrzymujemy też taki wynik 640x480x24 ale już z ID %50031300..
czyli są to różne tryby jednak ze wzglęu na jakiegoś buga nie można otworzyć trybu 32 po podaniu głębokości.. trzeba podać ID.
owszem udało mi się otworzyć tryb 32 ale nie dlatego że w podałem parametr depth 32 - wtedy zawsze zwraca bład.
Trzeba podac paramater 24 ale miec tylko zdefiniowane tryby 32. Albo tak jak napisalem otworzyć podajać parametr ID.
na 3.01 tez nie działa.. nie wierzę że przez tyle lat nikt tego nie zauważył, bo przecież by to poprawili to już któraś wersja wydana z icomp, jeśli by to była powszechnia znana rzecz to powinni popawrić.. chyba ze zostawili
Napisze chyba do icompu, tylko sprawdzę jeszcze z wersją 3.01
Okazuje się i sprawdzałem to na P96 i CGX, że teoretycznie nie da się "poprosić"
funkcji BestMode i OpenScreen o otworzenie okna w trybie 32 bit mimo że mamy taki tryb na liście.
Upewniłem się za pomocą tego programiku z linku (to jest przykład requestera z devkit p96)
https://we.tl/t-uCQgJqU3fp
Próba otwarcia takiego okna np. 320x240x32 skutkuje że OpenScreen zwraca błąd.
W sensie jeśli on dostanie parametr "32". I nie działa to nie tylko na WinUAE ale i na Vampirach,
bo mi różne osoby mówiły.
Ale tu się zaczyna najlepsze.. i dobrze pokazuje to załączony programik.
Jeśli wybierzemy z gotowej listy np. 640x480x24 to otrzymujemy wynik: 640x480x24 i ID $50031200
ale tu uwaga, jesli otworzymy tryb z listy 640x480x32 to otrzymujemy też taki wynik 640x480x24 ale już z ID %50031300..
czyli są to różne tryby jednak ze wzglęu na jakiegoś buga nie można otworzyć trybu 32 po podaniu głębokości.. trzeba podać ID.
owszem udało mi się otworzyć tryb 32 ale nie dlatego że w podałem parametr depth 32 - wtedy zawsze zwraca bład.
Trzeba podac paramater 24 ale miec tylko zdefiniowane tryby 32. Albo tak jak napisalem otworzyć podajać parametr ID.
na 3.01 tez nie działa.. nie wierzę że przez tyle lat nikt tego nie zauważył, bo przecież by to poprawili to już któraś wersja wydana z icomp, jeśli by to była powszechnia znana rzecz to powinni popawrić.. chyba ze zostawili
11.03.2021 02:51
[#29]
Re: [C, RTG] Różne tryby ekranu 16, 24, 32 bpp - a grafika w programie.
@mateusz_s, post #28
jeszcze poprawka bo sprawdziłem jeszcze raz.
Jeżeli piszemy w P96 API to jesdnak p96OpenScreen daje rade otworzyć ekran jeśli mu podamy parametr 32.
Problem jest jeśli piszemy w CGX API..
Choć ciekawe jest to, że ten programik od sprawdzania z trybow z lity byl z devkita p96.
Dla mnie to o tyle ważne, że wyświetlanie w trybie 32 jest znacznie szybsze niż niż 24,
pewnie dlatego że są pełne inty, bufor 24 miał po 3 bajty na pixel i nie bylo juz tak szybko,
zreszta nie mozna wtedy uzywac struktury rgba w programie co tez przyspiesza
Rozwiązaniem jest zorbienie LAunchera przed programem, w którym mozemy wybrac rozdielczosc 32bit,
a schowac pozostałe 24 tryby
Jeżeli piszemy w P96 API to jesdnak p96OpenScreen daje rade otworzyć ekran jeśli mu podamy parametr 32.
Problem jest jeśli piszemy w CGX API..
Choć ciekawe jest to, że ten programik od sprawdzania z trybow z lity byl z devkita p96.
Dla mnie to o tyle ważne, że wyświetlanie w trybie 32 jest znacznie szybsze niż niż 24,
pewnie dlatego że są pełne inty, bufor 24 miał po 3 bajty na pixel i nie bylo juz tak szybko,
zreszta nie mozna wtedy uzywac struktury rgba w programie co tez przyspiesza
Rozwiązaniem jest zorbienie LAunchera przed programem, w którym mozemy wybrac rozdielczosc 32bit,
a schowac pozostałe 24 tryby