Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 … 5 6 7 8 9 10 11 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
masterpiece
Bardzo mysle o paralaksie, choc nie do konca rozumiem czemu wszyscy mowia zeby to robic w trybie znakowym. Ja i tak pamiec ekranu w PIC zawsze bede mial w trybie graficznym. Jak ktos bedzie chcial tryb tekstowy to po prostu zmienie sposob generowania z tego ekranu danych dla Antica.
A propos budowania ekranu z kafli itp. To pokazuje ze gdybym mial robic jeden uniwersalny frimeware wyprzedzajac potrzeby to juz do konca zycia nic innego bym nie robil. Wole wypuscic wersje podstawową 1.0 i reagowac na konkretne potrzeby koderow. Przeciez jeden bedzie chcial kafla 16x16, a drugi 24x16 a trzeci poprosi dodatkowo o scroll. Nie sposob przewidziec wszystkiego.
Tym bardziej ze PIC tez nie ma nieskonczonej mocy i nie wszystko pociagnie.
Zrodla udostepnie wszystkim, jak tylko bedzie jakas w miare kompletna i opisana wersja. Z 3 powodow:
1. Ja jestem przecietnym koderem nawet w asm 6502, a tego asm PIC24 ucze sie od miesiaca czy dwoch. Bardzo mozliwe ze ktos podkreci moje procedury zeby dzialaly 2x szybciej.
2. Ten asm jest dosc prosty (wyzej zamiescilem link do opisu rozkazow). Licze na to ze nie ruszajac (a nawet niekoniecznie do konca je rozumiejac) tych najbardziej podstawowych procedur komunikacyjnych, ktos bedzie mogl dopisac sobie potrzebne mu procedury. Czyli np popatrzy jak wyglada moja procka stawiajaca punkt, a druga kreslaca odcinek i dopisze sobie wlasne kreslace okrag. I wzbogaci tym frimeware.
3. Sytuacja ktora opisal XXL, ze ludzie pisza gry a ja na zyczenie pisze im frimeware jest dobra, jesli tych "ludzi" bedzie 2 :P Ale jak bedzie wiecej to nie wydole. Szczegolnie ze jak od poczatku mowie, mam wielkie braki w umiejetnosciach "scenowych". Zaawansowane przekszatalcenia 2D, grafika 3D, czy nawet matematyka zmiennoprzecinkowa to tematy, ktorych nigdy nie uzywalem w asm na Atari. Pomysl ze nagle bede umial zaimplementowac to w asm PIC jest hmmm optymistyczny ;)
Bardzo mysle o paralaksie, choc nie do konca rozumiem czemu wszyscy mowia zeby to robic w trybie znakowym. Ja i tak pamiec ekranu w PIC zawsze bede mial w trybie graficznym. Jak ktos bedzie chcial tryb tekstowy to po prostu zmienie sposob generowania z tego ekranu danych dla Antica.
na znakach z uwagi na kolizje gracz/tło jak się ma mapę do tego, faktycznie w przypadku Tomka może być inaczej, jesli paralaksa ma służyc jedynie jako tło(ozdoba) to wystarczy kolizje PMG w zetknięciu z danym kolorem tła, drugi powód to szybkość, nie rozumiem tylko XXL cyt: nieograniczonej liczby fontów z zestawie, po prostu dla mnie zestaw ma ograniczenia do 256 bo każdy reprezentowany tam znak ma tylko 8 bitów.
trzeba poeksperymentować w realu, kiedy bedzie dostępny devkit ? można zamawiać ?
Ostatnio edytowany przez cougar (2012-09-07 11:21:04)
> choc nie do konca rozumiem czemu wszyscy mowia zeby to robic w trybie znakowym
bo sie dostaje za friko jeden kolor wiecej
> dla mnie zestaw ma ograniczenia do 256 bo każdy reprezentowany tam znak ma tylko 8 bitów
reprezentacja znaku w pamieci obrazu nie musi byc ograniczona do 8 bitow. ale akurat tu jest inny temat: znakow masz na ekranie 40x24 czyli 960 roznych fontow jednoczesnie mozesz wyswietlic. TOMEK ma taka przewage wlasnie ze potrafi podawac anticowi dane w odpowiedniej (zaprogramowanej) kolejnosci czyli nawet jak wezmiesz ustawisz pamiec ekranu na adres $4000 i wypelnisz ten obszar jednym znakiem to TOMEK pod definicje tego znaku moze podkladac rozne dane w zaleznosci od KOLEJNOSCI odwolania. ogolnie lepiej jest zeby ANTIC intyerpretowal dane jak trybu tekstowego no ale ciezko przekonac skoro nawet niektorzy nie lapia roznicy miedzy trybem tekstowym/graficznym antica :/ to jest ogromna zaleta, nie ma ograniczen co do ilosci fontow w zestawie a i kolor 1 wiecej... troszke to przypomina tryb BBC micro.
> reprezentacja znaku w pamieci obrazu nie musi byc ograniczona do 8 bitow.
nie musi ale sprzętowo jest a głównie chodzilo mi o to, że pod charbase nie znajdzie się nigdy więcej definicji niz 256, nie wazne to teraz bo nie rozumiem istotniejszych rzeczy
> TOMEK ma taka przewage wlasnie ze potrafi podawac anticowi dane w odpowiedniej (zaprogramowanej) kolejnosci czyli nawet jak wezmiesz ustawisz pamiec ekranu na adres $4000 i wypelnisz ten obszar jednym znakiem to TOMEK pod definicje tego znaku moze podkladac rozne dane w zaleznosci od KOLEJNOSCI odwolania
to wiele wyjaśnia jednak nadal nie rozumiem jak się odwołuje do tych znaków Tomek i gdzie miałbym umieścic model mapy obiektów i kontrolować kolizje
a najprościej na przykładzie filmiku:
playground łącznie z obiektami jest w pamieci na Tomku, pozycje obiektów sa pobierane z jakiejś tablicy, gdzie ona się znajduje i jak jest zapisywana ?, tekst w demie jest w trybie hires czyli tekst też jest spritem tak ?
Ostatnio edytowany przez cougar (2012-09-07 13:06:26)
2. Ten asm jest dosc prosty (wyzej zamiescilem link do opisu rozkazow). Licze na to ze nie ruszajac (a nawet niekoniecznie do konca je rozumiejac) tych najbardziej podstawowych procedur komunikacyjnych, ktos bedzie mogl dopisac sobie potrzebne mu procedury. Czyli np popatrzy jak wyglada moja procka stawiajaca punkt, a druga kreslaca odcinek i dopisze sobie wlasne kreslace okrag. I wzbogaci tym frimeware.
dokladnie to mialem na mysli gdy pisalem o (xxl, specjalnie dla Ciebie ;) ) UPUBLICZNIENIU ZRODEL.
> nie musi ale sprzętowo jest a głównie chodzilo mi o to, że pod charbase nie znajdzie się nigdy więcej definicji niz 256
z TOMKIEM to sprzetowe ograniczenie znika. ANTICowi wystarczy definicja jednego znaku a wyswietlal bedzie "ile tylko chcesz" nawet jak 2 takie same znaki leza kolo siebie to ANTIC wyswietli rozna zawartosc - nie ma juz ograniczenia sprzetowego.
> to wiele wyjaśnia jednak nadal nie rozumiem jak się odwołuje do tych znaków Tomek
Nosty wyjasnil w pierwszym zdaniu posta 152 ja w 154, 148 i wczesniej tez.
> playground łącznie z obiektami jest w pamieci na Tomku, pozycje obiektów sa pobierane z jakiejś tablicy, gdzie ona się znajduje i jak jest zapisywana ?, tekst w demie jest w trybie hires czyli tekst też jest spritem tak ?
moze byc, ale nie musi. jesli jest to bedzie szybciej, mozesz budowac pamiec ekranu 6502 a tomek ja podlozy ANTICOWI ale szybciej bedzie jak zbuduje ja TOMEK. TOMEK dziala szybko bo dane ma w swojej pamieci wiec jesli chcesz zeby mogl szybko umieszczac obiekty na ekranie musisz te obiekty skopiowac do pamieci tomka i dopiero z niej na ekran...
powiem tak, pomysl jest taki zeby wszystkie rozkazy wydawane na stronie d5 wykonywaly sie natychmiast, czyli mozesz pracowac w trybie interaktywnym ;-) ale masz rozkaz ktory mowi zapisuj dane od adresu takiego i takiego po czym zapisujesz - czy to beda dane do wyswietlania, czy obraz tekstowy, definicje czy sam program "wyswietlania" to juz jest nieistotne, to samo z czytaniem - 6502 tez moze czytac pamiec obrazu tak jak atntic albo pamiec "wyswietlania"
dlatego tez bardzo zalezy mi na osobnych obszarach zapisu i czytania dla 6502 i antica na d5.
ostatni akapit to propozycja zobaczymy co na to Nosty...
a jak wygląda kwestia detekcji kolizji? jakoś wspomagana czy bez wspomagania?
dla mnie bez wsparcia. nic tak nie irytuje jak kolizja plajera z 1 pixelem podloza ;-) kolizje robie programowo.
a jak wygląda kwestia detekcji kolizji? jakoś wspomagana czy bez wspomagania?
xxl juz tlumaczyl, mapa obiektow(podloza) po stronie thomasa wiec lepiej jak tomek obsluzy kolizje, szybciej po prostu ale zalezy co chcesz robic... ten tandem zalezy od projektu
ot i madrego milo posluchac ;)
@ Candle
masz mi za zle, ze nie fanbojuje VBXL ?
zacytuje tylko klasyka:
Never wrestle with a pig, you both get all dirty, but the pig likes it. Never argue with an idiot.
ps. nie troluje bo jak widzisz udzielam sie wylacznie na tym watku na aa
kropka. koniec tematu.
Ostatnio edytowany przez cougar (2012-09-07 21:07:46)
nie, mam ci za zle, ze fanbojujesz, nie wazne co
OT: ja nie w temacie, ale o co chodzi z tym FANBOJOWANIEM ?
nie widze zwiazku..
kolizje programowe w.mnie sa jednak lepsze i czesto wychodza jakby przy okazji. na przykladzie cybernoida/asteroids/hobgoblin2 widze, ze sa szybkie i swietnie sie sprawdzaja. nie warto komplikowac Nostemu projektu.
Poniewaz znow jest wiele hipotez i niedomówien, to moze opiszę pokrótce jak chcę zorganizować pierwszy prosty frimeware graficzny i poproszę o komentarze.
Założenia:
1. TOMEK w kazdej ramce od nowa rysuje cały ekran, czyli najpierw tło a na nim wszystkie obiekty. Nie widzę sensu w zabawie w obliczenie które elementy się przesuneły względem ostatniego obrazu i które fragmenty trzeba odswiezac czy zamalowywac. Pojechanie po całosci bedzie szybsze.
2. Z małej ilosci pamięci (8KB a od tego odchodzą jeszcze 2 strony) wynika brak mozliwosci buforowania w większości przypadków. Czyli na początek zakładamy że cały obrac będzie rysowany w czasie miedzy zakonczeniem rysowania przez Antic ostatniej linii obrazu, a rozpoczęciem rysowania pierwszej linii kolejnego obrazu.
Jednak w przyszlosci będę chciał dodać tryb, w ktorym PIC ma dwie pamięci obrazu i w czasie kiedy rysuje na jednej to Anticowi podaje dane z drugiej, a w kolejnej ramce na odwrót. Moze sie to przydać do trybu $0D Antica (160x96 w 4 kolorach).
3. To czy dane dla Antica bedą podawane w trybie graficznym czy tekstowym, to kwestia niezależna od wewnętrznej reprezentacji obrazu, która bedzie zawsze graficzna. Jesli programista Atari zazyczy sobie trybu tekstowego to zmieni jedynie sposob podawania danych dla Antica.
Jest rozkaz: "definiuj tryb graficzny" gdzie podaje sie szerokosc ekranu, ilosc linii i tryb Antica. Obecnie cały ekran obslugiwany przez PIC musi byc w jednym trybie graficznym.
Ale pamietajmy ze dzieki Anticowi i display list, PIC nie musi obslugiwac calego ekranu! Mozna mu zlecic np generowanie tylko 140 linii na ktorych dzieje sie akcja, a np. panel umiescic gdzies w pamieci Atari w dowolnym trybie graficznym.
4. To jak bedzie rysowane tło jest niezalezne od dalszych operacji. Moze to byc statyczny obrazek (najszybsza opcja). Moze byc skladany z kafli o roznej wielkosci. Kwestie scrolla na razie zostawmy do dalszego zastanowienia.
5. Obiekty: tła, bitmapy i fonty będą skladowane w pamieci flash PIC'a. Zakladam ze będą mogly byc tam ladowane przez Atari. Na obiekty bedzie mozna wykorzystac od 66KB do 100KB.
6. Obiekt typu bitmapa moze miec szerokosc bedącą wiekokrotnoscia slowa (2 bajty) i dowolna ilosc linii.
7. Zamierzam zrobic obsluge duszków w formie podobnej do sprzętowych PMG. Liczba duszków będzie ograniczona do max 32 (oceniam ze to wystarczająca liczba, ale się do niej nie przywiązuję na razie). Będą rozkazy, służące do przypisania do duszka bitmapy, ustawienia go na pozycji X,Y itp. Te dane (nr bitmapy, x, y) bedą zapamiętywane w tablicy.
8. NAJWAZNIEJSZE: Schemat generowania obrazu przez Atari będzie wygladal tak:
Tuz po zakonczeniu rysowania ostatniej linii obrazu przez Antic, Atari zarzadza tlem: np wydaje rozkaz narysowania tla o numerze N z pamieci obiektow, albo rozkaz scrolla itp. Czeka na narysowanie tła. Pamiętajmy, że "czeka" to pojęcie umowne. Przeciez programista bedzie wiedzial co robi i ile mniej wiecej czasu PIC bedzie wykonywal te komendę. Atari moze w tym czasie wykonac cos pozytecznego, np wywolac player muzyki.
Po narysowaniu tła, Atari moze wydać rozkazy rysowania punktów, linii, innych figur geometrycznych, pisania tekstów itp itd. Wszystkie te polecenia będą wykonywane natychmiast.
Wydaje tez rozkazy przypisania obiektow do duszkow (np w celu animacji), zmiany ich pozycji itp.
Atari będzie mialo do dyspozycji również rozkaz "Rysuj obiekt N na pozycji X,Y". Ten rozkaz jest niezalezny od duszkow. Po prostu Tomek wezmie bitmape o wskazanym numerze i natychmiast naniesie ją na obraz w wybranym trybie (OR, AND, XOR, +maska). Po co to? Ano moim zdaniem nie ma sensu marnowac duszkow na jakies drobne obiekty typu pociski, linie lasera,
itp. Tym moze zarzadzac Atari kazac je rysowac w kazdej ramce.
Kolejny bardzo wazny rozkaz to "Rysuj duszki". Jesli duszkow bedzie 32, to ten rozkaz bedzie mial 4 bajty argumentow: po jednym bicie na duszka. 1 - duszek bedzie rysowany, 0 = duszek nie bedzie rysowany.
Ten rozkaz bedzie mozna wydawac wiele razy w ciągu rysowania jedbego obrazu.
Po co tak? Bo mozemy chciec najpierw narysowac jakies duszki będące na trzecim planie, uzupelniajace tlo o elementy ruchomer, pozniej naniesiemy "ręcznie rysowane" elementy, pociski, rysowane linie itp. A potem kolejnym rozkazem "rysuj duszki" naniesiemy obiekty pierwszoplanowe.
Innymi slowy, mozemy w ten sposob decydowac co na czym rysujemy.
9. Po przygotowaniu calego obrazu. Atari wydaje polecenie: "Generuj dane dla Antica". Od tego momentu PIC wie, ze jesli przyjdzie odczyt z "cwiartki $D5xx nalezacej do Antica" to ma podawac kolejno dane z pamieci ekranu w wybranym trybie.
10. Dzieki temu ze strone $D5 podzielilismy na obszary, w czasie kiedy Antic generuje obraz, program Atari moze jednoczesnie bez konfliktow korzystac z uslug PIC'a, np wydajac rozkazy operacji matematycznych czy inne. Moze nawet wydawac rozkazy wplywajace na pamiec obrazu, ale trzeba pamietac, ze moze to byc "brzydko widac".
I to tyle w duzym skrocie.
a jak wygląda kwestia detekcji kolizji? jakoś wspomagana czy bez wspomagania?
Nie wygląda. Nie mam na razie pojecia jak to zrobic, a wszystkie metody jakie jestem w stanie wymyslic wydaja mi sie koszmarnie niewydajne szczegolnie przy 32 duszkach.
Choc mysle ze prawdziwie przydatne byloby wychwytywanie nie kolizji "kazdy z kazdym" ale kolizji miedzy 2 obiektami (np. statki 2 graczy) a calą resztą obiektow i tlem.
Ale i tak na razie jest to dla mnie piesn przyszlosci. Outsoursing zakodowania tego bedzie mile widziany :)
Ostatnio edytowany przez nosty (2012-09-08 01:05:06)
> dzieki Anticowi i display list, PIC nie musi obslugiwac calego ekranu!
> Obiekty: tła, bitmapy i fonty będą skladowane w pamieci flash PIC'a. Zakladam ze będą mogly byc tam ladowane przez Atari. Na obiekty bedzie mozna wykorzystac od 66KB do 100KB.
o wlasnie, i dla tego uwazam, ze nawet najtansza wersja spokojnie "powinna wystarczyc kazdemu"
tych duszkow nie czuje, zamiast przypisywania obrazka do duszka i pozniej uzywanie go, latwiej by mi bylo zdefiniowac sobie 'kafelek' jako obrazek wielkosci x,y i pozniej ukladac go na ekranie nawet 10 razy ale zmieniac mu zrodlo danych, sortowanie kolejnosci wyswietlania wychodzi samemu przy np taich grach jak izometryczne, pozwolic ukladac 'kafelki' z dokladnoscia do pixela i sprawa zalatwiona.
---
na amidze masz bardzo rozbudowany system duszkow i ktora gra z niego korzysta?
Ostatnio edytowany przez xxl (2012-09-08 10:20:13)
frimeware?
do kolizji na pixlach "kazdego sprita z każdym" w locie czyli "per line" wystarczy mały bufor na ktory jest jeszcze miejsce w tomku(moze tak samo robic tez atarka). Wczesniej myslalem, że po stronie atari tryb znakowy ulatwiłby uproszczona kolizje AABB ale to było do wczoraj kiedy XXL wyjasnil szczegóły, możliwe, że nadal to jakieś ułatwienie w szukaniu rozwiązania ale chyba nie tędy droga, Tomek z uwagi na szybkość musi sobie poradzić z kolizjami (wielkość i ilosc obiektów). Coraz bardziej sklaniem się do tego co pisał nosty o "rozjechanym firmware", tomek to osobliwy temat, zależny od projektu... kiedy bedzie dostępny devkit ?
z tymi duchami to nie lepiej byłoby gdyby były nieograniczone i obiektowo je potraktować ? user tworzy definicje/class(rozmiar, kolor..) ich instancje(poł.x,y, source) i metody (animuj, nr warstwy) i wskazuje tylko tomkowi gdzie ma szukać tablicy czyli ten obszar gdzie zapisuje atarka w tomku a bitmapy do nich w tomku. Może to śmieszne z punktu widzenia kodera asm, więc niech rzuci ktoś kamieniem to się zamkne
Ostatnio edytowany przez cougar (2012-09-08 13:23:29)
Nosty, a prace praktyczne obecnie na jakim etapie?
Czekam na konwertery napiecia z TME (nie mieli na stanie) zeby zlozyc 2-3 prototypy w postaci cartridgy i sprawdzic min czy uklady zasilania z Atari i resetu dzialaja ok.
Jednoczesnie pracuje (wlasnie teraz bo w w tygodniu nie mialem czasu) nad procedurami obslugi i rysowania duszkow. Staram sie na bierzaco tworzyc dokumentacje rozkazow.
Na razie nie ma o czym mowic. Przez pare tygodni bedzie cisza, choc pewnie pokaze jeszcze jedno demo za jakis czas :)
Trzymamy kciuki :)
Sprawdzam procedury graficzne...
http://youtu.be/kfnsgPS6vdg
Pięknie to wygląda!
Mam kilka pomyslow na gry, dla ktorych Tomek jest wprost stworzony i latwo bedzie je teraz zrobic, a ktorych dotąd nie bylo na Atari :)
Ale sam wszystkiego nie pociagnę. Dlatego teraz skupiam sie nie na grach, ale na sprzecie i silniku, zeby jak najszybciej udostepnic finalnego carta developereom z mozliwoscia flashowania wsadu z poziomu Atari.
Na szczescie są już osoby, ktore zadeklarowaly pomoc i sprzetową i programową, wiec patrze pozytywnie w przyszlosc.
Strony Poprzednia 1 … 5 6 7 8 9 10 11 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.109 sekund, wykonano 16 zapytań ]