Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthornosty
   • CommentTime2 Dec 2014

    
   Jak wszystko pójdzie dobrze i się wyrobię, to w sobotę, dzięki uprzejmości grey'a będę mógł zaprezentować na scenie mój cart TOMEK-8 :)
   
   NIE oznacza to, że projekt jest już ukończony, ale pierwsze egzemplarze "developerskie" trafią niebawem do koderów.
   
   Chcę jednak już teraz, korzystając z rekordowej frekwencji na SV opowiedzieć jak dokładnie TOMEK działa, jakie ma możliwości, jakie mam plany rozwojowe.
   
   Także zapraszam, choć nie znam jeszcze godziny prezentacji.
2. • 2: CommentAuthortebe
   • CommentTime2 Dec 2014 zmieniony

    
   przecież na Allegro te karty są już w sprzedaży od dobrych kilku miesięcy, już nawet pierwsze produkcje mają pojawić się na SV14, Nosty zaspałeś
3. • 3: CommentAuthornosty
   • CommentTime2 Dec 2014

    
   Już nie przesadzaj, były na Atari projekty, które rozwijały się znacznie dłużej.
   PS. W pierwszej chwili aż sprawdziłem :)
4. • 4: CommentAuthoras...
   • CommentTime2 Dec 2014

    
   Ha ha...
   Czy bezrobotniak nie sprzedaje ich na allegro :)
5. • 5: CommentAuthorxxl
   • CommentTime2 Dec 2014

    
   swietny pomysl z taka prezentacja.
   
   na pewno znalazloby sie wiecej takich "wystawcow". ja z przyjemnoscia posluchalbym jak swoj projekt reklamuje i jak o nim mowi sam konstruktor czy programista.
6. • 6: CommentAuthornosty
   • CommentTime2 Dec 2014 zmieniony

    
   xxl - Ty to sobie zarezerwuj na SV dla mnie sporo czasu, bo jeśli paczka, którą Seban mi dzisiaj wyśle, dojdzie na czas, to jeden prototyp z SV przywieziesz do domu :)
7. • 7:
      
     CommentAuthorDracon
   • CommentTime2 Dec 2014

    
   Czy teraz będzie tak, że soft atarowski będzie pisany rozdzielnie - dla "podstawki", dla VBXE i TOMKA? ;o
8. • 8:
      
     CommentAuthorlarek
   • CommentTime2 Dec 2014

    
   Wprawdzie już trochę wiem o projekcie, ale chętnie zobaczę prezentację. Super sprawa.
9. • 9: CommentAuthornosty
   • CommentTime2 Dec 2014 zmieniony

    
   @Dracon - nie mam pojęcia. Nie używam VBXE - jest dla mnie za mało koszerne ;)
   
   W sumie, jeśli rozdzielisz logikę gry od procedur graficznych, to możesz zrobić wersję dla kazdej z tych trzech platform. Ale na TOMKA najłatwiej :)
   
   TOMEK jest pomyslany jako IDE czy też graficzna platforma RAD (Rapid Aplication Development), ale wynikowo obraz generuje Antic.
   Moim marzeniem jest aby służył do łatwego tworzenia na Atari gier dotąd "niemożliwych do zrobienia" czyli np tower defence, mortal kombat itd.
   
   W czasie prezentacji chcę pokazać jak łatwo to się robi w asemberze.
10. • 10:
       
      CommentAuthormaly_swd
    • CommentTime2 Dec 2014

     
    Daj jakiś filmik jak to obecnie działa, aby każdy wiedział o czym jest mowa:)
    Ja widziałem tylko to:
11. • 11: CommentAuthorwieczor
    • CommentTime2 Dec 2014

     

    nosty:

    W sumie, jeśli rozdzielisz logikę gry od procedur graficznych, to możesz zrobić wersję dla kazdej z tych trzech platform. Ale na TOMKA najłatwiej :)

    
    
    I tak to się powinno robić, przy okazji logika gry jest łatwiejsza do ogarnięcia i gra powstaje szybciej. W sumie to na VBXE robi się to łatwo - czy łatwiej czy trudniej niż na TOMKA nie wiem bo go nie używam. Ale dlatego, że go nie mam :)
    
    Nadal Antic generuje obraz, VBXE zastępuje GTIA i ma kilka dodatkowych trybów ale tu się nie będę zagłębiał, dopóki sam się nie zagłębię w VBXE co mam w planie, żeby głupot nie nagadać.
12. • 12: CommentAuthormono
    • CommentTime2 Dec 2014

     
    A widziałeś wersję na VBXE: ->link<- ? :D
    @nosty: Cieszę się na tą prezentację - TOMEK8 rulezuje!
13. • 13: CommentAuthornosty
    • CommentTime2 Dec 2014

     
    @mono - oczywiście, że widziałem i poczułem się wyróżniony :) Choć wiedziałem już wcześniej, że na VBXE jest to teoretycznie możliwe.
    
    @maly_swd - na SV pokaże nowe demko, właśnie teraz nad nim pracuję. TOMEK nie potrafi obecnie wiele więcej, w końcu czy ktoś potrzebuje więcej niż kilkadziesiąt kolorowych duszków animowanych co ramkę? ;) Ale rozwiązałem kilka problemów, które były kluczowe dla przekazania go do twórców gier.
14. • 14:
       
      CommentAuthortdc
    • CommentTime2 Dec 2014

     
    Jestem bardzo zainteresowany, co nosty dla nas przygotowal;)
15. • 15: CommentAuthornosty
    • CommentTime3 Dec 2014

     
    Przygotował? 8-)
    tdc, naprawdę jesteś zbytnim optymistą, jeśli sądziłeś, że wezmę się za prezentację już dwa dni przed zlotem ;)
16. • 16: CommentAuthorwieczor
    • CommentTime3 Dec 2014

     
    Jeżeli ma poniżej 500 slajdów, to amatorka nie prezentacja ;)
17. • 17: CommentAuthornosty
    • CommentTime11 Dec 2014

     
    Pokaz miał zdaje się 24 slajdy :)
    
    A na dokładkę dwa mini-demka pokazane w ramach wild-compo:
    ->link<-
    ->link<-
18. • 18: CommentAuthorkade
    • CommentTime11 Dec 2014

     
    Rewelacja !
19. • 19: CommentAuthormono
    • CommentTime11 Dec 2014

     
    Pralaksa robi wrażenie.
20. • 20:
       
      CommentAuthorjhusak
    • CommentTime11 Dec 2014 zmieniony

     
    Paralaksa była na zakończenie programu.
    
    Albo Porare Raxu. Czy Porarera xu.
    ->link<-
    
    A tak na poważnie - no robi robi wrażenie. jako dopałka do gierek rewelacja. Czekam na strzelankę z miliardem sprajtów.
21. • 21: CommentAuthormono
    • CommentTime11 Dec 2014

     
    Bardzo szybką i dynamiczną. Z efektownymi broniami i wybuchami. Rewelacja będzie :)
22. • 22: CommentAuthortebe
    • CommentTime11 Dec 2014

     
    Nosty, gdy pokazywałeś na telefonie filmik z Tomkiem w akcji, nie zauważyłem nawet że jest tam paralaxa, teraz to dopiero robi wrażenie
    
    cały ekran gry jest odrysowywany przez Tomka?
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime12 Dec 2014 zmieniony

     
    @tebe, nie słuchałeś wykładu :)
    
    Atari komunikuje się z Tomkiem pod d5xx (dowolnym)
    
    Obraz definiujesz wysyłając dane do flash poprzez D500, a potem już aranżujesz scenę. Pamięć na sprajty i tła - coś około 120 kB, tyle ile pic ma flasha minus core.
    
    A pomysłowe w wyświetlaniu jest to, że Tomek generuje specjalnie spreparowaną linię dla Antica co linię, a DL musi ustawić Anticowi adres na D500. Co linię. Antic sobie tę linię pobiera jak gdyby nigdy nic i wyświetla.
    
    Czyli odpowiedź: ekran można podzielić na okno akcji generowane przez Tomka i resztę (panele etcetery), którą generuje Atari.
    
    Wielkość pamięci okna Tomka jest ograniczona przez 8kB minus dane sprajtów (położenie etc).
24. • 24: CommentAuthornosty
    • CommentTime12 Dec 2014

     
    @tebe - no jest mniej więcej tak jak Kuba opisał. W wypadku tego dema cały ekran jest generowany przez TOMKA. Nie używałem też scrolla Anticowgo. Inaczej mówiąc, wszystkie obiekty na ekranie były co ramkę rysowane od nowa w "pamięci ekranu" w Tomku. Przy czym komendy gdzie co narysować wysyła Atari, czyli Atari steruje, a Tomek rysuje. A dokładniej, to wszystko to jest rysowane w czasie kiedy Antic nie pobiera danych obrazu, bo wtedy komunikacja 6502 z Tomkiem jest zakazana.
25. • 25: CommentAuthortebe
    • CommentTime12 Dec 2014

     
    rozumiem że organizacja danych w pamięci Tomka to 1 bajt = 1 Pixel Atari XE/XL, obraz Atari jest tłumaczony i przetwarzany wewnętrznie na chunky-pixel, dopiero na końcu z powrotem tłumaczony jest na bajty aby Antic mógł go wyświetlić
26. • 26: CommentAuthorgorgh
    • CommentTime12 Dec 2014

     
    nosty, odwalasz kawal potrzebnej roboty
27. • 27:
       
      CommentAuthorjhusak
    • CommentTime12 Dec 2014 zmieniony

     
    @tebe, przy takiej organizacji zabraknie pamięci. Stawiam, że pamięć jest dokładnie tak reprezentowana, jak w Atari. Tam jest 8kB ramu.
    Ponadto przy wywalaniu danych z pica na ekran nie ma zapewne czasu na jakiekolwiek konwersje.
28. • 28:
       
      CommentAuthormaly_swd
    • CommentTime12 Dec 2014

     
    Nosty jesteś wielki (chociaż w realu to jakiś 180cm będzie).
    Demko gierki z paralaxem jest extra!
    
    Możesz mi powiedzieć co oznacza skrót TOMEK-8 ?
29. • 29: CommentAuthornosty
    • CommentTime12 Dec 2014 zmieniony

     
    @maly_swd - mam tylko 170cm ;) trochę większy będę kiedy wyjdzie pierwsza porządna gra na tym carcie ;)
    Na SV ktoś mi zwrócił uwagę, że nazwanie carta męskim imieniem jest gejowskie ;) Ale jak widać tolerancja w narodzie rośnie, bo do tej pory nikt się nie dziwił i nie dokuczał. A nazwałem go tak na cześć mojego synka. Chciałem przy tym zachowąć odrobinę tradycję Zenona, który zawsze nadawał swoim cartom imiona, chociaż były to imiona żeńskie.
    Czemu -8 to już kompletnie nie pamiętam, szczególnie, że jest 16-bitowy :D
    
    @tebe, @jakub - to niezupełnie tak jest. Tzn faktycznie w PIC'u jest 8KB RAM, co wymusza oszczędność. No i programista Atari wogóle nie musi wiedzieć jaka jest wewnętrzna organizacja pamięci. Samodzielnie niczego tam nie "rysuje", a jeśli jakimś rozkazem zażąda danych z pamięci ekranu to dostanie je w formacie Atari. Antic rzecz jasna też.
    
    W tej chwili organizacja wewnętrznej pamięci ekranu jest identyczna jak w Atari, za wyjątkiem tego, że bajty w linii są zamienione kolejnością: 1, 0, 3, 2, 5, 4, ... 40, 39. Już nie pamiętam dokładnie, ale taka organizacja oszczędzała mi przy rysowaniu obiektów jedną instrukcję swapowania bajtów w słowie (procek jest 16-bitowy). Ocywiście w ten sam sposób są przygotowane też wszystkie obiekty, które mają być rysowane.
    
    Ale to nie jest jedyna możliwość. Bo to nie jest tak jak napisał Jakub że nie ma czasu na konwersję podczas podawania danych Anticowi. Wprost przeciwnie: przy 40MIPS'ach czasu jest mnóstwo :)
    Dlatego ajcek albo xxl (nie pamiętam już który z nich) zasugerowali mi np żebym wogóle nie robił pamięci ekranu, tylko bufor jednej linii i na podstawie położenia obiektów rysował linię za linią.
    Najpierw odrzuciłem to rozwiązanie jako zbyt skomplikowane, ale teraz widzę, że ma sporo plusów. Całościowa wydajność TOMKA mogłaby wtedy wzrosnąć. No i wolne parę KB pamięci to bardzo przydatna rzecz. Gdyby chcieć się bawić np w grafikę 3D itd, czy przekształcenia geometryczne obiektów itd.
    Także przemyślę to jeszcze.
    
    Rozważam jeszcze jedną możliwość, przy zachowaniu obecnego wariantu, tzn pamięci ekranu na którym rysuję całe obiekty. Myślę, czy dla trybów w którym jeden pixel kodowany jest na 2 bitach, nie rozbić pamięci ekranu na dwie części: w każdej z nich jeden pixel to byłby jeden bit. Czyli jeden bajt z pierwszej części zawierałby bity parzyste 8 kolejnych pixeli, a odpowiadający mu bajt z drugiej części bity nieparzyste. W taki sam sposób byłby przechowywane obiekty.
    Taka organizacja pozwoliłaby mi łatwo rysować w trybie, kiedy kolor 00 ma być przeroczysty. Ale jeszcze sprawdzę czy mi się to opłaci, czy nie lepiej zastosować konwersję bitów za pomocą tablicy.
    
    Ale jak pisałem to są wszytsko szczegóły techniczne, które mogą nie interesować programisty od strony Atari. Chyba, że będzie chciał wykorzystywać tylko "blitter" i używać TOMKA bardzo "niskopoziomowo".
30. • 30:
       
      CommentAuthorjhusak
    • CommentTime12 Dec 2014

     
    Hehe. Ja swego czasu zaprojektowałem prostą bibliotekę dla mikrokontrolerów avr - definiowało się kontrolki - przyciski, pola tekstowe i listy rozwijane - oraz ich położenie, kolejność odwołań zgodna z kolejnością w liście, a odrysowywanie całego ekranu punkt po punkcie powodowało ich rysowanie wraz z ekranem i ich stanem w odpowiednich miejscach. W ogóle nie używało to pamięci na żadne bufory, a wyglądało ślicznie. Inna sprawa, że cykl odświeżania ekranu zajmował ok. sekundy dla kolorowego ekraniku typu 160x120.
    
    Da się, wiem. Nie wiem, jak to jest w picu zrealizowane, ale mamy w sumie ok. 20 cykli pica na cykl atari, co przy pobieraniu danych max co drugi cykl przez antic mamy 40 cykli na przygotowanie bajtu. Może nie wystarczyć przy natłoku sprajtów w konkretnym miejscu, czy też dużej ich ilości w ogóle.
31. • 31: CommentAuthortebe
    • CommentTime12 Dec 2014

     
    czyli Tomek-8 pozycjonuje duchy programowe co piksel odpowiednio przesuwając bity obiektu z pamięci wewnętrznej 128kb w locie ?
    
    na standardowym Atari większość czasu CPU zajęłaby właśnie taka zabawa z przesuwaniem bitów, chyba że poświęci się pamięć na przechowanie duchów w pamięci po 4 warianty, każdy z przesunięciem o piksel jak np. w Bomb Jack
    
    a co z maską, czy jest potrzebna, jeśli odrysowuje wszystko od nowa, czyli tło i duchy, to w sumie nie będzie potrzebna, chyba że będzie ktoś chciał zaoszczędzić cykli
    
    czy ma operacje na duchach jak VBXE na blokach pamięci, czyli odbicie lustrzane w pionie, poziomie? to pozwala zaoszczędzić pamięci, postać jest skierowana w prawo, jeśli chcemy w lewo, to sprzętowo odbija lustrzanie
32. • 32: CommentAuthornosty
    • CommentTime13 Dec 2014 zmieniony

     
    @tebe, w PIC'u jest znacznie bogatszy asembler. Np ma rozkaz:
    SL W2, #x, W4
    który przesuwa w lewo zawartość rejestru W2 o liczbę bitów x (0-15) i wynik zapisuje w rejestrze W4. To wszystko w 1 cyklu. Rejestrow Wx jest 16 i każdy obejmuje całą pamięć RAM + mapowaną część pamięci programu. To pozwala poszaleć.
    W moich procedurach rysujących w tej chwili najbardziej zwalnia konieczność obcinania obiektu na lewym i prawym brzegu ekranu. Ten problem by odpadł, gdybym mógł sobie pozwolić na bufor pamięci z lewej i prawej strony każdej linii. Ale nie mam takiego komfortu, chyba, że niewielki marginaes, dla małych obiektów.
    Dlatego jeśli programista wie, że obiekt nie będzie wystawał, to może użyć innych znacznie szybszych procedur, które przygotowałem na taką okoliczność.
    
    Maska jest potrzebna zawsze, jeśli chcesz rysować z częściową przezroczystością. To, że odrysowujesz co ramkę cały ekran nic tu chyba nie zmienia?
    Przy czym rozróżniam dwa rodzaje przezroczystości:
    1. obiekt jest 4 kolorowy (lub 2 w trybie hi-res), i niektóre jego elementy mają być przezroczyste niezależnie od koloru.
    2. obiekt ma 3 kolory, a kolor 00 definiuje przezroczystość.
    
    Punkt 1 jest teraz zaimplementowany, ale wymaga oczywiście pliku maski, który zajmuje tyle samo miejsca w pamięci obiektów (części pamięci programu) co obiekt. A mógłby o połowę mniej (dla trybu 4-kolorowego).
    
    Punkt 2 muszę zrobić, i kombinuję jak będzie najwydajniej. Stąd pomysły innej organizacji pamięci ekranu (np. rozdzielenie bitów parzystych i nieparzystych do różnych obszarów).
    
    Jeśli masz dobry pomysł na wydajne rysowanie z przezroczystością to byłbym wdzięczny, bo sam nic nie znalazlem, a mam wrażenie, że odkrywam koło od nowa.
    
    Odbicia obiektów są prawie na samej górze mojej listy todo. To musi być.
    Można by też dodać przekształcenia geometryczne: obrót, skalowanie, rozciąganie, ale to akurat jest pod koniec mojej listy.
33. • 33: CommentAuthorxxl
    • CommentTime13 Dec 2014 zmieniony

     
    mam przepisany caly VectorGenerator na 6502, mysle ze raczej nie byloby problemu z implementacja na Tomku8. efekt bylby taki, ze po kosmetycznych przerobkach mozna by bylo odpalac na maluchu takie gierki jak Asteroids.
    tu przyklad dzialania tego emulca na atari:
    

    
    
    sprawa dwa. chce przygotowac pamiec ekranu tak:
    1. tryb tekstowy, uzywam 32 znakow aby antic pobieral z generatora znaki tylko z jednej strony (drugiej strony zestawu znakow), tworze sobie ekran atrybutow o wielkosci takiej jak ekran w trybie tekstowym. na ekranie atrybutow uzywam bajtow gdzie najmlodsze bity sa brakujacymi bitami numeru znaku z pamieci ekranu a reszta to moga byc kolory i inne bajery.
    2. kopiuje pamiec ekranu i atrybutow do Tomka8 - niech to bedzie 1,8 kb jednorazowo a w normalnym trybie (podczas zabawy) licze nie wiecej jak 100 bajtow.
    3. ustawiam program antica tak, zeby kazda linie czytal z tego samego miejsca w pamieci atari - pamiec ekranu to 0,1,2,3...31.
    4. ustawiam antica tak, zeby pobieral znaki od $D4 (granica 1kb)
    
    oczekuje ze atari wyswietli mi 256 zetaw znakow w trybie tekstowym + atrybuty np. kolory czy inwersja. oczywiscie zestaw znakow znajduje sie w pamieci Tomka ale nie w operacyjnej zeby nie pozeral cennych 8 KB.
    
    jest to mozliwe?
34. • 34: CommentAuthorKonop
    • CommentTime13 Dec 2014

     
    @Nosty. Przy wariancie z jedną linią możesz również łatwo policzyć kolizje pomiędzy obiektami, podobnie jak realizuje się to sprzętowo. Wystarczy tablica statusów występowania obiektu w danym miejscu (pozycji X). Pojedynczy element tablicy musi mieć rozmiar bitowy odpowiadający maksymalnej liczbie obiektów.
    
    Rozmiar samej tablicy odpowiada maksymalnej szerokości wiersza (384 piksele?). Sortujesz obiekty wedle pozycji pionowej.
    Inicjujesz tablicę na wartości false (brak kolizji).
    Renderujesz obiekty w kolejności posortowanej, linia po linii, obiekt po obiekcie. Gdy obiekt w danym wierszu jest nieprzezroczysty ustawiasz na odpowiedniej pozycji X bit odpowiadający numerowi renderowanego obiektu (funkcja OR).
    
    Na koniec renderingu klatki obrazu dysponujesz informacją o kolizjach pomiędzy obiektami.
    
    To rozwiązanie jest fajne, gdyż nie wymaga dużych ilości pamięci i jest proste w realizacji.
35. • 35: CommentAuthorKonop
    • CommentTime13 Dec 2014

     
    Technicznie rzecz biorąc, potrzebne są dwa bufory:
    
    a) wynikowy, opisany powyżej, na podstawie którego podejmujemy decyzję, czy faktycznie nastąpiły kolizje
    b) tymczasowy z flagami występowania obiektów w obecnym wierszu
    
    Należy scalać informacje z bufora tymczasowego z buforem wynikowym - co wiersz. Bufor tymczasowy należy inicjować co wiersz, natomiast wynikowy - jednokrotnie. Nie powinno to obciążyć nadto Tomka.
36. • 36: CommentAuthorKonop
    • CommentTime13 Dec 2014

     
    Niestety, powyższy algorytm nie zadziała. Potrzebny jest bardziej wyrafinowany. Pomyślę nad takowym.
37. • 37: CommentAuthornosty
    • CommentTime14 Dec 2014

     
    @Konop - cieszę się z Twojego zainteresowania. Pixelowe wykrywanie kolizji to coś o czym nawet nie myślałem - wydało mi sie za trudne i obciążające nawet dla Tomka. W planach średniego zasięgu miałem jedynie zrobienie kolizji na obiektach definiowanych prostokątami i kołami. Wiekszość koderów, z którymi rozmawiałem uznała to za satysfakcjonujące. Niektórzy twierdzili nawet , że spokojnie poradzą sobie z wykrywaniem kolizji sami po stronie Atari, tylko na podstawie pozycji obiektów.
    
    Weź pod uwagę, że przy kilkuset obiektach na ekranie, raczej nierealne i niepotrzebne jest wykrywanie kolizji "każdy z każdym". Nawet nie ma jak tego raportować do Atari.
    
    Pomyślałem, że każdy obiekt powienien należeć do jednej z kilku kategorii i zależnie od tego brać udział w wykrywaniu i raportowaniu kolizji:
    0 - nie bierze udziału w wykrywaniu kolizji (np tlo)
    1 - obiekty aktywne: kolidują z innymi kategoriami oraz z obiektami własnej kategorii
    2 - obiekty aktywne zewnętrznie: kolidują z innymi kategoriami, ale nie z obiektami własnej (np pociski).
    
    Pewnie pojawiłaby się jeszcze potrzeba innych kategorii. A może warto by stworzyć tabelkę pozwalającą zdefiniować, które kategorie kolidują z którymi. To byłoby najbardziej elastyczne rozwiązanie.
    
    Ale jak pisałem: wykrywanie kolizji nie znalazło się w top-5 rzeczy o które pytali programiści, więc odłożyłem je na później.
38. • 38: CommentAuthornosty
    • CommentTime14 Dec 2014 zmieniony

     
    @xxl - to co chcesz zrobić jest możliwe, ale można to zrobić znacznie prościej. Mam wrażenie, że już kiedyś to omawialiśmy, ale nie mogę znaleźć notatek.
    
    Przede wszystkim, chcę mieć zawsze w pamięci Tomka obraz graficzny, obiekty graficzne itd. Obsługa trybu tekstowego będzie polegała wyłącznie na "zaemulowaniu" go dla Antica. Tzn podawania mu bajtów tak jak chce je pobierać w trybie tekstowym.
    Przy takim podejściu, pamięć zestawu znaków może być ustawiona na $D500, a każdy znak podawany Anticowi będzie miał wartość $00. Następnie, kiedy Antic próbuje pobrać definicję znaku $00 to jest mu ona podawana na podstawie zawartości pamięci obrazu (graficznego) w Tomku. Czyli każdy zwracany znak będzie miał wartość $00, ale każdy będzie miał inną definicję.
    Do tego trzeba oczywiście dodac mapę 5-koloru (lub inversu). Będzie mogła to być mapa bitowa lub bajtowa (choć zajmie więcej pamięci).
    
    Natomiast jeśli faktycznie chcesz się posługiwać znakami przy operacjach na obrazie, to spróbuj o nich myśleć jak o szczeólnym przypadku kafli, o rozmiarze 1 bajta na 8. Możesz mieć w pamięci graficznej Tomka obiekt będący definicją 256 kafli i umieszczać je dowolnie na ekranie. Ale dla procedur, będą to zwykłe obiekty graficzne.
    Obsługa kafli nie ma nic wspólnego z trybem tekstowym.
39. • 39: CommentAuthornosty
    • CommentTime14 Dec 2014

     
    @Konop, a co myślisz o pomyśle rozdzielenia bitów parzystych i nieparzystych w pamięci obrazu (nieważne czy całego, czy jednej linii), oraz w definicjach obiektów graficznych?
    
    Wg mnie, pozwoliłoby to łatwo tworzyć maskę przy rysowaniu w trybie gdzie kolor $00 ma być przezroczysty.
    
    O co mi dokładnie chodzi:
    Załóżmy, że mamy 2 bajty obiektu (definiujące 8 punktów w trybie 4-kolorowym):
    00 01 10 10 00 11 01 11
    
    W pamięci chciałbym je przechowywać w 2 różnych buforach jako:
    bity parzyste: 01000111
    i nieparzyste: 00110101
    
    Jeśli teraz zrobię OR tych dwóch bajtów, a następnie negację, to otrzymam piękną maskę: 10001000.
    Rysowanie to:
    (maska AND tło) OR obiekt
    Przy czym oczywiście tło (a więc pamięć ekranu) też jest w 2 buforach: bity parzyste i nieparzyste osobno.
    
    
    Takie kodowanie pamięci ekranu i obiektów, pozwoliłoby mi też zmniejszyć o połowę wielkość maski przechowywanej w pamięci Tomka, przy trybie rysownia, gdzie obiekt jest 4-kolorowy, a maska przezroczystości definiowana oddzielnie i niezależna od koloru.
40. • 40: CommentAuthortebe
    • CommentTime14 Dec 2014

     
    maska dla takiego podejścia to prekalkulowana tablica 256 bajtów, dla każdej kombinacji 2 bitów można wyznaczyć maskę
    
    z doświadczenie z Bomb Jack-iem wiem że jest to mało praktyczne rozwiązanie, bo duchy programowe aby odróżnić je od tła są obrysowane "czarną" obwódką, czyli kombinacja 00 zamiast symbolizować przeźroczystość powinna zostać zinterpretowana jako kolor, bez dodatkowej maski się nie obejdzie
    
    chyba że Tomek dostanie bogatszą informację o kolorach, co z kolei znowu wiąże się ze zwiększonym zapotrzebowaniem na pamięć
    
    bez maski może działać metoda XOR (EOR), zamiast AND tło, OR obiekt
    wystarcza EOR obiekt, pierwszy EOR kasuje, drugi EOR stawia obiekt
    
    mam nadzieję że TOMEK pozwala wybrać jaką operację przeprowadzić, AND, OR, EOR na bloku pamięci
41. • 41: CommentAuthornosty
    • CommentTime14 Dec 2014 zmieniony

     
    @tebe - tak, też doszedłem do tego, że jeśli kolor 00 ma być przezroczysty, to można użyć tablicy. Ale tablica musi być 8-bitowa, a ja w tej chwili rysując operuję na słowach 16-bitowych. Trzaba by więc żąglować bajtami w słowie, czyli dochodzi kilka cykli w samym środku pętli. Dlatego pomyślałem o tym rozdzieleniu bitów parzystych i nieparzystych na dwa obszary pamięci. Wtedy nie trzeba by tablicy, a maska robiłaby się jedną instrukcją OR jak to pokazałem wyżej.
    
    A przy masce niezależnej od koloru (a pewnie taka będzie faktycznie najczęściej używana) też byłby zysk w takiej organizacji pamięci, bo maska mogłaby wtedy zajmować o połowę mniej bitów. Przecież ta maska składa się zawsze z par 00 i 11, to po co przechowywać te nadmiarowe bity? Rozdzielenie w pamięci obrazu bitów parzystych i nieparzystych pozwoliłoby zredukować wielkość maski o połowę.
    
    Wciąż to rozważam.
    
    Tak, TOMEK pozwala wybrać sposób rysowania: OR, AND, XOR, choć te dwa ostatnie sposoby mają przecież zastosowanie praktycznie wyłącznie w trybie mono?
    
    "bez maski może działać metoda XOR (EOR), zamiast AND tło, OR obiekt wystarcza EOR obiekt, pierwszy EOR kasuje, drugi EOR stawia obiekt"
    
    Nie kumam. Tzn nie kumam tego "bez maski" bo ja robię właśnie (maska AND tło) OR obiekt. (obiekt EOR tło) EOR obiekt, to bez sensu. Możesz bardziej łopatologicznie, albo na przykładzie?
42. • 42: CommentAuthortebe
    • CommentTime14 Dec 2014

     
    łopatologicznie, odpal Gremlins, Mario Bros na XE/XL i zobaczysz jak to działa
43. • 43: CommentAuthornosty
    • CommentTime14 Dec 2014

     
    E no to żadne rozwiązanie :) W trybie hi-res to jeszcze, ale w 4-kolorowym sprawdzi się może jedynie przy małych szybko poruszających się obiektach.
44. • 44: CommentAuthortebe
    • CommentTime14 Dec 2014

     
    sprawdzi się jeśli tło jest mało kolorowe, jak ma to miejsce w MarioBos, Gremlins, zajmuje najmniej miejsca, nie wymaga synchronizacji z ramka etc.
45. • 45: CommentAuthorKonop
    • CommentTime16 Dec 2014

     
    @nosty Możliwość swobodnego definiowania maski wedle upodobań projektanta grafiki jest kluczowa. W Ryśku maski są osobnymi, niezależnymi definicjami, dzięki czemu można zrealizować kontrastowe obramowanie. Kombinacja bitowa %00 (lub dowolna inna) nie musi również być wykorzystana wyłącznie do obramowania, ale jako pełnoprawny kolor użyty do narysowania wnętrza obiektów. Generalnie rzecz biorąc, nie wymuszałbym wiązania pomiędzy maskami, a grafiką właściwą, gdyż znacznie ogranicza to możliwości stworzenia ciekawej grafiki. Istnieją inne techniki optymalizacji zajętości pamięci skrzatów (wykorzystane również w Ryśku :>).
46. • 46: CommentAuthornosty
    • CommentTime16 Dec 2014 zmieniony

     
    @Konop - zgadzam się. I tak jak pisałem maska niezależna od kolorów jest już w tej chwili obsługiwana. Oczywiście, maskę można skompresować od ręki o połowę usuwając bity nadmiarowe (skoro w masce mamy wyłącznie pary 00 i 11), a potem "rozkompresowywać" w locie używając tabeli konwersji do przekształcenia 8 bitów maski w 16-bitowe słowo.
    
    Ale wydaje mi się, że wymyśliłem wygodniejszy sposób wykonywania wszelkich operacji na grafice 4-kolorowej: rozdzielenie pamięci ekranu (oraz definicji obiektów) wewnątrz Tomka na dwie części, zawierające odpowiednio bity parzyste i nieparzyste.
    Potem, przy wystawianiu bajtów dla Antica bity z tych dwóch obszarów byłyby łączone "na suwak".
    
    Moim zdaniem ułatwiłoby to:
    - wykorzystanie maski niezależnej od koloru "skompresowanej" do pojedynczych 0 i 1 zamiast par, bez konieczności jej konwersji na postać par,
    - utworzenie w locie i wykorzystanie maski z koloru (dowolnego z czterech),
    - odbicie poziome skrzata,
    - przyszłe przekształcenia geometryczne (zoom, obrót).
    
    Po prostu mam wrażenie, że bardzo niewygodnie robi się wszelkie operacje na grafice, mając reprezentację pixela na dwóch kolejnych bitach. W moim pomyśle każdą operację trzeba by wykonywać podwójnie (na dwóch obszarach pamięci), ale w każdym z nich pielowi odpowiada tylko jeden bit, co upraszcza operacje.
    
    I dlatego chciałem poznać Twoją i tebe opinię na temat tego pomysłu organizacji ekranu.
    Jeśli niezbyt zrozumiale to opisałem to dajcie znać.