Amaurote izometr 3d na c64

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
Awatar użytkownika
BagoZonde
Posty: 57
Rejestracja: 15 gru 2011, 09:33
Grupa: Commocore
Kontakt:

#41 Post autor: BagoZonde »

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

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

Awatar użytkownika
at0mic
Posty: 82
Rejestracja: 02 gru 2011, 14:55

#42 Post autor: at0mic »

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
Załączniki
bitmapa.gif
bitmapa.gif (5.16 KiB) Przejrzano 17669 razy
At0mic

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#43 Post autor: skull »

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 ...
Bo pecet to zwykły banan...

Awatar użytkownika
BagoZonde
Posty: 57
Rejestracja: 15 gru 2011, 09:33
Grupa: Commocore
Kontakt:

#44 Post autor: BagoZonde »

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.

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#45 Post autor: wegi »

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ż

Awatar użytkownika
at0mic
Posty: 82
Rejestracja: 02 gru 2011, 14:55

#46 Post autor: at0mic »

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?
At0mic

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#47 Post autor: wegi »

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

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

Awatar użytkownika
at0mic
Posty: 82
Rejestracja: 02 gru 2011, 14:55

#48 Post autor: at0mic »

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 ;)
At0mic

zielok
Posty: 438
Rejestracja: 07 lis 2008, 21:23
Kontakt:

#49 Post autor: zielok »

tak, BRUSH to brush

Awatar użytkownika
at0mic
Posty: 82
Rejestracja: 02 gru 2011, 14:55

#50 Post autor: at0mic »

czy to jest TG JSL

Obrazek

co z ALBIONEM i POLONUSEM?
At0mic

zyga
Posty: 177
Rejestracja: 05 gru 2008, 08:58
Grupa: Alliance

#51 Post autor: zyga »

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

Awatar użytkownika
BagoZonde
Posty: 57
Rejestracja: 15 gru 2011, 09:33
Grupa: Commocore
Kontakt:

#52 Post autor: BagoZonde »

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 ;).

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#53 Post autor: wegi »

Jetboy nie wyjaśnił?

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

Awatar użytkownika
BagoZonde
Posty: 57
Rejestracja: 15 gru 2011, 09:33
Grupa: Commocore
Kontakt:

#54 Post autor: BagoZonde »

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 ;).


Awatar użytkownika
at0mic
Posty: 82
Rejestracja: 02 gru 2011, 14:55

#56 Post autor: at0mic »

to są tak wspaniałe materiały, że już nic nie muszę pisać tylko czytać te delicje ;) - lepsze niż kryminał :)
At0mic

Awatar użytkownika
BagoZonde
Posty: 57
Rejestracja: 15 gru 2011, 09:33
Grupa: Commocore
Kontakt:

#57 Post autor: BagoZonde »

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.

jhusak
Posty: 1
Rejestracja: 08 gru 2013, 11:06

#58 Post autor: jhusak »

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.

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#59 Post autor: comankh »

witamy na forum \m/

Awatar użytkownika
drsun
Posty: 38
Rejestracja: 19 sty 2014, 13:46

#60 Post autor: drsun »

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ń?

ODPOWIEDZ