c64scene.pl

dobrze że to już obczaiłeś, sorry ale nie zawsze człowiek ma szansę odpowiedzieć.

Dwie mapy kolorów (dwie kopie), są tylko dla "przełącznika" kształtów sprites w $d018,
w ten sposób można przełączyć wszystkie sprites "na raz" nawet w badline, bo przy włączonych wszystkich 8-miu, zostaje tam tylko 4 cykle na to - czyli akurat.

spoko..
acha, czyli że i w trybie ze zmianami $d025 i $d026 w sprites co 21 linii, i w tym co 1 linię, dwie mapy kolorów są identyczne ? W sumie to dlaczego - przecież można chyba nimi przejścia tonalne robić.
I nie do końca rozumiem, co by miała dawać zmiana kształtów sprites ? Chodzi tylko o tą zmianę co 21 linii, tak?

No i jedna uwaga: włączonych jest 7 sprajtów ($7F do $D015).

Powiem szczerze: edytor z tego zrobić, to trochę porażka. Tzn. mam na myśli to, że grafik musiał by się nieźle napocić żeby "od zera" coś narysować z takimi ograniczeniami, i przy każdym pixelu się zastanawiać skąd go wziąć (tło/bitmapa/4pixel sprajt. Bardziej edytor chyba do korekcji konwertów przydatny

Przy okazji, dla ciekawskich - tak wyglądają składowe obrazka:

1. Podłoże, czyli mapa kolorów 8x8:



2. Warstwa pierwsza, czyli sprajty X-expand w multicolor



3. Warstwa druga, czyli HiRes z bitmapy



-----------------

Połączenie 1+2



Połączenie 1+2+3



Teraz muszę trochę poczytać o programowaniu na PC

Pozdrawiam

nes pisze:Chodzi tylko o tą zmianę co 21 linii, tak?

tak, inaczej nie zdążysz przełączyć wszystkich kształtów.
lda sta to 6 cykli, razy 8 to 48, 8 sprites zabierają 8*2+3 = 19 w każdej linii w której są wyświetlane, czyli 63-19 = 44 - czyli już brakuje 4 cykli, żeby wykonać skuteczną zmianę w wybranej linii.

Fakt, MUCSU wykorzystuje 7 sprites, czyli można się wyrobić, ale ... nie w Badline , stąd ta druga kopia ekranu koloru - teraz możesz sobie kształty ustalić wcześniej, a tylko w odpowiedniej linii przełączyć mapę kolorów w $d018 na nr2, potem kształty zmieniasz w nr1 i przełączasz przy "kolejnej okazji" (czyli w następnej +21 liniii) itd.

OK, dzięki

A jeszcze pytanie - o tym że to zielone tło po prawej w tym konkretnym obrazku jest ma w lewej połowie podłoże z 8x8 a w prawej ze sprites w multicolor zadecydował automatycznie konwerter, czy to jest ta ręczna zmiana o której pisał isildur ?

Nie, ręczna korekta była tylko w minimalnym stopniu, Isildur trochę "przesadził".
Ale akurtat kolorowanie tych obszarów można z góry narzucić konwerterowi. W wersji konwertera nr2, można poustawiać, wybór manualny kolorów, oraz wymusić stary tryb (bez zmiany co linię koloru w $d025,$d026) i ja wlaśnie z tego korzystam - nowego konwertera do starego formatu .

skull pisze:Nie, ręczna korekta była tylko w minimalnym stopniu, Isildur trochę "przesadził"

Nie do końca, po prostu nie mówiłem Ci o każdym pikselu, sam palec wskazujący lewej ręki to było jakieś 20 konwersji, a konwersja odbywa się tak: obrazek w P1 -> konwerter MUCSU - jeśli źle to screenshot, korekta w P1 i zapętlenie. Po prostu czasami nieważne co zrobisz, to konwerter i tak zrobi po swojemu, tzn. tam jakieś uśrednianie kolorów w danym obszarze działa.

digger - fajna opcja jest w Twoim edytorze - to pixelowanie patternami podoba mi się to
btw. w jakim trybie jest obrazek ?
no i ogólnie respect za taki projekt we flash

Mam pytanie - najnowsza wersja IMOSa to ta?
IMOS V0.6B 7.1

A do Diggera - Czy jest szansa, żeby śledzić postępy w wersji online - czy może planujesz wersję standalone dla testerów

jok pisze:Mam pytanie - najnowsza wersja IMOSa to ta?
IMOS V0.6B 7.1

Tak. Potem udostępniłem źródła, gdyby ktoś potrzebował coś sobie pozmieniać/dopisać - http://noname.c64.org/csdb/release/?id=89228 (pod Borland C++ chyba 6.0 albo 5.0, nie pamiętam)

Nes, website u Mayka (toto zyje jeszcze? Ci nie klika

właśnie go o to kilka dni temu pytałem - powiedział że niestety fizycznie tamten serwer z danymi przepadł, tak że tutorial też. zachowała się tylko niepełna wersja, tutaj wystawiam:

http://4x4.x12.pl/imos/imos.html

brakuje chyba trochę obrazków i nie wiem czy później nie było coś jeszcze dopisane, jakieś tutoriale

Jeśli ktoś byłby zainteresowany wyświetlarką MUCSU w JavaScripcie, to zamieszczam tutaj:

http://apt.hopto.org/nes/mucsu/

Można sobie podglądnąć źródło wyświetlarki.
W linku jest przykładowy plik, który można pobrać na dysk i następnie otworzyć z wyświetlarki.


Niestety nie wiem dlaczego dopiero za drugim otwarciem plik się wyświetla :/

Może komuś się na coś przyda.

Pzdr

Świetny temat chłopaki!
Właśnie takich rzeczy na forum brakuje mi najbardziej!
Dzięx!

Ogólnie to uważam, że tryb ten jest warty zainteresowania - niestety jak na razie jest tylko converter, a brak jest jakiegokolwiek edytora, nawet najprostszego - a może będzie w najnowszej wersji IMOS-a ?:)

chętnie bym po(beta)testował taki edytorek

Link przeniesiony:

http://apt.hopto.org/nes/impact/mucsu/

Przy okazji, strona Impact:

http://apt.hopto.org/nes/impact/

Kurczę zróbcie edytor do tego trybu - odwdzięczę się grafą na miarę Archmage'a
Serio - mam 2 niewydane rysunki pod MUCSU, ale nie dam rady się bawić w 20 konwersji na jeden palec jak Isildur. Leżą, kwitną a ja tracę motywację.

A dlaczego nie NUFLI? Ma o wiele mniej ograniczeń dla artysty, za to przy wkładaniu do dema koder będzie zgrzytał zębami, ale Ty chcesz wydać te obrazki standalone. I jest edytor, na C64 ale zawsze coś, drobne poprawki można zrobić.

bo do NUFLI jest a do MUCSU wogóle nie ma.

Poza tym ten tryb nie musi być tylko do statycznego pokazu - on się nadaje jeszcze pod coś - np. scrolowanie), nie trzeba go mieć na całą szerokość ekranu - wtedy zastosowania się mnożą. NUFLI, ufli. fli ,ifli srifli, nawet zoom4 nie mają takiej możliwości, i żrą całą powierzchnie ekranu.

Wiem wiem, mówiłem do joka, jeśli grafiki mają nie być przeznaczone do dem, to nie ma lepszej opcji niż NUFLI.