Będzie, będzie - już niedługo, dosyć mroczna ;) tyle, że potrzebne będzie drugie podejście - kanały we RMT mi się za szybko skończyły i trza "poupychać". :) A, wywal tego "Self Teścia", na WinPLusie sprawdzałem i mi skakał tam zamiast do gry (czasem mam joy-a "odpiętego").
Kaz - wiesza się wtedy jeśli po wspinaczce nie zejdzie się na dół,
Ale ja wlasnie nie moge zejsc na dol, bo sie wiesza... :)
Mam problem z połączeniem plików Integratorem. Jeśli włączy się przełączanie automatyczne po 5s, to działa, ale obrazek tytułowy jest wyświetlany zbyt krótko
Wprowadziles ruchome elementy do obrazka, to pewnie przyczyna, ze nie starcza czasu na obsluge klawiszy. To podobny efekt, gdy obrazek jest przeladowany przerwaniami (szczegolnie w pierwszym lub ostatnim wierszu rysunku). Moze Tebe by podpowiedzial, jak rozwiazac taki problem?
@Gonzo: obrazek jest monochromatyczny (30 odcieni). Może dałoby się go wykorzystać jako loading screen (coś jak np. w "Kick Off") - po naciśnięciu klawisza wczytuje się właściwy program (gra).
Super że są szanse na ukończenie gry - czekam z niecierpliwością :)
Integrator rozpoznaje pewną sekwencję kodu, którą generuje G2F i dlatego prawdopodobnie innych formatów nie rozpozna. Na nową wersję na razie nie ma co liczyć. Za dużo mam rozpoczętych projektów i chyba mi życia nie starczy, żeby wszystko skończyć.
i chyba mi życia nie starczy, żeby wszystko skończyć.
Przeciez medycyna robi stale postepy w wydluzaniu zycia... :D
PS. Wlasciwie to trzeba by, zeby ewentualny nastepny "Integrator" rozpoznawal sekwencje kodow AIS zamiast G2F. Jako, ze autor tych programow jest ten sam, to moze cos by sie mozna od niego bylo dowiedziec - jak to zrobic?
Ladna grafika. To ripowana, czy autorska? Nie wiem czy to zludzenie optyczne, ale ogladajac na Atari800win caly czas mam wrazenienie ze ten przesuwajacy sie bohater lekko drga, jakby sie nierownomiernie przesuwal. On jest zrobiony na duszkach (?) wiec plynnosc powinna byc idealna. Moze to zludzenie przy ogladani na takim tle, ale az ciezko na nim skupic wzrok. Tez tak macie?
Na Altirra aby nie drgało trzeba przełączyć Atari w NTSC i dać na pełny ekran. To dlatego, że w Windowsach pełna płynność jest możliwa tylko na pełnym ekranie a NTSC dlatego, że Altirra ustawia 60Hz dla pełnego ekranu nawet jak Atari jest w Pal więc logiczne że musi skakać bo się nie synchronizuje. Na tym ustawieniu już tylko czasem przytnie ale to wina złego kodu emulatora. Atari800Win zawsze skakał bo jest źle napisany ale nie patrzyłem jak to wygląda na ostatniej wersji. Na prawdziwym sprzęcie zapewne jest płynnie nawet w Pal.
Sprawa nie dawala mi spokoju, wiec pozwolilem sobie program odrobine sdeasembolowac i strace'owac na Altirze i wychodzi mi ze faktycznie drgac nie powinno, czyli to co widze musi byc niedoskonaloscia emulacji ewentualnie zludzeniem. Faktycznie na Altirze NTSC efekt jest jeszcze ciekawszy: postac przez wiekszosc czasu rusza sie plynnie, za to raz na jakis czas solidnie przycina.
Co do stwierdzenia "Atari800Win zawsze skakał bo jest źle napisany", to zauwazam tylko, ze na zdecydowanej wiekszosci produkcji ten emulator pokazuje ruch duszkow plynnie, a na zalaczonym flimbo2.xex nie i to mnie wlasnie zainteresowalo.
Sprawdziłem dokładnie najnowszą wersję atari800win(2.2.1). Jest o wiele lepiej niż kiedyś. Na wersji SDL czasem przycina(nie pozwala włączyć vsync bo pisze, że niedostępne dla trybu). Na wersji DX tnie na GDI i GDI+ ale w trybie Direct3D i na pełnym ekranie jest płynnie, zarówno w PAL jak i w NTSC. Oczywiście trzeba pamiętać aby mieć pulpit ustawiony wcześniej na 50Hz dla Pal lub 60Hz dla NTSC. Teoretycznie powinno być też dobrze przy wielokrotnościach tych częstotliwości 100Hz, 120Hz itd. ale nie mam w tej chwili możliwości przetestować. Trochę nierówno ustawiona jest tekstura(przekrzywione teksele) na której jest to renderowane i trochę psuje efekt jak się ustawi bardzo wysoką rozdzielczość ale płynność jest raczej OK.
normalnie szacun ludzi ulicy ;), byle tak dalej p.s. błąd może wynikać z nachodzeniu się procek vblank na siebie, sprawdź czy przy kraszu na monitorze nie masz śmieci na stosie
plik flimbo_back_layer.xex Jest przesuw ekranu w obu kierunkach ale są błędy w wyświetlanej grafice tła. W tej wersji nie ma drugiego planu.
Plik flimbo3.xex Ruch joystickiem w prawo powoduje drgnięcie ekranu i wrażenie występowania drugiego planu ale trwa to jedynie przez ułamek sekundy po czym otrzymujemy czarny ekran. Ruch joystickiem w lewo owocuje przesuwem ekranu, który wygląda nieciekawie. Przesuwa się bowiem kilka wierszy u góry ekranu oraz na dole przy nieruchomym środku.
@nosty: ja tylko rzuciłem na to okiem ale wydaje mi się że mu przepisywanie ekranu nachodzi na ekran i dlatego szarpie. Wątpie żeby ogólnie nie mieścił się w vblanku bo mi ta procka zajmował 1/3 vblank więc czasu powinno być sporo w zapasie. Jutro zerknę dokładniej jak się sprawa nie wyjaśni ;)
wydaje mi się, że sposób na optymalizację procki może być taki, że tworzysz 4 zestawy znaków dla 4 faz ruchu 2 tła i podmieniasz je gdy tylko zachodzi taka potrzeba, pozostaje tylko obliczenie i rozmieszczenie znaków tła na ekranie co 4 fazy(czyli dość rzadko) co można myślę w rozsądnym czasie zrobić, tak że zostanie jeszcze sporo czasu
A ja jesli mozna, chcialbym sie dowiedziec jakie sa ograniczenia tego parallaxa? - Widze ze jest wąski obraz. - Widze, ze grafika na drugim planie nigdy nie siega wyzej niz pewien poziom (maxymalnie dochodzi do tych kisci bananow wiszacych pod sufitem na pierwszym tle). Czy to ograniczenie? - Mam wrazenie, ze wszystki elementy grafiki na pierwszym planie maja wymiary pelnego znaku. Czyli ze nie mozna umiescic na pierwszym planie znaku zawierajacego 1 zapalony pixel ktory poruszal by sie na tle drugiego planu (tak by reszta pixeli tego znaku byla przezroczysta)? - Czy sa jakies ograniczenia proporcji ilosc grafiki na pierwszym i drugim planie (czli np ze min. 50% drugiego planu musi byc zasloniete)?
I generalnie chcialbym sie dowiedziec JAK TO DO CHOLERY JEST ZROBIONE? :D Bo ja mysle od wczoraj i nie wiem jak zrobic to z tak piekna plynnoscia zeby sie wyrabialo :/