09.01 17:56
[#182]
Re: Dewelopment gry Sołtys
@Don_Adan, post #181
Dzisiaj zrobiłem tak:
- spakowałem grę do LHA bez kompresji
- podzieliłem Splitterem na pliki z ustawieniem limitu 512 kB (wyszły 24 pliki)
- spakowałem je LZMA
- dodałem tagi tym plikom dla depakera
Wyszło 6 dyskietek. Dzięki takiej kombinacji mogę sobie powybierać dowolnie częściowe pliki na kolejne dyskietki tak, aby móc jak najlepiej je wypełnić. Pierwsza dyskietka ma sporo luzu dla skryptu Installera, wszelkich wymaganych bibliotek, archiwizera LhA, który jest też niezbędny itp.
Wcześniej próbowałem działać na plikach wielkości 1 MB ale miałem zbyt małe pole manewru przy rozmieszczaniu ich do konkretnych ADFów. Na plikach 512 kB jest ich po prostu więcej, dzięki czemu mam większy wybór w ich rozlokowywaniu na dyskietki.
- spakowałem grę do LHA bez kompresji
- podzieliłem Splitterem na pliki z ustawieniem limitu 512 kB (wyszły 24 pliki)
- spakowałem je LZMA
- dodałem tagi tym plikom dla depakera
Wyszło 6 dyskietek. Dzięki takiej kombinacji mogę sobie powybierać dowolnie częściowe pliki na kolejne dyskietki tak, aby móc jak najlepiej je wypełnić. Pierwsza dyskietka ma sporo luzu dla skryptu Installera, wszelkich wymaganych bibliotek, archiwizera LhA, który jest też niezbędny itp.
Wcześniej próbowałem działać na plikach wielkości 1 MB ale miałem zbyt małe pole manewru przy rozmieszczaniu ich do konkretnych ADFów. Na plikach 512 kB jest ich po prostu więcej, dzięki czemu mam większy wybór w ich rozlokowywaniu na dyskietki.
09.01 21:20
[#183]
Re: Dewelopment gry Sołtys
@tukinem, post #182
Ale nie musisz dzielic po rowno na 512KB.
Mozesz na rozne wielkosci dzielic, np. pierwszy plik 1.2MB, drugi plik 1.5MB, trzeci plik 900KB.
Dla dobrego joinera nie ma to znaczenia ile bajtow ma dany plik, moze miec dowolna wielkosc.
A LZMA ma to do siebie, ze im dluzszy plik pakujesz tym lepiej pakuje.
Jeden 1MB plik bedzie lepiej spakowany niz ten sam plik podzielony na 2 czesci 512KB.
Mozesz to zreszta sam sprawdzic.
6 dyskietek tez w sumie jest OK.
Zrobisz jak uwazasz.
Mozesz jakiegos krotkiego joinera/splittera uzyc do laczenia/dzielenia plikow.
To nie musi byc lha, moze byc cos innego np.
link
link
Albo mozna stworzyc jakis prosty wlasny spliter do lha, skoro archiwum jest niespakowane to powinno byc proste.
I mozna paredziesiat KB pewnie zyskac na dyskietce.
Mozesz na rozne wielkosci dzielic, np. pierwszy plik 1.2MB, drugi plik 1.5MB, trzeci plik 900KB.
Dla dobrego joinera nie ma to znaczenia ile bajtow ma dany plik, moze miec dowolna wielkosc.
A LZMA ma to do siebie, ze im dluzszy plik pakujesz tym lepiej pakuje.
Jeden 1MB plik bedzie lepiej spakowany niz ten sam plik podzielony na 2 czesci 512KB.
Mozesz to zreszta sam sprawdzic.
6 dyskietek tez w sumie jest OK.
Zrobisz jak uwazasz.
Mozesz jakiegos krotkiego joinera/splittera uzyc do laczenia/dzielenia plikow.
To nie musi byc lha, moze byc cos innego np.
link
link
Albo mozna stworzyc jakis prosty wlasny spliter do lha, skoro archiwum jest niespakowane to powinno byc proste.
I mozna paredziesiat KB pewnie zyskac na dyskietce.
10.01 00:07
[#187]
Re: Dewelopment gry Sołtys
@cholok, post #185
Jesli chcesz zeby kazdy plik LZMA mial np po 425 KB to nie mozesz dzielic niespakowanego archiwum lha na takie same czesci np po 800 KB.
Bo PackFire je roznie spakuje. Jeden plik po spakowaniu bedzie mial np 200KB, drugi 356KB, trzeci 380 KB, czwarty 287KB. iitp.
Dlatego ja bym robil swoje wlasne dzielenie pilkow FileMasterem 2.2.
Gra Soltys ma 12 MB niespakowana.
Najpierw bym obcial pierwsze 3 MB i je spakowal.
Jesli by po spakowaniu bylo np. 845 KB, to bym zostawil.
A jesli by wyszlo 900 KB to bym cial jeszcze raz, ale teraz tylko 2,9MB.
Tak zeby spakowana LZMA czesc zmiescila sie na dyskietce FFS.
A lacznie spakowana i niespakowana czesc miala max 3,8 MB.
Tak, zeby gre dalo sie zainstalowac na A1200 z 4 MB fast.
Bo PackFire je roznie spakuje. Jeden plik po spakowaniu bedzie mial np 200KB, drugi 356KB, trzeci 380 KB, czwarty 287KB. iitp.
Dlatego ja bym robil swoje wlasne dzielenie pilkow FileMasterem 2.2.
Gra Soltys ma 12 MB niespakowana.
Najpierw bym obcial pierwsze 3 MB i je spakowal.
Jesli by po spakowaniu bylo np. 845 KB, to bym zostawil.
A jesli by wyszlo 900 KB to bym cial jeszcze raz, ale teraz tylko 2,9MB.
Tak zeby spakowana LZMA czesc zmiescila sie na dyskietce FFS.
A lacznie spakowana i niespakowana czesc miala max 3,8 MB.
Tak, zeby gre dalo sie zainstalowac na A1200 z 4 MB fast.
10.01 09:45
[#188]
Re: Dewelopment gry Sołtys
@Don_Adan, post #187
Ale jezeli Tukinem celuje w to, zeby instaler dzialal juz od 1MB fast.
To ja bym podzielil glowny plik na 1515000 bajty.
Powinno byc ich wtedy 8.
Spakowal LZMA.
Sprawdzil, czy te 8 plikow zmiesci sie ladnie na 4 dyskietkach FFS.
Jak nie, to podzielil jeszcze raz, ale teraz na 1450000 bajty.
Bedzie wtedy jeszcze 9 maly plik.
Czyli ogolnie bylyby cztery dyskietki z danymi gry, i jedna na obsluge instalacji gry na HD, czyli Installer, joiner, depacker itp.
To ja bym podzielil glowny plik na 1515000 bajty.
Powinno byc ich wtedy 8.
Spakowal LZMA.
Sprawdzil, czy te 8 plikow zmiesci sie ladnie na 4 dyskietkach FFS.
Jak nie, to podzielil jeszcze raz, ale teraz na 1450000 bajty.
Bedzie wtedy jeszcze 9 maly plik.
Czyli ogolnie bylyby cztery dyskietki z danymi gry, i jedna na obsluge instalacji gry na HD, czyli Installer, joiner, depacker itp.
10.01 13:25
[#189]
Re: Dewelopment gry Sołtys
@Don_Adan, post #188
1 515 000 bajtów to jest ponad 1 MB. Do tego w pamięci musi się zmieścić plik skompresowany. Podczas dekompresji takiego będzie pod A0 wskaźnik do spakowanego pliku, a pod A1 wskaźnik do miejsca rozpakowania. Jeżeli dobrze rozumuję, to musi być zaalokowana pamięć dla obu tych plików, więc 1 MB fast RAM to zbyt mało na plik spakowany + ok 1.44MB (1515000B). A jeszcze w pamięci zasiądzie skrypt instalujący, biblioteka xfdmaster.library, kod depakera itd.
Dlatego bezpiecznie działam na pliczkach 512 kB.
@cholok: jeśli użyję LhA z parametrem -V do podziału na pliki częściowe, to później musiałbym dołączyć tą samą wersję LhA do gry, aby móc połączyć. Najnowsza wersja LhA - ta z Aminetu nie obsługuje już archiwów podzielonych na częściowe pliki.
Dlatego bezpiecznie działam na pliczkach 512 kB.
@cholok: jeśli użyję LhA z parametrem -V do podziału na pliki częściowe, to później musiałbym dołączyć tą samą wersję LhA do gry, aby móc połączyć. Najnowsza wersja LhA - ta z Aminetu nie obsługuje już archiwów podzielonych na częściowe pliki.
10.01 13:57
[#190]
Re: Dewelopment gry Sołtys
@tukinem, post #189
Zgadza sie, ale taka A1200 HD to 2 MB chip i 1 MB fast, czyli lacznie 3 MB pamieci.
xfdmaster alokuje kazda wolna pamiec, a nie tylko pamiec fast.
Czyli robi to tak, najpierw alokowana bedzie pamiec fast (bo fast ma wyzszy priorytet niz chip) i do fastu bedzie wczytany spakowany LZMA plik z dyskietki.
A potem alokowany bedzie obszar 1515000 bajtow na depakowany plik.
Jesli w A1200 jest tylko 1 MB fast to zostanie zaalokowana pamiec chip, a jesli w systemie jest 3 MB lub wiecej pamieci fast to zostanie zaalokowany fast.
Wiec wszystko bedzie ok.
Byc moze tylko trzeba bedzie troche zmniejszyc te 1515000 bajtow, bo moze sie ladnie nie pomiescic na dyskietce.
Dlatego potrzebne sa wyniki spakowanych (podzielonych) juz czesci.
Ostatnia aktualizacja: 10.01.2025 14:00:37 przez Don_Adan
xfdmaster alokuje kazda wolna pamiec, a nie tylko pamiec fast.
Czyli robi to tak, najpierw alokowana bedzie pamiec fast (bo fast ma wyzszy priorytet niz chip) i do fastu bedzie wczytany spakowany LZMA plik z dyskietki.
A potem alokowany bedzie obszar 1515000 bajtow na depakowany plik.
Jesli w A1200 jest tylko 1 MB fast to zostanie zaalokowana pamiec chip, a jesli w systemie jest 3 MB lub wiecej pamieci fast to zostanie zaalokowany fast.
Wiec wszystko bedzie ok.
Byc moze tylko trzeba bedzie troche zmniejszyc te 1515000 bajtow, bo moze sie ladnie nie pomiescic na dyskietce.
Dlatego potrzebne sa wyniki spakowanych (podzielonych) juz czesci.
Ostatnia aktualizacja: 10.01.2025 14:00:37 przez Don_Adan
10.01 14:08
[#192]
Re: Dewelopment gry Sołtys
@Don_Adan, post #190
Rozumiem. Na wyniki to poczekamy gdzieś do marca, jak już będę mieć całkowicie gotową grę. Raczej nie upcha się idealnie plików częściowych po spakowaniu. Jeśli dla przykładu pliki po spakowaniu wyjdą po około 600 kB to zawsze zostanie ponad 200 kB luzu na każdej dyskietce, a to sporo. Zobaczymy, gdy będę mieć już komplet plików. Ja byłbym za tym, aby wstawić instalatorowi splitter i joiner. Pliki po spakowaniu LZMA połączyć w jeden, a następnie podzielić na takie bezpieczne 860 kB.
10.01 15:18
[#193]
Re: Dewelopment gry Sołtys
@tukinem, post #192
Mozna i tak, choc ja bym staral sie gre upchnac na 5 dyskietkach o ile sie zmiesci, przy 1515000 bajtach.
Tylko pamietaj, zebys wykasowal wszystkie niepotrzebne pliki, bo czasami sie zdarza ze cos sie zmienia w grze i jakis zbedny plik zostaje.
Ostatnia aktualizacja: 10.01.2025 15:18:48 przez Don_Adan
Tylko pamietaj, zebys wykasowal wszystkie niepotrzebne pliki, bo czasami sie zdarza ze cos sie zmienia w grze i jakis zbedny plik zostaje.
Ostatnia aktualizacja: 10.01.2025 15:18:48 przez Don_Adan
10.01 16:33
[#194]
Re: Dewelopment gry Sołtys
@Don_Adan, post #193
Sporo teraz zyskuję na muzyce, bo początkowe założenie to było 200 kB na moduł, a że lokacji w grze jest 24 + menu gry, to wychodziło 25*200 kB. Bartesek podsyła mi pliki poniżej 100 kB, co ładnie obniża rozmiar gry.
Tu na obrazku zaznaczyłem muzykę, którą mam, a niezaznaczone pliki z tego katalogu zostaną podmienione na pliki poniżej 100 kB, więc kto wie... może na 4 dyskietki jeszcze wejdzie:
Oczywiście moduły są bez kompresji. Jeśli to tak pójdzie, to 13*100 kB daje mi 1300 kB zluzowanie, czyli bardzo dużo.
Tu na obrazku zaznaczyłem muzykę, którą mam, a niezaznaczone pliki z tego katalogu zostaną podmienione na pliki poniżej 100 kB, więc kto wie... może na 4 dyskietki jeszcze wejdzie:
Oczywiście moduły są bez kompresji. Jeśli to tak pójdzie, to 13*100 kB daje mi 1300 kB zluzowanie, czyli bardzo dużo.
10.01 17:37
[#195]
Re: Dewelopment gry Sołtys
@tukinem, post #194
Fakt, to moze byc mniej.
Wedlug mnie na 5 dyskietkach zmiesci sie na pewno, jak mody zostana podmienione.
Na 4 dyskietkach byc moze da rade.
W sumie jezeli pozostale pliki w grze sa juz w wersji final to mozesz zrobic 2 archiwa lha.
Jedno z modami i drugie z pozostalymi plikami.
Wtedy bedzie wiadomo jak dobrze LZMA pakuje MOD-y. Bo teraz jest 3,65MB modow.
I bedziesz juz nawet mogl zaczac tworzyc skrypt instalacyjny.
Moze jakies inne problemy wyplyna wtedy.
BTW.Jak sie nudzisz to spakuj LZMA demo JUMP AGA.
Kiedys proponowalem Kefirowi, zeby zrobil tez wersje instalacyjna Jump AGA na dyskietkach , uzywajac takiej metody jakiej Ty teraz uzywasz. Myslalem, ze na 3 dyskietkach by sie wtedy gra zmiescila. To bylo jeszcze w czasach bez intra.
Ostatnia aktualizacja: 10.01.2025 17:39:08 przez Don_Adan
Wedlug mnie na 5 dyskietkach zmiesci sie na pewno, jak mody zostana podmienione.
Na 4 dyskietkach byc moze da rade.
W sumie jezeli pozostale pliki w grze sa juz w wersji final to mozesz zrobic 2 archiwa lha.
Jedno z modami i drugie z pozostalymi plikami.
Wtedy bedzie wiadomo jak dobrze LZMA pakuje MOD-y. Bo teraz jest 3,65MB modow.
I bedziesz juz nawet mogl zaczac tworzyc skrypt instalacyjny.
Moze jakies inne problemy wyplyna wtedy.
BTW.Jak sie nudzisz to spakuj LZMA demo JUMP AGA.
Kiedys proponowalem Kefirowi, zeby zrobil tez wersje instalacyjna Jump AGA na dyskietkach , uzywajac takiej metody jakiej Ty teraz uzywasz. Myslalem, ze na 3 dyskietkach by sie wtedy gra zmiescila. To bylo jeszcze w czasach bez intra.
Ostatnia aktualizacja: 10.01.2025 17:39:08 przez Don_Adan
10.01 22:12
[#199]
Re: Dewelopment gry Sołtys
@Don_Adan, post #181
Czyli co lzx -9 nie dziala jednak?
link
Tak mi przyszlo do glowy, ze to taki pseudo key jest tylko, niby ze wersja zarejestrowana, a nic nie dziala tak jak powinno.
Mialem kiedys innego keya z BBS-u zarejestrowanego na kogos, ale zmienilem keya, bo ten tekst mi sie bardziej podobal.
Nigdy nie testowalem czy na tamtym keyu lzx by lepiej pakowal.
link
Tak mi przyszlo do glowy, ze to taki pseudo key jest tylko, niby ze wersja zarejestrowana, a nic nie dziala tak jak powinno.
Mialem kiedys innego keya z BBS-u zarejestrowanego na kogos, ale zmienilem keya, bo ten tekst mi sie bardziej podobal.
Nigdy nie testowalem czy na tamtym keyu lzx by lepiej pakowal.
11.01 10:53
[#200]
Re: Dewelopment gry Sołtys
@tukinem, post #198
Jak chcesz probowac czegos pozytecznego, to mozesz sprobowac napisac wlasny spliter do niespakowanych archiwow lha.
Spakuj sobie lha bez kompresji jakis 1 plik.
I obejrzyj pod FileMasterem 2.2 (FileEdit).
O ile dobrze pamietam to powinno byc cos takiego:
-lh0- czyli najpierw naglowek 0, bodaj oznacza niespakowany plik
a potem tylko nie pamietam w jakiej kolejnosci
dlugosc pliku (longword) czytany bajtami
moze byc tez druga dlugosc bo chyba jest packed i unpacked size
word checksum (tez czytany bajtami)
nazwa pliku ze sciezka
bity protekcji (to mozna pominac)
dane z pliku
zreszta mozliwe, ze jest w necie gdzies opis takiej struktury.
A skoro potrafisz dodac naglowek do pliku i umiesz obslugiwac banki w BB2, to powinno byc dla Ciebie dosc proste.
A taki programik bedzie krotszy niz lha.
Edycja.
No chyba, ze Krashan napisze o ile sie nudzi.
Ostatnia aktualizacja: 11.01.2025 10:54:18 przez Don_Adan
Spakuj sobie lha bez kompresji jakis 1 plik.
I obejrzyj pod FileMasterem 2.2 (FileEdit).
O ile dobrze pamietam to powinno byc cos takiego:
-lh0- czyli najpierw naglowek 0, bodaj oznacza niespakowany plik
a potem tylko nie pamietam w jakiej kolejnosci
dlugosc pliku (longword) czytany bajtami
moze byc tez druga dlugosc bo chyba jest packed i unpacked size
word checksum (tez czytany bajtami)
nazwa pliku ze sciezka
bity protekcji (to mozna pominac)
dane z pliku
zreszta mozliwe, ze jest w necie gdzies opis takiej struktury.
A skoro potrafisz dodac naglowek do pliku i umiesz obslugiwac banki w BB2, to powinno byc dla Ciebie dosc proste.
A taki programik bedzie krotszy niz lha.
Edycja.
No chyba, ze Krashan napisze o ile sie nudzi.
Ostatnia aktualizacja: 11.01.2025 10:54:18 przez Don_Adan
11.01 12:40
[#201]
Re: Dewelopment gry Sołtys
@Don_Adan, post #200
Dałoby radę napisać, tylko zupełnie inaczej musiałbym alokować pamięć.
W tym kodzie co tam napisałem mam stały blok zaalokowany poprzez DC. Największy plik w grze to plik uruchamialny który ma ponad 600 kB, więc musiałbym użyć DCB.b 600*1024,0 co już na starcie rozciągnie taki splitter. Spróbuję z użyciem systemowego AllocMem_. Obym nie przedobrzył...
Stworzyłem dwa pliki tekstowe:
file1.txt z danymi: PLIK1
file2.txt z danymi: PLIK2
Spakowałem bez kompresji i tak to wygląda:
Ostatnia aktualizacja: 11.01.2025 12:47:30 przez tukinem
W tym kodzie co tam napisałem mam stały blok zaalokowany poprzez DC. Największy plik w grze to plik uruchamialny który ma ponad 600 kB, więc musiałbym użyć DCB.b 600*1024,0 co już na starcie rozciągnie taki splitter. Spróbuję z użyciem systemowego AllocMem_. Obym nie przedobrzył...
Stworzyłem dwa pliki tekstowe:
file1.txt z danymi: PLIK1
file2.txt z danymi: PLIK2
Spakowałem bez kompresji i tak to wygląda:
Ostatnia aktualizacja: 11.01.2025 12:47:30 przez tukinem
11.01 13:57
[#202]
Re: Dewelopment gry Sołtys
@tukinem, post #201
To chyba pierwszy jest checksum albo extra ID lha (czytany bajtami)
potem ID, -lh0-
potem packed/unpacked (longwordy, czytane bajtami w PC-towym stylu)
dalej jakies dane moze data utworzenia pliku lub archiwum czy bity protekcji
wyglada, ze wielkosci sa wszystkie w PC-towym stylu czyli LE.
Jesli BB2 potrafi generowac Sekcje BSS, a nie tylko Code i Data.
To nie potrzebujesz uzywac
DCB.b 600*1024,0
Tylko na koncu kodu BB2:
Ostatnia aktualizacja: 11.01.2025 13:58:43 przez Don_Adan
potem ID, -lh0-
potem packed/unpacked (longwordy, czytane bajtami w PC-towym stylu)
dalej jakies dane moze data utworzenia pliku lub archiwum czy bity protekcji
wyglada, ze wielkosci sa wszystkie w PC-towym stylu czyli LE.
Jesli BB2 potrafi generowac Sekcje BSS, a nie tylko Code i Data.
To nie potrzebujesz uzywac
DCB.b 600*1024,0
Tylko na koncu kodu BB2:
Section Buffer,BSS Buffy ds.b 600*1024
Ostatnia aktualizacja: 11.01.2025 13:58:43 przez Don_Adan
11.01 14:32
[#203]
Re: Dewelopment gry Sołtys
@Don_Adan, post #202
W BB nie ma hunków pamięci. Wszystko ląduje w pierwszej kolejności w fast ramie, a jeśli go brak, to w chip ramie.
Siądę do tego wieczorem ale ogólnie to może być fajna sprawa. Nie zgadza mi się kilka rzeczy ale myślę, że mogę to pominąć, np 2 bajty przed -lh0- różnią się dla pierwszego i dla drugiego pliku.
Rozmiar bufora to w tym wypadku będzie obojętny, bo przy pakowaniu bez kompresji packed = unpacked.
Problemem może być też odczyt nazwy pliku do wypakowania bo nie wiem czy na końcu nazwy ma być jakiś specjalny znak.
Ogólnie napiszę ten kod podobnie jak działa LhA, czyli będzie działać tylko z CLI oraz trzeba będzie podać dwa parametry: plik połączony , ścieżka do zapisu plików.
Może z 50 kB zajmie ten plik po kompilacji. Zobaczymy.
Mnie się wydaje że to jest amigowy endian bo mamy tutaj 00000005.
Ostatnia aktualizacja: 11.01.2025 14:34:42 przez tukinem
Siądę do tego wieczorem ale ogólnie to może być fajna sprawa. Nie zgadza mi się kilka rzeczy ale myślę, że mogę to pominąć, np 2 bajty przed -lh0- różnią się dla pierwszego i dla drugiego pliku.
Rozmiar bufora to w tym wypadku będzie obojętny, bo przy pakowaniu bez kompresji packed = unpacked.
Problemem może być też odczyt nazwy pliku do wypakowania bo nie wiem czy na końcu nazwy ma być jakiś specjalny znak.
Ogólnie napiszę ten kod podobnie jak działa LhA, czyli będzie działać tylko z CLI oraz trzeba będzie podać dwa parametry: plik połączony , ścieżka do zapisu plików.
Może z 50 kB zajmie ten plik po kompilacji. Zobaczymy.
longwordy, czytane bajtami w PC-towym stylu
Mnie się wydaje że to jest amigowy endian bo mamy tutaj 00000005.
Ostatnia aktualizacja: 11.01.2025 14:34:42 przez tukinem
11.01 14:46
[#204]
Re: Dewelopment gry Sołtys
@tukinem, post #203
To nie jest Amigowy endian.
Bajt $2D to jest koniec ID (-lh0-).
A dalej masz $05000000.
I nastepne $05000000.
Jedno z nich jest packed size a drugie unpacked size.
A ze tutaj nie ma kompresji to wartosc jest taka sama.
Meynaf mi kiedys napisal spliter do glownego pliku (banku) z gry HOMM2, to bylo pareset bajtow tylko, moze 1KB max.
to mozna bylo by prosto przerobic. Ale nie mam teraz dostepu do tego pliku.
Bajt $2D to jest koniec ID (-lh0-).
A dalej masz $05000000.
I nastepne $05000000.
Jedno z nich jest packed size a drugie unpacked size.
A ze tutaj nie ma kompresji to wartosc jest taka sama.
Meynaf mi kiedys napisal spliter do glownego pliku (banku) z gry HOMM2, to bylo pareset bajtow tylko, moze 1KB max.
to mozna bylo by prosto przerobic. Ale nie mam teraz dostepu do tego pliku.
11.01 15:21
[#206]
Re: Dewelopment gry Sołtys
@Don_Adan, post #204
No taka jest różnica pomiędzy BB a ASM. Napisałem sobie strukturę + odczyt danych i wyszło mi 16 kB pliku exe. A jeszcze odczyt i zapis danych.
Moim zdaniem packed/unpacked size jest w amigowym endianie zapisany jako $00000005 w bajcie 8 i drugi w bajcie 16 ta sama wartość. Wartość $05000000 zaczyna się dziwacznie od bajtu 7. Jeśli zrobię Peek.l od tego bajtu, to na 68000 otrzymam guru, więc nawet gdybym chciał przekształcić tego endiana to nie odczytam longa z 7 bajtu.
Jak mam odczytywać nazwę pliku do zapisu? Tzn jak odczytać wiem, ale nie wiem jakim bajtem się kończy nazwa pliku. Po bajcie $74 (ostatnia litera nazwy pliku to: "t") w pierwszym przypadku mam: $F0 6E 41 00 00 a w drugim mam $ B0 6F 41 00 00. Jeśli będę odczytywać ścieżkę do zapisu, to muszę znać bajt, który kończy odczyt tej ścieżki, tak jak w przypadku łańcuchów tekstowych to jest bajt 00. Tutaj mogę tak zrobić, że odczytuję aż do bajtu $00, a następnie usuwam ostatnie 3 bajty, które tutaj w Filemasterze są wyświetlane jako ".nA" i ".oA". I to chyba dobre rozwiązanie.
Moim zdaniem packed/unpacked size jest w amigowym endianie zapisany jako $00000005 w bajcie 8 i drugi w bajcie 16 ta sama wartość. Wartość $05000000 zaczyna się dziwacznie od bajtu 7. Jeśli zrobię Peek.l od tego bajtu, to na 68000 otrzymam guru, więc nawet gdybym chciał przekształcić tego endiana to nie odczytam longa z 7 bajtu.
Jak mam odczytywać nazwę pliku do zapisu? Tzn jak odczytać wiem, ale nie wiem jakim bajtem się kończy nazwa pliku. Po bajcie $74 (ostatnia litera nazwy pliku to: "t") w pierwszym przypadku mam: $F0 6E 41 00 00 a w drugim mam $ B0 6F 41 00 00. Jeśli będę odczytywać ścieżkę do zapisu, to muszę znać bajt, który kończy odczyt tej ścieżki, tak jak w przypadku łańcuchów tekstowych to jest bajt 00. Tutaj mogę tak zrobić, że odczytuję aż do bajtu $00, a następnie usuwam ostatnie 3 bajty, które tutaj w Filemasterze są wyświetlane jako ".nA" i ".oA". I to chyba dobre rozwiązanie.
11.01 15:51
[#207]
Re: Dewelopment gry Sołtys
@tukinem, post #206
Zapisało oba pliki tekstowe poprawnie.
Skompilowałem i wyszło 20 kB pliku exe. Obym miał rację co do odczytu rozmiaru pliku.
Dla chętnych zamieszczam tutaj listing:
Ostatnia aktualizacja: 11.01.2025 15:53:53 przez tukinem
Skompilowałem i wyszło 20 kB pliku exe. Obym miał rację co do odczytu rozmiaru pliku.
Dla chętnych zamieszczam tutaj listing:
; tryb testowy
#TEST = 0
NEWTYPE .fileOnDisk
_size.l ; rozmiar
_data.l ; wskaznik
_name.s ; nazwa pliku
End NEWTYPE
DEFTYPE .fileOnDisk src,fts
DEFTYPE .l offset
; ZMIENNE:
; src zmienna pliku odczytanego
; fts zmienna pliku do zapisu
; offset pozycja odczytu w pamieci
;--------------------------------------------------------------
; nalezy uruchomic z dwoma parametrami
; BBSplit <PLIK> <KATALOG_WYJSCIOWY>
CNIF #TEST=0
If NumPars<>2 Then End
CEND
;--------------------------------------------------------------
; wczytanie pliku
CNIF #TEST=0
src\_name = Par$(1)
DEST$=Par$(2)
CELSE
src\_name = "DH1:Unpacked/arc.lha"
DEST$="RAM:"
CEND
src\_size = FileSize(src\_name)
src\_data= AllocMem_(src\_size,0)
BLoad src\_name,src\_data
;--------------------------------------------------------------
offset = 8
; PETLA ZAPISU
While offset<src\_size
fts\_size = Peek.l(src\_data+offset)
; NAZWA PLIKU DO ZAPISU
offset+14
a$ = ""
While Peek.b(src\_data+offset)<>0
a$=a$+Chr$(Peek.b(src\_data+offset))
offset+1
Wend
a$ = UnLeft$(a$,3) ; usuwam 3 ostatnie znaki
fts\_name = a$
; KOPIOWANIE DANYCH
fts\_data = AllocMem_(fts\_size,0)
offset+2
CopyMem_ src\_data+offset , fts\_data , fts\_size
offset+fts\_size+8
BSave DEST$+fts\_name , fts\_data , fts\_size
FreeMem_ fts\_data,fts\_size
Wend
FreeMem_ src\_data,src\_size
EndOstatnia aktualizacja: 11.01.2025 15:53:53 przez tukinem
11.01 15:58
[#208]
Re: Dewelopment gry Sołtys
@tukinem, post #206
PC-towy long w ASM odczytac mozesz tak:
A jak to zrobic w BB2 to nie wiem.
Moze wstawka asemblerowa?
Lha nie pochodzi z Amigi, tylko z Unixa bodaj.
A to jest tylko Amigowy port, ktory musi byc kompatybilny, tak zeby rozpakowywanie archiwow dzialalo na kazdym systemie.
Zrob sobie pare testowych archiwow.
Zmien nazwe pliku "file1.txt" na "file10.txt"
Raczej na pewno lha nie uzywa zadnego znacznika dla konca nazwy pliku.
Tylko jeden z bajtow okresla dlugosc nazwy.
Musisz znalezc, ktory to jest bajt.
I kopiujesz wtedy po prostu podana ilosc znakow, a nie sprawdzasz czy jest jakis znak.
move.b (A0)+,D0 ror.l #8, D0 ;obrot w prawo o 8 bitow, czyli o bajt move.b (A0)+,D0 ror.l #8, D0 ;obrot w prawo o 8 bitow, czyli o bajt move.b (A0)+,D0 ror.l #8, D0 ;obrot w prawo o 8 bitow, czyli o bajt move.b (A0)+,D0 ror.l #8, D0 ;obrot w prawo o 8 bitow, czyli o bajt
A jak to zrobic w BB2 to nie wiem.
Moze wstawka asemblerowa?
Lha nie pochodzi z Amigi, tylko z Unixa bodaj.
A to jest tylko Amigowy port, ktory musi byc kompatybilny, tak zeby rozpakowywanie archiwow dzialalo na kazdym systemie.
Zrob sobie pare testowych archiwow.
Zmien nazwe pliku "file1.txt" na "file10.txt"
Raczej na pewno lha nie uzywa zadnego znacznika dla konca nazwy pliku.
Tylko jeden z bajtow okresla dlugosc nazwy.
Musisz znalezc, ktory to jest bajt.
I kopiujesz wtedy po prostu podana ilosc znakow, a nie sprawdzasz czy jest jakis znak.
11.01 16:32
[#209]
Re: Dewelopment gry Sołtys
@Don_Adan, post #208
Hexmage960 mi kiedyś podał jak prosto zmienić endiana w longu.
Nie wiem jakiego endiana używa unix, wiem jedynie że znaki końca wierszy w plikach ma identyczne jak Amiga.
Zrobiłem to tak, że przy odczycie nazwy pliku sprawdza, czy odczytany bajt=0. Jeśli tak, to usuwam 3 ostatnie odczytane bajty. W wolnej chwili przetestuję go na innych plikach i zobaczymy.
Jeszcze jest kwestia szybkości działania. Jeśli będzie dużo plików, to może różnie się zachowywać, a samo kopiowanie danych to systemowa funkcja CopyMem_. Nie użyłem CopyMemQuick_, ponieważ już tutaj widać, że czasem dane zaczynają się od nieparzystego adresu i nie chciałbym spowodować zwiechy na 68000.
Ostatnia aktualizacja: 11.01.2025 16:41:46 przez tukinem
Nie wiem jakiego endiana używa unix, wiem jedynie że znaki końca wierszy w plikach ma identyczne jak Amiga.
Zrobiłem to tak, że przy odczycie nazwy pliku sprawdza, czy odczytany bajt=0. Jeśli tak, to usuwam 3 ostatnie odczytane bajty. W wolnej chwili przetestuję go na innych plikach i zobaczymy.
Jeszcze jest kwestia szybkości działania. Jeśli będzie dużo plików, to może różnie się zachowywać, a samo kopiowanie danych to systemowa funkcja CopyMem_. Nie użyłem CopyMemQuick_, ponieważ już tutaj widać, że czasem dane zaczynają się od nieparzystego adresu i nie chciałbym spowodować zwiechy na 68000.
Ostatnia aktualizacja: 11.01.2025 16:41:46 przez tukinem
11.01 16:58
[#210]
Re: Dewelopment gry Sołtys
@tukinem, post #209
Na razie jest raczej na pewno zle.
Program podzieli ten jeden testowy plik, na innych sie bedzie wywalal, lub tworzyl smieci.
Wlasnie, tutaj dane/longwordy/wordy moga byc na nieparzystym adresie i program bedzie sie wywalac na 68000 jak bedziesz odczytywal longword jako 4 bajty na raz. A nie bajt po bajcie.
Wiec to co podalem jest dzialajace na 68000, krotsza wersja nie zadziala na 68000, jesli longword bedzie na nieparzystym adresie.
Program podzieli ten jeden testowy plik, na innych sie bedzie wywalal, lub tworzyl smieci.
Wlasnie, tutaj dane/longwordy/wordy moga byc na nieparzystym adresie i program bedzie sie wywalac na 68000 jak bedziesz odczytywal longword jako 4 bajty na raz. A nie bajt po bajcie.
Wiec to co podalem jest dzialajace na 68000, krotsza wersja nie zadziala na 68000, jesli longword bedzie na nieparzystym adresie.