Może, ale nikt tu "fixów" nie cytował a ja to przetestowałem - potwierdzam działa. :-P Ciekawe jak takie poprawki wpłyną na inne dotychczas problematyczne produkcje?
Ja po prośbie, jak ktoś rozgryzie już ten "fjuczer": "event recording" (...) save your game using the "-record mygame.dat" and later impress your friends by (...) using the "-playback mygame.dat" bo mi coś nie działa. Czy to działa z atrkami, xexami, czy muszą być w tym samym katalogu? Odpaliłem record, wlazłem pod F1, zamontowałem atr z planszami do Robbo ;) i pograłem. Potem F9 i odpaliłem play, a tu mi zonk Self Test???
Hmmm... ta powyzsza statystyka wlasciwie nie wymaga komentarza... Mnie inna wersja niz Windowsowska nie interesi, szkoda, iz nie ma komu jej zrobic.... :-/
Odpaliłem builda pod Windows i niestety "NTSC Filter" nie ma / nie działa (albo uruchamiam emulator ze złym parametrem). Tak czy siak, fajnie że coś ruszyło w ostatnich miesiącach: Altirra - chociaż odnoszę wrażenie, że autor nie zdaje sobie sprawy z tego, że zapotrzebowanie na ten emulator rzeczywiście istnieje, i że tworzy go "dla siebie" - i Atari800, które samo w sobie jest z racji interfejsu użytkownika nieużywalne pod jedynym słusznym systemem, ale może zmobilizuje kogoś do rozwijania WinPLusa ;)
@galu Fakt, ja tam najbardziej lubię rozwiązania typu program + front-end, GUI itp. To daje tę wolność wyboru i łatwość pracy. Pamiętanie tych wszystkich komend, zmiennych, wklepywanie w konsoli za każdym razem... Taki mencoder np. - koszmar. Owszem się przydaje, do odpalenia jakiegoś batcha. Ale jeśli chodzi o atari800 - przydało by się jakieś klikalne międzymordzie. Nie wiem w jakim stopniu Atari800Win korzysta z atari800 (modyfikuje program źródłowy), ale gdyby to był projekt fornt-endu, to pewnie byłby bardziej niezależny od platformy systemowej.
@miker - dzięki za informację, pod wersją sdl-ową NTSC Filter można wybrać z poziomu UI - Display Settings > NTSC artifacting settings > NTSC Filter. Nie ma żadnych dodatkowych ustawień (jak w innych emulatorach) i nie można skalować obrazu - ale i tak rewelacja ;)
Nie mam pojęcia czy się da i jakim nakładem pracy, ale miło byłoby mieć emulację: 1. VBXE - pewnie by się spopularyzowało dzięki temu.
2. 65816 - np. dla DracOS i TRSDesktop lub emulację konkretnych działających dopałek typu Warp, itp.
3. innych rozszerzeń (może ktoś chcieć TighToolsPacket lub cokolwiek innego), może jako jakieś pluginy??
4. dowolne skalowanie wielkości okna, lub przynajmniej więcej predefiniowanych wielkości.
5. przy fullscreenie na rozdziałkach panoramicznych zachowanie proporcji 4:3 bez rozciągania.
6. zdefiniowane profile firmowych konfiguracji i opcji dla modeli: 400, 800, różnych XL, 65XE, 130XE, 65XEGS, itp. Znaczy żeby po wybraniu 400 był właściwy ROM, bez BASICa, itd, a dla 800XL też właściwy ROM i BASIC, ale oczywiście z możliwością podmiany np. na QMEG i zapisania własnych profili konfiguracji np. "moja 130XE z 320kB i QMEG".
ad.1. Emulacja VBXE jest niewykonalna, ale calkiem realna jest emulacja konkretnego rdzenia VBXE. I to juz nawet jest, bo mialem okazje widziec w akcji - implementacja Laoo w emulatorze Atari++. Rzeczywiscie szkoda, ze nie w Atari800Win.
ad.3. Są - cartrigde. Mozna tez podmienic OS ROM :).
ad.4. Jestem przeciw dowolnemu skalowaniu, ale jestem za tym, zeby to bylo skalowanie z zachowaniem proporcji ekranu. Emulator STeem jest dowolnie skalowalny i czasem jak niechcaco go przeskalujesz (chcac przeciagnac) to trzeba go wylaczyc, a potem wlaczyc.
A ja bym chcial prosta rzecz.... "Emulacje" SIO2IDE.. a dlaczego w cudzym słowie. Wystarczylaby mi mozliwosc okreslenia dysku/folderu w ktorym bybly obraz mojej karty CF wyciagnietej z SIO2IDE i niechby emulator sprawdzil czy jest tam plik konfiguracyjny SIO2IDE z zapisanym mapowaniem dyskow.... i jesli jest podmapowalby mi je w ten sam sposob...... A jakby jeszcze dzialalo te kilka rozkazwo SIO zmieniajacych to mapowanie to juz by bylo wspaniale.
Efekt: Wkladam sobie karte wyciagnieta prosto z malucha do czytnika w grzybie (a w emulatorze mam wskazany ten czytnik jako SIO2IDE), odpalam emulator... i mam to samo co w rzeczywistym Atari przed chwila!!
"(...) pełna emulacja umożliwiająca programową modyfikację działania wewnętrznego układu (gdzie można np. przeprogramować blitter w koprocesor) jest delikatnie mówiąc praktycznie niemożliwa."
...cd 7. drukowanie na drukarce PC - już zgłaszał Kaz, ale dodaję swój głos na to, bo nawet jeżeli ktoś coś dłubie w edytorach, czy programach graficznych na prawdziwym atari, to pewnie mało kto ma prawdziwą drukarkę, na aukcjach są drogie, głównie dostępnie w USA, a z racji wagi przesyłka bardzo droga, materiały eksploatacyjne mało dostępne, itp. Tak więc nawet materiały przygotowane na prawdziwym atari, można by wydrukować z emulatora po przeniesieniu na PC.
uicrOBee: To raczej lepsza byłaby przejściówka która podłączona do portu drukarki w real Atari, miałaby wyjście na RS-232 lub USB na PC, a pecet by drukował normalnie na swojej drukarce :)
Drukowanie plikow tekstowych z emulatora Atari800Win nie jest moze wygodne, ale mozliwe. Wlaczasz "P: patch" w opcjach, drukujesz do pliku, a Windows poslusznie tworzy plik txt. Taki plik, jesli ma znaki ATASCII (np. semigrafike) mozna druknac uzywajac np. pecetowskiego programu ATASCII View czy innego tego typu.
Problemem jest wydruk z emulatora w trybie graficznym.
A czy jest już jakiś obowiązujący rdzeń VBXE - w sensie default... Bo z tego co się orientuję to się zmienia. A czy emulacja VBXE nie jest możliwa... No nie wiem, pomijając kwestie wydajnościowe, to by po prostu była emulacja tego procesora który tam siedzi :)
wieczór: rdzeń możesz sobie w każdej chwili sam wgrać inny, i to z poziomu Atari. Co więcej, nic nie stoi na przeszkodzie, aby Twoja aplikacja korzystała z Twojego rdzenia, nie przygotowanego przez Electrona czy nikogo innego. I wcale VBXE nie musi wtedy służyć za kartę grafiki...
Sikor: Ja o tym wiem :) Mowa o emulatorze - skoro nie miałby mieć pełnego VBXE tylko emulacje konkretnego rdzenia to stawia to pod znakiem zapytania takie rozwiązanie
Na razie emulatory nie maja emulacji jakiegokolwiek rdzenia, wiec nie martwmy sie na zapas :).
wieczor - rdzenia "jedynie slusznego" nie ma, ale VBXE nie ma tez miliona uzytkownikow, z ktorych kilkudziesieciu bedzie w stanie napisac sobie wlasny rdzen. Na razie to jedynie Electron udostepnia kolejne wersje rdzenia i mozna je uznac za "defaultowe".
A jak ktorys z tych kilku programistow obecnych na scenie Atari, ktorzy sa w stanie to ewentualnie napisac, zechce udostepnic cos innego - to musza sie liczyc z tym, ze emulator z wbudowana emulacja konkretnego rdzenia VBXE tego nie pokaze, wiec odbiorcami beda tylko posiadacze prawdziwej karty. I co w tym zlego? Ja uwazam, ze nic. Jesli autor chce, zeby dzialalo tak, a nie inaczej to wolna wola. Nie powinnismy ograniczac pomyslowosci programisty, czy szerzej tworcy, tylko z powodu trzymania sie narzuconego odgornie "standardu".
A poza tym zawsze tak jest, ze to emulatory musza gonic za prawdziwym sprzetem i taka wlasnie jest korzysc z posiadania oryginalnego sprzetu :).
A posiadanie emulatora, nawet z niedoskonala, ale jednak emulacja VBXE, zawsze sie przydaje. Chocby do developmentu softu.
Też tak uważam. Więc fajnie by było wystawić emulację VBXE w postaci plugina, który każdy dla konkretnego rdzenia mógłby sobie dopisać ;) Bo pytanie brzmi który rdzeń wbudować. Jakoś mi się tak wydaje, że brak jakichś produkcji na VBXE częściowo wynika z faktu, że wszyscy się przyczaili i czekają na coś w miarę "finalnego", na zasadzie: ja napiszę a za miesiąc już nie będzie działać... :)
@wieczór: na zasadzie: ja napiszę a za miesiąc już nie będzie działać... Widać, nie potrafisz czytać ze zrozumieniem. To programista tworzący coś w danej chwili decyduje, co ma być w rdzeniu. Wystarczy napisać, że program wymaga rdzenia xxxx.vzx.xxx.bz7 - i każdy go w danej chwili może użyć. Na takiej zasadzie działa VBXE, więc nie ma czegoś takiego, że "nie chodzi, bo zmieniony rdzeń". Po prostu - najpierw wgrywamy odpowiednią konfigurację i już.
Sikor, spokojnie :). Kolega dopiero obczaja temat VBXE, zreszta jak my wszyscy.
A brak produkcji na VBXE tlumaczylbym raczej tym, ze ma to circa dwadziesia osob, z tego nie wszystkie w postaci finalnej czyli zamontowane w kompie. Z tych dwudziestu osob... niech spojrze na liste... dziewiec osob mialo jako przeszlosc programistyczna, cztery sa czynne. Z tych czterech Draco opublikowal juz zestaw Basicowy do obslugi trybow VBXA, Electron program do ogladania BMP, TeBe planuje jakas produkcje, xxl tez. I tajemnica wyjasniona.
Sikor: umiem czytać , ale (może błędnie?) założyłem, że istnieje jakiś rdzeń tzw. oficjalny - defaultowy - naturalnie jest rozwijany. Jeśli nie, to widzę następujące problemy: 1. Który miałby w zasadzie być w emulatorze skoro pełnego VBXE "niedasie" ?...
2. Wgrywanie rdzenia to pewna procedura - albo każda produkcja będzie nosiła ze sobą własny rdzeń, albo rozwiązanie ma poważny problem użytkowy. Weź no każ userowi ładować nowy rdzeń własnoręcznie aby pograł w Twoją gierkę :) A w inną - następny. To się mija z celem, ja opcjonalne rdzenie traktuję jako wynalazki, dodatki, powinien być jakiś default, na który powstanie większość produkcji.
Ja przypomnę że temat zaczął się od emulatora :) Jak ktoś w końcu (Candle?..) wpadnie na pomysł jak mam VBXE podłączyć u siebie i mi go zrobi, to przestanę kwękać ;)
Mam na myśli bibliotekę procedur wykonujących podstawowe operacje do szybkiej obsługi grafiki, umożliwiające zrobienie do tego gierki, systemu operacyjnego itp.
ad.1 Ten, ktory opublikowal Electron, autor projektu VBXE.
ad.2. skad bierze sie w Tobie przekonanie, ze kazdy musi sobie napisac wlasny rdzen, zeby napisac gre? Rdzen jest wlasnie takim "systemem operacyjnym" i "biblioteka", ktora sie domagasz. I pozwala robic co tam sobie zazyczysz w kwestii grafiki (zobacz dokumentacje).
Mozliwosc napisania i ladowania wlasnego rdzenia to tylko ekstra mozliwosc, dla naprawde zaawansowanych programistow, ktorzy moga wykorzystac hardware to stworzenia czegos zupelnie innego, na przyklad wlasnie kooprocesora zamiast karty graficznej.
Nie oszukujmy sie jednak, szanse powstania rdzeni o innych funkcjach sa bardzo male. Na Twoim miejscu nie bardzo bym sie wiec martwil tym, ze bedzie "wiele rdzeni do wielu roznych gier". Nie bedzie ani wielu rdzeni, ani wielu gier. Przyczyna pozostaje ta sama: jest tylko kilku programistow.
A wszystkie produkcje, ktore aktualnie powstaja dzialaja z rdzeniem stworzonym przez Electrona, bo niby z czym maja dzialac? Przyjmij wiec dla spokoju swojej duszy, ze jest "defaultowy" rdzen - ten wlasnie Electronowy.
Atari++? I supose Laoo is going to ask (or even he just asked) about project leader's bless for his patch. It can take effect in official release.
Atari800Win PLus? The new core (Atari800 2.1.0) is ready to be ported for Windows, but someone has to do it. I heard that were some problems with Microsoft VS compilation, so Jaskier published sources to be helped.
Generalnie - póki co, to niniejszy temat należy potraktować w sferze marzeń, ew. mniej lub bardziej odległych planów. Już wcześniej wspomniałem, że na AtariAge pewien gostek pytał o źródła PLus-a (dokładnie tutaj tutaj: ->link<- ) i zanim się zabrał (a w zasadzie _niby zabrał_ za kompilowanie) wspomniał o kompilatorze pod tytułem Digital Mars ( ->link<- ). Jaskier puścił źródła wersji 4.1 (opartej bodajże na corze 2.0.2) i od jakiegos czasu kompletna cisza w temacie.
Może kto jeszcze nie jest zarejestrowany na A-age, zrobi to i pobombarduje nieco wspomniany temat pytaniami.
Ponieważ ostatnio kompilowałem w ramach projektu profilera źródła Atari800Win 4.0 Plus, to przejrzałem co by było trzeba zmienić w źródłach Atari800 v2.1.0, by się skompilo ponownie. Niestety jest tego dużo... Pracy co najmniej na kilka dni. Jakby ktoś chciał się pobawić, to moge podesłać projekt dla Visual Studio 2005, którym kompilowałem źródła z ->link<-
Wiesz, nie śpieszy się - nawet po kawałku możesz przerabiać (o ile masz oczywiście chęci i czas). Myślę, że gra jest warta świeczki. No i może ktos pomoże (ja niestety w tej materii zielony zupełnie jestem).
Chęci są, z czasem gorzej. Wolę też wpierw dokończyć grę, którą piszę. Potem zaś zabiorę się raczej za debugger w stylu emulatora AppleWin lub spróbuję zintegrować ->link<- z emulatorem jako debugger. IMHO aż tylu przełomowych zmian w wersji 2.1.0 nie ma, by było warto tracić dużo czasu.
Miker @"Może kto jeszcze nie jest zarejestrowany na A-age, zrobi to i pobombarduje nieco wspomniany temat pytaniami."
Ja obserwuje ten temat dosc dlugo, ale zauwazam na razie tylko ogromna aktywnosc wymienionego na forum. Jakos mi sie tak kojarzy, ze im kto wiecej opisuje na forum co robi, tym mniej robi... :)
Czytam to w co się ten wątek zamienił i kajam się, kajam... Czasami mam pretensje dla Linuksa, jednak to jest genialny pomysł back-end i front-end - program i nakładka! Nie wiem ile atari800 w Atari800Win i jak to tam siedzi, ale to koszmar - po każdym wydaniu nowego atari800 trzeba by kompilować na nowo wersję Win. Ja wiem, w świecie MS to norma, większość emulców tak ma ale tak mi kołata w głowie czy za prapoczątków przyjęto właściwą strategię, skoro jeden program zależny jest od drugiego. Taki DOSbox ma parę frontendów, niektóre stare ale wciąż działające z najnowszą wersją.
W Atari800WIn chciałbym mieć domyślnie ten sam tryb nagrywania filmów avi co w DOSBoxie. Szalenie wydajny, nawet na moim leciwym sprzęcie nagrywa bez problemów ładne filmy o rozsądnej obietości.
@KAZ > Jo - można. Próbowałeś kiedyś DOSBoxa? "DOSBox will create an AVI movie, including any audio using the ZMBV (Zip Motion Blocks Video) codec. To initiate recording you press the CTRL-ALT-F5 combination. To stop recording, you press the same combination again.". Tak po prostu, bez grzebania, ustawiania itp. Bardzo wydajne rozwiązanie. Na moim Athlonie XP 2800+ emuluje dosa, zgrywa wideo z dźwiękiem do pliku a w tle gra muzyka. W Atari800Win jedyny rozsądny kodek to MS Video 1 lub pełne klatki ;-). Swoją drogą, muszę poinstalować tego ZMBV i zobaczyć czy zechce działać z Atari800Win