27.06.2013 15:02
[#61]
Re: pisanie GRY w C pod A500
@teh_KaiN, post #58
zobacz jeszcze vbcc (wspiera C99), natomiast co do gcc, to wazna jest wersja!!!, radze raczej pozostac na 2.9.... Ogolnie nie ma najlepszego kompilatora, kazdy ma jakies zady i walety. Musisz sprawdzic, ktory wygeneruje najlepszy kod dla 68000 w tym akurat przypadku.
PS. Cudow jednak nie bedzie. Srednio zaawansowany koder ASM 68000 wygeneruje lepszy kod i to bez zabawy jakimis wyrafinowanymi optymalizacjami, niz wszystkie w/w kompilatory C
PS. Cudow jednak nie bedzie. Srednio zaawansowany koder ASM 68000 wygeneruje lepszy kod i to bez zabawy jakimis wyrafinowanymi optymalizacjami, niz wszystkie w/w kompilatory C
27.06.2013 18:01
[#62]
Re: pisanie GRY w C pod A500
@Hextreme-Attic, post #59
Tylko że na aminecie są same paczki bez inkludów, a na EAB Zone coś dzisiaj nie mogę się zalogować.
@gx: póki co priorytetem w wyborze kompilatora jest to, żeby odpalić to na czystej maszynie 1.3 bez dodatkowych, pozaworkbenchowych bibliotek. Jak prace będą bardziej zaawansowane, to później może się pobawię w jakieś benczmarki na żywym organizmie, co produkuje lepszy kod. Ale najpierw trzeba mieć co benczmarkować :)
@gx: póki co priorytetem w wyborze kompilatora jest to, żeby odpalić to na czystej maszynie 1.3 bez dodatkowych, pozaworkbenchowych bibliotek. Jak prace będą bardziej zaawansowane, to później może się pobawię w jakieś benczmarki na żywym organizmie, co produkuje lepszy kod. Ale najpierw trzeba mieć co benczmarkować :)
27.06.2013 19:16
[#63]
Re: pisanie GRY w C pod A500
@teh_KaiN, post #62
Udało się!
Co zrobiłem? Właściwie nie wiem dokładnie, co. :) Jest parę rzeczy, które się wydarzyły:
1. zrezygnowałem z vmake, bo on z automatu do wszystkich wywołań dodaje -noenv. I dlatego nie chciał mi łapać tego, co mam dopisane w user-startup
2. dorzuciłem inkludy z paczki źródeł DICE 3.15 z Aminetu, ale chyba nawet z nich nie korzysta
3. dmake ma problem sam ze sobą, ten zaproponowany jakieś 2 posty wcześniej przez Hextreme-Attic też nie chciał działać. Poszedłem za wskazówką od Kiera i użyłem zwykłego make. Analogiczny dmakefile nie chce mi działać, nie mam pojęcia czemu, wywala na sam koniec mielenia źródeł fatal 6 - can't create [nazwaPliku].o
Potem zostały błędy kompilacji, tj. DICE jest mniej odporny na flejowatość programisty (następstwo deklaracji, brakujące prototypy funkcji, gcc nawet nie pisnął), nagłówki widać też trochę się różnią zawartością (proto/intuition.h automatycznie inkludował proto/graphics.h w ADE, tutaj już tak nie jest), no i nieszczęsny __far.
Teraz całość się kompiluje i działa ślicznie na wb1.3 bez żadnych crashów. Jest tylko jeden mały błąd - gra działa na view LORES, viewport ma 240 szerokości i jest centrowany do środka, mimo to na 1.3 Amidze to nie przeszkadza i radośnie pozwala wyjeżdżać kursorem na lewo i prawo poza ekran. Za viewem ukryty jest intuition screen, który też ma 240 szerokości i intuition window, które też ma 240 szerokości. Wygląda na to, że muszę ręcznie pilnować tego, żeby kursor nie wyjechał poza widoczne pole.
Ostatnia aktualizacja: 27.06.2013 19:33:11 przez teh_KaiN
Co zrobiłem? Właściwie nie wiem dokładnie, co. :) Jest parę rzeczy, które się wydarzyły:
1. zrezygnowałem z vmake, bo on z automatu do wszystkich wywołań dodaje -noenv. I dlatego nie chciał mi łapać tego, co mam dopisane w user-startup
2. dorzuciłem inkludy z paczki źródeł DICE 3.15 z Aminetu, ale chyba nawet z nich nie korzysta
3. dmake ma problem sam ze sobą, ten zaproponowany jakieś 2 posty wcześniej przez Hextreme-Attic też nie chciał działać. Poszedłem za wskazówką od Kiera i użyłem zwykłego make. Analogiczny dmakefile nie chce mi działać, nie mam pojęcia czemu, wywala na sam koniec mielenia źródeł fatal 6 - can't create [nazwaPliku].o
Potem zostały błędy kompilacji, tj. DICE jest mniej odporny na flejowatość programisty (następstwo deklaracji, brakujące prototypy funkcji, gcc nawet nie pisnął), nagłówki widać też trochę się różnią zawartością (proto/intuition.h automatycznie inkludował proto/graphics.h w ADE, tutaj już tak nie jest), no i nieszczęsny __far.
Teraz całość się kompiluje i działa ślicznie na wb1.3 bez żadnych crashów. Jest tylko jeden mały błąd - gra działa na view LORES, viewport ma 240 szerokości i jest centrowany do środka, mimo to na 1.3 Amidze to nie przeszkadza i radośnie pozwala wyjeżdżać kursorem na lewo i prawo poza ekran. Za viewem ukryty jest intuition screen, który też ma 240 szerokości i intuition window, które też ma 240 szerokości. Wygląda na to, że muszę ręcznie pilnować tego, żeby kursor nie wyjechał poza widoczne pole.
Ostatnia aktualizacja: 27.06.2013 19:33:11 przez teh_KaiN
18.09.2013 19:52
[#64]
Re: pisanie GRY w C pod A500
@teh_KaiN, post #1
Ciąg dalszy zmagań z DICE. Mógłby ktoś mnie łaskawie oświecić, czemu to mi się bez problemu kompiluje w gcc, zaś dcc ma z tym problemy natury "Subroutine too complex"?
wtf
Całość to wycinek większego kodu, także nazewnictwo może się wydać bez sensu. Wielu rzeczy brakuje żeby działało, typowanie jest miejscami nie takie jak trzeba, ale powinno dać się to cudo skompilować. Nawet jak zrobię wewnątrz funkcji wywołanie BltBitmap z pustymi argumentami (same zera / nulle) w postaci:
to i tak funkcja mi nie chce ruszyć. Wtedy pomaga zabawa ze skraceniem listy argumentów. I tu się zastanawiam - DICE ma jakieś z tym ograniczenia? Jak tak, to jakie?
wtf
Całość to wycinek większego kodu, także nazewnictwo może się wydać bez sensu. Wielu rzeczy brakuje żeby działało, typowanie jest miejscami nie takie jak trzeba, ale powinno dać się to cudo skompilować. Nawet jak zrobię wewnątrz funkcji wywołanie BltBitmap z pustymi argumentami (same zera / nulle) w postaci:
void drawChar(struct BitMap *pbmDest, tFont *pFont, UWORD uwX, UWORD uwY, char cNo) {
BltBitMap(
NULL,0,0,
NULL,0,0,
0,0,
0x0c0, 0xff, NULL
);
}to i tak funkcja mi nie chce ruszyć. Wtedy pomaga zabawa ze skraceniem listy argumentów. I tu się zastanawiam - DICE ma jakieś z tym ograniczenia? Jak tak, to jakie?