Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez Fox
Jakiej synchronizacji? Jakie postrzępienie?
dla wyłączonych "badlines" tracimy 5-y kolor, pierwszy wiersz obrazu i ostatnie 4 linie obrazu
Dlaczego?
Podpisuję się pod uwagami Bobera. Poza tym dlaczego tylko 10 minut na demo?
Święta racja.
:) Pierwszej linii (ze skrolem) nie dasz rady wyciągnąć, bo DCTR liczy od VSCROL do 7. Za to drugą (z wyłączonym skrolem) wyciągniesz, bo DCTR liczy od 0 do VSCROL. Możesz używać po 8 linii z fontu: np. ustawiasz VSCROL na 12, a po ósmej linii przełączasz font i VSCROL na 4. Znowu 8 linii (DCTR w tym czasie od 8 do 15, z fontu brane linie 0-7) i przełączasz font i VSCROL na 12. Itd.
Można też w drugą stronę: aby mieć badlinie w każdej linii i co za tym idzie możliwość podkładania 5-go koloru co linię, a nie 8.
Przy okazji, dziękuję za przedruk.
Tryb znakowy nic nie daje filetom, a tylko kradnie cykle. Bufor krawędzi możesz przecież zorganizować tak jak na pierwszym rysunku, a blitować hektarem kodu do zwykłego trybu graficznego. Tak zrobiłem w Drunk Chessboard.
tebe: bad lines można się pozbyć manipulując VSCROLem. Można je uzyskać dowolnie, od 1 do 240 na ekranie.
Spróbuj Atari800Win PLus w wersji 3.1 - bazuje na Atari800 1.2.4 i po wybraniu odpowiedniej rozdzielczości będzie chodzić tak samo szybko.
Sikor: powodzenia.
... oby nie było tak jak z internetową wersją energy, gdzie wszystko zrobiliśmy sami i tak naprawdę nowy artykuł dołożyłem sobie ... sam :)
No ale daliśmy radę, bo wzięliśmy się solidnie do roboty a nie gdybaliśmy na forum. :)
Do identycznej poprawki też linia 166 odpowiedzialna za wizualizację. Skomitowałem właśnie poprawki w tych dwóch liniach.
Czy zmiana rozwiązuje problem?
Jaki Mac?
Spróbuj zmienić w 189 linii libasap-xmms.c FMT_S16_NE na FMT_S16_LE. Jeśli to nie pomoże, to w 39 linii 16 na 8. Jeśli to nie pomoże, wystaw WAV z nagraniem tego, co słyszysz.
Krótki: możemy zacząć, oczywiście w nowym wątku.
Pomysł jest dobry. W ZIPie mogłaby się znaleźć też okładka kasety (PNG lub JPG), oryginalna instrukcja (PDF), itp.
FUJI napisał/a:W jednym pliku atr nie przechowuje się zawsze jednego programu, w jednym pliku cas też nie trzeba. Dlaczego mojej ulubionej kasety z programami w basicu nie mam przechowywać w całości w jednym pliku cas ?
A niby dlaczego miałbyś tak robić, skoro zdrowy rozsądek podpowiada inaczej? Chyba tylko z sentymentu, ale skoro tak, to chyba lepiej żebyś nie miał możliwości przewijania inaczej niż po blokach, żeby było to bliższe pracy z rzeczywistym magnetofonem ;)
Mogę zrozumieć oba podejścia:
a. Chcemy łatwo odnaleźć grę, mieć porządek w plikach, bezproblemowo ją wczytać.
b. Chcemy jak najwierniej symulować rzeczywisty sprzęt - widzieć trójwymiarowy model magnetofonu z licznikiem, wciskanymi klawiszami, odgłosem przewijania taśmy. Podłączanie pliku CAS wygląda jak wkładanie prawdziwej kasety. Widzimy okładkę, na której zapisane są wartości licznika. Powinna jeszcze być operacja czyszczenia głowicy. ;)
W ogóle ten problem powinien zostać rozwiązany w sposób jednolity dla dyskietek i kaset - powinna być możliwość jakiegoś grupowania kilku obrazów taśm/dyskietek w archiwa z możliwością łatwego przełączania pomiędzy nimi.
a. Podobne nazwy plików, różniące się końcową cyfrą lub literą. Atari800Win PLus ma komendę łatwego przekładania takich obrazów dysków - wymaga ona aktualizacji, aby działała też na nazwach takich, jak na atarionline (z nawiasami).
b. Atari800 ma opcję zapisu i odczytu "Disk Set" - pliki tekstowe, w każdej linii nazwa pliku. Moim zdaniem chybiony pomysł.
c. Paczkę trzymamy w ZIP.
laoo: Włączaj swoje poprawki do projektów, a nie twórz własne forki - będzie więcej użytkowników. Np. puściłeś plugin FAIL/Imagine, a kodu źródłowego nie. To niezgodne z licencją GPL. ;)
ASAP nie ma problemów wydajnościowych ani jako aplet Javy ani jako Flash, ani tym bardziej jako .NET.
Nie wiem czy w trakcie trwania wiersza tekstowego.
Też, a nawet w środku linii. W takich przypadkach jednak uzyskiwany efekt nie jest oczywisty.
no dobra, posmialismy sie, masz epi racje - ten tryb to wyjatek, nadal jednak twierdze ze nie jest prawda jakoby "rozne tryby mialy rozna szerokosc bajtowa linii" jak twierdzi jellonek. Po prostu chcialem zauwazyc ze jellonek wprowadza mawa w blad.
jeleniu, owszem, ale to nie zalezy od trybu jak pisales tylko od DMACTL
Mikey, pogrążasz się. Z ośmiu trybów graficznych ANTICa tylko 3 mają 40 bajtów na linię: GR.7, GR.8 i GR.15, a "wyjątki" to GR.3, GR.4 (po 10 bajtów), GR.5, GR.6 i GR.14 (po 20 bajtów).
Liczba bajtów w linii to nie wszystko. Mają jeszcze znaczenie: liczba bitów na piksel oraz proporcje.
To jest przyszłość emulatorów. Coś z naszego podwórka: ASMA.
- Mozesz podac przyklad trybu graficznego (bo o takich tu mowa) ktory ma pamieciowo inna szerokosc linii niz 40 bajtow?
- Gr.3
- przeciez to jest 40x24
LOL, jesteście lepsi od basha. :D
Uniwersalną procedurę w BASICu masz w poście #9. Jeśli jest dla Ciebie dużo za wolna i potrzebujesz w całości w asemblerze, to napisz, dla którego trybu graficznego.
Są wyniki gfx compo! Składam wyrazy uznania wszystkim uczestnikom.
mam nadzieję że się to nie przerodzi w odrestaurowanie tematu, a jedynie go zakończy
Masz na myśli offtopic.
Wracając do tematu: poziom prac w konkursie graficzno-scenowym na AOL jest bardzo wysoki i nie wiadomo, czy Powrooz wygra. :)
Bresenham jest najszybszy i najdokładniejszy.
Chyba w Bajtku był artykuł o optymalizacji rysowania okręgu - zaczęto od sin+cos, później wykorzystano symetrię, a później równanie okręgu (pętla FOR po X z krokiem 3, wyliczanie Y, DRAWTO).
E no, jest dość optymalna. Można orować z #$f0, co likwiduje skrupuły przed wyrzuceniem anda. ;)
Prostując:
RTCLOCK cyka co ok. 20ms w PAL i 16.67ms w NTSC. Pytałeś o 10 ms, czego dobrym przybliżeniem będzie:
ldx #155
delay_loop stx $d40a
dex
bne delay_loopCykl w Atari zawsze trwa tyle samo. Laoo miał na myśli DMA ANTICa oraz przerwania.
atari.area forum » Posty przez Fox
Wygenerowano w 0.061 sekund, wykonano 27 zapytań