Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez tebe
nie działa na 1.10, gdzie zmiany nie dotyczą Overlaya ani ładowania palety kolorów, więc powinno działać, sprawdzaj wersję rdzenia i pozwalaj działać na wersji >= 1.09
XXL twoja gra NIGHTDRIVER nie działa na nowszym rdzeniu niz 1.09, Twoja detekcja rdzenia szwankuje
dla tych którzy potrzebują dokonać konwersji na znaki (klocki) np. mapy poziomów z jakiejś gry, tak aby zamienić duży plik BMP na konretne klocki o zadanej wielkości, albo ileś klatek animacji zapisanej w jednym dużym pliku BMP poddać kompresji bezstratnej dzieląc ją na mniejsze bloki może przydać się PC-towy program MAPPYWIN32 http://www.tilemap.co.uk/mappy.php
w założeniu MAPPYWIN służy od edycji poziomów gier 2D, także izometrycznych
przy jego pomocy udało mi się pierwszy level z gry Rick Dangerous z postaci dużej BMPy przerobić na klocki o rozmiarze 16x8 pixli, w rezultacie otrzymałem takich klocków 134 i mapę levelu z informacją o ułożeniu tych klocków (dla rozmiaru klocka 8x8 pixli program się zawiesił)
krótki opis tworzenia mapy:
File -> New Map... -> podajemy rozmiar dla TILE (klocka) i rozmiar samej mapy, wybieramy ile bitów na paletę kolorów -> OK
wczytanie klocków odbywa się przez File -> Import, pojawią się w oknie Block Editor, potem możemy z nich układać poziomy
zamiana dużej BMPy na klocki: tworzymy mapę dla zadanej wielkości klocka, następnie MapTools -> Useful functions: -> Create map from big picture
może komuś się przyda i ułatwi mu pracę
po zamontowaniu VBXE prążki znikają :) obraz jest gładki jak pupa niemowlaka
jeśli tak, to w paczce z mads-em jest bresenham
coś takiego
scrad equ $80 ;.w
fontfilesize equ $82 ;.w
charscount equ $84 ;.w
firstchar equ $86 ;.b
origintotop equ $87 ;.bmożna zapisać uniwersalniej i przejrzyściej
org $80
scrad .ds 2
fontfilesize .ds 2
charscount .ds 2
firstchar .ds 1
origintotop .ds 1albo
.zpvar scrad fontfilesize charscount .word firstchar origintotop .byte = $80no jak miło że XXL wspiera VBXE, to teraz czas na konwersje z Amigi, może asemblera Motoroli XLL jeszcze nie tykał
do czego to już doszło, to może trzeba przyjąć dla Atari XE/XL za standard końca linii #13#10 jak na PC żeby w przyszłości się innym nie myliło :)
była kiedyś o tym mowa, VBXE byłby wtedy jeszcze raz tak duży i jeszcze bardziej skomplikowany
gdyby tak jeszcze postacie poruszały się w dowolnym kierunku a nie tylko w 4ech, to można zrobić Counter Strike 2D :), chować się za murkiem, strzelać powyżej murku itp.
p.s.
nowa gra z rzutem izometrzycznym na ZX Spectrum W*H*B, ciekawe podejście do tematu, na YouTube można obejrzeć rozgrywkę http://www.pouet.net/prod.php?which=53100
zmagania w tej grze na PS3 http://www.youtube.com/watch?v=bheCWlrtp-o
ogólnie w Knight Lore i pewnie każdym innym izometrycznym silniku realizują to przez ciągłe odrysowywanie fragmentów pola gry gdzie znajduje się bohater
Nosty na VBXE powstały już użytki autorstwa Draco i są jak najbardziej pożyteczne, w sumie jeśli poświęcisz tyle samo czasu na poznanie VBXE co na wypisywaniu tutaj swoich dyrdymał to pewnie powstanie coś ciekawszego
do konwersji różnie się podchodzi i podchodziło, jedne będą wtórne inni twórcze, wszystko zależy od środków jakie dostaje się do dyspozycji, czasu i motywacji, sposób XXL-a na konwersję jest na pewno szybki, nie musi angażować grafika (tylko do ekranu tytułowego), co najwyżej muzyka
już z taką Cywilizacją jest problem w 4 kolorach, bo jak zaprezentować w sposób wyróżniający jednostki graczy, VBXE rozwiązuje problem :)
obrazki zapalają się i zostają wygaszone płynnie
kup nowe Atari Pajero :)
VBXE udostęnia max 4 palety kolorów, którą paletę wybierzemy zależy od mapy kolorów, w 4 bajcie mapy kolorów zawarta jest m.in. informacja o palecie kolorów dla Overlay
tak że buforowanie palet jest jak najbardziej osiągalne
p.s.
Candle jak masz znajomych koderów ze sceny 16,32 bit to może namówisz któregoś aby jakieś intro czy efekt popełnił pod VBXE, a nuż spodoba mu się i będzie kodera więcej :)
p.s. #2
dla VBXE możliwe są plasmy z rotacją palety kolorów jak dla PC, albo np. animacja Wormhola z wykorzystaniem rotacji palety
SIN(centre,amp,size[,first,last])
where:
centre is a number which is added to every sine value
amp is the sine amplitude
size is the sine period
first,last define range of values in the table. They are optional.
Default are 0,size-1.Example: dta a(sin(0,1000,256,0,63)) defines table of 64 words representing a quarter of sine with amplitude of 1000.
p.s.
pseudo rozkaz SIN pochodzi z XASM-a, MADS-owy jest co najwyżej RND
na C64 też powstają konwersje
http://www.pouet.net/prod.php?which=53042
ta konkretnie dotyczy gry z maszyny Vertrex
wersja z dzieleniem na 16KB bloki ma tą zaletę że można te 16KB bloki spakować, blok INIT będzie wówczas wzbogacony o wywołanie depakera, wówczas coś co zajmuje 700KB może zająć 180KB
w sumie można się pokusić aby zrealizować to tylko przy użyciu samego Exomizera bez potrzeby asemblacji
; bank #0
org $2000
lda #kod_banku_nr0
sta PORTB
rts
ini $2000
org $4000 ; bank nr0
ins 'bank22.dat' ; plik maksymalnej długości 16KB
; bank #1
org $2000
lda #kod_banku_nr1
sta PORTB
rts
ini $2000
org $4000 ; bank nr1
ins 'bank22.dat' ; plik maksymalnej długości 16KB
itd.....wartość zapisywana do PORTB nie powoduje wyłączenia OS-a
podobnie realizuje się ładowanie do VBXE, z tym że inaczej wygląda blok INI
po co wykrywać kolizję między duchami GTIA a Overlayem? bardziej przydatna jest detekcja kolizji pomiędzy duchami Overlay
aktualnie problematyczna jest dostępność grafik 256 kolorowych i osób potrafiących taką grafikę spłodzić, albo brak czasu u takowych osób
chciałbyś aby wszystkie klocki były odświeżane w każdej kolejnej klatce ? wg tego co kiedyś pisał Electron to bodaj do 32 duchów 16x16 powinien umieć obsłużyć blitter w 1 ramce, ale nie sprawdzałem tego
poza tym blitter ma kilka trybów pracy, wolniejszych i szybszych
jeśli IOBoard Candla pozwoli na transfery większe niż 19200 można pokusić się o bardziej rozbudowany sposób łączenia Atari z PC, np. Atari będzie robić za terminal a obliczenia przejmie PC
pewnie dzięki odpowiedniej kolejności rysowania, tzn. najpierw rysujesz te z tyłu, potem te znajdujące się coraz bliżej obserwatora, dzięki temu klocki najbliższe będą zasłaniać te najdalsze
http://forum.defence-force.org/viewtopi … 729dfcd0d1
http://gmc.yoyogames.com/index.php?showtopic=343847
i od autora m.in. gry Head Over Heels 'Jon Ritman's Isometric Tutorial'
http://dkozar.com/documents/Jon_Ritmans … torial.pdf
atari.area forum » Posty przez tebe
Wygenerowano w 0.088 sekund, wykonano 18 zapytań