Komentowana treść: Google Drive dla AmigaOS 3.x
02.02.2016 16:44
[#31]
Re: Google Drive dla AmigaOS 3.x
@Hexmage960, post #30
W Amiga OS (już od 1) nie trzeba tykać bitmapy, należy tylko podpiąć wskaźnik pod RastPort
Mi chodziło o RastPort
A mi chodzi o BitMap. Co z tego, że rastport robi za abstrakcję skoro bitmapa jest kompletnie nierozszerzalna? No chyba, ze twierdzisz, że nigdy nie ma potrzeby alokacji własnej bitmapy?
Proponuje też lekturę funkcji InitBitMap() ktora jako jedyna w systemie 1.x pozwalała na zainicjalizowanie bitmapy. Nawet ona mówi, że trzeba samemu ustawić bitplany. Co więcej, ustawiając je nie ma możliwości podania w jakim są formacie. Tak więc nie, OS1.x nie pozwalał na oderwanie się od chipsetu.
W oficjalnej dokumentacji jest wyraźnie napisane, że struktura Screen->BitMap nie powinna być używana, w zamian powinno się używać Screen->RastPort, bo liczba bitplanów może wzrosnąć.
Nie zmienia to kompletnie faktu, że poprzez publiczność struktur ludzie alokowali je samemu (przez AllocMem a nie przez AllocBitMap) przez co struktura NIE mogła wlaśnie wzrosnąć bez zerwania kompatybilności. Wiele aplikacji mogło robić dokładnie tak jak zrobione jest to w Screen->BitMap i umieszczać tą strukturę w swoich danych.
Dodatkowo, upublicznienie struktury odcinało możliwość dodania do niej innych informacji co do danych które opisuje. Np formatu bitplanów, faktu braku bitplanów itp.
W dokumentacji jest wyszczególnione, które funkcje są niskopoziomowymi.
OwnBlitter() stanowi systemowy semafor na Blitter, konieczny ze względu na wielozadaniowość. I znowu, ta funkcja należy do niskopoziomowych.
Te niskopoziomowe funkcje powodują, że wszystko co piszesz będzie niekompatybilne i przywiązane do chipsetu w konkretnej wersji.
Nie, graphics.library (a szczególnie w wersji z systemu 1.x) nie pozwala na odcięcie się od chipsetu.
02.02.2016 17:21
[#32]
Re: Google Drive dla AmigaOS 3.x
@kiero, post #31
Dobrze, zgodzę się z tym, że w systemie 1.x InitBitMap() służy do inicjalizacji bitmapy, zatem pozwala na tworzenie tylko bitmap planarnych na użytek programu.
Programy takie po prostu nie będą akcelerowane przez nowsze kości graficzne. Ale będą działać poprawnie na nowych kościach o ile stosują funkcje korzystające z RastPortu jako interfejsu do takiej BitMapy. Zatem nie wymagają chipsetu do działania.
RastPort robi za abstrakcję i ma akcesory typu SetAPen(), zatem jest to struktura prywatna. Nic zatem nie stoi na przeszkodzie by rozszerzyć funkcje rysujące korzystające z RastPortu. Te akcesory mogą patrzeć na pole BitMap na swój sposób.
Pełniejsze wsparcie RTG rzeczywiście wprowadzono w 3.x.
Programy takie po prostu nie będą akcelerowane przez nowsze kości graficzne. Ale będą działać poprawnie na nowych kościach o ile stosują funkcje korzystające z RastPortu jako interfejsu do takiej BitMapy. Zatem nie wymagają chipsetu do działania.
RastPort robi za abstrakcję i ma akcesory typu SetAPen(), zatem jest to struktura prywatna. Nic zatem nie stoi na przeszkodzie by rozszerzyć funkcje rysujące korzystające z RastPortu. Te akcesory mogą patrzeć na pole BitMap na swój sposób.
Pełniejsze wsparcie RTG rzeczywiście wprowadzono w 3.x.
02.02.2016 20:34
[#33]
Re: Google Drive dla AmigaOS 3.x
@Hexmage960, post #32
Programy takie po prostu nie będą akcelerowane przez nowsze kości graficzne. Ale będą działać poprawnie na nowych kościach o ile stosują funkcje korzystające z RastPortu jako interfejsu do takiej BitMapy
Po pierwsze, zobacz ile masz funkcji które operują bezpośrednio na bitmapach. Nigdzie nie jest napisane żeby ich nie używać.
Po drugie, używanie rastportu do manipulacji na bitmapie NIE załatwia magicznie problemów które są z bitmapami. Rastport nie ma żadnych dodatkowych informacji co do bitmapy. Widzę też, że nie widzisz problemów z ograniczoną "objętością" bitmap. Takie upublicznienie struktur automatycznie powoduje, że twój program przestanie działać poprawnie (włącznie z zawieszeniem się) np w przypadku kiedy ktoś otworzy ekran o większej ilości bitplanów niż 8 albo zaalokuje bitplany które nie są planarne. To samo z bitmapami które używane są do wyświetlania. Pamiętaj, że możesz wskazać bitmapę dla ekranu. W tym przypadku ekran nawet się nie otworzy.
RastPort robi za abstrakcję i ma akcesory typu SetAPen(), zatem jest to struktura prywatna
Nie, nie jest to struktura prywatna. Jest w 100% publiczna. Niestety robi za "abstrakcje" tak jak reszta AmigaOSu. Wszystko jest publiczne co od razu stawia nazywanie tego abstrakcją pod znakiem zapytania. Po prostu nie ma API które pozwala na dostęp oraz modyfikację wszystkich aspektów rasptportu. Szczątkowe API (nie ma możliwości oczytu i zapisu wszystkich atrybutów. co więcej, nie ma możliwości alokacji rastportu!) pojawiło się w 3.x ale błędy przeszłości i tak wykluczają jakiekolwiek zmiany w tych strukturach. Nie ma mowy o ich rozszerzeniu.
Te akcesory mogą patrzeć na pole BitMap na swój sposób.
Niestety nie mogą patrzyć na swój sposób bo nie widzą absolutnie nic poza tym co "normalny" program widzi. Tak jak pisałem, RastPort nie ma i nie może mieć dostępu (w pełni bezpieczny sposób) do większej ilości informacji na temat bitmapy.
02.02.2016 21:28
[#34]
Re: Google Drive dla AmigaOS 3.x
@kiero, post #33
OK. Wyobraź sobie sytuację, gdy piszą nową wersję Amiga OS z obsługą trybów RTG. W tej sytuacji muszą wprowadzić bitmapy typu chunky przy zachowaniu pełnej kompatybilności z poprzednimi wersjami Amiga OS.
Tak się szczęśliwie składa, że BitMapa ma pole Flags z wieloma wolnymi polami oraz pole Depth oraz na sztywno określone 8 pól Planes. Funkcja AllocBitMap() mogłaby w nowej odsłonie pobierać nową flagę i tworzyć odpowiednią strukturę BitMap (rozszerzoną - nic nie wiemy o rozmiarze tej struktury).
Nowy Amiga OS może zrobić użytek z takiej flagi, która musi być wyzerowana we wcześniejszych wersjach. oraz ewentualnie również z rozszerzenia struktury BitMap (np. 9 pole Planes).
Pierwsze 8 planów w zasadzie nie musi być wtedy nawet wypełnionych buforami planarnymi, ponieważ funkcje nowego Amiga OS zawsze rozpoznają z jaką BitMapą mają do czynienia.
Gdybyśmy jednak potrzebowali używać takiej BitMapy ze starymi funkcjami, albo programami, które grzebią w bitmapie bezpośrednio, to oczywiście te pola musiałyby być również zaalokowane celem pełnej kompatybilności ze starszymi programami. InitBitMap() oczywiście nie ustawiałoby naszej flagi.
Być może można to rozwiązać w ten sposób, że zamiast kombinować z rozszerzaniem struktury BitMap, po prostu wprowadzić nową strukturę typu BitMap Chunky off-screen i dodać nowe funkcje do graphics.library. Wtedy z przyśpieszenia sprzętowego chunky korzystałyby wybrane programy.
Także pewne pole manewru jest w przypadku rozszerzania BitMap, choć przyznam, że rzeczywiście struktury ze wczesnego Amiga OS są trudne w rozbudowie. Programiści Commodore jednak radzili sobie i z takimi problemami wprowadzając rozszerzenia struktur (ViewExtra, ViewPortExtra) oraz obiekty (BOOPSI, Datatypy).
Tak się szczęśliwie składa, że BitMapa ma pole Flags z wieloma wolnymi polami oraz pole Depth oraz na sztywno określone 8 pól Planes. Funkcja AllocBitMap() mogłaby w nowej odsłonie pobierać nową flagę i tworzyć odpowiednią strukturę BitMap (rozszerzoną - nic nie wiemy o rozmiarze tej struktury).
Nowy Amiga OS może zrobić użytek z takiej flagi, która musi być wyzerowana we wcześniejszych wersjach. oraz ewentualnie również z rozszerzenia struktury BitMap (np. 9 pole Planes).
Pierwsze 8 planów w zasadzie nie musi być wtedy nawet wypełnionych buforami planarnymi, ponieważ funkcje nowego Amiga OS zawsze rozpoznają z jaką BitMapą mają do czynienia.
Gdybyśmy jednak potrzebowali używać takiej BitMapy ze starymi funkcjami, albo programami, które grzebią w bitmapie bezpośrednio, to oczywiście te pola musiałyby być również zaalokowane celem pełnej kompatybilności ze starszymi programami. InitBitMap() oczywiście nie ustawiałoby naszej flagi.
Być może można to rozwiązać w ten sposób, że zamiast kombinować z rozszerzaniem struktury BitMap, po prostu wprowadzić nową strukturę typu BitMap Chunky off-screen i dodać nowe funkcje do graphics.library. Wtedy z przyśpieszenia sprzętowego chunky korzystałyby wybrane programy.
Także pewne pole manewru jest w przypadku rozszerzania BitMap, choć przyznam, że rzeczywiście struktury ze wczesnego Amiga OS są trudne w rozbudowie. Programiści Commodore jednak radzili sobie i z takimi problemami wprowadzając rozszerzenia struktur (ViewExtra, ViewPortExtra) oraz obiekty (BOOPSI, Datatypy).
02.02.2016 21:45
[#35]
Re: Google Drive dla AmigaOS 3.x
@Hexmage960, post #34
OK. Wyobraź sobie sytuację, gdy piszą nową wersję Amiga OS z obsługą trybów RTG.
Ale nie piszemy. Ty napisałeś, że AmigaOS od wersji 1 jest w stanie oderwać się od chipsetu. Nie jest. To było początkiem dyskusji. Ale pociągnijmy dalej.
Tak się szczęśliwie składa, że BitMapa ma pole Flags z wieloma wolnymi polami oraz pole Depth oraz na sztywno określone 8 pól Planes. Funkcja AllocBitMap() mogłaby w nowej odsłonie pobierać nową flagę i tworzyć odpowiednią strukturę BitMap (rozszerzoną - nic nie wiemy o rozmiarze tej struktury).
Tak się pechowo składa, że przez fakt bycia kompletnie otwarta od początku istnienia aplikacje mogły ją inicjalizować same bez pośrednistwa systemu operacyjnego. "Bo szybciej". W nowej wersji systemu można ale stare aplikacje nie będą z tym działać. Zerwanie kompatybilności... Jeżeli miałbyś struktury w pełni prywatne problem byłby dużo mniejszy. Wynik: stare aplikacje nie będą działać bo polegają na konkretnej budowie struktur.
Pierwsze 8 planów w zasadzie nie musi być wtedy nawet wypełnionych buforami planarnymi, ponieważ funkcje nowego Amiga OS zawsze rozpoznają z jaką BitMapą mają do czynienia.
Stare aplikacje nie rozpoznają. Wszystko co proponujesz to ograniczenie/zerwanie z kompatybilnością.
Gdybyśmy jednak potrzebowali używać takiej BitMapy ze starymi funkcjami, albo programami, które grzebią w bitmapie bezpośrednio, to oczywiście te pola musiałyby być również zaalokowane celem pełnej kompatybilności ze starszymi programami. InitBitMap() oczywiście nie ustawiałoby naszej flagi.
Bingo.
Być może można to rozwiązać w ten sposób, że zamiast kombinować z rozszerzaniem struktury BitMap, po prostu wprowadzić nową strukturę typu BitMap Chunky off-screen i dodać nowe funkcje do graphics.library. Wtedy z przyśpieszenia sprzętowego chunky korzystałyby wybrane programy.
Takie coś trzeba było zrobić na początku. I nie, nie nowy typ bitmapy tylko bitmapy w pełni prywatne które alokuje się systemem operacyjnym, które nie zwracają struktur widocznych dla programisty itp. No ale dzięki temu co jest to system działał szybciej na 68000. Problem w tym, że to ślepa uliczka. Nie tylko w przypadku graphics.
Programiści Commodore jednak radzili sobie i z takimi problemami wprowadzając rozszerzenia struktur (ViewExtra, ViewPortExtra) oraz obiekty (BOOPSI, Datatypy).
Oczywiście. I jeżeli od samego poczatku wszystko byłoby BOOPSI albo przynajmniej jeżeli w momencie wyjscia 2.0 (chyba wtedy wyszło BOOPSI?) ogłosiliby, że wszystko inne na 100% przestanie działać np w 2.1 (i by musiało przestać ale jednocześnie byłby czas dla aplikacji na dostosowanie się) to by było OK. Wtedy jeszcze byli programiści żeby wypuścić nowe wersje. Niestety osoby odpowiedzialne za rozwój dały przysłowiowej dupy i mamy co mamy.
03.02.2016 08:13
[#37]
Re: Google Drive dla AmigaOS 3.x
@kiero, post #35
Programiści Amiga OS z C= nie chcieli zrywać kompatybilności ze starszymi programami. To moim zdaniem dobrze - baza działającego oprogramowania się stale powiększała - nie trzeba było zaczynać wszystkiego od nowa.
Ja właśnie to lubię w Amiga OS - kompatybilność, stabilność oraz po prostu porządność. Źle napisane programy (np. korzystające z rejestrów sprzętowych w nieudokumentowany sposób) zawsze będą działać źle.
W przypadku BitMap rzeczywiście wydaje się, że trudno jest rozszerzyć nie zrywając kompatybilności. Wiem, że nawet grzebanie w BitMapie ekranu bezpośrednio ogólnie było akceptowalne (ale zalecane było korzystanie z okna typu BackDrop). W przypadku okienek zaleca się korzystać z pola RPort.
Programiści C= jednak byli przygotowani na wprowadzenie nowych kości (mitycznych AAA, bądź RTG) z wieloma Blitterami bądź 32-bitowym Copperem. Myślę, że taki kontynuator Amiga OS od C= miałby mądrze rozwiązane kwestie rozszerzenia BitMap. Ponieważ karta graficzna nigdy nie była w standardzie, to nigdy tego nie zrobiono. I pewnie nigdy się nie dowiemy.
Jeśli chodzi o meritum naszej rozmowy to struktury RastPort, ViewPort w pewnym stopniu przysłaniają realizację wewnętrzną, czyli Blittera i Coppera. Zgodzę się z Tobą, że nie zrywają z Chipsetem całkowicie, ale częściowo.
Obiekty wprowadzono stosunkowo późno, trudno. Jednakże system Amiga OS był tworzony przez dobry zespół programistów. Podejrzewam, że wprowadzanie nowych obiektowo-zorientowanych elementów to była wtedy kwestia czasu.
Dziś komputery są tak szybkie, że z reguły niekompatybilności rozwiązuje się emulacją. Wtedy to było nie do przyjęcia.
Ostatnia aktualizacja: 03.02.2016 08:16:29 przez Hexmage960
Ja właśnie to lubię w Amiga OS - kompatybilność, stabilność oraz po prostu porządność. Źle napisane programy (np. korzystające z rejestrów sprzętowych w nieudokumentowany sposób) zawsze będą działać źle.
W przypadku BitMap rzeczywiście wydaje się, że trudno jest rozszerzyć nie zrywając kompatybilności. Wiem, że nawet grzebanie w BitMapie ekranu bezpośrednio ogólnie było akceptowalne (ale zalecane było korzystanie z okna typu BackDrop). W przypadku okienek zaleca się korzystać z pola RPort.
Programiści C= jednak byli przygotowani na wprowadzenie nowych kości (mitycznych AAA, bądź RTG) z wieloma Blitterami bądź 32-bitowym Copperem. Myślę, że taki kontynuator Amiga OS od C= miałby mądrze rozwiązane kwestie rozszerzenia BitMap. Ponieważ karta graficzna nigdy nie była w standardzie, to nigdy tego nie zrobiono. I pewnie nigdy się nie dowiemy.
Jeśli chodzi o meritum naszej rozmowy to struktury RastPort, ViewPort w pewnym stopniu przysłaniają realizację wewnętrzną, czyli Blittera i Coppera. Zgodzę się z Tobą, że nie zrywają z Chipsetem całkowicie, ale częściowo.
Obiekty wprowadzono stosunkowo późno, trudno. Jednakże system Amiga OS był tworzony przez dobry zespół programistów. Podejrzewam, że wprowadzanie nowych obiektowo-zorientowanych elementów to była wtedy kwestia czasu.
Dziś komputery są tak szybkie, że z reguły niekompatybilności rozwiązuje się emulacją. Wtedy to było nie do przyjęcia.
Ostatnia aktualizacja: 03.02.2016 08:16:29 przez Hexmage960
