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:
      
     CommentAuthorKaz
   • CommentTime9 Apr 2014 15:04 zmieniony

    
   W starej poczcie znalazlem mail od Mono z takim oto fajnym programem z 1994 roku do wyswietlania okienek w trybie hires, zdaje sie ze jeszce nie byl publikowany na AOL, moze sie komus przyda do prostych gier czy uzytkow:
   
   

   Mono:

   W załączniku macie źródła i dane. Okna są w trybie OS0 (gr.0) i korystają ze zwykłego zestawu znaków - nie ma tu żadnych sztuczek. Mankamentem tego jest niestety to, że mamy tylko 128 znaków do dyspozycji. Póki co wykorzystywany jest zestaw GWIN.FNT (uwaga - plik z binarnym nagłówkiem) bez polskich znaków. Zestawy GW.FNT i GWPL.FNT nie różnią się od siebie i zawierają polskie znaki, ale na razie nie są wykorzystywane.
   
   Ilość okien jednocześnie wyświetlanych na ekranie jest chyba ograniczona do 255. Każde okno ma swoją strukturę w pamięci i można ją swobodnie modyfikować (np. pozycje rogów okna, położenie menu, rodzaj kursora w menu, itd. - bardziej szczegółowy opis podeślę Wam kiedy przeanalizuję co robi znaleziony kod) bez oglądania się na inne elementy na ekranie. Kiedy trzeba zaktualizować ekran wywołuje się jedną procedurę, która przerysowuje cały ekran naraz. Ten system okien korzysta z pomysłu Jeff'a polegającym na tym, że okna nie mają bufora w którym zachowuje się to, co leży pod spodem - tutaj w pamięci przechowywana jest tylko treść okna. Program odświeżający ekran rysuje cały ekran znak po znaku i rozstrzyga z którego okna ma wziąć ile znaków. Metoda nie jest najwydajniejsza, ale pozwala zaoszczędzić trochę bajtów.
   
   Treść okna jest zwykłym tekstem zakończonym znakami EOL ($9b). System sam rozpoznaje koniec lini i oczywiście wypełnia resztę spacjami. Treść okna może być rysowana z dowolnym offsetem (na plus i na minus) w każdej osi.
   
   GWIN.COM to programik demonstracyjny pokazujący kilka okien. Zmieniające się tło to pewien eksperyment polegający na generowaniu każdego znaku przy przerysowywaniu desktopu z generatora liczb losowych. Treść desktopu może być analogicznie, jak okno (bo niczym się od niego nie różni) zadana również na stałe i można tam np. wygenerować jakiś obrazek w ascii-art (mamy zdefiniowane chyba 4 znaki półcieni co daje nam 9 poziomów) lub animować jakąś plazmę. Klawiszami strzałek można przesuwać treść okna informacyjnego.
   Aby uzyskać kontrolki, które potrzebujecie do gry (checkbox, radio, zwykły button) można by zmodyfikować zestaw znaków i dopisać odpowiednie komponenty do systemu okien.
   
   Ten system nadaje się w sumie bardziej do jakichś narzędzi niż do gier (chyba, że tekstowych, czy jakichś decyzyjnych w stylu "panowie i poddani" czy "businessman"), ale ma zaletę taką, że jest względnie szybki. Może się jednak okazać, że będziecie potrzebować czegoś innego.
   Pooglądajcie sobie go i sami zdecydujcie. (...)

   
   
   W katalogu uzytkow tutaj:
   ->link<-
   
   

   • Gephard Windows.atr
2. • 2:
      
     CommentAuthorKaz
   • CommentTime9 Apr 2014 15:04

    
   Jeszcze znalazlem uzupelniajace informacje, bardzo cenne, dzieki Mono!
   
   

   Mono:

   Oczywiście, że można by wymieniać generator znaków, lub jego część. Możnaby też spróbować przełączać generatory co kilka wierszy i zmodyfikować engine żeby dało się więcej grafiki wpakować (znaki i ramki okna zostałyby w tym samym miejscu w każdym generatorze, chyba że w danym wierszu nie byłyby wykorzystywane).
   Po przejrzeniu zestawów widać, że:
   - w GWIN.FNT dałoby się dostać 35 znaków na grafikę eliminując: pełne ramki, copyright, strzałki, #,$,%,&,',*,+,/,<,=,>,@,\,^,_ i |. Znaki [ i ] zostawiłbym do markowania ew. przycisków, ale może warto by je np. poprawić, żeby nie były takie płaskie. W razie potrzeby można je też usunąć dzięki czemu dostaniemy 37 znaków na grafikę (może da się też wykorzystać półcieniowania).
   - w GWPL.FNT usuwając te same znaki możnaby dostać 21/23 znaki dla grafiki.
   Zestawy znaków można by przełączać co kilka wierszy tekstu zależnie od zajętości elementów graficznych - najprościej to zrobić trzymając gotowe zestawy w pamięci i zamieniając 24 bajtową tablicę chtab z adresami zestawów a na dli zrobić prostą procedurę:
   
   dlint equ *
   sta areg
   sty yreg
   ldy vcount
   lda chtab-15,y
   ;sta wsync
   sta chbase
   ldy yreg
   lda areg
   rti
   
   chtab org *+93
   
   Komórki areg i yreg powinny być na stronie zerowej (np. $80 i $81). Adresy zestawów znaków dla kolejnych wierszy trzeba ustawiać w tablicy chtab z interwałem co 4 np. 0 wiersz w bajcie 0, pierwszy wiersz w bajcie 4, 23 wiersz w bajcie 92. No i oczywiście ustawić dli w dliście. Taka niedogodność jest podyktowana tym, żeby jak najszybciej zmienić adres zestawu znaków zanim ANTIC zabierze nam całą pierwszą linię ekranową nowego wiersza trybu na pobranie danych obrazu.
   Gdyby widać było mruganie związane z przełączaniem zestawów na końcu ostatniej linii skanningowej wiersza to można albo odkomentować sta wsync, albo może pomoże umieszczene areg i yreg w normalnej pamięci a nie na stronie zerowej (osobiście wolę takie rozwiązanie niż blokowanie procesora wsync'em).
   Oczywiście nie musimy mieć 24 zestawów znaków w pamięci :)
   Jeśli do grafik wystarczy te 35 znaków wtedy nie trzeba dli a tylko podczas przełączania grafik podmieniać zawartość tychże 35 znaków. Ale pewnie chcielibyście mieć raczej więcej grafiki, niż mniej :)
   
   Gdyby procedura dli dalej była za szybka można jeszcze zamiast zapisywać/odtwarzać rejestry z komórek umieszczać je na stosie:
   
   dlint equ *
   pha
   tya
   pha
   ...
   pla
   tay
   pla
   rti
   
   Trzeba to po prostu dobrać.
3. • 3: CommentAuthormono
   • CommentTime9 Apr 2014 15:04

    
   Gwoli sprostowania. Nie jest to kompletny system, ale próby. Są tam mechanizmy do wyświetlania treści okna i skrolowania. OIDP są jeszcze jakieś kursory (poziome i pionowe). Nigdy nie zostało to ukończone, ale można by pomyśleć nad rozwinięciem tego w pełną wygodną bibliotekę (niedużą) do wykorzystania we własnych programach narzędziowych.
   Ach te "okienka" - miałem wtedy fazę na to :) Prawdę mówiąc z wszystkich okienek najbardziej podobały mi się Borlandowe Turbo Vision i taka właśnie biblioteczka na Atari byłaby bardzo fajna. Oczywiście bez tych wszystkich myszek, dżojstików i innych niepotrzebnych rzeczy - sama klawiatura! ;>
4. • 4:
      
     CommentAuthortdc
   • CommentTime9 Apr 2014 18:04

    
   Ale myszka na Atari to żaden problem;) Nie wliczając gier które wykorzystują procedury do obsługi myszek z Amigi i Atari ST, to jeszcze mamy systemowe wsparcie dla np. pióra świetlnego czy tabliczki - w mojej ocenie się nadaje, a do tego jest banalne do oprogramowania.
5. • 5: CommentAuthor0xF
   • CommentTime10 Apr 2014 11:04

    
   Bodajże w "Bajtku" były handlery W: i chyba O: pozwalające używać okien jak E:.
6. • 6: CommentAuthorbob_er
   • CommentTime10 Apr 2014 12:04

    
   Gdyby była dostępna jakaś biblioteka z oknami (bo takie okna widzę w formie biblioteki) z podstawowym zestawem widgetów (otwórz/zapisz plik, itp...) - to ja byłbym bardzo szczęśliwy.
   Na swoje rozwiązanie jestem trochę za leniwy, ale mam pewien projekcik, który by rozpędu nabrał.
   
   0xF - kojarzę te Bajtkowe okna. Z tym, że tam one sprowadzały się chyba do ramki.
7. • 7: CommentAuthorwieczor
   • CommentTime10 Apr 2014 13:04

    
   Ciekawe co się dzieje z tym:
   
   ->link<-
   
   Miałem nadzieję że to będzie takie rozwiązanie.
8. • 8: CommentAuthorbob_er
   • CommentTime10 Apr 2014 13:04

    
   Też miałem taką nadzieję. Ale gość chyba za bardzo to rozbudowywuje jak na liba. Dla mnie - to by mogło być oparte nawet na trybie tekstowym. A nawet lepiej by tak było :).
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime10 Apr 2014 14:04

    
   A jakby zaprząc blitter VBXE, to by migiem działało :)
10. • 10: CommentAuthor0xF
    • CommentTime10 Apr 2014 14:04

     

    bob_er:

    0xF - kojarzę te Bajtkowe okna. Z tym, że tam one sprowadzały się chyba do ramki.

    
    Nie. Zapis do nich był ograniczony przez ramkę i nadmiar tekstu był przewijany w ramach okna. A samych ramek było kilka wzorów do wyboru.
11. • 11: CommentAuthorbob_er
    • CommentTime10 Apr 2014 19:04

     
    No, ale jednak ramki okien. Tam nie dało się chyba ich przesuwać (mało potrzebny bajer). Ale nie było też elementów typu button, menu, itd... Nie było też standardowych widgetów...
12. • 12:
       
      CommentAuthorPecus
    • CommentTime11 Apr 2014 13:04

     
    A w IKSie nie było takiego handlera okien przypadkiem? Bo z tego co pamiętam to ten z Bajtka tylko wyświetlał okno i ograniczał wyświetlanie tekstu do tego okna, a ten z IKSa dodatkowo zapamiętywał tło i odtwarzał je po wykonaniu CLOSE (trzeba tylko było zachować kolejność zamykania odwrotną do otwierania). I chyba miał jeszcze jakieś funkcjonalności.... Ale to lata temu było i mogę się mylić :)
13. • 13: CommentAuthormono
    • CommentTime11 Apr 2014 15:04

     
    @tdc: Mysz jest niewygodna przy obsłudze programów :) Klawiatura best solution for ever!
14. • 14: CommentAuthorwieczor
    • CommentTime11 Apr 2014 15:04

     
    @mono: ta, zwłaszcza okienkowych :)
15. • 15: CommentAuthorxxl
    • CommentTime11 Apr 2014 15:04

     
    do obslugi programow na atari sluza klawisze:
    
    - START,
    
    - SELECT,
    
    - OPTION,
    
    - HELP,
    
    - RESET.
16. • 16: CommentAuthorpin
    • CommentTime11 Apr 2014 20:04

     
    - a do obsługi niektórych wystarczy po prostu RESET ;)
17. • 17: CommentAuthorwieczor
    • CommentTime11 Apr 2014 23:04 zmieniony

     
    A joysticki, paddle, trackballe, tabliczki graficzne i myszy dedykowane specjalnie do xl/xe wynaleźli masoni :)
    Kazdy interfejs ma specyficzny kontroler z ktorym dziala najlepiej, okienkowy - to zalezy, co jest w okienkach, czy mozna je przesuwac, przewijac, przelaczac sie pomiedzy nimi bez zamykania - ale jesli tych cech nie ma to sa tylko pseudo-okienka :)
    
    Co do klawiszy nomen omen konsoli, same ich nazwy wskazuja do obslugi jakich programow sluza - po prostu do gier.
18. • 18: CommentAuthorpin
    • CommentTime12 Apr 2014 19:04

     
    Czyli już wiesz, czym zajmuje się w wolnych chwilach XXL ;)
19. • 19: CommentAuthorflashjazzcat
    • CommentTime14 Apr 2014 22:04

     
    The "New GUI" is still happening, but it's rather a large project and I have to fit it in around other things. But those with patience will be rewarded. :)
20. • 20: CommentAuthorwieczor
    • CommentTime14 Apr 2014 23:04

     
    But those with patience will be rewarded. :)

    
    
    I'm infinitely patient... So, if reward can be chosen, I'd like to get new Lamborghini and small house with swimming pool at Florida, thank you :)
21. • 21: CommentAuthorflashjazzcat
    • CommentTime15 Apr 2014 13:04

     
    Any reward, as long as it's software. :)
22. • 22: CommentAuthorwieczor
    • CommentTime15 Apr 2014 14:04

     
    Ok, before I'll start pasting links here, I'll let you rethink your commitment :)
23. • 23: CommentAuthorflashjazzcat
    • CommentTime15 Apr 2014 19:04

     
    :)
    
    BTW: Is it possible to interact with the Gephard demo in any way? I tried pressing keys, etc, and nothing happened. The idea of using character data as window content is most interesting, however. I chatted some time ago with Andym00 about the concept.
    
    If a text-based UI is required, meanwhile, the UI employed by FDISK (APT) and UFLASH could be made fit for public consumption as a library if there is any interest. It has a complete dialog manager with drop-down lists, radio and command buttons, etc, and is object-oriented, in as much as several dialogues can be opened simultaneously. It certainly speeds up development by a significant factor. I've just had no motivation to make it fit for release, however. The library is around 4KB long, IIRC.
24. • 24:
       
      CommentAuthormgr_inz_rafal
    • CommentTime15 Apr 2014 20:04

     
    You can move text inside a window by using - = + and *.
25. • 25: CommentAuthorflashjazzcat
    • CommentTime15 Apr 2014 21:04

     
    Ah, thanks: that works.