Komentowana treść: Gloom - kod źródłowy
10.05.2017 08:16
[#37]
Re: Gloom - kod źródłowy
@] SKOLMAN_MWS ˇ agrEssOr [, post #31
no właśnie do tego doszedłem po przejrzeniu samego kodu.
tak jak napisałem to co jest w BB2 to tylko testy - np test pocedury c2p. I to jest np fajny przykład bo procedura jest w assemblerze (zasemblowana) i dodawana jako plik .o do kodu w blitz basicu). samo to pozwala już się trochę pobawić.
inna ciekawostka - Główny plik .asm ma 190 kb!! i faktycznie ciężko się go analizuje, nie zakładał bym że ktoś to weźmie na warsztat.
tak jak napisałem to co jest w BB2 to tylko testy - np test pocedury c2p. I to jest np fajny przykład bo procedura jest w assemblerze (zasemblowana) i dodawana jako plik .o do kodu w blitz basicu). samo to pozwala już się trochę pobawić.
inna ciekawostka - Główny plik .asm ma 190 kb!! i faktycznie ciężko się go analizuje, nie zakładał bym że ktoś to weźmie na warsztat.
10.05.2017 12:36
[#38]
Re: Gloom - kod źródłowy
@retronav, post #37
I tak ten kod jest prostszy niż Alien Breeda 3D II. Wziąć na warsztat może tylko ktoś, kto lubi taką pracę. Pytanie czy znajdzie się taka osoba.
Szczerze mówiąc po Benefactorze i Dune II miałem kiedyś chęć przeanalizować Glooma, do którego zrobiłem kilka programów użytkowych.
Z Benefactorem poradziłem sobie dość sprawnie, analizując kod asemblera bez żadnych komentarzy. Muszę przyznać, że jest to bardzo przejrzysty i ładny kod.
Niestety, choroba i leczenie lekarstwami mocno ograniczyła moje pole manewru w tym temacie. Po prostu jak próbowałem pracować na komputerze bolała mnie głowa. To się ciągnęło latami.
Choroba była naprawdę perfidna i nieprzyjemna.
Na szczęście ostatnio zdrowieję już kapitalnie dzięki najwłaściwszym lekom, które biorę ponad 8 miesięcy. Programowanie ostatnio idzie mi zdecydowanie lepiej. Ostatnio czyli zaledwie od tygodnia.
Z tego względu na efekty jeszcze trzeba poczekać. Ale już pracuję skutecznie. Efektami pracy podzielę się jak wszystko będzie gotowe.
Dzisiaj napisałem na przykład obsługę joysticka za pomocą gameport.device do wykorzystania w grach. Jestem z kodu zadowolony.
Gloom wymaga rzeczywiście bardzo dużo czasu, którego w tej chwili nie mam. Może w wakacje przyjrzę się temu.
Ale najpierw chciałbym przygotować grę na RetroKomp. Mam też w planach parę niespodzianek.
Szczerze mówiąc po Benefactorze i Dune II miałem kiedyś chęć przeanalizować Glooma, do którego zrobiłem kilka programów użytkowych.
Z Benefactorem poradziłem sobie dość sprawnie, analizując kod asemblera bez żadnych komentarzy. Muszę przyznać, że jest to bardzo przejrzysty i ładny kod.
Niestety, choroba i leczenie lekarstwami mocno ograniczyła moje pole manewru w tym temacie. Po prostu jak próbowałem pracować na komputerze bolała mnie głowa. To się ciągnęło latami.
Choroba była naprawdę perfidna i nieprzyjemna.
Na szczęście ostatnio zdrowieję już kapitalnie dzięki najwłaściwszym lekom, które biorę ponad 8 miesięcy. Programowanie ostatnio idzie mi zdecydowanie lepiej. Ostatnio czyli zaledwie od tygodnia.
Z tego względu na efekty jeszcze trzeba poczekać. Ale już pracuję skutecznie. Efektami pracy podzielę się jak wszystko będzie gotowe.
Dzisiaj napisałem na przykład obsługę joysticka za pomocą gameport.device do wykorzystania w grach. Jestem z kodu zadowolony.
Gloom wymaga rzeczywiście bardzo dużo czasu, którego w tej chwili nie mam. Może w wakacje przyjrzę się temu.
Ale najpierw chciałbym przygotować grę na RetroKomp. Mam też w planach parę niespodzianek.
10.05.2017 21:03
[#39]
Re: Gloom - kod źródłowy
@Pinto, post #24
Bez uszczypliwości, ale...
Żeby się najlepiej przekonać dlaczego, trzeba by się nauczyć assemblera, C, wykorzystania scalaków Amigi, obsługę systemu, połączenia tego wszystkiego w kupę i spróbować zrobić taką wersję RTG. Zabawa przy próbie zrobienia czegoś takiego będzie "przednia", a nagroda jak się uda, kilka poklepań po plecach, troszkę narzekania, bo coś można było zrobić lepiej.
A pisząc badziewie, mamy wolność tworzenia, swój własny kod, który na pewno będzie łatwiejszy do zrozumienia, niż assembler kogoś innego (grzebanie w czyimś kodzie assemblerowym to masochizm jest! - żeby się w kodzie Glooma połapać, to nie wiem ile czasu trzeba, ale myślę że miesięcy po kilka godzin dziennie) i postęp (jak coś się udaje to największa nagroda - krótka przerwa w rwaniu sobie włosów z głowy dlaczego to ku... nie działa
) będą lepsze dla nas, a na koniec mamy większą satysfakcję bo robimy coś nowego, bardziej twórczego, choć ktoś może nazwać to badziewiem. No bo do genialnego kodu jednej czy drugiej gry, to faktycznie jest badziewie, ale chodzi o fun. Po co się katować, każdy robi to co mu przynosi satysfakcję, bawi.
Ostatnia aktualizacja: 10.05.2017 21:06:24 przez flops
Żeby się najlepiej przekonać dlaczego, trzeba by się nauczyć assemblera, C, wykorzystania scalaków Amigi, obsługę systemu, połączenia tego wszystkiego w kupę i spróbować zrobić taką wersję RTG. Zabawa przy próbie zrobienia czegoś takiego będzie "przednia", a nagroda jak się uda, kilka poklepań po plecach, troszkę narzekania, bo coś można było zrobić lepiej.
A pisząc badziewie, mamy wolność tworzenia, swój własny kod, który na pewno będzie łatwiejszy do zrozumienia, niż assembler kogoś innego (grzebanie w czyimś kodzie assemblerowym to masochizm jest! - żeby się w kodzie Glooma połapać, to nie wiem ile czasu trzeba, ale myślę że miesięcy po kilka godzin dziennie) i postęp (jak coś się udaje to największa nagroda - krótka przerwa w rwaniu sobie włosów z głowy dlaczego to ku... nie działa
) będą lepsze dla nas, a na koniec mamy większą satysfakcję bo robimy coś nowego, bardziej twórczego, choć ktoś może nazwać to badziewiem. No bo do genialnego kodu jednej czy drugiej gry, to faktycznie jest badziewie, ale chodzi o fun. Po co się katować, każdy robi to co mu przynosi satysfakcję, bawi.Ostatnia aktualizacja: 10.05.2017 21:06:24 przez flops