c64scene.pl

Brush, dobre. Racja. Bitmapa i nie ma na to bata.

Nie miałem kiedy siąść, ale powalczę.

brush zobacz dobrze czy to jest na bitmapie bo to że znalazłeś ekran pod $6000-$7f40 i kolorki pod $4400-47e7 tego wcale nie dowodzi.

Zobacz jak ten obraz wygląda:
Obrazek

gra jest zrobiona trikowo ale według mnie na znakach a nie na bitmapie natomiast ułożenie generatorów znaków jest takie, że sprawia wrażenie że jest to bitmapa - albo ja czegoś jeszcze nie wiem o VIC i się mylę.

Ta bitmapa nawet nie jest buforowana więc przepisywanie jej byłoby widoczne bo nie wystarczy czasu na przepisanie 8KB w 20000cykli/50=4000 cykli/klatkę a trzeba przepisać nie dość że bitmapę to Color RAM i Char RAM.

mogę się oczywiście mylić i chciałbym się mylić w tym wypadku

ze screena wygląda na typowego znakowca.

Co do przepisywania bitmapy ... co ramkę, to może czasu i nie wystarczy, ale dlaczego co ramkę ?:)
a po co są komórki scrolla $d011 i $d016 ? Tu przesunięcie jest oczywiście niby bezsensowne bo tylko w granicach 8 pixli, ale...
przecież przepisywać ekran możemy do innej bitmapy (w innym banku), podczas tego 8-mio pikslowego ruchu - daje to 8 ramek na przepisanie - starczy z nawiązką, a potem przełączasz bitmapę i od nowa ...

No, do tego samego się skłaniam. Po prostu przekopiować bitmapę i wjo. Śmignę to w wolnym czasie choć jest to prosty kod i opierać się będzie tylko o reverse wszystkich elementów (to najtrudniejsza część myślę) i zbudowanie generatora plansz. Będzie on mógł też nanosić od razu te elementy 3d. Do tego wspomogę się jakimś narzędziem napisanym na Amidze na przykład. Mój pierwszy kod po prostu rysował wszystkie kawałki w locie odczytując konkretne rodzaje pól (trawa, droga, etc.). W tym przypadku trzeba oczywiście oprócz bitmapy z grafą utworzyć też mapę informującą o rodzaju pola.

Gdzieś w domu zrobiłem sobie program, który wstawia pojedyncze piksele (miałem tam jeszcze jakiegoś buga) ale generalnie sadzi je na ekranie więc zobaczę na ile to może być szybkie po odpowiedniej przeróbce.

brush pisze:
[...]
Jak to wygląda w praktyce zobacz tutaj: http://csdb.dk/release/?id=55080
[...]

brasz nie pytał zauważ - to jest of coz bitmapa to po pierwsze

po drugie zobacz na rozmieszczenie - to nie jest fullscreen - a więc nie potrzeba tylu danych do przepisywania - stąd scores jak dla ślepca - prawie na pół ekranu
Ponieważ jest to bitmapa to level jest tak krótki, bo dane zajmują więcej jak dla charsetów z powtarzającymi się znakami
Przy VSP przepisujesz tylko ostatnią kolumnę
Poszerzone sprites - aby zasłonić calą bitmapę potrzeba ich 7 - nie jest zasłonięta cała - policz ile widzisz ruchomych obiektów i jak szerokie w tych liniach są napisy. Napisy to sprajty i pozostałe chodzące stworki pewnie też

pierwszy raz słyszę o VSP ale ciekawie to wygląda i znikają pewne ograniczenia kolorystyczne trybu znakowego w którym tylko

11 - ma kolor zmienny poprzez Color RAM (0-7)-tylko wybór z pierwszych siedmiu kolorów
10 -$d023
01 -$d022
00 -$d021

Wegi jestem Ci wdzięczny za pomoc i codzienną porcję emocji związanych z poznawaniem czegoś nowego dla mnie.

VSP - czy trudny jest to sposób?

Starożytni mawiali: "Wdzięczność to rzadka cecha i... bój się jej"

VSP - artykuły Jetboya w C&A i codebase

Ściągnij sobie ICU64 dla VICE możesz zobaczyć grafikę i pamięć w sposób "graficzny"

zielone rasterki to odczytywana pamięć
czerwone - zapisywana
żółte odczyt i zapis
czarne - nic nie jest wykonywane na niej
niebieskie - wykonujący się kod

właśnie czytam highLife z 1991 roku 5-numer

najlepis koderzy:
-----------------------
1. Polonus
2.TG JSL
3.ALBION
4.BRUSH
5.PAMPAM
6. HAIN
IGNAC
JUMBO
PROKOP
10. REVISOR

czy BRUSH to brush ?

ades redakcji :
ul. Lelewela 3/1
05-400 Otwock

Ciekawe kto teraz tam mieszka i czy znalazł stare dyskietki z grami z C64

tak, BRUSH to brush

czy to jest TG JSL

Obrazek

co z ALBIONEM i POLONUSEM?

at0mic pisze:co z ALBIONEM i POLONUSEM?

POLONUS żyje: http://www.riversedge.pl/8-bitowe_wspom ... i_polonusa

Tutaj wywiad (trochę starawy, fakt): http://www.exbee.pl/emu64/menu.php?art=67

Czy ktoś wyjaśnił by mi działanie VSP? Poczytałem co nieco, ale średnio to rozumiem. Mało tego na sieciuni. Jak to w ogóle działa, wiecie, ideologicznie jak to działa

i praktycznie. Może Mythosa przejrzę, może tego Freda. Tam jest właśnie chyba line cruncher - co poznaję po tym, że jest górne menu. Tak naprawdę zebrałem pare informacji, poznałem też koleżkę z Niemiec, z którym wymieniamy się wiedzą i on ma "prawie" działające VSP więc nie potrzebuję gotowych rozwiązań, kawałka kodu. Chcę to po prostu zrozumieć

. Myślałem, że w wykładziku Dekay z Cresta z 2011 to znajdę, ale chyba nic tam nie ma. Przewinąłem pobieżnie, teraz dopiero zacznę to oglądać od deski do deski. Przydałby się koleżka od kodowania, z którym można wyjść na większe piwo

.

Jetboy nie wyjaśnił?

- do powtórki wszystkie artykuły Jetboya z cyklu "Jak zrobić własne demo" plus wszystkie "Pamiętniki artylerzysty" Ignaca

Wegi, o tym zapomniałem, żenua. Poszukam na necie bo mam tylko strzępy na papierze. Ale wiecie, nie ma to jak pogadać z kimś na taki temat, się coś w człowieku uruchamia

.

to są tak wspaniałe materiały, że już nic nie muszę pisać tylko czytać te delicje

- lepsze niż kryminał

Tak, tak, zapoznałem się już z tą treścią z elysium, znalazłem wątek na "pewnym polskim" forum skąd chyba przekleiłeś tę listę

. Dzięki

.

Swoją drogą ściągnąłem to także w ramach preservation

, same skarby.

Jako ten, który przyspieszył Amaurote w wersji na Atari 2-3 razy ( w zależności od liczby obiektów na ekranie, czym więcej, tym większe przyspieszenie), dzięki czemu powstało Amaurote+, a przed chwilą Amaurote 128, oraz jako człowiek znający technikalia c64, piszę, co następuje.
- wersja izometryczna na c64 o prędkości zbliżonej do oryginału Amaurote na Atari jest możliwa.
- Amaurote pracuje w trybie graficznym.
- nie ma doublebufferingu, jest offscreen, który potem robi "fade" na główny, ale nie podczas gry.
- maski posadają WSZYSTKIE obiekty zarówno ruchome i nieruchome, w tym ramka heksagonalna.
- można uzyskać przewagę stosując sprajty do wskaźników i np. kulki.
- można pozbyć się ramki, ona dość skutecznie spowalnia, jej rysowanie trwa ok. 1.5 ramki, po przyspieszeniu, 0.7
- jest pewien problem przy zmianie konfiguracji ekranu "z linia po linii" na comodorowską. Próbowałem to zrobić na Atari, ale zbyt skomplikowane dla mnie było przesuwanie obiektu o mniej niż jeden znak w pionie. Niemniej dla zdolniejszego nie powinno być problemu :)

Pamiętajcie, że Amaurote na Atari pracuje przy wąskim ekranie, co skutecznie zmniejsza ilość cykli dostępu do pamięci przez Antica (8 cykli dostępu na linię) co oznacza ok. 8% szybciej, niż normalna szerokośc ekranu oraz jakieś 10% jeśli nie używamy trybu tekstowego. Ogólnie realna prędkość procesora to 1.3 MHz przy tej konfiguracji.

Najlepszą wersją do modyfikacji na c64 jest wersja atarowska.
Największe przyspieszenie to modyfikacja organizacji ekranu z 28 bajtów szerokości offscreenu (pustego miasta) i w związku z tym przyspieszenie procedur rysujących sprajty; wyrzucenie obicia symetrycznego w locie, zmiana sposobu rysowania ramki. Kod napisany dość wysokopoziomowo, jak na assembler (np. listy z buforami tła pod sprajtami), kilkanaście błędów :), jednak dość rozrzutny, śmiało można wyciąć z niego 8 kb bez utraty prędkości. Zmiana organizacji na tryb graficzny w organizacji znakowej (8 w dół jeden w prawo) też znacząco przyspiesza rysowanie sprajtów, pomimo ww problemów.

witamy na forum \m/

Chciałem zapytać czy Wasz projekt nowego Amaurote na c64 został porzucony, czy trwają nad nim prace, jeśli tak, to na jakim poziomie? W sumie ostatni post jest sprzed dwóch lat, ale ciekawi mnie czy jednak udało się dojść do jakichś rozwiązań?

c64scene.pl

Amaurote izometr 3d na c64