i to niby moja wina :)
przecież jest takie bezpieczne coś jak DTA c, DTA d
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNetChat: Nowy klient IRC dla Atari Pierwsza publiczna wersja alfa FujiNetChat, nowoczesnego klienta IRC wykorzystującego interfejs FujiNet.
Gearlynx 1.2.2 Gearlynx doczekał się aktualizacji. Wprowadzono podgląd SCB, wyszukiwanie w pamięci oraz poprawki.
Wyniki FujiCup 2025 Poznaliśmy najlepsze gry na 8-bitowe Atari wydane w 2025 roku według jury oraz publiczności.
Wyniki konkursu i gala FujiCup 2025 Poznaj zwycięzców dorocznego turnieju FujiCup 2025 wspierającego twórców gier na Atari XL/XE.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
atari.area forum » Posty przez tebe
i to niby moja wina :)
przecież jest takie bezpieczne coś jak DTA c, DTA d
a takie tam, natychmiastowy #
p.s.
Fox opisz jeszcze interlace Rybagsa, będzie kolejny artek z przykładowym kodem, może w końcu wypuścisz je z szuflady
a takie tam, natychmiastowy #
p.s.
Fox opisz jeszcze interlace Rybagsa, będzie kolejny artek, może w końcu wypuścisz je z szuflady
użycie w relokowalnym kodzie składni
ldx #<cos
ldy #>coszostanie zinterpretowane jako tryb absolutny # z wartością młodszy/starszy jednak ta wartość nie będzie relokowana
dopiero kod
ldx <cos
ldy >coszostanie zinterpretowany jako młodszy/starszy bajt adresy i będzie relokowany
proszę pamiętać że mads, xasm są dziećmi QA, nie rozumiem tej chęci pisania znaku dodatkowego, zapomnieliście QA
trzeba odpowiednio wybierać przeciwników, jak Kliczko, a nie liczyć tylko na szczęście ;)
Mads 1.9.7 taki kod:
blk reloc main jmp *+3 jmp @+ @: jmp ? ?: rtsjmp *+3 nie tworzy relokowalnego kodu, pozostałe tworzą.
dziękuję za informację, w załączniku wersja mads-a z nowymi poprawkami
zbiór przydatnych algorytmów, przykłady m.in. w Pascalu i jakimś Basicu
spora ilość źródeł efektów graficznych w QBasic-u
był ogłoszony nowy rdzeń 1.26 na głównej? dowiaduję się o jego istnieniu dopiero z tego wątku, co to za marketing dupny
twister, w kilku wersjach
szybki BLUR, poniżej link do opisu kilku szybkich metod blurowania
http://www.gamasutra.com/view/feature/3 … ng_in_.php
na Atari można szybciej jeśli rozdzielimy nasz efekt na dwa bufory których wartości będziemy uśredniać
w pierwszym przebiegu wypełniamy bufor1, następnie blur bufor1 = (bufor1 + bufor2) / 2, wyświetlamy bufor2
w drugim przebiegu wypełniamy bufor2, następnie blur bufor2 = (bufor1 + bufor2) / 2, wyświetlamy bufor1
dwie operacje dodawania 'bufor1 + bufor2' to najszybciej jak się da, zamiast '/2' najlepiej stworzyć tablicę z przeliczonymi wartościami 0..255 * jakiś ułamek typu 0.457
sposób w dwoma buforami jest zdecydowanie szybszy niż uśrednianie wartości wokół piksla
z tego co zauważyłem było kilka wersji playera, właśnie różniących się sposobem odczytu, użyte inne komendy aby co poniektóre karty CF nie siały błędami
może ten player będzie robił za benchmark kart CF ;)
uaktualniony CHESS ZOOMROTATOR, zamiast testu kolejnych zakresów wystarczy operacja 'and $10' lub 'and 8' itp.
przykład realizacji KEFRENSBAR
nowa strona ze źródłami wielu starych efektów
http://www.pouet.net/prod.php?which=17682
źródła dla C64 (ca65) chessboard zoomer, w 256 bajtach
dorzuciłem cytat z Barymag-a #2 na temat ZOOM SCROLLA, jest to opis metody realizacji tego efektu
o zmaganiach w odkrywaniu rotowanej szachownicy :)
kopiowanie w pionie zrealizuje program Antic-a, w poziomie jedna tablica w stylu
ldx bajt_obrazu,y
lda tablica_wspak,x
sta bajt_obrazu+height/2,ycałkiem sensowne, zobaczę jak "rysuje" się takimi eor-owanymi patternami
dodam też że istnieje kolejna możliwość optymalilzacji ze względu na symetryczność górnej i dolnej części szachownicy, dolną cześć trzeba przekopiować "wspak" względem górnej, czyli wyrysowanie szachownicy sprowadza się tylko do połowy obrazu
for j = 0 to height div 2 - 1
for i = 0 to width - 1
Pixels[width-i-1,height-j-1] := Pixels[i,j]
next i
next jsprawdziłem możliwość optymalizacji tego chess zoomrotatora, tzn. dla bloków piksli 4x8 (odpowiednik znaku Atari) powstaje za dużo kombinacji poza pojemnością zestawu znakowego, podobnie dla bloków 4x4, natomiast dla 2x4 (ćwiartka znaku) jest lepiej ale i tak za dużo bo liczba niepowtarzalnych bloków dochodzi do 164
dla bloku 2x2 piksle powstaje stała liczba kombinacji 16, niezależnie czy mamy 64 fazy obrotu dla danej skali powiększenia czy 128 liczba niepowtarzalnych bloków jest stała =16
00,00,00,00
00,00,00,FF
00,00,FF,00
00,00,FF,FF
00,FF,00,00
00,FF,00,FF
00,FF,FF,00
00,FF,FF,FF
FF,00,00,00
FF,00,00,FF
FF,00,FF,00
FF,00,FF,FF
FF,FF,00,00
FF,FF,00,FF
FF,FF,FF,00
FF,FF,FF,FFinnymi słowy dla 64 faz obrotu o zadanej skali powiększenia dla każdego bloku obrazu o rozmiarze 2x2 piksle istnieje 64 bajtowa tablica z informacją o 16 różnych kombinacjach bloków
udało się rozgryźć tą pętlę, dodałem opis CHESS ZOOMROTATOR-a
modyfikując pętle renderująca piksle uzyskać możemy roto-zoomowane pionowe pasy, kwadraty, szachownice jeśli zaczniemy przelączać test dla XP <-> YP
test dla kwadracików (dla pionowych pasów zamiast <8 będzie np. =8)
for j=0 to height -1
for i=0 to width-1
if (xp >> 8) mod 16 < 8 then plot(i,j) = white
xp ...
yp...
next i
xp..
yp...
next jsprawdzałem ile zajmą dane dla rotozooma 128x128 piksli o 64 klatkach obrotu w wersji bez optymalizacji, zapisanie wszystkich wyliczonych ofsetów X:Y dla tekstury zajmie ~1MB, po spakowanie 7Zip-em zejdzie do 128KB, spakowanie ZIP-em ~290KB
teraz wersja z załącznika dla metody z postu #41 która sprowadza się do wyliczenia jednego "kafelka" obrazu a potem to już "stemplowanie" tym kafelkiem tak aby pokryć cały obraz, dane zajmują bez kompresji 49KB
gdyby zamiast ofsetów do tekstury trzymać już gotową wyliczoną teksturę którą tylko wypełniamy obraz, zajętość pamięci zmniejszy się, szybkość "stemplowania" też wzrośnie jeśli będziemy robić to znakami a nie bajtami
ta procka z posta #41 pozwala obliczyć tylko jeden "kwadrat" zoom-rotatora, resztę piksli przepisuje się na tej podstawie dla x-Xofset, y-Yofset
to jest tylko wewnętrzna pętla, reszta jest podobna jak w klasycznej metodzie http://madteam.atari8.info/index.php?prod=fx#rzoom
wg moich domysłów to właśnie ta procka której używają komodorowcy, pozwala to zmniejszyć rozmiar danej klatki animacji, liczymy tylko jej niewielki fragment, resztę na tej podstawie przekopiowujemy
zresztą postaram się zamieścić gotowy przykład
atari.area forum » Posty przez tebe
Wygenerowano w 0.090 sekund, wykonano 16 zapytań