25.11.2012 01:49
[#92]
Re: Kolejny hicior w natarciu...
@gx, post #88
"ale nic poza tym (ilosc bitow koloru jest przepisywana na wywolanie systemowe (szczesliwie zgodne z SA_Depth) i na tym wlasciwie koniec"
Sugerujesz że zmiana jednego parametru w poleceniu jest równie łatwa jak napisanie procedury w AMOSie ? procedury która powstała pięc lat po wprowadzeniu kości AGA ? I nie była tak prosta i tak oczywista jak zmiana jednego z parametrów polecania w GFA Basicu.
Problem polega na inności sprzętów 8 i 16 bitowych, to co w ośmiobitowcach robiło się przez peek i poke w szesnasto bitowcach tak już nie działało poprawnie.
Nie korzystałem z ekranów w HAMie więc nie będę się wypowiadał na temat ich otwierania.
A wracając do tematu to w GFA Basicu wystarczyło zmienić jeden parametr w poleceniu a w AMOSie potrzeba było do tego samego całej skomplikowanej i wieloliniowej procedury która została upubliczniona w momencie kiedy praktycznie nie była już potrzebna. Możesz oczywiście udowadniać że dzięki temu w AMOSie było łatwiej, szybciej i lepiej, tylko kto w to jeszcze uwierzy ?
Pozdrawiam
Sugerujesz że zmiana jednego parametru w poleceniu jest równie łatwa jak napisanie procedury w AMOSie ? procedury która powstała pięc lat po wprowadzeniu kości AGA ? I nie była tak prosta i tak oczywista jak zmiana jednego z parametrów polecania w GFA Basicu.
Problem polega na inności sprzętów 8 i 16 bitowych, to co w ośmiobitowcach robiło się przez peek i poke w szesnasto bitowcach tak już nie działało poprawnie.
Nie korzystałem z ekranów w HAMie więc nie będę się wypowiadał na temat ich otwierania.
A wracając do tematu to w GFA Basicu wystarczyło zmienić jeden parametr w poleceniu a w AMOSie potrzeba było do tego samego całej skomplikowanej i wieloliniowej procedury która została upubliczniona w momencie kiedy praktycznie nie była już potrzebna. Możesz oczywiście udowadniać że dzięki temu w AMOSie było łatwiej, szybciej i lepiej, tylko kto w to jeszcze uwierzy ?
Pozdrawiam
25.11.2012 11:54
[#94]
Re: Kolejny hicior w natarciu...
@RadoslawF, post #92
Sugeruje tylko, ze nic, ani jote nie rozumiesz co sie do Ciebie pisze, o programowaniu nie wspomne, chociaz na poczatku twierdziles w swojej pelnej proznosci przekonaniu, ze to absolutnie na AMOS 1.x niemozliwe zeby otworzyc ekran AGA, zapomniales tylko dodac, ze to dt. tylko graf. komend AMOSa 
i TYLKO TO CI UDOWODNILEM!, niewazne bylo czy latwiej czy prosciej, teraz tylko przekrecasz kota ogonem zeby wyszlo na Twoje :).
Na otwarciu ekranu systemowego (przy minimum OS3.x, na OS1.x i 2.x nie zadziala, nawet jak beda kosci AGA) z 8 bitplanami konczy sie AGAtowatosc tego GFA Basic... wiec sie tak tym nie rajcuj, bo dalej robisz jak w AMOSie
AMOS nie posiada zadnej komendy otwierajcej ekran systemowy, ale ma scr=intcall(offset) , wystarczy podac offset funkcji OpenScreen z intuition.library, do rejestru a0 (komenda amosa areg(0)=... zaladowac wsk. do struktury i masz to samo :) (ulatwienie polega na tym, ze AMOS otwiera intuition itd...), tylko zeby na tym postawic choc jeden AGAtowski piksel trzeba zrezygnowac z komend AMOSa i uzywac juz funkcji graphics.library poprzez gr=gfxcall(offset) itd... . Czy tak jest latwiej, na pewno latwiej niz jezdzic po rejestrach (poza tym w C pod OS zrobisz podobnie) i zawsze mozna zapakowac to w proste amosowe procedury/funkcje wywolywane w programie w jednej linii :)...
Tak mozna bylo zrobic juz w wersji 1.x, wiec jezeli ktos napisal tak swoj program w AMOS 1.x przed epoka AGA, to tez zmienil tylko jedna wartosc (dok. w strukturze opisujacej ekran) i mial 8 bitplanow, tylko co z tego, jeszcze daleka droga do tego zeby pisac o wykorzystaniu AGA... juz pierwsza bariera na jaka trafia to zbudowanie AGAtowskiej palety, bo do tego jest juz inna funkcja w systemie (setrgb32 zamiast setrgb4)... i GFA Basic nie mogl jej znac, takze masz tylko 12bit palete... co to znaczy, mowiac krotko, witaj w AMOSie
Ostatnia aktualizacja: 25.11.2012 12:08:20 przez gx
i TYLKO TO CI UDOWODNILEM!, niewazne bylo czy latwiej czy prosciej, teraz tylko przekrecasz kota ogonem zeby wyszlo na Twoje :).Na otwarciu ekranu systemowego (przy minimum OS3.x, na OS1.x i 2.x nie zadziala, nawet jak beda kosci AGA) z 8 bitplanami konczy sie AGAtowatosc tego GFA Basic... wiec sie tak tym nie rajcuj, bo dalej robisz jak w AMOSie
AMOS nie posiada zadnej komendy otwierajcej ekran systemowy, ale ma scr=intcall(offset) , wystarczy podac offset funkcji OpenScreen z intuition.library, do rejestru a0 (komenda amosa areg(0)=... zaladowac wsk. do struktury i masz to samo :) (ulatwienie polega na tym, ze AMOS otwiera intuition itd...), tylko zeby na tym postawic choc jeden AGAtowski piksel trzeba zrezygnowac z komend AMOSa i uzywac juz funkcji graphics.library poprzez gr=gfxcall(offset) itd... . Czy tak jest latwiej, na pewno latwiej niz jezdzic po rejestrach (poza tym w C pod OS zrobisz podobnie) i zawsze mozna zapakowac to w proste amosowe procedury/funkcje wywolywane w programie w jednej linii :)...
Tak mozna bylo zrobic juz w wersji 1.x, wiec jezeli ktos napisal tak swoj program w AMOS 1.x przed epoka AGA, to tez zmienil tylko jedna wartosc (dok. w strukturze opisujacej ekran) i mial 8 bitplanow, tylko co z tego, jeszcze daleka droga do tego zeby pisac o wykorzystaniu AGA... juz pierwsza bariera na jaka trafia to zbudowanie AGAtowskiej palety, bo do tego jest juz inna funkcja w systemie (setrgb32 zamiast setrgb4)... i GFA Basic nie mogl jej znac, takze masz tylko 12bit palete... co to znaczy, mowiac krotko, witaj w AMOSie
Ostatnia aktualizacja: 25.11.2012 12:08:20 przez gx
25.11.2012 12:45
[#96]
Re: Kolejny hicior w natarciu...
@gx, post #94
Nie pisałem że to musi być ekran systemowy, wręcz pisałem o ekranie otwieranym komendą AMOSa i porównywałem jej skuteczność z komendą GFA Basica. Pisałem o ekranach 8 bitowych, bo z większa ilością kolorów nie używałem/nie potrzebowałem podobnie jak znakomita większość użytkowników tych języków więc daruj sobie przenoszenie tej dyskusji na inny poziom.
Pozdrawiam
Pozdrawiam
25.11.2012 15:29
[#97]
Re: Kolejny hicior w natarciu...
@RadoslawF, post #96
Daruj sobie usprawiedliwienia 
cytuje #44: ".... W AMOSie rozwiązano to oczywiście inaczej i o ile są różne dodatki czy rozszerzenia to o takich pozwalających na otwarcie ekrany w trybie .... nie słyszałem...":)
Takze wlasnie uslyszales, jak to mowia, lepiej pozno niz wcale... :) . Nie wiedziec czegos to nie jest cos zlego czy powod do jakiegos wstydu, ale wiedziec i tkwic uparcie w miejscu itd... nie sluzy prawdzie. Tez wszystkiego nie wiem, dlatego czytam, slucham, mysle, kojarze fakty, wyciagam wnioski itd... I Tobie tez to radze, nie tylko w tym temacie, ale kazdym innym jaki podejmujesz.
cytuje #44: ".... W AMOSie rozwiązano to oczywiście inaczej i o ile są różne dodatki czy rozszerzenia to o takich pozwalających na otwarcie ekrany w trybie .... nie słyszałem...":)
Takze wlasnie uslyszales, jak to mowia, lepiej pozno niz wcale... :) . Nie wiedziec czegos to nie jest cos zlego czy powod do jakiegos wstydu, ale wiedziec i tkwic uparcie w miejscu itd... nie sluzy prawdzie. Tez wszystkiego nie wiem, dlatego czytam, slucham, mysle, kojarze fakty, wyciagam wnioski itd... I Tobie tez to radze, nie tylko w tym temacie, ale kazdym innym jaki podejmujesz
. 25.11.2012 16:14
[#98]
Re: Kolejny hicior w natarciu...
@gx, post #97
Świetna metoda z tym daruj sobie usprawiedliwienia. To ja tez użyję.
Daruj sobie usprawiedliwienia
Cytat z postu nr. 82, "jezeli tego samego nie przewidzeli w innych jezykach i nie ma odpowiednich dodatkow... to jest praktycznie rownie skomplikowane co w AMOS - jezyki ktore tutaj wymieniamy mieszcza sie w tym samym pradygmacie programowania."
W odpowiedzi otrzymałeś:
Cytat z postu nr.86, "Jak sam przyznałeś nie znasz AMOSa, nie znasz też GFA Basica z którym pierwszego AMOSa porównywałem. Jak skomplikowane jest otwarcie ekranu nie przewidzianego przez autorów języka w AMOSie już wiesz, w GFA Basicu piszesz standardową komendę a w trzecim parametrze zamiast 3 piszesz 8 i masz otwarty ekran 8 bitowy(jeśli komputer na to pozwala). Będziesz nam udowadniał że jest to równie skomplikowane jak w AMOSie ?"
I jak rozumiem udajesz że tych wpisów nie było lub są nie na temat.
O temacie otwarcia ekranów w productivity nawet nie wspomnę, gładko omijasz ten problem próbując go czasami zastąpić otwarciem ekranu w HAM.
W podsumowaniu: "Nie wiedziec czegos to nie jest cos zlego czy powod do jakiegos wstydu, ale wiedziec i tkwic uparcie w miejscu itd... nie sluzy prawdzie. Tez wszystkiego nie wiem, dlatego czytam, slucham, mysle, kojarze fakty, wyciagam wnioski itd... I Tobie tez to radze, nie tylko w tym temacie, ale kazdym innym jaki podejmujesz"
Pozdrawiam
Daruj sobie usprawiedliwienia
Cytat z postu nr. 82, "jezeli tego samego nie przewidzeli w innych jezykach i nie ma odpowiednich dodatkow... to jest praktycznie rownie skomplikowane co w AMOS - jezyki ktore tutaj wymieniamy mieszcza sie w tym samym pradygmacie programowania."
W odpowiedzi otrzymałeś:
Cytat z postu nr.86, "Jak sam przyznałeś nie znasz AMOSa, nie znasz też GFA Basica z którym pierwszego AMOSa porównywałem. Jak skomplikowane jest otwarcie ekranu nie przewidzianego przez autorów języka w AMOSie już wiesz, w GFA Basicu piszesz standardową komendę a w trzecim parametrze zamiast 3 piszesz 8 i masz otwarty ekran 8 bitowy(jeśli komputer na to pozwala). Będziesz nam udowadniał że jest to równie skomplikowane jak w AMOSie ?"
I jak rozumiem udajesz że tych wpisów nie było lub są nie na temat.
O temacie otwarcia ekranów w productivity nawet nie wspomnę, gładko omijasz ten problem próbując go czasami zastąpić otwarciem ekranu w HAM.
W podsumowaniu: "Nie wiedziec czegos to nie jest cos zlego czy powod do jakiegos wstydu, ale wiedziec i tkwic uparcie w miejscu itd... nie sluzy prawdzie. Tez wszystkiego nie wiem, dlatego czytam, slucham, mysle, kojarze fakty, wyciagam wnioski itd... I Tobie tez to radze, nie tylko w tym temacie, ale kazdym innym jaki podejmujesz"
Pozdrawiam
25.11.2012 18:03
[#102]
Re: Kolejny hicior w natarciu...
@gx, post #94
Ja tak sobie myślę, ze dałoby się używać ekranu systemowego w Amosie (przynajmniej w teorii).
I używać tego razem z komendami amosowymi, tylko nie wiem jakby to wyglądało.
W Amosie obraz przechowuje się gdzieś w jakiejś pamięci. wystarczy znać ten dokładny offset.
Następnie stworzyć kilka funkcji w amosie.
1.
By otwierał się systemowy ekran intuition OpenScreen.
2.
Następnie stworzyć komendę swego rodzaju Flip().
Gdzie cała zawartość ekranu amosowego by kopiował na ekran intuition.
Przy tym znać trzeba własnie offset tego amosowego, gdzie trzyma tą grafike.
3.
No i przy tworzeniu takich gierek systemowych trzeba używać na początku funkcji
AmosToBack. By ekran amosa był niewidoczny.
Potem dzięki naszym dwóm nowych funkcji amosowych możemy mieć systemowy ekran.
Ale to taka zwykła nakładka i za pewnie może być powolna.
Program by wygladal mniej wiecej tak:
AmosToBack
INTUITION_SCREEN_OPEN(640,480,hires);
Do
RYSUJ_TU_BOBA() : Rem [Cos tu rysujemy]
FLIP() : Rem [Kopiujemy cala zawartosc amosowego ekranu do intuition-ekranu]
Loop
Ale ciagle by pozostal problem 64-32 kolorowych bobów.
I używać tego razem z komendami amosowymi, tylko nie wiem jakby to wyglądało.
W Amosie obraz przechowuje się gdzieś w jakiejś pamięci. wystarczy znać ten dokładny offset.
Następnie stworzyć kilka funkcji w amosie.
1.
By otwierał się systemowy ekran intuition OpenScreen.
2.
Następnie stworzyć komendę swego rodzaju Flip().
Gdzie cała zawartość ekranu amosowego by kopiował na ekran intuition.
Przy tym znać trzeba własnie offset tego amosowego, gdzie trzyma tą grafike.
3.
No i przy tworzeniu takich gierek systemowych trzeba używać na początku funkcji
AmosToBack. By ekran amosa był niewidoczny.
Potem dzięki naszym dwóm nowych funkcji amosowych możemy mieć systemowy ekran.
Ale to taka zwykła nakładka i za pewnie może być powolna.
Program by wygladal mniej wiecej tak:
AmosToBack
INTUITION_SCREEN_OPEN(640,480,hires);
Do
RYSUJ_TU_BOBA() : Rem [Cos tu rysujemy]
FLIP() : Rem [Kopiujemy cala zawartosc amosowego ekranu do intuition-ekranu]
Loop
Ale ciagle by pozostal problem 64-32 kolorowych bobów.
