Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL!
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
Zaloguj się lub zarejestruj by napisać odpowiedź
Nie mogę znaleźć tutoriala w którym Ingram opisał i dał przykład dla sprzętowego scroll'a STE.
W archiwum z jego strony ( i na bus error saulota ) akurat brak tego zagadnienia.
Czy ktoś takowe posiada? Bardzo poproszę, po jestem na trylion % pewien że gdzieś, kiedyś posiadałem jego tutorial w którym sprzętowy scroll był opisany.
Ze szczegółów pamiętam że był to ekran złożony z 9 plików .neo ( 3x3 ) które można było płynnie scroll'ować myszą.
takie coś będzie git?
http://www.sarnau.info/atari:atari_ste_ … on_the_ste
http://atari-ste.anvil-soft.com/html/devdocu2.htm
http://www.atari-forum.com/wiki/index.p … _/_Paradox
Je znam, więc jak nie znajdę tego Ingram'owego to te opisy będą musiały wystarczyć :) Szkoda, bo u Ingrama były przykłady :D A ten tutorial co załączyłeś to właśnie bez tego katalogu co szukam, ale dzięki :)
No ale w czym problem, przecież to jest dość proste ?
Nigdy nie twierdziłem że to jest trudne :P Ale ja zawsze wolę... a zresztą nie czuję potrzeby tłumaczenia się :P
Temat nieaktualny, znalazłem ten tutorial w mailu bo go kiedyś sam sobie przesyłałem :)
jurex, możesz go udostępnić?
Włala :)
A, i pokićkało mi się że to Ingrama :]
Ostatnio edytowany przez jury (2011-06-08 13:56:10)
Ha, pobawiłem się tym hardware scroll'em i przyznaję że jest cholernie prosty i efektowny. Ech, szkoda że w "tamtych" czasach góra 5 gier go wykorzystywała. Można było przeca robić gry które by wykrywały czy jest STE i jeśli tak to scrollowały płynnnie, a pozostałym STx'om zostałby dziadowski scroll procesorem :D
W świecie gamedevu panuje mentalność "get the shit done FAST", dlatego mało kto się wysilał. Szczególnie przy portach gier na inne platformy.
sqward, no racja. Taki Cannon Fodder woła o pomstę do nieba :(
Z czym się zgodzę, to niektóre gry faktycznie chodzą wolniej, niż ich odpowiedniki na Spectrum, ale jest oczywiste, że du.py dali koderzy, jak z resztą słusznie zauważył Sqward.
Jeśli faktycznie świat gamedev wyznaje zasadę "get the shit done FAST" to badziewne konwersje nie są winą koderów tylko kierowników projektów i manadżerii która zmusza do takiej pośpiechu. Wtedy nie ma czasu na dopieszczanie, tylko robi się po najmniejszej linii oporu, ale faktycznie, najlepiej zwalić wszystko na koderów :P
Ostatnio edytowany przez jury (2011-06-16 19:34:17)
A właśnie nie - przekonałeś mnie.
100% zgody.
jury: to zależy. ja w pracy widzę, że jest grupa koderów (manageró), którzy odwalają wszystko po najmniejszej linii oporu. I nawet nie mówie tutaj o stronie wizualnej projektów, tylko o np. nie hackowanie wszystkiego w taki sposób, że następny projekt trezeba pisać od zera. Ciekawe jest to, że to właśnie ludzie, którzy pisali gry na amigę i ST. Poprostu wtedy się tak pisało.
To też zależy od firmy i też sposobu zarządzania projektem(czy menedżerowie mają trochę oleju w głowie czy nie). Ale powszechnie robi się wszystko jak najszybciej, po najmniejszej linii oporu, problemy zamiata się pod dywan i wychodzi to przy następnych projektach jak trzeba na istniejącej bazie kodu coś zrobić, ale się nie da bo jest miliard zależności zaszytych w kodzie związanych z poprzednimi projektami. Bazowej funkcjonalności nie da się tak po prostu wyodrębnić. I potem się buduje na tym i buduje i wychodzi z tego wielka kula z miliardem niepotrzebnych rzeczy. I co się potem serwuje klientowi? Mocniejszy komputer, z większą ilością procesorów np. 16, ramu i powierzchni dyskowej (to nie tylko gamedev).
Ale wierzę, że jest gdzieś takie miejsce i że do niego trafię w którym panuje porządek, wszystko jest robione z zasadami sztuki, trzymanę za mordę i jak ktoś zrobi lewą wrzutę kodu to jest tygodniami torturowany, smażony prądem i kopany po jajkach. I oczywiście ja bym był tam szefem ;))))) ...
:D
jury: to zależy. ja w pracy widzę, że jest grupa koderów (manageró), którzy odwalają wszystko po najmniejszej linii oporu. I nawet nie mówie tutaj o stronie wizualnej projektów, tylko o np. nie hackowanie wszystkiego w taki sposób, że następny projekt trezeba pisać od zera. Ciekawe jest to, że to właśnie ludzie, którzy pisali gry na amigę i ST. Poprostu wtedy się tak pisało.
Z tym to nawet nie będę polemizował, bo to wszystko oczywiście zależy od poszczególnego egzemplarza kodera :)
Więc są i tacy ( niestety chyba nie w mniejszości ) którzy zawsze idą po najmniejszej linii oporu niezależnie od wszystkiego. Natomiast w momencie tworzenia projektu metodą "get the shit done FAST" wszyscy w zespole muszą zapierniczać jak odrzutowce przez co zazwyczaj projekt traci na wartości. A "get the shit done FAST" zawsze i wyłącznie narzuca manadżeria a nie ostatnie pionki które projekt wykonują, czyli w tym przypadku koderzy.
Ostatnio edytowany przez jury (2011-06-17 07:53:46)
Saulot: W jednej firmie, w której pracowałem tak było :) Może w obecnej też tak będzie. Nie poddaje się :)
Bawię się tym scrollem dalej i coś mi się wykrzacza po wpisaniu mojego vbl'a pod $70. Ratunku, nie wiem o co mu chodzi, bo już zgłupłem.
Okroiłem wszystko tylko do wyświetlenia PI1 i wrzucenia mojej procedury vbl, która komplenie nic nie robi i nadal lipa.
Wstrętny kod:
jsr init
movem.l picture1+2,d0-d7
movem.l d0-d7,$ff8240
move.w #2,-(a7)
trap #14
addq.l #2,a7
move.l d0,a0
move.l #picture1+34,a1
move.l #picture2+34,a2
move.l #199,d0
l1
move.l #39,d1
l2 move.l (a1)+,(a0)+
dbf d1,l2
move.l #39,d2
l3 move.l (a2)+,(a0)+
dbf d2,l3
dbf d0,l1
move.w #7,-(a7)
trap #1
addq.l #2,a7
move.l #vbl,$70
move.w #7,-(a7)
trap #1
addq.l #2,a7
move.b #0,$ff820f
move.w #$777,$ff8240
jsr restore
clr.l -(a7)
trap #1
vbl
move.l d0,d1
rte
include init.s
section data
picture1 incbin demon9.pi1
picture2 incbin demon9.pi1
adr_ekr ds.l 1init.s jest rodem prosto z tutoriala perihelion'a
Ostatnio edytowany przez jury (2011-06-19 20:48:47)
Po pierwsze primo, dałbyś chyba radę z jednym incbinem.
Po drugie primo, nie zapamiętujesz oryginalnej wartości wektora vbl, a potem go nie przywracasz - prawdopodobnie po zakończeniu programu kod vbla idzie w krzaki.
adamk: to zależy co ma w init i restore ;)
vbl
move.l d0,d1
rte
To przecież rozwali kod który się wykona po wyjściu z przerwania.
OK, za mało danych dałem chyba :)
W init i restore mam oczywiscie zapamietanie i odzyskanie oryginalnego vbl'a.
Zawartość zaprzykładowego przezemnie vbl'a nie ma znaczenia. Tak dla jaj :) aby coś było wpisałem to move.l d0,d1 :)
To niech moja vbl'ka wygląda tak:
vbl
rte
A problem mam taki że jak debuguję to coś to już w momencie move.l #vbl,$70 emulator się zawiesza.
A co do tego:
Po pierwsze primo, dałbyś chyba radę z jednym incbinem.
Tak, wiem. Ale robię scroll'a poziomego i za chwilę pojawi się jeszcze 8 incbin'ow i kazdy będzie inny. To tylko przyklad. Skupmy się na tym ze się zawiesza w momencie move.l #vbl,$70 :)
Ostatnio edytowany przez jury (2011-06-19 21:56:22)
Ja w GFA radziłem sobie bez używania blitera- wprawdzie scroll tylko w pionie był ale był płynny :) Po prostu rezerwowałem sobie obszar pamięci, potem wgrywałem obrazek pod obrazkiem do tego obszaru i zmieniałem początek adresu z którego ma być wyświetlany ekran :) Było płynie i szybko :)
jury: to spróbuj wwalić tam jakiegoś nop'a, wrzucić słowo even przed VBL i odpal zamiast monsta np. adebug. monst daje ciała czasami.
Ja w GFA radziłem sobie bez używania blitera-
Ale tutaj chodzi o użycie sprzetowego hardscrolla nie blittera.
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.100 sekund, wykonano 16 zapytań ]