Pytanko, czy ktos cos wie/slyszal - jakie produkcje sie szykuja na VBXE? Z tego co ja wiem, Jarek Kaczor chcialby zrobic jakis slideshow, ja ze Scalakiem wahamy sie, czy zrobic tekstowke z wykorzystaniem mozliwosci VBXE...
Jellonek obiecał swego czasu Mortal Combat... Ciekawe, czy dotrzyma słowa ;) A na poważnie: chętnie bym jakąś produkcję na VBXE obejrzał... Sam jestem na to za słaby... ;( Poza tym - tam się chyba bez znajomości assemblera nie obejdzie... :(
Wydaje mi się, że sam program obsługi banków zeżarł by dużą część pamięci używaniej przez TB - pierw trzeba ustalić stan banków, potem je załadować danymi kopiowanymi z bufora w bloku podstawowym, a gdzie miejsce na sam program ? I czy przypadkiem pamięć wykorzystywana przez procedury TBXL nie pokrywa się z bankami VBXE ?
Myślę że odpowiedzią na temat jest Action! Wykorzystanie Action! z VBXE jest optymalnym rozwiązaniem: duża wygoda programowania, wydajność a przy okazji pozbycie się wad Action! bo wiele istotnych rzeczy załatwia nam wspaniały hardware.
Myślę że jest to temat wart rozważenia. W końcu to taka sytuacja w której mamy fajny kompilator w którym wygodnie da się programować, a przy tym skupiamy się jedynie na samej grze bo np. procedur spritesów już pisać nie trzeba itp.
MaW: zwróciłeś tu uwagę na istotny problem. Może tak: najpierw uruchomić program, który wszystko sprawdza i zgrywa dane do vramu VBXE a następnie program w TB lub Action! który już tylko operuje na danych ? Kilka DOSów na Atari wspiera batche.
No, z tego co wiem - rysunki już można robić. Nowy G2F wspomaga... Czyli pierwsze narzędzie już jest ;) No i czekamy na jellonka, obiecał, że jak będzie VBXE to napisze MK na Atari :P
Pierwszym narzedziem nie byl G2F tylko program Electrona do wyswietlania grafik w trybie Overlay. Program TeBe umozliwia pewne prace w trybie mapy kolorow, ale jako edytor grafiki nadaje sie mniej niz srednio, bo przeciez nie do tego powstal i ten "grzech pierworodny" bycia konwerterem fonty-grafika zanim sie ciagnie :).
Najlepiej chyba przygotowywac grafike w programach na peceta - szczegolnie jesli ma miec 256 kolorow. Mozna niby uzywac Amigi czy duzego Atari, ale to juz w lepszych konfiguracjach, drogich i trudnych do zdobycia.
A z pisaniem Mortal Kombat to mnie sie zdaje jest jak w tym dowcipie o Partii: "jak Partia mowi, ze zrobi, to mowi, a nie ze zrobi" :)
Kupilem bezposrednio od Electrona, teraz czekam z niecierpliwoscia az dotrze. Tylko mam dylemat czy wstawiac w nowe 65 xe w folijce czy upychac w xegs box mk2 . Najlepiej by sie dwa VBXE przydaly, hehe.
TBXL można użyć, dostęp do rejestrów jest, ja bawiłem się z w zwykłym Basicu, jeden POKE i mamy oddzielnie kolory tła i fontów
jeśli chodzi o duchy, to procedury nimi sterujące trzeba napisać w ASM i wepchnąć do pamięci VBXE, w aktualnych wersjach rdzenia tak jest, Electron zrezygnował z co niektórych możliwości aby zyskać wolną przestrzeń na inny kod, po prostu wszystkiego nie da się upchnąć do pamięci rdzenia VBXE
Przeciwnicy VBXE podnosili, ze czeka nas zalew oprogramowania na ta karte, ze to odciagnie koderow od malego Atari, ze bedzie Sodoma i Gomora.
Nie bez satysfakcji stwierdzam, ze potwierdzila sie jednak moja teza, ze koderow to nie odciagnie, a co najwyzej przyciagnie nowych. I prosze. Candle nie kodowal gier na male Atari, a tu nagle zabral sie za development gier ;)
skoro VBXE daje 256 kolorów w 320x200, a Rapidus daje procka 65816 - że można by sprobówać przeportować grę Wolfenstein 3D z Apple IIGS, bo właśnie tam ta gra jest na ten procek i w tej rozdziałce:
No i Apple IIGS chodzi z prędkością 2,86MHz, a Rapisus 20MHz... jest potencjal :) No i w wtedy byłby sens użytkowy dla graczy, żeby mieć Rapidusa i VBXE. Bo obecnie z softem bida.
to tylko obrazek z wersji DOSowej skonwertowany do VBXE, wyświetlony na moim Atari z VBXE i przechwycony przez grabber Avermedia GamecaptureHD2 :) To tak wygląda - tyle że statycznie. Są dwa porty Wolfa na ten procek co w Rapidusie - Apple IIGS i Nintendo SNES.
Rapidus świetnie sobie radzi z odtwarzaniem sampli czy nawet MOD-ów na IRQ wywoływanym co linię obrazu, sample w pamięci wysokiej długości max 64KB
tylko nie wiem co ma VBXE do Rapidusa, skoro to są oddzielne układy i nie ma jakiejś magistrali DMA która by je spinała
to tak jakbyś chciał przewieźć tonę węgla, ale masz tylko taczkę, musisz małymi porcjami najwolniej jak można ten węgiel transportować, cała para idzie w gwizdek
pełen potencjał Rapidus osiąga kiedy cały kod programu jest w jego pamięci wysokiej, pamięć banku #0 ($0000..$FFFF) jest potrzebna tylko po to aby wystartować przerwania, ustawić program dla ANTIC-a, udostępnić stronę zerową i stos (RAM #0 = FAST RD/RW)
dla RAM #0 = FAST RD/RW, program ANTIC-a musi być poza obszarem $0000..$3FFF
jakiekolwiek odwołania do banku #0 w obszar ($4000..$FFFF) spowalniają Rapidusa
100% Rapidusa to wyłączony obraz, wyłączone przerwania, głucha cisza i tylko kod powyżej adresu $FFFF
p.s. przykład gry 'Titus The Fox' to przykład na osiągnięcie maksymalnego obciążenia blittera VBXE, tam gdzie obraz szarpie blitter już się nie wyrabia w ramce, albo główna pętla programu niepotrzebnie czeka na synchronizację
