22.10.2010 19:14
[#91]
Re: Ktoś jeszcze pisze gry na klasyki
@G. Kraszewski, post #89
ale C++ wywodzi sie z C, wiec nie az tak roznym jak probujesz to przedstawic ;)
roznica w przypadku platformowki miedzy C z wstawkami asm a calym programem w asmie bedzie minimalna. W zasadzie wszystko co w platformowce musi szybko dzialac to 80% gry, wiec wiekszosc rzeczy powinno byc zakodowane w asmie. Wiec po co te C dla zasady ?
;)
roznica w przypadku platformowki miedzy C z wstawkami asm a calym programem w asmie bedzie minimalna. W zasadzie wszystko co w platformowce musi szybko dzialac to 80% gry, wiec wiekszosc rzeczy powinno byc zakodowane w asmie. Wiec po co te C dla zasady ?
;)
22.10.2010 19:48
[#92]
Re: Ktoś jeszcze pisze gry na klasyki
@selur, post #91
ale C++ wywodzi sie z C, wiec nie az tak roznym jak probujesz to przedstawic
Wystarczająco różnym, żeby bezsensownym było używanie argumentów przeciwko programowaniu obiektowemu jako argumentów przeciwko C. To coś jak twierdzenie, że ponieważ jedzenie gotowane w mikrofalówce jest niezdrowe, nie należy gotować na kuchence gazowej, tylko zawiesić kociołek nad ogniskiem.
W zasadzie wszystko co w platformowce musi szybko dzialac to 80% gry
Z sufitu wziąłeś tę liczbę. W każdej grze jest masa kodu znajdującego się poza główną pętlą animacji. Poza tym wielu asmkoderom wydaje się, że ich kod jest szybszy tylko przez sam fakt napisania go w asemblerze, co jest oczywistym nonsensem. Nie znając dobrze wewnętrznej budowy procesora i timingów instrukcji, można napisać w asmie kod wolniejszy niż to, co wygeneruje kompilator C. Im wyższy procesor 68k, tym łatwiej osiągnąć taki efekt. Kompilator nie wstawia przecież NOP-ów dla zabawy, a oglądanie wyników jego pracy bywa czasami pouczające.
Jeżeli prowadziłeś jakieś pomiary porównawcze wydajności kodu w C i asemblerze, może warto pokazać wyniki?
Wystarczająco różnym, żeby bezsensownym było używanie argumentów przeciwko programowaniu obiektowemu jako argumentów przeciwko C. To coś jak twierdzenie, że ponieważ jedzenie gotowane w mikrofalówce jest niezdrowe, nie należy gotować na kuchence gazowej, tylko zawiesić kociołek nad ogniskiem.
W zasadzie wszystko co w platformowce musi szybko dzialac to 80% gry
Z sufitu wziąłeś tę liczbę. W każdej grze jest masa kodu znajdującego się poza główną pętlą animacji. Poza tym wielu asmkoderom wydaje się, że ich kod jest szybszy tylko przez sam fakt napisania go w asemblerze, co jest oczywistym nonsensem. Nie znając dobrze wewnętrznej budowy procesora i timingów instrukcji, można napisać w asmie kod wolniejszy niż to, co wygeneruje kompilator C. Im wyższy procesor 68k, tym łatwiej osiągnąć taki efekt. Kompilator nie wstawia przecież NOP-ów dla zabawy, a oglądanie wyników jego pracy bywa czasami pouczające.
Jeżeli prowadziłeś jakieś pomiary porównawcze wydajności kodu w C i asemblerze, może warto pokazać wyniki?
22.10.2010 20:01
[#93]
Re: Ktoś jeszcze pisze gry na klasyki
@selur, post #91
C wygląda mi na bardziej przyswajalny i dlatego się o niego spytałem, natomiast nie sądzę aby przewijanie jednopoziomowego tła jak w giana sisters było aż tak zasobożerne jak wielopoziomowy efekt paralaksy z JIM POWER, jedyne co mi potrzeba w tej chwili to scroll statycznego tła i animacja postaci, jeśli zajdzie potrzeba pisania wstawek w ASM, to zacznę iść w tym kierunku. znajomość języka C przydaje się w innych dziedzinach jak programowanie procesorów PIC, Atmega itd itp. Zawsze jest nadzieja, że znajdzie się ktoś, kto pomoże :)
Kompilator nie wstawia przecież NOP-ów dla zabawy, a oglądanie wyników jego pracy bywa czasami pouczające.
No właśnie wiadomo, że kompilator spełnia tutaj kluczową rolę jeśli chodzi o wydajność, dlatego przydałby się jakiś teścik wydajności np tej samej gry napisanej w C i skompilowanej za pomocą najlepszego kompilatora na klasyka i najnowszego dostępnego cross-kompilatora na windows lub linuksa.
Kompilator nie wstawia przecież NOP-ów dla zabawy, a oglądanie wyników jego pracy bywa czasami pouczające.
No właśnie wiadomo, że kompilator spełnia tutaj kluczową rolę jeśli chodzi o wydajność, dlatego przydałby się jakiś teścik wydajności np tej samej gry napisanej w C i skompilowanej za pomocą najlepszego kompilatora na klasyka i najnowszego dostępnego cross-kompilatora na windows lub linuksa.
22.10.2010 21:33
[#94]
Re: Ktoś jeszcze pisze gry na klasyki
@G. Kraszewski, post #87
Problemem za dawnych dobrych amigowych czasów było to, że koder pisał na docelowym (cienkim) konfigu, przez co nie mógł użyć dobrych kompilatorów C, głównie chodzi mi o GCC. SAS/C wysiada pod względem jakości generowanego kodu w porównaniu do GCC 2.95.3. O zabytkach w stylu Dice C, Maxonie i innych nie wspomnę. Tylko, żeby wygodnie pracować z GCC trzeba mieć 030, ze 32 MB fastu i dysk twardy. W czasach mistrzów Amosa taki konfig był rzadkością. Teraz to już nie jest rarytas, zresztą można krosskompilować na PC.
Na czym opierasz porównanie, że GCC 2.95.3 generuje lepszy kod niż SAS/C ? Bo ja osobiście nie jestem zadowolony ani z GCC ani z SAS/C - ale ja mam małe doświadczenie w tym temacie.
Na czym opierasz porównanie, że GCC 2.95.3 generuje lepszy kod niż SAS/C ? Bo ja osobiście nie jestem zadowolony ani z GCC ani z SAS/C - ale ja mam małe doświadczenie w tym temacie.
22.10.2010 22:12
[#96]
Re: Ktoś jeszcze pisze gry na klasyki
@selur, post #88
C++ mogło nie przypaść Ci do gustu jeśli wcześniej pracowałeś w AMOSie. Dlatego, że AMOS i generalnie wszystkie odmiany Basica zostawiają wiele złych nawyków podczas projektowania i pisania programów. Po pierwsze w AMOSie programy pisze się głównie rozkaz po rozkazie, bez wcześniejszego planowania, nagminnie korzysta się z polecenia "Goto", programowanie proceduralne takie jak w C istnieje, ale jest szczątkowe. Swoją drogą w C polecenie "goto" istnieje, ale jest bardzo nie zalecane i uważane za zły nawyk.
Programowanie w C++ rządzi się innymi prawami, wymaga odmiennego podejścia do zagadnienia, czyli pisanego programu. Program trzeba najpierw zaprojektować i stworzyć "świat" podzielony na szereg obiektów o określonych cechach. Trzeba określić relacje między tymi obiektami, znaleźć części wspólne między obiektami, opisać zachowanie się obiektów. Ma to bardzo dobre odniesienie do świata rzeczywistego.
Tworząc świat gry np. Giany Sisters trzeba najpierw stworzyć bohatera, później świat w którym ten bohater się porusza no i następnie postacie przeszkadzające naszemu bohaterowi w podróży, jak również skarby które może zebrać itp. Pisząc w C++ najlepiej oddzielić implementację różnych zachowań bohatera od jego rzeczywistego rysowania i animacji. Te procedury będą zapewne napisane jako wstawki asemblerowe ;) Na przykład klasa Giana to nasza bohaterka, którą charakteryzuje m.in:
- położenie na mapie,
- zwrot, czyli kierunek w którym się porusza,
- prędkość marszu,
- przyspieszenie w pionie (czyli czy skacze lub spada),
Świat w jakim się porusza charakteryzuje ziemia, po której stąpa oraz platformy po których może skakać. Dodatkowo w tym świecie mogą być obecne wrogie stwory oraz skarby do zebrania (grałem kiedyś w Giana Sisters i piszę to co pamiętam z tej gry). Stworki mają cechy wspólne z bohaterką, ponieważ to też są jakieś istoty, które poruszają się, jednakże ich zachowaniem kierują zupełnie inne siły, tj. idą w prawo aż do napotkania przeszkody po czym kierują się w lewo itd. Skarby (owoce itp.) charkateryzuje przede wszystkim położenie oraz punkty ile zbierze się za podniesienie danego przedmiotu. Poza tym są to martwe przedmioty, które się nie poruszają, co odróżnia je od żywej fauny naszego świata.
Zatem możemy stworzyć najpierw klasę świat, w którym wszystko się dzieje. Świat będzie zawierał położenie wszystkich platform, przeszkód oraz dane o wszystkich obiektach (stworach, skarbach) wewnątrz tego świata. Np. w C++ napiszemy:
CPlatform to klasa która określa platformę w naszym świecie po której może chodzić nasza bohaterka, jak i wrogowie. Mogą też na niej leżeć skarby.
Wszystkie obiekty w naszym świecie są powiązane ze sobą za pomocą węzłów (tworzą tzw. listę). Najlepiej gdy te obiekty są posortowane względem położenia [X,Y], wtedy operacje na takich obiektach będą bardzo szybkie.
Nasza bohaterka:
Teraz polecam dla każdego obiektu napisać odpowiednie procedury wewnątrz klas (tzw. metody), odpowiedzialne za przeróżne czynności i zachowanie danego obiektu. Na przykład dla klasy CTreasure określona została metoda IsCollected, która sprawdza czy przypadkiem w pobliżu nie znajduje się bohater, który może zebrać przedmiot. Jeśli w pobliżu znajduje się bohater, to przedmiot zostaje wzięty, egzemplarz klasy zostaje usunięty z listy, a punktacja rośnie według rodzaju wziętego obiektu. Dla klasy CBaddie (wrogi stworek) zostały określone metody: IsHarming() i IsDying(). Pierwsza sprawdza czy przypadkiem w pobliżu nie znajduje się bohater, którego stworek może zranić, a druga czy przypadkiem bohater nie spada na głowę naszemu stworkowi zabijając go i kompletując punkty.
Teraz jak nasza gra będzie wyglądać? Po stworzeniu takiego zestawu klas i metod dalsza praca staje się o wiele prostsza. Więc tak: dana jest nam cała zainicjowana klasa CGianaWorld ze wszystkimi platformami, skarbami i potworami obecnymi na planszy. Trzeba wszystko ożywić i wprawić w ruch.
Zatem jedno wykonanie pętli naszego programu wyglądałoby tak:
I to by był w praktyce cały silnik prostej platformówki. Oczywiście brakuje tutaj implementacji szeregu funkcji, ale te mogę opisać w następnym poście. Wszelkie procedury rysowania i skrolowania ekranu byłyby "zatajone" przed samym programistą za pomocą implementacji. I czy w C++ nie pisze się naprawdę łatwo i przyjemnie? ;) Należy pamiętać o sortowaniu współrzędnych w celu zmaksymalizowania wydajności algorytmów. No i potrzeba użyć dobrego kompilatora. Pozdrawiam i mam nadzieję że, ten przykład napisania prostej gry platformowej przyda się osobom, które taką grę pragną napisać. Jest to tylko przykład (piszę go na bieżąco z głowy), bo taką grę można napisać na naprawdę wiele sposobów.
Programowanie w C++ rządzi się innymi prawami, wymaga odmiennego podejścia do zagadnienia, czyli pisanego programu. Program trzeba najpierw zaprojektować i stworzyć "świat" podzielony na szereg obiektów o określonych cechach. Trzeba określić relacje między tymi obiektami, znaleźć części wspólne między obiektami, opisać zachowanie się obiektów. Ma to bardzo dobre odniesienie do świata rzeczywistego.
Tworząc świat gry np. Giany Sisters trzeba najpierw stworzyć bohatera, później świat w którym ten bohater się porusza no i następnie postacie przeszkadzające naszemu bohaterowi w podróży, jak również skarby które może zebrać itp. Pisząc w C++ najlepiej oddzielić implementację różnych zachowań bohatera od jego rzeczywistego rysowania i animacji. Te procedury będą zapewne napisane jako wstawki asemblerowe ;) Na przykład klasa Giana to nasza bohaterka, którą charakteryzuje m.in:
- położenie na mapie,
- zwrot, czyli kierunek w którym się porusza,
- prędkość marszu,
- przyspieszenie w pionie (czyli czy skacze lub spada),
Świat w jakim się porusza charakteryzuje ziemia, po której stąpa oraz platformy po których może skakać. Dodatkowo w tym świecie mogą być obecne wrogie stwory oraz skarby do zebrania (grałem kiedyś w Giana Sisters i piszę to co pamiętam z tej gry). Stworki mają cechy wspólne z bohaterką, ponieważ to też są jakieś istoty, które poruszają się, jednakże ich zachowaniem kierują zupełnie inne siły, tj. idą w prawo aż do napotkania przeszkody po czym kierują się w lewo itd. Skarby (owoce itp.) charkateryzuje przede wszystkim położenie oraz punkty ile zbierze się za podniesienie danego przedmiotu. Poza tym są to martwe przedmioty, które się nie poruszają, co odróżnia je od żywej fauny naszego świata.
Zatem możemy stworzyć najpierw klasę świat, w którym wszystko się dzieje. Świat będzie zawierał położenie wszystkich platform, przeszkód oraz dane o wszystkich obiektach (stworach, skarbach) wewnątrz tego świata. Np. w C++ napiszemy:
class CGianaWorld
{
public:
CPlatform *m_FirstPlatform;
CObstacle *m_FirstObstacle;
CBaddie *m_FirstBaddie;
CTreasure *m_FirstTreasure;
CHeroGiana m_Hero;
};CPlatform to klasa która określa platformę w naszym świecie po której może chodzić nasza bohaterka, jak i wrogowie. Mogą też na niej leżeć skarby.
class CPlatform
{
public:
CPlatform *m_NextPlatform, *m_PrevPlatform;
ULONG m_XStart, m_YStart;
ULONG m_XEnd, m_YEnd;
ULONG m_Graphics;
BOOL OnPlatform();
};Wszystkie obiekty w naszym świecie są powiązane ze sobą za pomocą węzłów (tworzą tzw. listę). Najlepiej gdy te obiekty są posortowane względem położenia [X,Y], wtedy operacje na takich obiektach będą bardzo szybkie.
class CObstacle
{
public:
CObstacle *m_NextObstacle, *m_PrevObstacle;
ULONG m_X, m_Y;
ULONG m_Kind;
BOOL OnObstacle();
};
class CBaddie
{
public:
CBaddie *m_NextBaddie, *m_PrevBaddie;
ULONG m_X, m_Y;
LONG m_Direction;
ULONG m_Kind;
BOOL IsHarming();
BOOL IsDiying();
VOID Move();
};
class CTreasure
{
public:
CTreasure *m_NextTreasure, *m_PrevTreasure;
ULONG m_X, m_Y;
ULONG m_Kind;
BOOL IsCollected();
};Nasza bohaterka:
class CHeroGiana
{
public:
ULONG m_X, m_Y;
LONG m_Direction;
LONG m_XSpeed, m_YSpeed;
LONG m_XAcc, m_YAcc;
VOID Move( LONG XDir, LONG YDir );
};Teraz polecam dla każdego obiektu napisać odpowiednie procedury wewnątrz klas (tzw. metody), odpowiedzialne za przeróżne czynności i zachowanie danego obiektu. Na przykład dla klasy CTreasure określona została metoda IsCollected, która sprawdza czy przypadkiem w pobliżu nie znajduje się bohater, który może zebrać przedmiot. Jeśli w pobliżu znajduje się bohater, to przedmiot zostaje wzięty, egzemplarz klasy zostaje usunięty z listy, a punktacja rośnie według rodzaju wziętego obiektu. Dla klasy CBaddie (wrogi stworek) zostały określone metody: IsHarming() i IsDying(). Pierwsza sprawdza czy przypadkiem w pobliżu nie znajduje się bohater, którego stworek może zranić, a druga czy przypadkiem bohater nie spada na głowę naszemu stworkowi zabijając go i kompletując punkty.
Teraz jak nasza gra będzie wyglądać? Po stworzeniu takiego zestawu klas i metod dalsza praca staje się o wiele prostsza. Więc tak: dana jest nam cała zainicjowana klasa CGianaWorld ze wszystkimi platformami, skarbami i potworami obecnymi na planszy. Trzeba wszystko ożywić i wprawić w ruch.
Zatem jedno wykonanie pętli naszego programu wyglądałoby tak:
BOOL SingleStep( CGianaWorld ourworld )
{
CTreasure *treasure;
CObstacle *obstacle;
CBaddie *baddie;
CPlatform *platform;
BOOL GianaDead=FALSE;
for (treasure = ourworld.m_FirstTreasure; treasure != NULL; treasure = treasure->m_NextTreasure)
{
if (treasure->IsCollected())
{
Remove(&ourworld, treasure);
points += reward[ treasure->m_Kind ];
}
}
for (baddie = ourworld.m_FirstBaddie; baddie != NULL; baddie = baddie->m_NextBaddie)
{
baddie->Move();
if (baddie->IsHarming())
{
energy--;
if (energy == 0)
GianaDead = TRUE;
}
if (baddie->IsDying())
{
Remove(&ourworld, baddie);
}
}
ourworld.m_Hero.Move( GetJoystickX(), GetJoystickY() );
return (GianaDead);
}
void PlayGianaSisters( CGianaWorld ourworld)
{
while (!SingleStep( ourworld ));
return;
}I to by był w praktyce cały silnik prostej platformówki. Oczywiście brakuje tutaj implementacji szeregu funkcji, ale te mogę opisać w następnym poście. Wszelkie procedury rysowania i skrolowania ekranu byłyby "zatajone" przed samym programistą za pomocą implementacji. I czy w C++ nie pisze się naprawdę łatwo i przyjemnie? ;) Należy pamiętać o sortowaniu współrzędnych w celu zmaksymalizowania wydajności algorytmów. No i potrzeba użyć dobrego kompilatora. Pozdrawiam i mam nadzieję że, ten przykład napisania prostej gry platformowej przyda się osobom, które taką grę pragną napisać. Jest to tylko przykład (piszę go na bieżąco z głowy), bo taką grę można napisać na naprawdę wiele sposobów.
22.10.2010 22:26
[#97]
Re: Ktoś jeszcze pisze gry na klasyki
@Minniat, post #96
W C++ być może pisze się łatwo i przyjemnie, ale bardzo łatwo stracić wydajność kodu. Kilka nieopatrznie niejawnie wywołanych konstruktorów kopiujących na przykład i wydajność leży. Po prostu C++ bardzo dużo rzeczy robi "za plecami programisty" i ciężko nad tym zapanować. Zdecydowanie nie polecam C++ do pisania na maszyny o ograniczonej pamięci i mocy procesora.
22.10.2010 22:54
[#99]
Re: Ktoś jeszcze pisze gry na klasyki
@G. Kraszewski, post #97
W C++ być może pisze się łatwo i przyjemnie, ale bardzo łatwo stracić wydajność kodu. Kilka nieopatrznie niejawnie wywołanych konstruktorów kopiujących na przykład i wydajność leży. Po prostu C++ bardzo dużo rzeczy robi "za plecami programisty" i ciężko nad tym zapanować. Zdecydowanie nie polecam C++ do pisania na maszyny o ograniczonej pamięci i mocy procesora.
Cale C++ sie dla takich maszyn nie nadaje, ale juz jego podzbior tak. Podzbior C++ smigal mi na atmelu ATMega644P (64KB Flash, 4KB RAM) calkiem zacnie.
23.10.2010 16:47
[#102]
Re: Ktoś jeszcze pisze gry na klasyki
@Minniat, post #96
Dzięki Minniat za przykład, tylko pewnie taka gra napisana w C++ będzie wymagała chyba więcej niż 14MHz z fastem, chociaż głowy sobie ściąć nie dam.
Pierwsze co wogóle chciałbym zrobić to pomieszczenie skłądające się z dwóch ekranów, przesuwanych lewo-prawo, bohater i jakieś platformy do skakania, to by było takie moje środowisko robocze, w którym testowałbym swoje postępy, cała reszta byłaby dorobiona, dopiero, gdy w środowisku testowym technicznie wyglądałby wszystko na akceptowalnym poziomie.
Hołdys, ja rozumiem Twoje podejście ASM rulez, ale to nie jest chyba sztywna zasada, że każdy ma wszystko robić w assemblerze, poza tym jeśli ktoś stworzył algorytmy przesuwania ekranu w C, to znaczy, że chyba coś można jednak w C zrobić.
Tak w ogóle, to chyba temat powinien zostać przeniesiony do działu programowanie :)
Pierwsze co wogóle chciałbym zrobić to pomieszczenie skłądające się z dwóch ekranów, przesuwanych lewo-prawo, bohater i jakieś platformy do skakania, to by było takie moje środowisko robocze, w którym testowałbym swoje postępy, cała reszta byłaby dorobiona, dopiero, gdy w środowisku testowym technicznie wyglądałby wszystko na akceptowalnym poziomie.
Hołdys, ja rozumiem Twoje podejście ASM rulez, ale to nie jest chyba sztywna zasada, że każdy ma wszystko robić w assemblerze, poza tym jeśli ktoś stworzył algorytmy przesuwania ekranu w C, to znaczy, że chyba coś można jednak w C zrobić.
Tak w ogóle, to chyba temat powinien zostać przeniesiony do działu programowanie :)
23.10.2010 18:53
[#105]
Re: Ktoś jeszcze pisze gry na klasyki
@rafgc, post #102
Można przepisać ten przykład do zwykłego C, każdy zresztą program w C++ można napisać również w C, wiąże się to jednak z koniecznością rezygnacji z komfortu jakie daje programowanie zorientowane obiektowo.
Drugie rozwiązanie to programowanie obiektowe w Amiga E (Object Oriented E). Amiga E jest nastawiony na produkowanie kodu dla Amigi 68k więc podejrzewam, że prędkość kodu wynikowego będzie zadowalająca. No, ale tutaj musiałbyś nauczyć się Amiga E, co nie jest jednak trudne jeśli zna się już taki język jak C lub Pascal.
Ostatnia modyfikacja: 23.10.2010 18:53:50
Drugie rozwiązanie to programowanie obiektowe w Amiga E (Object Oriented E). Amiga E jest nastawiony na produkowanie kodu dla Amigi 68k więc podejrzewam, że prędkość kodu wynikowego będzie zadowalająca. No, ale tutaj musiałbyś nauczyć się Amiga E, co nie jest jednak trudne jeśli zna się już taki język jak C lub Pascal.
Ostatnia modyfikacja: 23.10.2010 18:53:50
24.10.2010 02:21
[#107]
Re: Ktoś jeszcze pisze gry na klasyki
@rafgc, post #106
AmigaE, odkąd jego Autor dawno temu uwolnił kod źródłowy dorobił się wielu klonów, nawet na PPC.
http://en.wikipedia.org/wiki/AmigaE
Swoją drogą, znalazłem taki bardzo stary testowy (i prymitywny) swój programik w E, który otwiera ekran, wyświetla obrazek, odtwarza muzykę w formacie AHX i skroluje w poziomie jakiś napis (procesorem, krótka procedurka w ASM). Nie pamiętam niestety teraz jak to działało w realu, ale na pewno pamiętam jeden swój wniosek: żadnych operacji na pojedynczych bitach w pamięci chip, tylko kopiowanie z pamięci fast głównie przez move.l. Jak się okazało, bardzo to ułatwiło pisanie softu bezpośrednio operującego na grafice bitplanowej, jak i jednocześnie działającego na kartach graficznych.
http://en.wikipedia.org/wiki/AmigaE
Swoją drogą, znalazłem taki bardzo stary testowy (i prymitywny) swój programik w E, który otwiera ekran, wyświetla obrazek, odtwarza muzykę w formacie AHX i skroluje w poziomie jakiś napis (procesorem, krótka procedurka w ASM). Nie pamiętam niestety teraz jak to działało w realu, ale na pewno pamiętam jeden swój wniosek: żadnych operacji na pojedynczych bitach w pamięci chip, tylko kopiowanie z pamięci fast głównie przez move.l. Jak się okazało, bardzo to ułatwiło pisanie softu bezpośrednio operującego na grafice bitplanowej, jak i jednocześnie działającego na kartach graficznych.
24.10.2010 21:03
[#110]
Re: Ktoś jeszcze pisze gry na klasyki
@BagoZonde, post #108
Jak pobieżnie sprawdziłem (bo to są sprawy sprzed kilku lat), użyłem pakietu playthx.lha znalezionego na jakiejś płytce z Aminetem, ale dziś (jeśli już nie wówczas) jest to wręcz nie do znalezienia. Była chyba jakaś heca z prawami autorskimi czy nazwą THX - nie pamiętam teraz dobrze i nie chce mi się szukać. Zresztą i tak jest to już "trochę" przestarzałe.
A cały ten program to jedna wielka lameriada że aż wstyd (chciałem tylko sprawdzić kilka rzeczy, pewnie też odtwarzanie ahx/thx), zresztą jest w kilku wersjach - jedna skroluje krótszy napis, druga dłuższy, trzecia losowe piksele. Widzę też że eksperymentowałem z BFINS oraz ROXL.L, chyba zacząłem też pisać procedurkę operującą na pamięci Fast... W każdym razie i tak chyba nigdy nigdzie nie użyłem poziomego przewijania obrazu bitplanowego przez procesor, więc chyba mi to nie wyszło :)
Sto razy prościej użyć procedury C2P, ale oczywiście ma to swoje ograniczenia na klasyku (choć praca na "bajtopikselach" wiele rzeczy przyśpiesza)
A cały ten program to jedna wielka lameriada że aż wstyd (chciałem tylko sprawdzić kilka rzeczy, pewnie też odtwarzanie ahx/thx), zresztą jest w kilku wersjach - jedna skroluje krótszy napis, druga dłuższy, trzecia losowe piksele. Widzę też że eksperymentowałem z BFINS oraz ROXL.L, chyba zacząłem też pisać procedurkę operującą na pamięci Fast... W każdym razie i tak chyba nigdy nigdzie nie użyłem poziomego przewijania obrazu bitplanowego przez procesor, więc chyba mi to nie wyszło :)
Sto razy prościej użyć procedury C2P, ale oczywiście ma to swoje ograniczenia na klasyku (choć praca na "bajtopikselach" wiele rzeczy przyśpiesza)
26.10.2010 12:00
[#115]
Re: Ktoś jeszcze pisze gry na klasyki
@rafgc, post #113
Warto zajrzeć tutaj http://amigadev.elowar.com/. Jest także polskie tłumaczenie ( nieudolne i częściowe ) Hardware Manual pod tytułem Amiga bez Tejemnic. Znajdziesz je na Retroreaders.
Ostatnia modyfikacja: 26.10.2010 12:19:20
Ostatnia modyfikacja: 26.10.2010 12:19:20
26.10.2010 17:30
[#116]
Re: Ktoś jeszcze pisze gry na klasyki
@rafgc, post #113
Zdaje się, że tylko w bibliotece (np. Narodowej) można sobie tę książkę poczytać. W sprzedaży juz jej dawno nie ma, być może można kupić ją czasami na allegro. Zdaje się też, że ktoś już się kiedyś chwalił na PPA, że ma chyba ją w formie PDF-a. Ale według mnie przeczytanie tej książki, to jest najprostsza metoda na naukę programowania w asemblerze na Amigę, gdyż zawiera przykłady z opisem po polsku.
Ostatnia modyfikacja: 26.10.2010 17:30:22
Ostatnia modyfikacja: 26.10.2010 17:30:22
26.10.2010 21:22
[#117]
Re: Ktoś jeszcze pisze gry na klasyki
@Don_Adan, post #116
Mam do dziś tę książkę i pomocna była mi w nauce asemblera. Całkiem niezła, jest tylko jeden "mały" problem: ten sposób programowania (na poziomie sprzętowym), przynajmniej jako coś powszechnego, skończył się już dawno temu, jeszcze w czasach Amig klasycznych - a wyjątki tylko potwierdzają regułę.
Większość przykładów jest praktycznie bezużyteczna i może wprowadzać początkujących w błąd, a pomijając trudność i niezrozumiałość, mogą też nie działać na czymś lepszym od A500. Jedyny plus jaki widzę, to pogłębienie wiedzy o możliwościach starego sprzętu i na pewno pewien zasób cennych porad i informacji.
No chyba, że ktoś chciałby jeszcze napisać odpalaną z dyskietek gierkę na A500 lub gołą A1200 - ale to już absolutnie poza zasięgiem "zielonych" programistów.
Większość przykładów jest praktycznie bezużyteczna i może wprowadzać początkujących w błąd, a pomijając trudność i niezrozumiałość, mogą też nie działać na czymś lepszym od A500. Jedyny plus jaki widzę, to pogłębienie wiedzy o możliwościach starego sprzętu i na pewno pewien zasób cennych porad i informacji.
No chyba, że ktoś chciałby jeszcze napisać odpalaną z dyskietek gierkę na A500 lub gołą A1200 - ale to już absolutnie poza zasięgiem "zielonych" programistów.
26.10.2010 22:49
[#118]
Re: Ktoś jeszcze pisze gry na klasyki
@Adam Kulesza, post #117
Całkiem niezła, jest tylko jeden "mały" problem: ten sposób programowania (na poziomie sprzętowym), przynajmniej jako coś powszechnego, skończył się już dawno temu, jeszcze w czasach Amig klasycznych - a wyjątki tylko potwierdzają regułę.
Zatem jaki sposób programowania proponujesz dla gołej A500 badź też gołęj A1200 ?
Większość przykładów jest praktycznie bezużyteczna i może wprowadzać początkujących w błąd, a pomijając trudność i niezrozumiałość, mogą też nie działać na czymś lepszym od A500.
Nie za bardzo chwytam z tym wprowadzaniem w błąd ? Mógłbyś rozwinąć. Dziękuje.
No chyba, że ktoś chciałby jeszcze napisać odpalaną z dyskietek gierkę na A500 lub gołą A1200 - ale to już absolutnie poza zasięgiem "zielonych" programistów.
Niekoniecznie, teraz jest zdecydowanie łatwiej, zawsze można zapytać na forum, jak nie na tym to na EAB.
Zatem jaki sposób programowania proponujesz dla gołej A500 badź też gołęj A1200 ?
Większość przykładów jest praktycznie bezużyteczna i może wprowadzać początkujących w błąd, a pomijając trudność i niezrozumiałość, mogą też nie działać na czymś lepszym od A500.
Nie za bardzo chwytam z tym wprowadzaniem w błąd ? Mógłbyś rozwinąć. Dziękuje.
No chyba, że ktoś chciałby jeszcze napisać odpalaną z dyskietek gierkę na A500 lub gołą A1200 - ale to już absolutnie poza zasięgiem "zielonych" programistów.
Niekoniecznie, teraz jest zdecydowanie łatwiej, zawsze można zapytać na forum, jak nie na tym to na EAB.
27.10.2010 00:43
[#120]
Re: Ktoś jeszcze pisze gry na klasyki
@asman, post #118
: Zatem jaki sposób programowania proponujesz dla gołej A500 badź też gołęj A1200 ?
Dla początkującego? Szczerze? Amos albo Blitz Basic ;)
(pomijając, że początkującemu odradzałbym już robienie czegoś na ten sprzęt. Nie ma to sensu, za dużo się zmieniło...)
: Nie za bardzo chwytam z tym wprowadzaniem w błąd ?
Jak pisałem: nie obsługuje się zasobów komputera w ten sposób (o wyjątkach już pisałem). Nie ma to też sensu (zwłaszcza np. blitter i sprajty), chyba że są założenia, że bardzo słaby klasyk i tylko pod emulator. Ale za tym musi iść wiedza, spora dawka umiejętności, a w tej chwili niemal niesamowite samozaparcie, bo nikomu to już nie jest praktycznie potrzebne. Wszystko się zmieniło, Amiga - choć poniosła klęskę - także. Jak więc pisałem, początkujący odpada.
Dla początkującego? Szczerze? Amos albo Blitz Basic ;)
(pomijając, że początkującemu odradzałbym już robienie czegoś na ten sprzęt. Nie ma to sensu, za dużo się zmieniło...)
: Nie za bardzo chwytam z tym wprowadzaniem w błąd ?
Jak pisałem: nie obsługuje się zasobów komputera w ten sposób (o wyjątkach już pisałem). Nie ma to też sensu (zwłaszcza np. blitter i sprajty), chyba że są założenia, że bardzo słaby klasyk i tylko pod emulator. Ale za tym musi iść wiedza, spora dawka umiejętności, a w tej chwili niemal niesamowite samozaparcie, bo nikomu to już nie jest praktycznie potrzebne. Wszystko się zmieniło, Amiga - choć poniosła klęskę - także. Jak więc pisałem, początkujący odpada.