Komentowana treść: AmiGameJam 2016
04.12.2016 13:19
[#34]
Re: AmiGameJam 2016
@Leon, post #28
Rozważyłeś połączenie wszystkich plików w jeden i czytanie ich przy użyciu odpowiedniego offsetu? Bo się do tego nie ustosunkowałeś. Weź na szybko połącz je w jeden plik albo wygeneruj taki pusty z zerami, który będzie ważył sumę wszystkich plików danego typu i zobacz czy wtedy mniej miejsca na dyskietce stracisz.
04.12.2016 13:54
[#35]
Re: AmiGameJam 2016
@Leon, post #28
Ogólnie jest to irytujące, że na starcie tracę ponad 20% miejsca na dyskietce tylko dlatego, że gra składa się z większej liczby plików.
Nie ma się co irytować. Tak przecież działają wszystie systemy plików na tej planecie. Zapewne masz tam pod ręką jakiegoś Windowsa, Linuxa czy Maka. Zrób plik tekstowy, który ma tylko jedną literkę. I zobacz jego właściwości. Na macOS (Windowsa czy Linuxa nie mam ale pewnie będzie podobnie) zobaczysz coś takiego:
Size: 1 byte (4 KB on disk)
Plik niby "waży" 1 bajt, a na dysku zajmuje 4096 bajtów. Czyli 512 bajtów to i tak jest niewielki blok.
Tak samo gdy się kopiuje na pendrive czy wysyła na FTP kilkaset tysięcy małych pliczków to zdecydowanie lepiej spakować je jakimś ZIP/LhA, nawet bez kompresji i wysłać taki jeden spakowany plik. Kilkaset tysięcy małych plików będzie się kopiowała/wysyłała wiele razy dłużej niż ten jeden spakowany nawet bez kompresji.
Ostatnia aktualizacja: 04.12.2016 14:05:03 przez MDW
04.12.2016 13:56
[#36]
Re: AmiGameJam 2016
@Leon, post #28
Moim zdaniem ten ktoś nie był taki głupi. Dane trzeba było zgrupować w pewne jednostki, czytanie bajt za bajtem z dysku byłoby nieefektywne, zważywszy również że każdy taki blok musi posiadać też sumę kontrolną. 512 bajtów to całkiem optymalny rozmiar dla takiego bloku.
Nie najlepszym pomysłem jest tworzenie wielu malutkich pliczków z tego samego powodu. Połącz te pliki w większe zbiory i nie tyle zyskasz miejsca na dysku, ale też te zbiory będą szybciej wczytywane.
Czytanie blokami nazywa się buforowaniem, zaś rozmiar bufora z reguły bierze się z badań statystycznych. To nie dzieło przypadku.
Ostatnia aktualizacja: 04.12.2016 13:59:10 przez Hexmage960
Nie najlepszym pomysłem jest tworzenie wielu malutkich pliczków z tego samego powodu. Połącz te pliki w większe zbiory i nie tyle zyskasz miejsca na dysku, ale też te zbiory będą szybciej wczytywane.
Czytanie blokami nazywa się buforowaniem, zaś rozmiar bufora z reguły bierze się z badań statystycznych. To nie dzieło przypadku.
Ostatnia aktualizacja: 04.12.2016 13:59:10 przez Hexmage960
04.12.2016 15:03
[#37]
Re: AmiGameJam 2016
@teh_KaiN, post #34
Na dyskietce tracę miejsce ze względu na dużą liczbę plików. Jak wrzucę 1 plik 850 KB to bez problemu zmieści się na dyskietce 878 KB (włączony FFS). Plików z poziomami nie mogę połączyć w jeden plik bo Backbone tego nie odczyta. Co najwyżej mogę spakować plik wykonywalny, który ma prawie 200 KB. Każdy poziom zapisany jest oddzielnie w 5 plikach (pic) czyli mając 31 poziomów mamy 155 plików w jednym katalogu. Można pewnie pobawić się ze zmianą wartości bloku z 512 do 256 ale nie będę mógł tego zapisać jako ADF.
Ostatnia aktualizacja: 04.12.2016 15:05:28 przez Leon
Ostatnia aktualizacja: 04.12.2016 15:05:28 przez Leon
04.12.2016 16:18
[#41]
Re: AmiGameJam 2016
@Leon, post #38
Przykładowo system z mniejszymi blokami.
512 bajtów to właśnie jest system z mniejszymi blokami.
Tak to jest jak się używa jakiegoś gotowego silnika. Pojawia się problem i jeżeli tego silnik nie ogarnia to jest się w kropce. Gdy się wszystko pisze samemu to można zrobić wszystko tak jak się chce.
A teraz taka bardziej konstruktywna rada.
Na jakie Amigi celujesz z tą grą? Jeżeli na więcej niż 1MB RAM to może zrobić taki prosty zabieg. Spakować te pliki do jednego miejsca jakimś ZIP czy LhA. Potem przy uruchamianiu gry niech się te pliki rozpakowują do RAM: i stamtąd gra by je odczytywała. Oczywiście nie tak po "hardcorowo" z RAM: tylko zrobić jakieś zgrabne przypisanie i z niego czytać.
Powiedzmy, że skrypt uruchamiający grę wyglądałby jakoś tak:
MakeDir RAM:MojaGraTemp
Assign MojaGraTemp: RAM:MojaGraTemp
LhA >NIL: x MojaGraDisk1:pliki.lha MojaGraTemp:
MojaGra.exe >NIL:
Na końcu skryptu można jeszcze dodać usuwanie przypisania MojaGraTemp: i katalogu RAM:MojaGraTemp wraz ze znajdującymi się w nim plikami.
W grze czytamy pliki używając takich ścieżek:
"MojaGraTemp:obrazek.iff"
"MojaGraTemp:muzyczka.mod"
"MojaGraTemp:tekscik.txt"
Nie wiem jak tam masz to wszystko zorganizowane ale można te pliki podzielić na jakieś mniejsze archiwa, np. archiwum dla każdego levelu, archiwum plików wspólnych dla wszystkich leveli.
No i nie zapomnij, że na dyskietce powinno być coś do rozpakowywania plików, bo ludzie odpalający grę z dyskietki często nie mają pojęcia, że Amiga ma system operacyjny.
Ostatnia aktualizacja: 04.12.2016 16:25:18 przez MDW
04.12.2016 16:35
[#42]
Re: AmiGameJam 2016
@Leon, post #37
A backbone umie robić normalne operacje na plikach? Jak tak, to przy wczytywaniu poziomów otwierasz ten duży plik "na surowo", czytasz z niego tyle bajtów ile potrzebujesz, zapisujesz je na (ram)dysku w postaci oddzielnego pliku jednego poziomu i potem go ładujesz funkcją backbonową. Kolejny poziom wczytujesz tak samo, nadpisując poprzedni plik pojedynczego poziomu.
Jeśli nie umie, to może umie wywołać polecenie linii komend? Jak tak to mogę Ci w C przygotować programik, który zrobi dokładnie to co pisałem wyżej, wystarczy że go będziesz mógł wywołać z poziomu gry w argumencie podając numer mapy.
Ostatnia aktualizacja: 04.12.2016 16:35:52 przez teh_KaiN
Jeśli nie umie, to może umie wywołać polecenie linii komend? Jak tak to mogę Ci w C przygotować programik, który zrobi dokładnie to co pisałem wyżej, wystarczy że go będziesz mógł wywołać z poziomu gry w argumencie podając numer mapy.
Ostatnia aktualizacja: 04.12.2016 16:35:52 przez teh_KaiN
04.12.2016 18:05
[#44]
Re: AmiGameJam 2016
@Leon, post #38
Nie biadol, tylko kompresuj exeka - to możesz zrobić najszybciej. Do plików executable polecam CrunchyDat , podczas mojej aktywności na scenie często ratował nam "tyłek" elegancko pakując intra.
04.12.2016 18:51
[#45]
Re: AmiGameJam 2016
@gorzyga, post #44
Z ciekawości sprawdziłem ten program, niestety wyskakuje błąd. Dobrze, że okroiłem dziś grafikę.
04.12.2016 22:15
[#51]
Re: AmiGameJam 2016
@asman, post #50
Mi się gdzieś obiło o uszy że Backbone generuje źródło amosowe i później je kompiluje. Mógłbyś je przejrzeć i tam pogrzebać w sprawie tych plików i pewnie wielu innych rzeczy też.
Ale gdyby potem chciał coś zmienić w Backbone to straciłby modyfikacje w AMOSowych źródłach. Po każdej zmianie w Backbone musiałby wprowadzać tę modyfikację jeszcze raz. Każdy generowany kod jest raczej niemodyfikowalny jeżeli nadal chce się zachować możliwość generowania nowych wersji.
Ech, zewnętrzne silniki... zabawa w nich to ciągła walka z ich ograniczeniami i dziwnymi problemami, które normalnie nie istnieją.
Ostatnia aktualizacja: 04.12.2016 22:20:25 przez MDW
04.12.2016 22:18
[#52]
Re: AmiGameJam 2016
@mailman, post #48
Można też wszystko spakować PowerPackerem i na samym początku s-s dać komendę do rozpakowywania w tle - PPDecrunch.
Crap-gra pt. "Rycerze Mroku" tak robi. :) Przed grą odpalony jest PPPatch (czy jak to się tam nazywało), wszystkie pliki są spakowane PowerPackerem i w locie się dekompresują. Na A500 spokojnie daje radę. Tylko, że to chyba nie o to chodziło. Tu raczej trzeba połączyć masę małych pliczków w jeden (lub kilka) większych i z nich wyłuskiwać to co się chce.
05.12.2016 11:03
[#53]
Re: AmiGameJam 2016
@MDW, post #51
Według mnie każdy generowalny kod jest właśnie modyfikowalny, bo jest tworzony według ściśle określonej reguły i nie powinno tu być dowolności jak w przypadku własnego dłubania.
Zatem to nie jest problem z wprowadzeniem modyfikacji i można to zautomatyzować - taki swój własny postproces. Minus jest taki że wtedy to potrzeba więcej wiedzy.
Takie ograniczenia w silniku też mogą wpływać pozytywnie, bo może część użytkowników skłoni się ku programowaniu :)
Swego czasu myślałem nad stworzeniem takiego narzędzia do tworzenia gier. Ale jak pomyśle że potem niektórzy chcą po 30 euro za produkcje stworzoną w takim kreatorze to odpuściłem sobie.
Zatem to nie jest problem z wprowadzeniem modyfikacji i można to zautomatyzować - taki swój własny postproces. Minus jest taki że wtedy to potrzeba więcej wiedzy.
Takie ograniczenia w silniku też mogą wpływać pozytywnie, bo może część użytkowników skłoni się ku programowaniu :)
Swego czasu myślałem nad stworzeniem takiego narzędzia do tworzenia gier. Ale jak pomyśle że potem niektórzy chcą po 30 euro za produkcje stworzoną w takim kreatorze to odpuściłem sobie.
05.12.2016 11:27
[#54]
Re: AmiGameJam 2016
@asman, post #53
@Asman
To Ty, jako autor takiego narzędzia decydujesz, czy może być on używany do celów komercyjnych. Możesz np. zrobić wersję takiego Asman's Game Creator Express i Asman's Game Creator Professional.
Za wersję używaną do celów komercyjnych żądałbyś odpowiedniej zapłaty za każdą wydaną w ten sposób grę.
@MDW
A ja lubię takie zewnętrzne silniki. Ograniczenia to koszt prostoty. Nie można mieć wszystkiego na raz. Tak samo Leon chce by był wilk sity i owca cała w temacie umieszczania danych na dyskietce.
Edytory i kreatory nawet przy swoich ograniczeniach dają ogromną swobodę działania. Uwielbiam tego typu konstruktory.
Najgorsze są gry bez żadnych konstruktorów. Raz przejdziesz i zapomnisz.
Oczywiście wolałbym, tak jak Asman by ludzie uczyli się programowania. Ale odpowiednie korzystanie z gotowych silników jest też dobre.
To Ty, jako autor takiego narzędzia decydujesz, czy może być on używany do celów komercyjnych. Możesz np. zrobić wersję takiego Asman's Game Creator Express i Asman's Game Creator Professional.
Za wersję używaną do celów komercyjnych żądałbyś odpowiedniej zapłaty za każdą wydaną w ten sposób grę.
@MDW
A ja lubię takie zewnętrzne silniki. Ograniczenia to koszt prostoty. Nie można mieć wszystkiego na raz. Tak samo Leon chce by był wilk sity i owca cała w temacie umieszczania danych na dyskietce.
Edytory i kreatory nawet przy swoich ograniczeniach dają ogromną swobodę działania. Uwielbiam tego typu konstruktory.
Najgorsze są gry bez żadnych konstruktorów. Raz przejdziesz i zapomnisz.
Oczywiście wolałbym, tak jak Asman by ludzie uczyli się programowania. Ale odpowiednie korzystanie z gotowych silników jest też dobre.
05.12.2016 11:32
[#55]
Re: AmiGameJam 2016
@asman, post #53
No ale chwila. Sytuacja wygląda tak:
A co do jakości generowanego kodu to różnie to bywa. Wiele osób zna te słynne strony www generowane przez MS Worda.
Ostatnia aktualizacja: 05.12.2016 11:36:18 przez MDW
- Coś sobie wyklikam w narzędziu.
- Generuję kod.
- Zmieniam coś w kodzie.
- Znów zmieniam coś w klikanym narzędziu.
- Generuję nowy kod i... nie ma w nim mojej modyfikacji. Muszę znów szukać w tym generowanym nieskomentowanym kodzie drugi raz dodawać te same modyfikacje. I tak za każdym razem gdy się coś w "klikaczu" zmieni.
A co do jakości generowanego kodu to różnie to bywa. Wiele osób zna te słynne strony www generowane przez MS Worda.
Ostatnia aktualizacja: 05.12.2016 11:36:18 przez MDW
05.12.2016 11:36
[#57]
Re: AmiGameJam 2016
@MDW, post #55
Zmieniam coś w kodzie.
Ten etap nie powinien zachodzić. Generowanego kodu zwykle nie wolno zmieniać. Można wprowadzać modyfikacje tylko niezależnie od generowanego kodu. Wówczas opisywany przez Ciebie problem nie zachodzi.
@56
Ja jako dziecko byłem bardzo cierpliwy i uwielbiałem wszystko robić sam i po swojemu. Nie lubiłem gotowców.
Ostatnia aktualizacja: 05.12.2016 11:38:38 przez Hexmage960
05.12.2016 12:25
[#58]
Re: AmiGameJam 2016
@Hexmage960, post #57
Ten etap nie powinien zachodzić. Generowanego kodu zwykle nie wolno zmieniać.
No właśnie to próbuję powiedzieć.
Jak przeczytałem, że proponuje się modyfikacje kodu wygenerowanego przez jakieś narzędzie to zrobiłem ten opis żeby polazać, że generowanego kodu nie powinno się modyfikować, bo wtedy tracimy możliwość ponownego generowania. Ostatnia aktualizacja: 05.12.2016 12:26:34 przez MDW
05.12.2016 12:31
[#59]
Re: AmiGameJam 2016
@MDW, post #55
Delikatny bezsens widzę w 3 i 4. Po co ktoś rozgarnięty miałby zmieniać coś w kodzie po to by potem zmieniać coś w narzędziu. Ale jak ktoś tak lubi, to wtedy ma więcej pracy :). Dlatego warto zautomatyzować takie rzeczy. Można też podejść inaczej, tylko w końcowym etapie zmienić i testować czy wszystko jest ok.
@Hexmage960
Ja nie jestem zwolennikiem dzielenia softu na ileś wersji, wprowadza to chaos i tworzy miejsca trudne do utrzymania kodu.
@Hexmage960
Ja nie jestem zwolennikiem dzielenia softu na ileś wersji, wprowadza to chaos i tworzy miejsca trudne do utrzymania kodu.
05.12.2016 12:44
[#60]
Re: AmiGameJam 2016
@asman, post #59
[lDelikatny bezsens widzę w 3 i 4. Po co ktoś rozgarnięty miałby zmieniać coś w kodzie po to by potem zmieniać coś w narzędziu.
Bo na przykład:
- poprawia znaleziony przez użytkowników błąd,
- bo rozwija swój projekt dodając jakieś funkcje (kolejne levele),
- bo robi nową wersję,
- bo chce wykorzystać możliwości nowej wersji silnika czy systemu operacyjnego.
Oprogramowanie się rozwija. To nie jest zamknięta, skończona i zalana betonem skrzynka.
Ostatnia aktualizacja: 05.12.2016 12:45:34 przez MDW