1

Temat: xBios - biblioteka IO dla gier ktore lubia przestrzen

mysle ze temat skierowany jest do programistow gier.

rozwiazanie to usunelo jedna z moich najwiekszych bolaczek czyli brak mozliwosci czytania/zapisywania danych pogrupowanych w pliki na dysku przy minimalnych wymaganiach - cala pamiec zajeta przez gre. co oferuje xBios - przedewszystkim wykonuje operacje na plikach i katalogach bez obecnosci DOSa, bez urzadzenia D:, bez systemu operacyjnego i bez przerwan. zajmuje 4 strony ramu, jest relokowalny i pozwala ladowac dane bezposrednio do calej pamieci (bez ograniczen stawianych przez dos) - rowniez do pamieci pod ROM. moze tez sluzyc jako inicjalizer/loader do gier.

wersje do pobrania oraz opis aktualizowany tu: http://xxl.atari.pl/?p=1076

--- edycja zrodla i opisu

Ostatnio edytowany przez xxl (2014-09-24 08:52:16)

http://atari.pl/hsc/ad.php?i=1.

2

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Komenda xBIOS_WRITE_FILE nie przyjmuje parametru określającego długości pliku do zapisu. Ta informacja musi gdzieś istnieć, aby komenda funkcjonowała prawidłowo. Skąd, kiedy i w jaki sposób jest ona pobierana?

xxl napisał/a:

dla PUT i GET jesli nie zapisujemy calego pliku potrzeba konczyc operacje CLOSE

Bardziej intuicyjne byłoby założenie, że CLOSE jest wymagany za każdym razem, gdy korzystamy z PUT/GET. Ma to również sens w każdym przypadku korzystania z komend xBIOS_LOAD_FILE, xBIOS_WRITE_FILE, nawet gdy implementacja CLOSE dla tych przypadków jest pusta. Taki sposób korzystania z biblioteki jest łatwiej sobie utrwalić. CLOSE jest komplementarne dla OPEN. Komenda xBIOS_RUN_FILE jest tutaj wyjątkiem, gdyż automatycznie otwiera i zamyka plik, a komenda LOAD_DIR nie operuje na pliku.

3

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

> Komenda xBIOS_WRITE_FILE nie przyjmuje parametru określającego długości pliku do zapisu.

ilosc danych do przeslania/odebrania ustalasz xBIOS_SET_LENGTH, jesli jej nie uzyjesz to komenda  xBIOS_WRITE_FILE zapisze caly plik.

> Bardziej intuicyjne byłoby założenie, że CLOSE jest wymagany za każdym razem,

CLOSE jest wymagane po operacjach zapisu WRITE i PUT. byc moze trzeba CLOSE nazwac inaczej.

Ostatnio edytowany przez xxl (2011-12-09 14:30:10)

http://atari.pl/hsc/ad.php?i=1.

4

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Długość jest znana - tzn. kto ją zna?

To może zamiast CLOSE nazwij to FLUSH.

"Physics is like sex: sure, it may give some practical results, but that's not why we do it." (Richard Feynman)
and... "Physics is to mathematics as sex is to masturbation." (podobno również R.F.)

5

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

> Długość jest znana - tzn. kto ją zna?

zapis jest przerywany jesli dotrzemy do konca pliku

http://atari.pl/hsc/ad.php?i=1.

6

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

mozesz uzyc CLOSE po WRITE/READ FILE ale nie bedzie zadnego efektu, Close wymagane jest po to, zeby zgromadzone dane w buforze zapisac na dysk - zapis jest buforowany. tak naprawde CLOSE jest wymagany tylko po PUT. po GET nie, ale jak chcesz mozesz uzywac.

Chodzi mi o to, aby jawnie wyspecyfikować w dokumentacji, że protokół korzystania z operacji READ/WRITE jest następujący: OPEN, READ/WRITE, CLOSE. Każdy inny sposób może spowodować niezdefiniowane zachowanie. Jako użytkownik biblioteki nie chciałbym pewnego dnia zostać zaskoczony faktem, że dotychczasowy protokół korzystania jest błędny z racji zmiany implementacji CLOSE. Specyfikując go jednoznacznie unikamy na przyszłość takich problemów.

Czy nie lepiej byłoby zamienić obecną parę komend WRITE_FILE/PUT_BYTE na jedną, bardziej ogólną WRITE_FILE, gdzie podawalibyśmy ilość bajtów do zapisu? Użytkownik biblioteki zna maksymalny rozmiar danych do przetransferowania, więc nie byłoby z tym problemów. Skracamy w ten sposób listę komend kosztem rozbudowania interfejsu nowej komendy. Dla mnie taki interfejs byłby bardziej intuicyjny. Zapis do pliku tym sposobem byłby także bardziej wydajny.

Ta sama uwaga dotyczy komendy READ_FILE.

EDIT:
Możnaby wprowadzić komendę SET_LENGTH (X,Y - długość pliku) dla operacji READ/WRITE. Byłaby to opcjonalna komenda wykonywana po otwarciu pliku. Jeśli nie zostanie wywołana - odczytywany/zapisywany jest cały plik. W przeciwnym przypadku operujemy na ilości danych przekazanych w komendzie SET_LENGTH. Od strony implementacyjnej nie jest to problemem, wystarczy jedna flaga oraz słowo opisujące długość. Pętla realizująca odczyt bajtów, którą powyżej umieściłeś, stałaby się szczegółem implementacyjnym. Tym sposobem odczyt/zapis określonej ilości bajtów byłby prostszy. Oczywiście wydłuża się w ten sposób implementacja biblioteki, ale być może zostało ci jeszcze trochę bajtów.

Ostatnio edytowany przez Marek Konopka (2011-12-07 14:07:23)

7

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

mozesz miec racje. jedno co piszesz jest sluszne tzn. trzeba bedzie chyba dodac:

ldy <file_len
ldx >file_len
jsr xBIOS_FILE_LENGTH

jesli tego nie zdefiniujesz zapisujesz/czytasz zawsze do konca pliku jesli jednak wykonasz FILE_LENGTH to po tej operacji LOAD/WRITE FILE bedzie dzialalo tylko do dlugosci zdefiniowanej LUB do konca pliku - co wystapi wczesniej.
po tej modyfikacji faktycznie CLOSE bedzie wymagane - 2 pieczenie na jednym ogniu

jednak PUT I GET musi zostac (musze miec mozliwosc czytania zapisywania wiekszej ilosci danych niz pojemnosc pamieci)

---
no popatrz popatrz... myslimy podobnie ;-)

tak, wolnego miejsca jest jeszcze bardzo duzo (z 4 stron pamieci na biblioteke zajete jest niecale 3)

Ostatnio edytowany przez xxl (2011-12-09 14:30:35)

http://atari.pl/hsc/ad.php?i=1.

8

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

jednak PUT I GET musi zostac (musze miec mozliwosc czytania zapisywania wiekszej ilosci danych niz pojemnosc pamieci)

Sekwencja komend SET_LENGTH (X,Y), SET_LENGTH (X) załatwiłaby sprawę.

9

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

wiem, ze tak mozna ale to nie jest wygodne. zaoszczedze kilka bajtow w bibliotece ale strace ergonomie.

zobacz jak przekazac parametr np do funkcja WRITE FILE a jak do PUT

zeby zapisac jeden bajt bedziesz musial w rejestrach trzmac adres danej przy PUT wystarczy do akumulatora zaladowac dana

lda dana
jsr

vs

ldy <adr_dana
ldx >adr_dana
jsr

ale oczywiscie przemysle to jeszcze bo moze sie myle.

http://atari.pl/hsc/ad.php?i=1.

10

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Alternatywa:

ldy #<file_name
ldx #>file_name                
lda #EMode.CHUNK // ew. clc
jsr xBIOS_OPEN_FILE

ldy #<$ffffff
ldx #>$ffffff
lda #^$ffffff
jsr xBIOS_SET_LENGTH

ldy #<adres
ldx #>adres
jsr xBIOS_WRITE

jsr xBIOS_CLOSE_FILE

vs

ldy #<file_name
ldx #>file_name
lda #EMode.STREAM // ew. sec
jsr xBIOS_OPEN_FILE

lda #value
jsr xBIOS_WRITE

jsr xBIOS_CLOSE_FILE

Czy planujesz, aby lokalizacja skąd/gdzie pobierane/zapisywane są dane, mogła być wyrażana przez liczbę większą od 16'stu bitów?

Ostatnio edytowany przez Marek Konopka (2011-12-07 15:22:58)

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Mam prośbę/radę co do nazwy: XBIOS jest już w 16/32bitowych Atarkach, więc proponuję zmianę, tak żeby się komuś nie pomyliło wink

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

12

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

dodane:

xBIOS_SET_LENGTH        equ xBIOS+$1e

przyklad uzycia:

                ldy <file_name
                ldx >file_name                
                jsr xBIOS_OPEN_FILE

                ldy #$80             ; len = $380
                ldx #$03
                jsr xBIOS_SET_LENGTH

                ldy <load_dest
                ldx >load_dest                
                jsr xBIOS_LOAD_FILE

czyli $380 bajtow zostanie zaladowanych z pliku. jesli plik jest krotszy niz (w tym przypadku $380) lub nie podamy dlugosci zostanie zaladowany caly plik.

pierwszy post wyedytowany

> XBIOS jest już w 16/32bitowych Atarkach, więc proponuję zmianę, tak żeby się komuś nie pomyliło

ta nazwa funkcjonuje nie tylko na st ale na malym atari chyba nie?

Ostatnio edytowany przez xxl (2011-12-09 14:31:06)

http://atari.pl/hsc/ad.php?i=1.

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

XBIOS jest składnikiem TOSu. Tyle.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

14

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

rozwiazanie to usunelo jedna z moich najwiekszych bolaczek czyli brak mozliwosci czytania/zapisywania danych na dysku.

Tę bolączkę usuwa dowolny DOS, wystarczy trzymać się zasad, nie trzymasz się tych zasad widocznie.

xxl napisał/a:

xBios moze dzialac jak zwykly inicjalizer (uruchami dowolna gre) ale nasza gra nie musi juz trzymac sie roznych ograniczen czyli moze przeprowadzic BEZPOSREDNIE ladowanie we wszystkie te obszary.

Mylisz ZASADY poprawnego tworzenia plików binarnych z ograniczeniami. W związku z tym Twoje produkcje nie trzymające się tych zasad będą działały tylko pod Twoim inicjalizerem - chora idea.

xxl napisał/a:

obecnie dziala dla AtariDos i urzadzen podlaczonych przez SIO czyli stacje dyskow, SIO2SD itp ale jesli ktos zrobi wersje na inny filesystem i/lub urzadzenie to tylko z pozytkiem dla userow tych urzadzen/filesystemow.

Jaki to "pozytek" że program będzie musiał mieć wersje pod:
- SIO + standardowa prędkość
- SIO + turbo (tyle wersji ile turb)
- SIDE
- MyIDE
a do tego wszystkie te wersje w odmianie AtariDOS, SpartaDOS, a może jakiś inny wymyślisz.....

Jednym zdaniem.
"Wymyślasz" coś co zostało już dawno wymyślone, oprogramowane i ustandaryzowane jako DOS, tylko po to by nie trzymać się standardów tworzenia plików binarnych i zasad współpracy programów z pamięciami zewnętrznymi.

To oczywiście moja prywatna opinia, ale się z nią zgadzam smile !!!

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

15

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

> Tę bolączkę usuwa dowolny DOS, wystarczy trzymać się zasad, nie trzymasz się tych zasad widocznie.

DOS ma wygorowane wymagania dotyczace pamieci i zasobow (przy ograniczonych zasobach atari to jest nie do przyjecia), niestety co moze umyka Twojej uwadze jest zwiazany z filesystemem zbyt mocno. czyli gra napisana pod "dosa" moze nie dzialac prawidlowo pod innym dosem :-)
w przypadku tej biblioteki nie ma takiego zagrozenia.


> Mylisz ZASADY poprawnego tworzenia plików binarnych z ograniczeniami.

nieprawda, nie lamie zasad tworzenia pliku binarnego, jesli sie niezgadzasz podaj ktora zasad jest tu zlamana.
Wydaje mi sie ze to wlasnie Ty mylisz tu zasady z OGRANICZENIAMI w dodatku z kazdym DOSem innymi.
rozszerzam mozliwosci uzycia plikow binarnych i to znaczenie pozbywajac sie garba OGRANICZEN DOSa i niego samego.


> Jaki to "pozytek" że program będzie musiał mieć wersje pod:

nieprawda, gra/program ma tylko jedna wersje, API jest stale. to biblioteka odpowiada za komunikacje i to biblioteka jest w wersjach na filesystem/urzadzenie tak jak w calym bozym swiecie, zmieniasz sprzet to zmien biblioteke lub wybierz biblioteke pod konkretny sprzet, gry beda dzialaly nadal.


> "Wymyślasz"

nie wymyslam nic nowego, skorzytalem z mozliwosci atari. pamietaj, przyzwyczajenia zabijaja, zwlaszcza te zle :-)

http://atari.pl/hsc/ad.php?i=1.

16

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

DOS ... niestety co moze umyka Twojej uwadze jest zwiazany z filesystemem zbyt mocno. czyli gra napisana pod "dosa" moze nie dzialac prawidlowo pod innym dosem :-)

DOSy są różne, obsługują różne filesystemy (mogę dzięki temy wybrać sobie HDD pod SDX i trzymać tam grę, która jest zgoadna z zasadami), jeśli ta gra prawidłowo używa OPEN, READ, PUT, WRITE, i CLOSE to MUSI działać pod KAŻDYM DOSem - pomijając zajętość pamięci oczywiście.

xxl napisał/a:

w przypadku tej biblioteki nie ma takiego zagrozenia.

Bo de facto gra z włączoną tą biblioteką będzie grą całodyskową zapisaną pod konkretnym filesystemem i działającą z konkretnym rozwiązaniem sprzętowym (w zależności od biblioteki oczywiście).
To nie łatwiej pisać po sektorach?

xxl napisał/a:

nieprawda, nie lamie zasad tworzenia pliku binarnego, jesli sie niezgadzasz podaj ktora zasad jest tu zlamana.

Z zasady nie ładujemy pliku w miejsce rejestrów systemowych, kulturalny programista nie ładuje bajtu 0 do zegara systemowego prosto z pliku, kultularny programista robi na początku programu kawałek kodu inicjujący rejestr zegara tym zerem. Jest to czytelne i jako takie prawidłowe. Zasady są jasne:
- nie ładujemy nic w obszar rejestrów systemowych, stosu itp.
- zakładamy, że to co jest pod MEMLO jest "święte", więc staramy się ładować kod jak najwyżej.
- nie wyłączamy ROMu w czasie ładowania.

xxl napisał/a:

nieprawda, gra/program ma tylko jedna wersje, API jest stale. to biblioteka odpowiada za komunikacje i to biblioteka jest w wersjach na filesystem/urzadzenie tak jak w calym bozym swiecie, zmieniasz sprzet to zmien biblioteke lub wybierz biblioteke pod konkretny sprzet, gry beda dzialaly nadal.

A jak jako programista tej gry chciałbym otworzyć dwa pliki jednocześnie?
Po prostu w efekcie końcowym albo powstanie kolejny DOS obsługujący w zależności od wersji rózny sprzęt i filesystemy - a nie będzie to już takie maleństwo. ... Albo zostanie to w postaci tego kadłubka, którym jest obecnie, który (eg Ciebie) znosi niektóre ograniczenia DOSa ale (wg mnie) nakłada na programistę inne ograniczenia, których nie ma DOS.
Może zakup w końcu 130XE i wtedy SDX załatwi Twoje problemy w większości... a przy okazji obsłuży od razu wszystkie filesystemy i użądzenia, bez posiłkowania się różnymi wersjami bibliotek.

Aaaa.... i zostaw $FFFA-$FFFF w spokoju !!!! smile

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

17

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

> DOSy są różne, .... to MUSI działać pod KAŻDYM DOSem

nieprawda, NOTE/POINT nie dziala tak samo w roznych dosach.

> Bo de facto gra z włączoną tą biblioteką będzie grą całodyskową zapisaną pod konkretnym filesystemem i działającą z konkretnym rozwiązaniem sprzętowym (w zależności od biblioteki oczywiście).

nie, gre mozesz sobie przeniesc na inne urzadzenie z innym filesystemem dla ktorego masz biblioteke i bedzie dzialac tak samo.

> To nie łatwiej pisać po sektorach?

nie, organizacja plikowa jest wygodna.

> Z zasady nie ładujemy pliku w miejsce

chcesz powiedziec ze zasady sa takie ze z zasady nie ...
gdyby to byly zasady chociazby z tym memlo to 90% gier by sie dzialalo

przykro mi ;-) obchodze te OGRANICZENIA


> A jak jako programista tej gry chciałbym otworzyć dwa pliki jednocześnie?

niestety, tylko jeden plik otwarty na raz. dlamnie wystarczy, musisz skorzystac z innego rozwiazania niz ta biblioteka.


> Może zakup w końcu 130XE i wtedy SDX załatwi Twoje problemy w większości...

te wszystkie rozszerzenia nadal nie pozwola mi na to na co pozwala ta biblioteka.


> Aaaa.... i zostaw $FFFA-$FFFF w spokoju

niestety, najlepsi tego nie robia. ucze sie od najlepszych :-)

http://atari.pl/hsc/ad.php?i=1.

18

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl, ale nie SET_LENGHT, tylko SET_LENGTH, dobrze?

Ostatnio edytowany przez Krótki (2011-12-09 14:06:05)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

19

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

nieprawda, NOTE/POINT nie dziala tak samo w roznych dosach.

No nie ładnie wink wykropkowałeś listę komend, NOTE/POINT na niej nie było - pisałem o konkretnym rozwiązaniu - a u Ciebie NOTE/POINT jest ?? tongue

xxl napisał/a:

nie, gre mozesz sobie przeniesc na inne urzadzenie z innym filesystemem dla ktorego masz biblioteke

Pytanie podchwytliwe.... jak taka gra załaduje sobie bibliotekę ?? - no chyba że będzie ona wkompilowana w grę - czyli: gra będzie miała różne wersje pod różne filesystemy/urządzenia. Cudowny pomysł.... "ops gra nie działa, czy to wersja Pod SIO i AtariDOS, czy może pod SIDE i SDX a może pod SIO i SDX .... muszę ściągnąć inna."

xxl napisał/a:

gdyby to byly zasady chociazby z tym memlo to 90% gier by sie dzialalo

MEMLO naciągałem, ale dwie pozostałe to zasady smile ... a gdzie by się te gry działy smile smile smile

xxl napisał/a:

niestety, tylko jeden plik otwarty na raz. dlamnie wystarczy

Beznadziejne ograniczenie, które trzeba będzie jakoś obchodzić tongue

Ostatnio edytowany przez Pecus (2011-12-09 14:29:43)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

20

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Pecus, a nie szkoda ci czasu?
ale piszcie chlopaki, piszcie - ubaw po pachy wink

przechodze na tumiwisizm

21

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

@Krotki, poprawione...

> No nie ładnie  wykropkowałeś listę komend, NOTE/POINT na niej nie było...

zadnej listy nie wykropkowalem, zrobiles to Ty, nie mozna mowic ze wszystko pod dos jest wymienne bo nie jest i kropka :-) note point nie ma bo jest dla mnie zbedne.

> Pytanie podchwytliwe.... jak taka gra załaduje sobie bibliotekę ?? - no chyba że będzie ona wkompilowana w grę - czyli: gra będzie miała różne wersje pod różne filesystemy/urządzenia. Cudowny pomysł.... "ops gra nie działa, czy to wersja Pod SIO i AtariDOS, czy może pod SIDE i SDX a może pod SIO i SDX .... muszę ściągnąć inna."

gra nie laduje biblioteki, jest tylko jedna wersja gry, biblioteka jest dla filesytstemu/urzadzenia. widze ze nie czytales o czym mowimy... przeczytaj prosze pierwszy post.


> MEMLO naciągałem, ale dwie pozostałe to zasady

te "zasady" DOSa sa tak samo naciagnane. plik binarny nie ma tych ograniczen.

http://atari.pl/hsc/ad.php?i=1.

22

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

O.K. Nie doczytałem o ładowaniu, czyli, trzeba będzie mieć DOSa, do tego xBiosa i grę .... dla każdej gry podfolder, albo dyskietka, albo ciagła zmiana nazw na xAutorun. A nie prościej pominąć jedno ogniwo i napisać grę tak by umiała działać z DOSem???

A co do wykropkowania, to zacytowałeś moje zdanie, w którym wymieniłem listę komend, bez tych komend tongue - a je wykropkowałeś. Bez urazy, ale patrz na to co sam piszesz.

Ostatnio edytowany przez Pecus (2011-12-09 15:03:34)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

23

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

xxl napisał/a:

plik binarny nie ma tych ograniczen.

Jest jedno, dosyć abstrakcyjne ograniczenie. Nie załadujesz w ten sposób danych od adresu $FFFF w przypadku formatu AtariDOS. Próba takiej operacji zapewne zakończy się zgonem, jeśli nie wprowadzi się dodatkowych zabezpieczeń.

24

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

Marek Konopka napisał/a:

Nie załadujesz w ten sposób danych od adresu $FFFF

A to ulubiony adres kolegi ;P



P.-S. Chłopaki nie bierzcie tego do siebie... lubię drażnić czasem tongue  Co nie zmienia faktu, że uważam to co napisałem - nie dopasowujmy systemu do gry, ale grę do systemu.

Ostatnio edytowany przez Pecus (2011-12-09 15:10:34)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

25

Odp: xBios - biblioteka IO dla gier ktore lubia przestrzen

> O.K. Nie doczytałem o ładowaniu, czyli, trzeba będzie mieć DOSa,

jednak nie doczytales. nie trzeba miec tylko mozna miec. biblioteke mozna nagrac do boot sektorow i wtedy dos jest niepotrzebny, jednak wydaje mi sie lepszym rozwiazaniem, zeby gra byla uruchamiana (poprzez biblioteke) z dosa ewentualnie tez bez dosa z dowolnego bootstrapa

@Marek Konopka: prawda


> nie dopasowujmy systemu do gry, ale grę do systemu.

gra ma dzialac na sprzecie a nie wpasowywac sie w ograniczenia DOSa

Ostatnio edytowany przez xxl (2011-12-09 15:14:02)

http://atari.pl/hsc/ad.php?i=1.