Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Rogul 1.0f Poprawki i nowe funkcje
a8rawconv GUI Graficzny interfejs użytkownika (GUI) dla narzędzia a8rawconv
TNFSD-GUI Graficzny interfejs użytkownika dla serwera TNFS
Wywiad z Bocianu na AtariOrbit Wojciech "Bocianu" Bociański, znany w naszym środowisku programista, udzielił wywiadu serwisowi AtariOrbit.
FujiNet. Artykuły odkrywające możliwości Jak urządzenie łączy Atari z nowoczesnością, umożliwiając społecznościową rywalizację w grach i korzystanie z sieciowego OS.
atari.area forum » Posty przez jury
PS Jaka to wersja TOSu na zdjęciu?
1993 to raczej zdecydowanie już 4.04, ale sprawdź za pomocą Sysinfo to się jeszcze wielu innych rzeczy o tym egzemplarzu dowiesz:
https://sites.google.com/site/stessenti … ls/sysinfo
Powinno być już lepiej.
Jest. Dzięki!
jest problem z wyjściem do Minta z gry uruchomionej w trybie pełno ekranowym.
A jak się to objawia, jakiś komunikat masz czy cuś?
U mnie wychodzi prawidłowo.
@Jury, jak chcesz zebym cos testował na jagpadzie to pisz :)
OK, załączam wersję która już działa z Jagpadem. W pierwszym poście też jest już wersja pałej paczki (zip) w której jest ta nowa binarka obsługująca Jagpada.
Dzięki Kroll za zgłoszenie problemu i testy.
Kompilat MiniSlug'a na najmocniejsze konfiguracje Falcona. CT6x oczywiście wymagany + jako, że grafika jest w 16bitach (co widać, jest naprawę kolorowa), to i SuperVidel wymaganay (nie wiem jak wygląda sprawa z Radeon'em, ale to też by dało radę)
Oczywiście uruchamia się na oryginalnym Videlu bo ma on tryb 16bit. I taki pierwszy poziom nawet jest grywalny. Wyjątkiem jest końcowy boss, tam już Videl klęka (a raczej ST RAM) ale tragedii jeszcze nie ma. Tragedia pojawia się na drugim poziomie który jest pod wodą, więc wszystko "pływa" i tu Videl nie wystarcza. Kolejne poziomy pewnie by już znów działały znośnie, bo mniej się na ekranie dzieje, ale przebrnąć przez 2 poziom to była by udręka (choć można pewnie by cheat'em przeskoczyć ten poziom)
Muzyka wyłączona, oryginalnie jest jakaś biblioteka Leonarda (Oxg) w c++ która odgrywa pliki YM, ale jak to gdzieś w sieci na ten temat ładnie napisane, 68k jest za słabe aby to pociągnęło. Sound FX'y są.
Klawiszologia:
F8 - pauza, wyjście
F9 - przełączanie 320x240 / 640x480 (nie polecam używać, no chyba, że na jakimś Firebee, ale też wątpię aby dało radę)
Strzałki - chodzenie
Spacja - skok
C - strzał
V - specjalny strzał
Jest szansa, że Jagpad zadziała, ale nie mam więc nie wiem.
Gra jest cholernie trudna, a przynajmniej dla mnie, ale jak trochę się pogra, to kurcze można iść jak przecinak :)
Tak wygląda na Amidze:
http://www.indieretronews.com/2017/06/t … metal.html
Edit:
Aha, ze względu na długie nazwy plików potrzebny MiNT.
dysk automatycznie pojawi mi się w TOS, czy może zależy to od wersji TOSa, albo dodatkowych sterowników?
Nie pojawi się* potrzebujesz jakiś sterownik. Z komercyjnych masz do wyboru sterownik HDDriver Uwe'go oraz sterownik PPutnika. A z darmowych to chyba najpoularniejszy jest IDC Pro + masa innych typu AHDI, Cecile, CBHD, Hushi ...
*chyba, że EmuTOS ma wbudowany sterownik, zupełnie nie śledzę EmuTOSa, ale wydaje mi się, że kiedyś czytałem że:
- EmuTOS ma już w sobie sterownik do dysku
- takie są plany i ma mieć sterownik kiedyś tam
- przyśniło mi się to
Nie jest warta tyle, frajera szuka. Mega obecnie jest warta tyle co Cyprian napisał za ile właśnie swoją kupił i za ile widuje na ebayu.
No to i ja dołączę do koncertu życzeń :) Chętnie przygarnę:
-PAK
-FRAK
-PuSTE
autor rozszerzeń właśnie bada zapotrzebowanie i chce zlecić produkcje.
A gdzie tam jest ta informacja? Bo nie mogę tego znaleźć.
Edit:
Sam sobie odpowiem. Bo chyba już nie bada zapotrzebowania, tylko ma ileś gotowców, bo jest info, że są dostępne. OK, to jeszcze lepiej :)
To jeszcze jedno. Chcesz zrobić init tablicy na starcie a pozniej dla kazego odswiezanego pixela ekranu robic w niej lookup a potem zapisywac znaleziony kolor do chunky buffora, tak?Nie wiem jak duzo odrysowywujesz co ramke, ale jesli wiekszosc ekranu to ten koszt też może się zrobić znaczący (w stosunku do przygotowania 8bit grafik wczesniej).
Na chwilę obecną jest to zrobione tak, że po przeliczeniu danego piksela od razu leci on do karty graficznej, co w naszym przypadku oznacza ST-RAM. Ale generalnie taki właśnie mam plan, że po przeliczeniu koloru najpierw będę go wrzucał do chunky buffora w TT-RAMie, a potem tylko jednym SDLowym blitem przerzucał to do ST-RAMu. To jest następny mój krok optymalizacji tego, ale już wstępnie w pół minuty byle jak na szybko skonstruowałem sobie taki bufforek i tam przekierowałem przeliczone kolory a potem jeden blit do ST-RAMu i faktycznie różnica w czasie wykonania była ogromna.
Swoja drogą używasz C2P w pełnym oknie 640x480? Ciekawe jestem jak to się spisuje, pewnie coś koło 3 ramek na to leci na CT60?
No ja akurat jak to mierzyłem to nie w ramkach tylko w milisekundach i wychodzi mi, że w 640x480x256 SDL przerzuca bufor ramki do ST-RAMu w jakieś 60 milisekund, czyli faktycznie jakieś plus/minus 3 ramki.
Dokładnie, tak zwany target to 060. I przyznam szczerze, że nawet nie rozważałem trybu TC, ba nawet o nim nie pamiętałem. Dla mnie jest to jakiś egzotyczny tryb, nie mówiąc, że kompletnie o nim nic nie wiem, oprócz tego, że raczej jest ciężki. A do tego tego potrzebuję rozdzielczości 640x480, więc czy tryb TC w takiej rozdzielczości nie zabił by ST-RAMu?. Choć kiedyś będę musiał się pobawić tym trybem,.
Ja generalnie mam jedną paletę 8bit, do której potrzebuję się konwertować, więc opcja ze zrobieniem tablicy w inicie to zdecydowanie najbardziej podobające mi się rozwiazanie. W sumie nawet jak bym miał tych palet więcej (a przecież była by to mocno skończona ilość) to i tak bym robił tablice, pewnie wtedy 6cio bitowe, zaufam Fox'owi, że nawet na 6 bitach straty będą niezauważalne.
Tu nasuwa się pytanie: czemu chcesz pracować na 24bitach?
Bo tak jest zrobione i specjalnie nie chce mi się wprowadzać dużo zmian. Jest to bardzo prosta gra, tyle, że w pierwszym SDLu i rozdzielczości 640x480, więc bezpośrednio po skompilowaniu tego, chodzi to wszystko jedna klatka na 2-4 sekund. Chcę to doprowadzić do stanu używalności i powoli widać różnice. Na razie "siedzę" jeszcze w menu, i tam jest właśnie kilka efektów, jak np credits'y co kilka sekund zmieniające się, gdzie starye napisy znikają tak jak dym.
JNie widzę jakiejś strasznej potrzeby robienia tego w runtime - jury dlaczego? Jak to mówią: najlepsza optymalizacje = nie liczyć;)
Nie, nic z tych rzeczy, jeśli z mojej wypowiedzi wynika, że uparcie chcę to robić realtime, to zupełnie niezamierzone. Zdecydowanie należę do tych dla których liczy się wynik końcowy, a jak jest osiągniety, to kompletnie nieistotne ;)
W weekend będę miał chwilkę, to zmontuję tablicę 7 czy nawet i 6 bit jak proponował Fox, i mam nadzieję, że będzie git.
Podepnę się pod temat mam monitor commodore 1084 VDE . Monitor wcześniej trochę piszczał i działał normalnie .W pewnej chwili obraz zaczął się raptownie zwężać i zgasł. Na chwilę obecna pali się jedynie dioda zasilania .Jest sens go naprawiać ? Co mogło zostać uszkodzone .
I co, naprawiałeś? Bo też mam monitor Commodore z tej serii który potrzebuje jakiegoś magika.
Dzięki Panowie, wygląda na to że tablica będzię najlepszym rozwiązaniem. Szczególnie kusząca jest ta opcja 2MB'owa bez zauważalnej straty.
Tak, zgadza się, właśnie funkcja SDL_MapRGB tak działa, tyle, że nawet na CT6x tak wolno, że nie da się tego używać w tak zwanym czasie rzeczywistym. Dlatego też myślałem, że w demach czy grach używa się jakichś jeszcze bardziej stratnych algorytmów aby to działało wydajnie.
Jak będziesz miał chwilkę, to podrzuć te linki.
Jak się robi konwersję z palety 24bit do indeksowanej 8bit w grach czy demach na Falcona aby to działało wydajnie w c/c++?
Bo mam sobie taki przypadek, blok 250x70 pikseli (czyli jakieś 18 tysięcy pikseli) i po przeliczeniu mega prostego efektu na tym bloku (które trwa jakieś kilka milisekund pod Hatari 68040@32MHz) dopasowanie składowych R, G, B do palety 8bit za pomocą SDL'owej funkcji SDL_MapRGB dla tych 18 tysięcy pikseli trwa około 3,5 sekundy!
Pod CT63 podkręconym na 95MHz jest oczywiście zauważalnie szybiej, ale i tak jest to dalekie od jakiejkolwiek sensownej prędkości.
Wymyśliłem, że sam sobie stworzę taką funkcję konwertującą, ale wyszło jeszcze z pół sekundy dłużej, a do tego ostateczne odwzorowanie koloru/indeksu palety jaki został wybrany jest zdecydowanie gorsze.
Jak się w takim razie ogarnia jakieś efekty na większej ilości pikseli, tak aby to działało znośnie? No chyba, że efekty robi się jakoś bezpośrednio na docelowej palecie aby uniknąć konwersji, ale to była by chyba jakaś masakra.
Wiele gier do odpalenia z HDD musiało być w tym celu spatchowanych i są one dostępne np. na stronach http://d-bug.me/ lub Pery Putnika.
Jeszcze tylko dodam, że Klapauzius też patchował gry na HDD itd (np pod CT6x):
http://www.klapauzius.net/Old_Games.html
Dzięki za sugestię, ale na razie robię tylko tryb kolorów 8bit, więc endian'y mnie nie dotyczą.
Coś mi przyszło do głowy jeszcze wczoraj, więc będę to dzisiaj jakoś sprawdzał.
Edit: OK, temat nieaktualny. Rozpierdzuchę palety robi funkcja SDL_DisplayFormat wywołana zbyt wcześnie. I to w sumie jest dość zrozumiałe, ale nie rozumiem dlaczego mimo wszystko jak później dostarczymy paletę, to z grafiki robi się mocno psychodeliczny twór. To znaczy, oczywiście odpowiedzialna za to jest zapewne również SDL_DisplayFormat, ale przynajmniej na razie już nie wnikam co i jak bo osiągnąłem to co mi obecnie potrzebne.
Cały wieczór dzisiaj spędziłem próbując ustawić paletę przez SDL i *ponownie* nie udało mi się (jakiś kawałek czasu temu po raz pierwszy chciałem to osiągnąć i spędziłem wtedy chyba ze 3 dni, ale w końcu się poddałem)
Może ktoś się dopatrzy czegoś co robię źle.
Generalnie robię to jak poniżej, ładuję bmp SDLową funkcją (choć i czytałem już specyfikację BMP i mam też własną funkcję ładującą BMP) potem buduję sobie paletę i SDLową funkcją ją ustawiam, i wg mojego rozumowania to powinno działać.
if( SDL_Init( SDL_INIT_EVERYTHING ) == -1 )
{
return 1;
}
screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );
for (x = 0; x <256; x++)
{
strcpy(s1, "screen po setvideomode: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, screen->format->palette->colors[x].r, screen->format->palette->colors[x].g, screen->format->palette->colors[x].b);
strcat(s1, s2);
loguj(s1);
}
if( screen == NULL )
return 1;
background = load_image( "data/images/title.bmp" );
for (x = 0; x < 256; x++)
{
paleta[x].r = background->format->palette->colors[x].r;
paleta[x].g = background->format->palette->colors[x].g;
paleta[x].b = background->format->palette->colors[x].b;
}
for (x = 0; x <256; x++)
{
strcpy(s1, "background po zaladowa: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
strcat(s1, s2);
loguj(s1);
}
if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
{
loguj("problem z ustawieniem palety1");
}
SDL_BlitSurface(background, NULL, screen, NULL);
SDL_Flip(screen);
SDL_Delay(1000);
Niemniej kolory są zawsze nie takie jak w pliku. Jeśli z takiego wczytanego BMPka do struktury SDLowej "zbieram" sobie paletę i loguję ją do pliku, to te wartości r, g i b są jakieś zupełnie inne. Co prawda nie wygląda to jak kompletnie losowe wartości:
background po zaladowa: indeks = 0 | r: 0 g: 0 b: 0
background po zaladowa: indeks = 1 | r: 0 g: 0 b: 85
background po zaladowa: indeks = 2 | r: 0 g: 0 b: 170
background po zaladowa: indeks = 3 | r: 0 g: 0 b: 255
background po zaladowa: indeks = 4 | r: 0 g: 36 b: 0
background po zaladowa: indeks = 5 | r: 0 g: 36 b: 85
background po zaladowa: indeks = 6 | r: 0 g: 36 b: 170
background po zaladowa: indeks = 7 | r: 0 g: 36 b: 255
background po zaladowa: indeks = 8 | r: 0 g: 73 b: 0
background po zaladowa: indeks = 9 | r: 0 g: 73 b: 85
background po zaladowa: indeks = 10 | r: 0 g: 73 b: 170
background po zaladowa: indeks = 11 | r: 0 g: 73 b: 255
...
ciach
...
background po zaladowa: indeks = 245 | r: 255 g: 182 b: 85
background po zaladowa: indeks = 246 | r: 255 g: 182 b: 170
background po zaladowa: indeks = 247 | r: 255 g: 182 b: 255
background po zaladowa: indeks = 248 | r: 255 g: 219 b: 0
background po zaladowa: indeks = 249 | r: 255 g: 219 b: 85
background po zaladowa: indeks = 250 | r: 255 g: 219 b: 170
background po zaladowa: indeks = 251 | r: 255 g: 219 b: 255
background po zaladowa: indeks = 252 | r: 255 g: 255 b: 0
background po zaladowa: indeks = 253 | r: 255 g: 255 b: 85
background po zaladowa: indeks = 254 | r: 255 g: 255 b: 170
background po zaladowa: indeks = 255 | r: 255 g: 255 b: 255tylko faktycznie jak jakaś paleta, ale zupełnie nie ta która była oryginalnie w BMP.
A tu jak co jest calutki kod który w trybie 640x480x8 próbuje wczytać plik BMP i po prostu go wyświetlić:
#include "SDL/SDL.h"
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
const int SCREEN_BPP = 8;
SDL_Surface *background = NULL;
SDL_Surface *screen = NULL;
SDL_Surface *fafa = NULL;
char s1[100], s2[100];
void loguj (char str[])
{
FILE *plik;
plik = fopen("log.txt", "a");
fprintf(plik, "%s\n", str);
fclose(plik);
}
SDL_Surface *load_image( char filename[] )
{
SDL_Surface* loadedImage = NULL;
SDL_Surface* optimizedImage = NULL;
loadedImage = SDL_LoadBMP( filename );
if( loadedImage != NULL )
{
optimizedImage = SDL_DisplayFormat( loadedImage );
SDL_FreeSurface( loadedImage );
}
return optimizedImage;
}
int main( int argc, char* args[] )
{
SDL_Event event;
SDLKey key;
int x, y, indeks_pal;
int koniec = 0;
Uint8 *pixel_addr;
SDL_Color paleta[256];
for (x = 0; x < 256; x++)
{
paleta[x].r = x;
paleta[x].g = x;
paleta[x].b = x;
}
for (x = 0; x <256; x++)
{
strcpy(s1, "szara paleta: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
strcat(s1, s2);
loguj(s1);
}
if( SDL_Init( SDL_INIT_EVERYTHING ) == -1 )
{
return 1;
}
screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );
for (x = 0; x <256; x++)
{
strcpy(s1, "screen po setvideomode: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, screen->format->palette->colors[x].r, screen->format->palette->colors[x].g, screen->format->palette->colors[x].b);
strcat(s1, s2);
loguj(s1);
}
if( screen == NULL )
return 1;
background = load_image( "data/images/title.bmp" );
for (x = 0; x < 256; x++)
{
paleta[x].r = background->format->palette->colors[x].r;
paleta[x].g = background->format->palette->colors[x].g;
paleta[x].b = background->format->palette->colors[x].b;
}
for (x = 0; x <256; x++)
{
strcpy(s1, "background po zaladowa: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
strcat(s1, s2);
loguj(s1);
}
if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
{
loguj("problem z ustawieniem palety1");
}
SDL_BlitSurface(background, NULL, screen, NULL);
SDL_Flip(screen);
SDL_Delay(1000);
if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
{
loguj("problem z ustawieniem palety2");
}
SDL_Delay(1000);
indeks_pal = 0;
SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0, 0, 0));
for (x = 0; x < 640; x = x + 5 )
{
for (y = 0; y < 200; y++)
{
pixel_addr = (Uint8 *)screen->pixels + (screen->pitch * y) + x;
*pixel_addr = indeks_pal;
pixel_addr++;
*pixel_addr = indeks_pal;
pixel_addr++;
*pixel_addr = indeks_pal;
pixel_addr++;
*pixel_addr = indeks_pal;
pixel_addr++;
*pixel_addr = indeks_pal;
}
for (y = 200; y < 400; y++)
{
pixel_addr = (Uint8 *)screen->pixels + (screen->pitch * y) + x;
*pixel_addr = indeks_pal + 128;
pixel_addr++;
*pixel_addr = indeks_pal + 128;
pixel_addr++;
*pixel_addr = indeks_pal + 128;
pixel_addr++;
*pixel_addr = indeks_pal + 128;
pixel_addr++;
*pixel_addr = indeks_pal + 128;
}
indeks_pal++;
}
if( SDL_Flip( screen ) == -1 )
return 1;
while (!koniec)
{
while (SDL_PollEvent(&event))
{
if (event.type == SDL_KEYDOWN)
{
key = event.key.keysym.sym;
if (key == SDLK_ESCAPE)
koniec = 1;
}
}
}
SDL_FreeSurface( background );
SDL_Quit();
return 0;
}A cały plik logujący dane z palet załączam do tematu.
O co tutaj chodzi?
Nie sprawdzałem z tą myszą, bo mam Eiffel więc musiałbym szukać oryginalnej klawiatury i myszy, ale jako że bardzo dawno grałem na padzie Segi na Falconie, to stwierdziłem, że może źle to pamiętam albo tak naprawdę to w ogóle nigdy nie grałem i tylko chciałem :) więc postanowiłem to zweryfikować na jakiejś grze. Ściągnąłem pierwszą lepszą grę dostosowaną do twardego dysku i Falcona ze strony Klapauzius'a i ... jednak dobrze pamiętałem odnośnie pada Segi. Wszystko działa OK i kierunki i fire. Cuda niewidy ...
Dokładnie. Niestety nie rozumiem dlaczego obsługa Fire nie działa dla klasycznego joysticka.
Do tego możesz jeszcze grać na padzie 16bitowej Segi.
Może w takim razie ktoś ma pomysł dlaczego poniższy kod nie działa dla przycisku joysticka (a np. działa dla pada Segi)
Aktywuję joystick tak:
joystick_atari = SDL_JoystickOpen(0);
if (joystick_atari != NULL)
{
printf("joystick number of buttons: %d\n", SDL_JoystickNumButtons(joystick_atari)); (tu zwraca oczywiście, że jest 1 przycisk)
printf("joystick number of axes: %d\n", SDL_JoystickNumAxes(joystick_atari));
printf("joystick number of balls: %d\n", SDL_JoystickNumBalls(joystick_atari));
printf("joystick number of hats: %d\n", SDL_JoystickNumHats(joystick_atari));
}A potem korzystam z niego tak:
SDL_JoystickUpdate();
current_hat = SDL_JoystickGetHat(joystick_atari, 0);
current_button = SDL_JoystickGetButton(joystick_atari, 0);- pośpiechu nie ma, będziesz miał chwilę to sprawdzisz :)
Postaram się jakoś to w najbliższym czasie sprawdzić. Ale w razie jakbym się ociągał z informacją, to się przypomnij, bo pamięć ma tę właściwość, że ulotną jest ;)
Może ktoś ma zalegający taki interfejs
Mam. Edit: ale nie wiem czy działający, od 15 lat leży w pudełku, przedtem działał. Sprawdzenie możliwe, ale nie takie hop, siup, już.
>> jakie są minimalne wymagania?
Trudno mi to wycenić. Najmniej wymagająca skórka (czyli oryginalana) na gołym Falconie jak piszesz, działa wolno, ale na dopalonym przez CT6x za szybko. W takim razie strzelam, że mogła by działać grywalnie na takim AB040, choć może wystarczyło by już CT2. Ale to tylko gdybanie, bo nie mam nic poza CT63 żeby sprawdzić.
atari.area forum » Posty przez jury
Wygenerowano w 0.076 sekund, wykonano 19 zapytań