tak, to jest uwzględnione (przesunięcie o pół pixla, dwa bity), inaczej wogóle aktualna AIS nie wyświetlała by HIP-ów
AIS 1.1.9 z aktualnego news-a ma zaimplementowane w/w procedury odczytu/zapisu HIP-a, można obejrzeć to w działaniu
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
atari.area forum » Posty przez tebe
tak, to jest uwzględnione (przesunięcie o pół pixla, dwa bity), inaczej wogóle aktualna AIS nie wyświetlała by HIP-ów
AIS 1.1.9 z aktualnego news-a ma zaimplementowane w/w procedury odczytu/zapisu HIP-a, można obejrzeć to w działaniu
ostatnio próbowałem dodać obsługę rysowania HIP-a w AIS, niestety poległem, odczyt jeszcze działa, ale każdorozowy zapis powoduje zniekształcenie HIP-a, czyli rysujemy kreskę i za każdym razem jak zapiszemy nasz nowy HIP otrzymujemy inną kreskę :)
przyjąłem że tryb 10 jest przesunięty w prawo względem piksli trybu 9, chyba dobrze przyjąłem
tryb 9 76543210 76543210
tryb 10 xx765432 10
odczyt działa tak:
for j:=0 to 199 do
for i:=0 to 39 do begin
v:=buf0[i+j*40];
m:=buf1[i+j*40];
cl0:=Interlace(pal0[buf] , pal1[m shr 4]);
cl1:=Interlace(pal0[v shr 4] , pal1[m shr 4];);
cl2:=Interlace(pal0[v shr 4] , pal1[m and $0f]);
cl3:=Interlace(pal0[v and $f] , pal1[m and $0f]);
buf:=v and $f;
end;
cl0, cl1, cl2, cl3 to kolory RGB piksli powstałych przez zmieszanie kolorów z PAL0 i PAL1 (PAL0 to kolory trybu 10, PAL1 to kolory trybu 9)
problem stanowi zapis, po zapisie obraz ulega przesunięciu, jakby smooth
for j:=0 to h-1 do
for i:=0 to w-1 do begin
x:=getPixel(i*8+0,j); // getPixel zwraca bajt, gdzie:
v:=x shl 4; // starszy nibbl to kolor trybu 10
// mlodszy nibbl to kolor trybu 9
x:=getPixel(i*8+2,j);
m:=x and $f0;
x:=getPixel(i*8+4,j);
v:=v or (x and $0f);
x:=getPixel(i*8+6,j);
m:=m or (x shr 4);
buf0[i+j*w]:=v; // gr9
buf1[i+j*w]:=m; // gr10
end;
obraz jest poddany operacji resize, więc skaczemy co 2 piksle 0,2,4,6,8 itd...
xx xx xx xx
0 2 4 6
jasności dla trybu 9 pobierane sa z piksli 0,4, kolory trybu 10 z piksli 2,6, w teorii powinno być OK, w praktyce tak nie jest
ktoś widzi tutaj jakiś błąd ?
w mojej Atarce KMK montował Pasiu, płytka podpisana przez Pasia (tak jak pozostałe), nie jest to IDEA
nie wiem jak pozostali, ale ja deklarowałbym się na te czekoladki :)
lista dysków z którymi na pewno współpracuje KMK http://atariki.krap.pl/index.php/KMK/J%C5%BB_IDE
ja za drugim razem trafiłem na dysk, który działa z KMK, pierwszy IBM 3.5" nie sprawdził się
jednak można prościej z użyciem ShellAPI
po uruchomieniu pliku OBX widać informację że to build 114 :)
instrukcja uaktulniona, na przyszłość sugeruję sprawdzać w praktyce
v1.8.6 - 1.8.7
- domyślny adres dla .ZPVAR ustawiony na $0080, poprzednio $0000
5 .zpvar candle .byte
6
7
8 FFFF> 2000-2001> A5 80 lda candle
9 end
9 = 0080 CANDLE
i tak trzeba banki zmienic z 4000..7fff na 8000..9fff
gra lepiej niż Covox Candle, niemożliwe ale prawdziwe
no ja też jestem zainteresowany
nie oglądać się na innych tylko robić swoje
kiedyś pobyt na party powodował wzrost motywacji do działania, obecnie co najwyżej wzrost mięśnia piwnego, zreszta na zjazdach C64 też za kołnierz nie wylewają
przyszłość sceny to większa wymiana wiedzy, dzielenie się nią, co nigdy nie było w tradycji sceny zbyt popularne
EDUKACJA:
mała liczba produkcji to też brak edukacji w kwestii spsobów realizacji efektów w demach, kiedyś Probe obiecał napisać pare artków na ten temat, pewnie czeka aż go ktoś przyciśnie, tutaj taka baza wiedzy dla C64 http://codebase64.org/doku.php (ja jednak sugerowałbym aby przedstawiać jakiekolwiek algorytmy w postaci pseudo kodu niż gotowego "zamazanego" kodu asm), ogólnie brakuje informacji o sposobie realizacji danego efektu, np. ostatnio modny efekt na C64, zoom rotator szachownicy, wiem że jest to tylko na znakach, nawet widać wystające narożniki znaków na stop klatkach, nadal nie wiem jak to jest robione
taki zoom scroller z Just Fancy, ile to lat temu było, dopiero niedawno wpadłem na sposób jego realizacji, rzeczywiście ASL, ROL jest w tym przydatne ze względu na zmianę sposobu reprezentacji wyświetlanych bajtów, do kodu Just Fancy nigdy nie zaglądałem bo i tak niewiele by to pomogło, gdyby ktoś podzielił się wiedzą na pewno było by łatwiej
jednak są też do opisania dużo prostsze efekty
innym pomysłem na zwiększenie dostępu do informacji byłoby zebranie dotychczasowych artków z najróżniejszych magazynów traktujących o sensownych sprawach ("Paczka TNQ" jest mało poważna) i umieszczenie ich w jednym miejscu, w postaci HTML, TXT, czyli zwiększenie dostępności artykułów scenowych, ich rozdrobnienie nikomu nie służy
wychodzi na to że demo scena jest freeware, ale wiedza jest już tutaj ściśle reglementowana
JĘZYKI:
aktualnie najczęściej używane to ASM i Turbo Basic, potem Action!, CC65
oprócz CC65 brak innych cross kompilatorów języków wyższego poziomu, zaletą CC65 jest możliwość napisania czegoś na malucha przez osoby które miały kontakt z C na wyższych platformach, a jest takich osób nie mało, wadą tej implementacji C jest spora zasobożerność
chodzi mi po głowie pomysł cross kompilatora Pascala z łatwą możliwością łączenia z kodem ASM, dostępnym typem REAL realizowanym przez pakiet FP Atari (np. FastChip Marslett-a), taki Pascal na pewno byłby łatwiejszy od C i bliższy miłośnikom Basica, TBasic-a
głównie chodzi o uniwersalność, pisząc na PC, masz możliwość też napisać coś dla XE/XL, czasy języków ściśle ukierunkowanych pod konkretny system, wymagające nauki nowej składni etc. nie przekonają wielu aby się ich uczyć, potrzebne są rozwiązania uniwersalne
p.s.
Stryker nie kojarzę abyś napisał cokolwiek kiedykolwiek, narysował, czy nawet próbował coś zrobić więcej, Twoją największą pasją jest naciskanie PLAY i STOP, tak że można zrozumieć Twój ograniczony punkt widzenia
jestem chętny
może zrób Candle listę, także na AtariAge, wtedy może uzbierać się większa liczba chętnych
gdyby MEC (Unfused, Unplugged) był świadom istnienia możliwości realizacji takiego trybu tekstowego HiRes, Lores z pixlem proporcjonalnym 4x4 (HiRes), 2x4 (LoRes) mógłby z niego skorzystać w swoich ostatnich demach, w których króluje tryb znakowy
wymiana pomysłów nie oznacza że ktoś komuś zawłaszczy jakiś efekt czy demo, ten sam efekt można zaprezentować na wiele sposobów
teraz pokrzyżowałem plany Fox-a i będzie musiał zmieniać napisy w demie 'new char mode, first presentation' na 'old char mode, second presentation' ;)
p.s.
rozumiem że tryb 12+ oznacza znak o wysokości 4 linii i standardowej szerokości, dopiero 12++ oznacza znak o połowie szerokości
p.s.#2
może ten tryb będzie bodźcem dla MEC-u aby kontynuowali przygodę z trybem znakowym i stworzyli trzecie demo z tego cyklu (dwukrotnie wyższa rozdzielczość w poziomie i pionie)
jeśli ktokolwiek aktualnie planuje coś zrobić w kwestii jakichkolwiek rozszerzeń, to polecam najpierw kontakt z Candle, może się bowiem okazać że zaczniecie dublować pomysły
chcąc niechcąc Candle zdominował obecnie swoimi zrealizowanymi pomysłami sprzęt 8-bit Atari
lepiej żeby zastosowane pomysły były kompatybilne ze sobą bo na n-tą liczbę wersji softu obsługującą każde rozwiązanie liczyć nie można
Tebe je upubliczni, bez czekania na demo, może komuś się przyda
czekać od 2003 na upublicznienie, masz coś jeszcze w zanadrzu Fox :)
stąd plik z przykładem do pobrania (nie wiem jak na aarea wrzucać pliki)
http://www.atariage.com/forums/index.ph … try1804753
ogólnie jest to połączenie wcześniejszych dokonań Fox-a w temacie trybu Konop-a, z tym że dotyczy on trybu znakowego, tak aby była możliwość użycia szybkiego dostępu do pamięci w stylu Konop-a i dodatkowo była możliwość prezentacji dodatkowej grafiki w rozdzielczości z pixlem jak w Graphics 15 OS
wiersz dzielony jest na pół sposobem opublikowanym przez Fox-a (tryb 9++) czyli rozdzielczość pionowa zwiększana jest sprzętowo , natomiast rozdzielczość pozioma programowo dzięki odpowiednio spreparowanemu zestawowi znaków
zestaw znaków modyfikowany jest tak aby otrzymać 8 kolorów dither (w przykładzie dla ditheru wykorzystane są tylko kolory 712,708 i 711, kolory 709 i 710 pozostają wolne do wykorzystania, tak samo wszystkie duchy są do wykorzystania)
gdyby atari posiadało zestaw 256 znakowy można otrzymać 16 kolorów dither, ale tak tylko 8 dla szybkiego dostępu do pamięci
lda starszy_nibbl_koloru,x
ora młodszy_nibbl_koloru,y
sta ekran
jeśli uprzeć się to i 11 kolorów dither, jednak wtedy postawienie dwóch znaków ćwiartkowych obok siebie będzie trwało dłużej
ldx kolor1_0_10
lda mul_11,x
sta adr+1
ldx kolor2_0_10
adr lda paleta,x
sta ekran
może komuś się przyda do wizualizacji :)
p.s.
istnieje możliwość aby obrazki G2F były zapisywane w ten sposób, aktualnie próbuję to zaimplementować, na razie z marnym skutkiem
p.s. #2
aktualnie ten tryb nie ma nazwy, jakieś propozycje, 9+++++++++++++++++++++++++++++++ ;)
musisz tylko Pin opłacić znaczek skarbowy
no co Ty Fox, chcesz zostać pustelnikiem
it's bug in mads, '.OR', '.AND' not works
p.s.
mads 1.8.8 bug fixed
skróty klawiszowe są szybsze od myszki, TAB przełączanie okienek, a wybór czegoś z menu na podstawie zaznaczonej dużej litery w treści komunikatu
to może jeszcze artefakty, pamięta ktoś czasy kiedy TV pozwalały wyświetlać kolor w HiRes dzięki artefaktom
VBXE to nie Arka Noego aby zabierać na pokład przestarzałe gatunki techniki
dzięki Vega :) pewnie skorzystam z kodu
zdaje się że stacja 1050 nie formatuje w formacie DD, tylko E i S
atari.area forum » Posty przez tebe
Wygenerowano w 0.092 sekund, wykonano 14 zapytań