01.12.2004 17:07
[#1]
Karta graficzna vs. Workbench
Jak:
1) Wykryć obecność karty graficznej, a dokładniej, to, czy interesujący mnie ekran (np. WB) otwarty jest "na karcie".
a) Czy wystarczy proste sprawdzenie modeID?
b) Czy dla tego samego trybu, ale na różnych kartach modeid jest zawsze ten sam?
2) Jak rysować w oknie otwartym na takim ekranie?
a) Czy obrazy np. o 3 bitplanach mogę normalnie wyświetlić w oknie używając do tego blittera (za pośrednictwem systemu ofkoz).
b) Czy mogę manipulować danymi bezpośrednio w bitplanach?
3) Jak rysować w więcej niż 8 bitach.
a) Jak wkleić bitmapę 24bitową do okna? Czy trzeba ją "rozbijać" na bitplany?
b) jak wkleić bitmapę o mniejszej głębi kolorów (np. 16 bit) do okna otwartego na 24 bitowym ekranie?
c) jak wkleić bitmapę o większej głębi kolorów (np. 24 bit) do okna otwartego na 16 bitowym ekranie?
Czy w przypadkach b) i c) muszę sam napisać procedurę zmieniającą głębię kolorów bitmapy?
Szukam wszelkich materiałów o obsłudze kart graficznych z poziomu systemu.
1) Wykryć obecność karty graficznej, a dokładniej, to, czy interesujący mnie ekran (np. WB) otwarty jest "na karcie".
a) Czy wystarczy proste sprawdzenie modeID?
b) Czy dla tego samego trybu, ale na różnych kartach modeid jest zawsze ten sam?
2) Jak rysować w oknie otwartym na takim ekranie?
a) Czy obrazy np. o 3 bitplanach mogę normalnie wyświetlić w oknie używając do tego blittera (za pośrednictwem systemu ofkoz).
b) Czy mogę manipulować danymi bezpośrednio w bitplanach?
3) Jak rysować w więcej niż 8 bitach.
a) Jak wkleić bitmapę 24bitową do okna? Czy trzeba ją "rozbijać" na bitplany?
b) jak wkleić bitmapę o mniejszej głębi kolorów (np. 16 bit) do okna otwartego na 24 bitowym ekranie?
c) jak wkleić bitmapę o większej głębi kolorów (np. 24 bit) do okna otwartego na 16 bitowym ekranie?
Czy w przypadkach b) i c) muszę sam napisać procedurę zmieniającą głębię kolorów bitmapy?
Szukam wszelkich materiałów o obsłudze kart graficznych z poziomu systemu.
01.12.2004 19:12
[#2]
Re: Karta graficzna vs. Workbench
@shg, post #1
1) a po co w ogóle to wykrywać?
a) nie bardzo
b) nie
2) przez graphics.library i intuition.library
a) tak, z tym, że to nie Ty decydujesz czy zrobi to blitter czy nie
b) po wblitowaniu nie, zanim zrobisz BltBitmapXXX() możesz do woli. Tylko, że lepiej dać sobie spokój z bitplanami, bo po co męczyć system konwersją P2C?
3) przez cybergraphics.library
a) BltBitmapXXX(). Na karcie GFX nie ma żadnych bitplanów.
b) BltBitmapXXX()
c) BltBitmapXXX()
Nie ma właściwie żadnych materiałów. Dla systemu nie ma różnicy czy ekran jest z chipsetu czy z karty. Jeżeli chcesz zrobić nowego Froggera, to musisz się dokładniej zapoznać z dokumentacją od CGX i popisać procedury od konwersji PIXELFORMATów. W pozostałych przypadkach powinien wystarczyć BltBitMapXXX(), WritePixel() i DrawXXX() wraz z autodokiem od graphics.library w wersji 3.x
a) nie bardzo
b) nie
2) przez graphics.library i intuition.library
a) tak, z tym, że to nie Ty decydujesz czy zrobi to blitter czy nie
b) po wblitowaniu nie, zanim zrobisz BltBitmapXXX() możesz do woli. Tylko, że lepiej dać sobie spokój z bitplanami, bo po co męczyć system konwersją P2C?
3) przez cybergraphics.library
a) BltBitmapXXX(). Na karcie GFX nie ma żadnych bitplanów.
b) BltBitmapXXX()
c) BltBitmapXXX()
Nie ma właściwie żadnych materiałów. Dla systemu nie ma różnicy czy ekran jest z chipsetu czy z karty. Jeżeli chcesz zrobić nowego Froggera, to musisz się dokładniej zapoznać z dokumentacją od CGX i popisać procedury od konwersji PIXELFORMATów. W pozostałych przypadkach powinien wystarczyć BltBitMapXXX(), WritePixel() i DrawXXX() wraz z autodokiem od graphics.library w wersji 3.x
03.12.2004 10:00
[#5]
Re: Karta graficzna vs. Workbench
@shg, post #4
Ad.1. W cybergraphics nie ma BltBitmap(). Ta funkcja jest w graphics. Bitmapa w takim wypadku może być w FAST, ale to generalnie nie powinno Cię interesować, bo i tak bitmapę musisz zaalokować przez AllocBitmap() a nie AllocMem(). AllocBitmap() samo wybierze, gdzie najlepiej umieścić bitmapę na podstawie przekazanych jej flag. Stąd też prosty wniosek, że wybierze też format bitmapy, więc grzebanie po niej ręcznie to najprostsza droga do dużych kłopotów.
Ad.2. Nie.
Jak robisz skiny, to daj sobie spokój z tym całym kombinowaniem tylko wczytaj grafikę przez datatypes i potem ewentualnie przeskaluj i tylko blituj. Nawet nie próbuj nic więcej tam grzebać, bo nie ma takiej potrzeby. Jeżeli Ci wychodzi, że musisz grzebać w bitmapie to znaczy, że coś źle zaprojektowałeś i idziesz w złym kierunku.
Ad.2. Nie.
Jak robisz skiny, to daj sobie spokój z tym całym kombinowaniem tylko wczytaj grafikę przez datatypes i potem ewentualnie przeskaluj i tylko blituj. Nawet nie próbuj nic więcej tam grzebać, bo nie ma takiej potrzeby. Jeżeli Ci wychodzi, że musisz grzebać w bitmapie to znaczy, że coś źle zaprojektowałeś i idziesz w złym kierunku.
04.12.2004 01:56
[#6]
Re: Karta graficzna vs. Workbench
@jrzeuski, post #5
to grzebanie w bitmapie to będzie ewentualnie jakaś wbudowana wizualizacja, ale to naprawdę "ewentualna".
Najprawdopodobniej będzie jakiś VU-meter, bitmapa - gradient powiedzmy od zieleni do czerwieni i w zależności od poziomu dźwięku wklejany odpowiedni kawałek, także tu zabawy z bitplanami nie będzie.
Ale na to jeszcze przyjdzie czas. Na razie muszę jakiekolwiek(!) gui zrobić :D
I tu są dwie koncepcje:
1) Do okienka wklejam ewentualne tło, a wszystkie przyciski są zrobione na gadgetach intuition (stąd było pytanie o 24 bitowe IntuitionImage).
2) W edytorze (o którym niżej) całe GUI "składane" jest do jednej bitmapy, a przyciski są niewidoczne, tylko tu pojawia się problem, bo musiałbym "ręcznie" podmieniać bitmapy np. z okazji wciśnięcia przycisku itp.
No i mam teraz problem, bo nie wiem, którą metodę wybrać. Przy pierwszej mogą być problemy z 24 bitowym IntuitionImage
2 metoda to z kolei więcej roboty.
Uprzedzając ewentualne pytania.
Dlaczego intuition? Bo jest szybkie, elastyczne i patrz patent poniżej.
Dlaczego nie inne:
- gadtools.library odpada w przedbiegach za swoje ramki 3D na buttonach, poza tym jest elastyczny jak drut stalowy
- MUI - kobyła i muł w jednym (czytaj: duże i powolne), zbyt skomplikowane programowanie, nie to, żebym nie umiał, ale zrobić coś więcej niż proste przyciski to już będzie chyba problem. Poza tym mój player ma działać na wszystkim z OS2.0 i wyżej, a używałem MUI na gołej A600, pochlastać się można
A na intuition wykombinowałem taki patent:
Edytor skórek (tak!) pozwalający dowolnie rozmieścić dowolne obrazy w oknie i przypisać im funkcje poszczególnych przycisków. Następnie tworzy odpowiednią listę gadgetów, obrazki zamienia na IntuitionImages, wszystko zapisuje do jednego pliku i dodaje tabelę relokacji (wskaźniki w strukturach Gadget itp.)
Takie GUI będzie się ładowało z prędkością światła - wystarczy wczytać z pierwszej częsci pliku wszystkie struktury (to się za jednym zamachem załatwi i do pamięci FAST oczywiście), z drugiej części zostaną wczytane wszystkie bitmapy (też tylko jeden Read() - te wylądują w pamięci CHIP, przynajmniej na razie), na koniec odczytana zostanie tabela relokacji i uaktualnione wskaźniki. Na koniec wczytana tablica jest gotowa do "przyklejenia" do okna.
W sumie to mogę nawet całe GUI wczytać jeszcze szybciej, za pomocą LoadSeg(), ale będzie trzeba napisać edytor, który będzie w stanie zapisywać pliki strawne dla LoadSeg(), a jakoś nigdy nie miałem ochoty się segmentami zajmować, ale może warto... to się zobaczy.
I wymyśliłem jeszcze rzeczy, których chyba nie mają inne playery -
1) graficzny edytor DSP - składamy z klocków typu suma, opóżnienie itd. odpowiedni schemat przetwarzania, następnie edytor ze schematu tworzy źródło plugina (ASM) i asembluje, najpewniej za pomocą Phx'a.
2) Graficzny edytor "przepływu" dźwięku - czyli budujemy sobie łańcuch np.: plik->dekoder->(zapis do pliku) DSP->(wizualizacja) głośniki
To, co w nawiasie, to odgałęzienie łańcucha.
Echhh, dobrze, że za marzenia nie karają
Skąd wziąć cybergraphich.library? zassałem z aminetu Picasso96.lha i cgx41_XXXX.lha, ale rzeczonej biblioteki tam nie wypatrzyłem.
Czy cybergraphics potrafi też smarować na kościach AGA?
Najprawdopodobniej będzie jakiś VU-meter, bitmapa - gradient powiedzmy od zieleni do czerwieni i w zależności od poziomu dźwięku wklejany odpowiedni kawałek, także tu zabawy z bitplanami nie będzie.
Ale na to jeszcze przyjdzie czas. Na razie muszę jakiekolwiek(!) gui zrobić :D
I tu są dwie koncepcje:
1) Do okienka wklejam ewentualne tło, a wszystkie przyciski są zrobione na gadgetach intuition (stąd było pytanie o 24 bitowe IntuitionImage).
2) W edytorze (o którym niżej) całe GUI "składane" jest do jednej bitmapy, a przyciski są niewidoczne, tylko tu pojawia się problem, bo musiałbym "ręcznie" podmieniać bitmapy np. z okazji wciśnięcia przycisku itp.
No i mam teraz problem, bo nie wiem, którą metodę wybrać. Przy pierwszej mogą być problemy z 24 bitowym IntuitionImage
2 metoda to z kolei więcej roboty.
Uprzedzając ewentualne pytania.
Dlaczego intuition? Bo jest szybkie, elastyczne i patrz patent poniżej.
Dlaczego nie inne:
- gadtools.library odpada w przedbiegach za swoje ramki 3D na buttonach, poza tym jest elastyczny jak drut stalowy
- MUI - kobyła i muł w jednym (czytaj: duże i powolne), zbyt skomplikowane programowanie, nie to, żebym nie umiał, ale zrobić coś więcej niż proste przyciski to już będzie chyba problem. Poza tym mój player ma działać na wszystkim z OS2.0 i wyżej, a używałem MUI na gołej A600, pochlastać się można
A na intuition wykombinowałem taki patent:
Edytor skórek (tak!) pozwalający dowolnie rozmieścić dowolne obrazy w oknie i przypisać im funkcje poszczególnych przycisków. Następnie tworzy odpowiednią listę gadgetów, obrazki zamienia na IntuitionImages, wszystko zapisuje do jednego pliku i dodaje tabelę relokacji (wskaźniki w strukturach Gadget itp.)
Takie GUI będzie się ładowało z prędkością światła - wystarczy wczytać z pierwszej częsci pliku wszystkie struktury (to się za jednym zamachem załatwi i do pamięci FAST oczywiście), z drugiej części zostaną wczytane wszystkie bitmapy (też tylko jeden Read() - te wylądują w pamięci CHIP, przynajmniej na razie), na koniec odczytana zostanie tabela relokacji i uaktualnione wskaźniki. Na koniec wczytana tablica jest gotowa do "przyklejenia" do okna.
W sumie to mogę nawet całe GUI wczytać jeszcze szybciej, za pomocą LoadSeg(), ale będzie trzeba napisać edytor, który będzie w stanie zapisywać pliki strawne dla LoadSeg(), a jakoś nigdy nie miałem ochoty się segmentami zajmować, ale może warto... to się zobaczy.
I wymyśliłem jeszcze rzeczy, których chyba nie mają inne playery -
1) graficzny edytor DSP - składamy z klocków typu suma, opóżnienie itd. odpowiedni schemat przetwarzania, następnie edytor ze schematu tworzy źródło plugina (ASM) i asembluje, najpewniej za pomocą Phx'a.
2) Graficzny edytor "przepływu" dźwięku - czyli budujemy sobie łańcuch np.: plik->dekoder->(zapis do pliku) DSP->(wizualizacja) głośniki
To, co w nawiasie, to odgałęzienie łańcucha.
Echhh, dobrze, że za marzenia nie karają
Skąd wziąć cybergraphich.library? zassałem z aminetu Picasso96.lha i cgx41_XXXX.lha, ale rzeczonej biblioteki tam nie wypatrzyłem.
Czy cybergraphics potrafi też smarować na kościach AGA?
04.12.2004 04:05
[#7]
Re: Karta graficzna vs. Workbench
@shg, post #6
Dlaczego bitmapy mają lądować akurat w pamięci CHIP? Nie lepiej, jeszcze przed otwarciem okna, zalokować ekran funkcją LockPubScreen(), po czym, z otrzymanego wskaźnika na strukturę ekranu, wyłuskać wskaźnik na bitmapę ekranu i podawać go za każdym razem przy wywoływaniu funkcji AllocBitMap()? W efekcie bitmapy będą lądować w takiej pamięci, jakiej powinny, tj. na AGA/ECS/OCS w CHIP, a na CGX/P96 - w FAST!
To samo tyczy się pakowania struktur do FAST-u. Po co? AllocMem() czy AllocVec() z flagą MEMF_PUBLIC załatwi sprawę niezależnie od tego, czy Amiga ma pamięć FAST, czy też nie.
To samo tyczy się pakowania struktur do FAST-u. Po co? AllocMem() czy AllocVec() z flagą MEMF_PUBLIC załatwi sprawę niezależnie od tego, czy Amiga ma pamięć FAST, czy też nie.
04.12.2004 15:40
[#9]
Re: Karta graficzna vs. Workbench
@shg, post #8
Z bitmapami pod P96 jest jednak pewien problem. Mianowicie kiedyś, gdy miałem A1200 z Mediatorem uzbrojonym w S3 ViRGE'a, przetestowałem zachowanie CGX-a i P96. Polegało to na tym, że uruchamiałem system na karcie GFX, a następnie uruchamiałem napisany przez siebie programik, który otwierał prywatny ekran (umyślnie wybierałem PAL) i wblitowywał niego bitmapy (ładowane via datatype'y). Pod kontrolą GCX-a nie było najmniejszych problemów, jednak z P96 działy się co jakiś czas cuda - zwiechy systemu, kaszana na ekranie, mnóstwo hitów itp. Wyglądało to trochę tak, jakby P96 powodował, że bitmapa blitowana do ekranu otwartego w PAL-u znajdowała się czasami w pamięci FAST (sprawdzałem printfem!), a nie w CHIP (i stąd zwiechy), albo była w formacie CHUNKY zamiast w PLANAR!
05.12.2004 17:49
[#10]
Re: Karta graficzna vs. Workbench
@shg, post #6
Zdecydowanie sposób nr 2. Żeby ułatwić sobie maksymalnie jego realizację zrób własne gadżety BOOPSI (podklasa gadgetclass) i tam w metodzie GM_RENDER blituj swoje bitmapy i ewentualnie obrysowywuj je ramką sygnalizującą wybór/wciśnięcie gadżetu.
PS. Stąd już tylko krok do realizacji tego w MUI
PS. Stąd już tylko krok do realizacji tego w MUI
06.12.2004 03:16
[#11]
Re: Karta graficzna vs. Workbench
@jrzeuski, post #10
Już coś zaczyna się dziać 
Na razie GUI jest zintegrowane z programem (ILBM przekonwertowany do źródła w C) i standardowe gadgety intuition.
Podmieniłem wszystkie gadgety systemowe, okienko nie ma ramki systemowej, tylko narysowaną.
GUI wygląda tak (wersja dle ekranu PAL bez "drgawek":
Ten zegar i seek bar są tylko namalowane , ale przyciski działają.
zobaczę czy da się to jakoś z BOOPSI wykombinować, ale to się chyba będzie uruchamiało znacznie wolniej i trudniej będzie to to zaprogramować.
Zastanawiam się nad gadgetem custom (z intuition), ale jakoś nie mogę sie "dokopać" do dokumentacji.
Na razie GUI jest zintegrowane z programem (ILBM przekonwertowany do źródła w C) i standardowe gadgety intuition.
Podmieniłem wszystkie gadgety systemowe, okienko nie ma ramki systemowej, tylko narysowaną.
GUI wygląda tak (wersja dle ekranu PAL bez "drgawek":
Ten zegar i seek bar są tylko namalowane
, ale przyciski działają. zobaczę czy da się to jakoś z BOOPSI wykombinować, ale to się chyba będzie uruchamiało znacznie wolniej i trudniej będzie to to zaprogramować.
Zastanawiam się nad gadgetem custom (z intuition), ale jakoś nie mogę sie "dokopać" do dokumentacji.
