Komentowana treść: Studio do tworzenia gier w formie biblioteki
22.05.2012 20:08
[#3]
Re: Studio do tworzenia gier w formie biblioteki
@selur, post #1
RPGa rzeczywiście zaprzestałem, ale dlatego że był to trudny projekt - zaprojektowanie i stworzenie interpretera skryptu zajęłoby trochę czasu. Postanowiłem wziąć się za coś łatwiejszego i z założenia dającego możliwość stworzenia interesujących gier arkadowych.
Zrobiłem już program demonstrujący bieżące możliwości biblioteczki o nazwie Piłeczki. Przedstawia on 12 dużych piłeczek odbijających się od ścian ekranu: Można podmieniać grafikę, wystarczy zamienić pliki (użyłem palety 16 kolorów).
http://minniatian.republika.pl/GameX/Pileczki.lha
Najlepiej jak ma się w komputerze co najmniej pamięć FAST. Wtedy program jest wykonywany z zadowalającą prędkością (program wykonywany w pamięci FAST działa szybciej), testowane na Amidze 1200 z 68040 i fastem. Usprawniłem dzisiaj podwójne buforowanie, tak że demko śmiga u mnie :D
Po tym demku następna w kolejności powinna być już mini-gierka. Mam już narysowaną pszczołę i helikopter :) Wymaga to rozbudowy pakietu o brakujące klasy.
@Mirek
Wprost przeciwnie, uważam, że to dobra kolejność. Dzięki tej biblioteczce mogłem szybko napisać tę prostą animację, i, będę mógł łatwiej i skuteczniej pisać gry (również innym programistom piszącym w C, bo mam zamiar napisać instrukcję i rozprowadzać pliki obiektów). Moje założenie jest: od prostych rzeczy po bardziej złożone.
Ostatnia aktualizacja: 22.05.2012 20:11:27 przez Robert-Minimat-Szacki
Zrobiłem już program demonstrujący bieżące możliwości biblioteczki o nazwie Piłeczki. Przedstawia on 12 dużych piłeczek odbijających się od ścian ekranu: Można podmieniać grafikę, wystarczy zamienić pliki (użyłem palety 16 kolorów).
http://minniatian.republika.pl/GameX/Pileczki.lha
Najlepiej jak ma się w komputerze co najmniej pamięć FAST. Wtedy program jest wykonywany z zadowalającą prędkością (program wykonywany w pamięci FAST działa szybciej), testowane na Amidze 1200 z 68040 i fastem. Usprawniłem dzisiaj podwójne buforowanie, tak że demko śmiga u mnie :D
Po tym demku następna w kolejności powinna być już mini-gierka. Mam już narysowaną pszczołę i helikopter :) Wymaga to rozbudowy pakietu o brakujące klasy.
@Mirek
Wprost przeciwnie, uważam, że to dobra kolejność. Dzięki tej biblioteczce mogłem szybko napisać tę prostą animację, i, będę mógł łatwiej i skuteczniej pisać gry (również innym programistom piszącym w C, bo mam zamiar napisać instrukcję i rozprowadzać pliki obiektów). Moje założenie jest: od prostych rzeczy po bardziej złożone.
Ostatnia aktualizacja: 22.05.2012 20:11:27 przez Robert-Minimat-Szacki
22.05.2012 21:08
[#5]
Re: Studio do tworzenia gier w formie biblioteki
@Mir3k, post #4
Na stronce w tej chwili jest kod źródłowy, jak klikniesz na odpowiedni link na górze strony, ale raczej nie będę udostępniał kodu źródłowego kolejnych rewizji, tylko pliki obiektów oraz pliki nagłówkowe. Co do artykułu to tak, zamierzam coś napisać na ten temat (przecież potrzebny jest opis biblioteki dla piszących swoje gry).
22.05.2012 21:49
[#6]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #5
Co do kodu źródłowego to mógłbyś poprawić przynajmniej najbardziej rażące błędy. używanie bitmap-planes[0] to jakaś kompletna pomyłka. Pomijam to, że nie zadziała na kartach graficznych to nie będzie tez działać na AGA/ECS/OCS. Uprzedzając twoją odpowiedź o BMF_INTERLEAVED poczytaj sobie co tak naprawdę ta flaga robi przy alokowaniu bitrmap. Powodzenia...
22.05.2012 22:05
[#8]
Re: Studio do tworzenia gier w formie biblioteki
@minniat:
I jeszcze jedno. Proponuję w obecnej bibliotece spróbować wyświetlić boba choćby kawałek poza lewą lub górną krawędzią ekranu (częściowo obcięty).
I jeszcze jedno. Proponuję w obecnej bibliotece spróbować wyświetlić boba choćby kawałek poza lewą lub górną krawędzią ekranu (częściowo obcięty).
22.05.2012 22:09
[#9]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #6
Użycie BMF_INTERLEAVED daje mi dwie korzyści:
1) rysowanie jednego obiektu graficznego zajmuje tylko jedną operację blitowania, a nie kilka (oczywiście sam rozmiar blitu jest większy).
2) ładowanie ILBM jest ogromnie uproszczone
Wiem jak technicznie wygląda bitmapa zaalokowana z flagą BMF_INTERLEAVED.
Z Bitmap-Planes[0] korzystam wiedząc, że nie jest to kompatybilne z kartami graficznymi, ale robię to dlatego, że dzięki temu mogę w banalny sposób załączać grafikę z Bitmap do obiektów typu Bob. Nie rozumiem dlaczego piszesz, że nie zadziała to na AGA?
Pamiętaj, że ja sporo poświęcam uwagi na optymalizację procedur dla klasyka. Funkcja BltMaskBitMapRastPort() jest troszkę za wolna. Technicznie też takie korzystanie z Bitmap nie jest wzbronione przez dokumentację na Amiga Developer CD 2.1. Jeśli będę pisał wersję specjalnie dla karty graficznej (a można to zrobić stosunkowo prosto), to dopiero wtedy będę się trzymał dokumentacji do CybergraphX bądź Picasso96, ale teraz nie chcę sobie utrudniać życia, bo powód jest prosty - klasyk ma u mnie pierwszeństwo.
1) rysowanie jednego obiektu graficznego zajmuje tylko jedną operację blitowania, a nie kilka (oczywiście sam rozmiar blitu jest większy).
2) ładowanie ILBM jest ogromnie uproszczone
Wiem jak technicznie wygląda bitmapa zaalokowana z flagą BMF_INTERLEAVED.
Z Bitmap-Planes[0] korzystam wiedząc, że nie jest to kompatybilne z kartami graficznymi, ale robię to dlatego, że dzięki temu mogę w banalny sposób załączać grafikę z Bitmap do obiektów typu Bob. Nie rozumiem dlaczego piszesz, że nie zadziała to na AGA?
Pamiętaj, że ja sporo poświęcam uwagi na optymalizację procedur dla klasyka. Funkcja BltMaskBitMapRastPort() jest troszkę za wolna. Technicznie też takie korzystanie z Bitmap nie jest wzbronione przez dokumentację na Amiga Developer CD 2.1. Jeśli będę pisał wersję specjalnie dla karty graficznej (a można to zrobić stosunkowo prosto), to dopiero wtedy będę się trzymał dokumentacji do CybergraphX bądź Picasso96, ale teraz nie chcę sobie utrudniać życia, bo powód jest prosty - klasyk ma u mnie pierwszeństwo.
22.05.2012 22:12
[#10]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #9
BMF_INTERLEAVED tells graphics that you would like your
bitmap to be allocated with one large chunk of display
memory for all bitplanes. This minimizes color flashing
on deep displays. If there is not enough contiguous RAM
for an interleaved bitmap, graphics.library will fall
back to a non-interleaved one.
Proponuję na przyszłość dokładniej czytać dokumentację jeżeli nie wiesz jak działają funkcji amigowych bibliotek.
bitmap to be allocated with one large chunk of display
memory for all bitplanes. This minimizes color flashing
on deep displays. If there is not enough contiguous RAM
for an interleaved bitmap, graphics.library will fall
back to a non-interleaved one.
Proponuję na przyszłość dokładniej czytać dokumentację jeżeli nie wiesz jak działają funkcji amigowych bibliotek.
22.05.2012 22:35
[#11]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #10
Wiem, że znowu mówię o rzeźbieniu w systemowych strukturach, ale pole BytesPerRow bitmapy zwykłej i Interleaved, jak i pola Planes[0..7] są odpowiednio ustawione. Obecnie mój kod tego nie uwzględnia (z góry zakładam, że bitmapa jest typu Interleaved). Wiem, że są funkcje ReadPixelArray, WritePixelArray do manipulacji Bitmapą, ale wymusiłyby one na mnie konwersję grafiki z ILBM na chunky czego w tej chwili pragnę uniknąć (no jeszcze pozostają Datatypy, ale sprawi to kolejne trudności).
Generalnie pisania jest dość dużo przy takiej biblioteczce, dziękuję za znalezione błędy lub niedociągnięcia, ja jestem bardzo szczęśliwy, bo coś udało mi się dokończyć (mowa o dotychczasowej wersji biblioteki). Teraz poczekajcie na mini-grę (chyba będzie to śmigłowiec strzelający rakietami, bądź latająca pszczoła), no i na release biblioteczki z instrukcją! :)
Ostatnia aktualizacja: 22.05.2012 22:37:12 przez Robert-Minimat-Szacki
Generalnie pisania jest dość dużo przy takiej biblioteczce, dziękuję za znalezione błędy lub niedociągnięcia, ja jestem bardzo szczęśliwy, bo coś udało mi się dokończyć (mowa o dotychczasowej wersji biblioteki). Teraz poczekajcie na mini-grę (chyba będzie to śmigłowiec strzelający rakietami, bądź latająca pszczoła), no i na release biblioteczki z instrukcją! :)
Ostatnia aktualizacja: 22.05.2012 22:37:12 przez Robert-Minimat-Szacki
22.05.2012 22:52
[#13]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #12
Dlatego też uwzględnię Twój raport podczas modernizacji kodu - procedura DrawGxBob będzie obliczać wszystkie parametry blitu na podstawie pól struktury Bitmap (mowa o wersji GameX dla klasyka z AGA). Zauważ, że przyznałem się do błędu, a grunt to wiedzieć o problemie.
Ostatnia aktualizacja: 22.05.2012 22:54:30 przez Robert-Minimat-Szacki
Ostatnia aktualizacja: 22.05.2012 22:54:30 przez Robert-Minimat-Szacki
22.05.2012 22:56
[#14]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #13
Rysowanie bobow nie ma nic wspolnego z bitmapami (przeczytaj jeszcze raz opis dla flagi BMF_INTERLEAVED bo widze, ze nie widzisz kiedy twoje aplikacje beda zawieszaly system). Oba bledy (wczytywanie grafik i rysowanie bobow) sa niezalezne od siebie. W celu lokalizacji problemu z rysowaniem bobow proponuje przestudiowanie swoich plikow naglowkowych.
22.05.2012 23:01
[#15]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #14
Chodzi Ci o to, że bitmapa może nie być typu INTERLEAVED, nawet jeśli takiej zażądam jeśli system nie znajdzie wystarczająco dużo pamięci. Rzeczywiście W takim razie procedura wczytywania IFFów też będzie musiała być zmodernizowana (wczytywanie będzie musiało również bazować na nagłówku BitMapy), dzięki za znalezienie błędu.
22.05.2012 23:23
[#20]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #19
To o co chodziło? Czemu tego nie wyjaśniłeś? Przecież nie będę się dopytywał w kolejnym poście tak jak teraz czynię... Czasem mam wrażenie że nie zależy Ci na wytknięciu błędu tylko na tym, by mi dokuczyć na forum. Napisz po prostu jaki widzisz problem, ja jak mogłeś się przekonać czytam posty, ale nie będę co chwila obiecywał, że coś poprawię. Mam zamiar poprawiać zgłoszone błędy, ale o kolejności działań dopiero zdecyduję. A tymczasem dość takiej rozwlekłej rozmowy, w taki sposób możesz mi to zgłaszać na priva, aniżeli zawstydzać na forum. No i zrobiło się już późno.
22.05.2012 23:34
[#21]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #20
to moja ostatnia podpowiedz. jezeli nawet nie chcialo ci sie sprawdzic to po co ja mam sie wysilac? masz pola x/y jako wartosci bez znaku co znaczy, ze nie mozesz wstawic tam ujemnej wartosci bo zostanie ona odczytana jako duza wartosc dodatnia. powodzenia i czekam na informacje o zawieszeniu prac nad biblioteka...
22.05.2012 23:43
[#22]
Re: Studio do tworzenia gier w formie biblioteki
@kiero, post #21
Kwestia znaku współrzędnych Bobów została dzisiaj poprawiona, tylko na necie leżą starsze źródła, podobnie double-buffering jest realizowany lepiej. Mam nadzieję, że tej biblioteczki nie czeka los innych moich projektów, bo jest to rzecz nad którą od początku pracuję sam. Współpraca z grafikiem mi tylko nie wychodzi, bo on ma jakąś odmienną wizję całej gry i pod tym kątem projektuje grafikę.
Pisanie tej biblioteczki idzie mi bardzo dobrze, myślę, że uda mi się projekt rozwinąć. Do weekendu powinienem uporać się z obsługą joysticka, dźwięków, może nawet muzyki, naprawię błędy zgłoszone przez Kiero odnośnie bitmap interleaved i zaprojektuję jakiegoś sympatycznego shootera, lub collect'em'upa. Taki plan da się zrealizować.
Ostatnia aktualizacja: 22.05.2012 23:51:48 przez Robert-Minimat-Szacki
Pisanie tej biblioteczki idzie mi bardzo dobrze, myślę, że uda mi się projekt rozwinąć. Do weekendu powinienem uporać się z obsługą joysticka, dźwięków, może nawet muzyki, naprawię błędy zgłoszone przez Kiero odnośnie bitmap interleaved i zaprojektuję jakiegoś sympatycznego shootera, lub collect'em'upa. Taki plan da się zrealizować.
Ostatnia aktualizacja: 22.05.2012 23:51:48 przez Robert-Minimat-Szacki
23.05.2012 00:13
[#23]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #3
i taki silniczek/biblioteki to bardzo dobry pomysł 
sprawdziłem te demo i tak rusza nawet na konfiguracji a'la A600 z 1MB chip
Niestety na OCS nie działa
co tam jeszcze... no miło by było jakby piłki się od siebie odbijały. W sumie najlepiej by było jakby odbijały się od siebie nie na zasadzie boxów tylko od faktycznych pikseli. Nie wiem czy taka funkcja jest dostępna ale miło by było jakby się pojawiła.
sprawdziłem te demo i tak rusza nawet na konfiguracji a'la A600 z 1MB chip
Niestety na OCS nie działa
co tam jeszcze... no miło by było jakby piłki się od siebie odbijały. W sumie najlepiej by było jakby odbijały się od siebie nie na zasadzie boxów tylko od faktycznych pikseli. Nie wiem czy taka funkcja jest dostępna ale miło by było jakby się pojawiła.
23.05.2012 00:33
[#24]
Re: Studio do tworzenia gier w formie biblioteki
@Mir3k, post #2
Taki toolkit to by była fajna rzecz gdzieś w 1990, bo takich technik się wtedy używało. Grzebanie w strukturach systemowych w 2012? Hacki działające (losowo z resztą) jedynie na ECS/AGA? Wtf? Jeśli zakładamy "łatwą przenośność między systemami" to rozpoczynanie prac od tworzenia kodu i API biblioteki, które od początku działać mogą jedynie na klasykach to jakieś nieporozumienie. Nic z tego nie wyjdzie.
To taki hint na szybko, może się czegoś nauczysz: jeśli chcesz mieć przenośny kod, to nie używaj modeid, bo to jest po pierwsze mocno przestarzałe nawet w amiświatku, a po drugie jeśli chciałbyś przenosić kiedyś kod na inne platformy - zupełnie nieprzenośne. Parametry, które powinien określać programista tworzący ekran to rozmiar ekranu, głębia lub format piksela, etc, natomiast to Twoja biblioteka powinna sama odnajdować najbliższy pasujący modeid podczas otwierania ekranu.
Ostatnia aktualizacja: 23.05.2012 00:40:53 przez Jacek Piszczek
To taki hint na szybko, może się czegoś nauczysz: jeśli chcesz mieć przenośny kod, to nie używaj modeid, bo to jest po pierwsze mocno przestarzałe nawet w amiświatku, a po drugie jeśli chciałbyś przenosić kiedyś kod na inne platformy - zupełnie nieprzenośne. Parametry, które powinien określać programista tworzący ekran to rozmiar ekranu, głębia lub format piksela, etc, natomiast to Twoja biblioteka powinna sama odnajdować najbliższy pasujący modeid podczas otwierania ekranu.
Ostatnia aktualizacja: 23.05.2012 00:40:53 przez Jacek Piszczek
23.05.2012 01:22
[#25]
Re: Studio do tworzenia gier w formie biblioteki
@Jacek Piszczek, post #24
Moja a1200, która pochodzi z 1992 roku również magicznym sposobem nie "unowocześniła się", jest nadal komputerem z 1992 roku, dlatego używam takiej techniki blitowania, jaka na niej jest skuteczna. Potrafię napisać to tak, by było bardziej przenośne, na przykład dane z plików graficznych byłyby w formacie chunky 8-bit i tak pewnie docelowo będzie. Póki co zastosowałem proste ładowanie z plików IFF.
Jeśli chodzi o modeid, to akurat funkcja GxOpenScreen (wcześniej GetGxScreen) jest tak sprytnie zaprojektowana, że pobiera indeks w tablicy trybów, tj. rozmiar ekranu i jego głębia w różnych trybach jest określona wewnątrz pliku gxscreen.o i interpretowana przez funkcje wewnątrz tego pliku. Obecnie dwa tryby - tradycyjne LORES 320x256 i HIRES 640x256 znane z Amigi są tam zapisane, ale można wprowadzić nowe np. 320x240, 640x480, 800x600 itp.
Chodzi też o to, żeby programy napisane z użyciem tej biblioteki były szybkie, czyli procedury były dostosowane do architektury i możliwości sprzętu. Oznacza to, że najpewniej powstaną oddzielne pliki gxscreen.o dla Amigi 1200, dla AmigaOS 4, każda realizująca zadanie w inny sposób. Bo wiadomo, że na Amidze 1200 nie uruchomię trybów 24-bit, a na MorphOSie nie skorzystam z Blittera. Oczywiście prototypy funkcji, ich protokół będzie identyczny, różne byłoby za to ciało funkcji.
Także przenośność jest tu zrealizowana w troszkę inny sposób, funkcje nie będą uniwersalne, jedynie API ma być takie samo. Programy by linkowało się z odpowiednimi plikami obiektów na różnych platformach. Nie wiem jeszcze jak się to sprawdzi w praktyce, ale ma to sens. Myślę, że będzie to znacznie lepsze rozwiązanie od dotychczas zastosowanych. Jestem autorem, więc proszę pisać do mnie odnośnie projektu, np. autorzy SDL nie interesują się naszymi platformami, a ja wprost przeciwnie. Proszę zatem nie skreślać projektu, zawsze można przecież zmodyfikować użyte techniki.
Podam jeszcze jeden przykład - na Amidze klasycznej np. nie skorzystam z AHI, tylko z audio.device a na MorphOSie pewnie AHI jest niezbędne. Jak to pogodzić? Ano właśnie skonstruować dwie funkcje o tym samym protokole, ale innym ciele - jeden wykorzystujący AHI, a drugi audio.device. Czy wyjaśniłem już mój pomysł? Podobnie będzie np. z obsługą kontrolera - w Amidze będzie to joystick i gameport.device itd.
Pozwólcie mi dokończyć gierkę przykładową. Żeby być szczerym planowałem użyć gameport.device i audio.device i pewnie wkrótce zostałbym skrytykowany, że nie używam AHI i joysticka na USB. Nie wszystko da się tak łatwo pogodzić. Obsługę tych drugich rzeczy zostawiłbym komuś kto np. przeniesie GameX na MorphOSa. Tymczasem życzę dobranoc wszystkim czytającym i Jackowi Piszczkowi.
Ostatnia aktualizacja: 23.05.2012 01:25:24 przez Robert-Minimat-Szacki
Jeśli chodzi o modeid, to akurat funkcja GxOpenScreen (wcześniej GetGxScreen) jest tak sprytnie zaprojektowana, że pobiera indeks w tablicy trybów, tj. rozmiar ekranu i jego głębia w różnych trybach jest określona wewnątrz pliku gxscreen.o i interpretowana przez funkcje wewnątrz tego pliku. Obecnie dwa tryby - tradycyjne LORES 320x256 i HIRES 640x256 znane z Amigi są tam zapisane, ale można wprowadzić nowe np. 320x240, 640x480, 800x600 itp.
Chodzi też o to, żeby programy napisane z użyciem tej biblioteki były szybkie, czyli procedury były dostosowane do architektury i możliwości sprzętu. Oznacza to, że najpewniej powstaną oddzielne pliki gxscreen.o dla Amigi 1200, dla AmigaOS 4, każda realizująca zadanie w inny sposób. Bo wiadomo, że na Amidze 1200 nie uruchomię trybów 24-bit, a na MorphOSie nie skorzystam z Blittera. Oczywiście prototypy funkcji, ich protokół będzie identyczny, różne byłoby za to ciało funkcji.
Także przenośność jest tu zrealizowana w troszkę inny sposób, funkcje nie będą uniwersalne, jedynie API ma być takie samo. Programy by linkowało się z odpowiednimi plikami obiektów na różnych platformach. Nie wiem jeszcze jak się to sprawdzi w praktyce, ale ma to sens. Myślę, że będzie to znacznie lepsze rozwiązanie od dotychczas zastosowanych. Jestem autorem, więc proszę pisać do mnie odnośnie projektu, np. autorzy SDL nie interesują się naszymi platformami, a ja wprost przeciwnie. Proszę zatem nie skreślać projektu, zawsze można przecież zmodyfikować użyte techniki.
Podam jeszcze jeden przykład - na Amidze klasycznej np. nie skorzystam z AHI, tylko z audio.device a na MorphOSie pewnie AHI jest niezbędne. Jak to pogodzić? Ano właśnie skonstruować dwie funkcje o tym samym protokole, ale innym ciele - jeden wykorzystujący AHI, a drugi audio.device. Czy wyjaśniłem już mój pomysł? Podobnie będzie np. z obsługą kontrolera - w Amidze będzie to joystick i gameport.device itd.
Pozwólcie mi dokończyć gierkę przykładową. Żeby być szczerym planowałem użyć gameport.device i audio.device i pewnie wkrótce zostałbym skrytykowany, że nie używam AHI i joysticka na USB. Nie wszystko da się tak łatwo pogodzić. Obsługę tych drugich rzeczy zostawiłbym komuś kto np. przeniesie GameX na MorphOSa. Tymczasem życzę dobranoc wszystkim czytającym i Jackowi Piszczkowi.
Ostatnia aktualizacja: 23.05.2012 01:25:24 przez Robert-Minimat-Szacki
23.05.2012 07:24
[#26]
Re: Studio do tworzenia gier w formie biblioteki
@XoR, post #23
W sumie najlepiej by było jakby odbijały się od siebie nie na zasadzie boxów
wykrycie kolizji dwoch okregow jest trywialne ;), ale po pikselach bedzie wiecej mielenia. zreszta w grach pcetowych tez najczesciej kolizje wykrywa sie po takich prymitywach, tylko uzywa sie ich wiecej na jeden obiekt, dlatego wydaje sie dokladniej.
23.05.2012 07:36
[#27]
Re: Studio do tworzenia gier w formie biblioteki
@Robert-Minimat-Szacki, post #25
ciezko bedzie Ci pogodzic swiat klasyka z lat 80 ze swiatem komputerow XXI wieku w temacie gier, bo to jednak zupelnie inne swiaty i inne podejscia do programowania gier, szczegolnie jezeli bedziesz chcial wykorzystac w pelni moc drzemiaco w klasykach i obecnym sprzecie, trudno to pogodzic ze soba nawet poprzez dodatkowa warstwe abstrakcji :)
moje zdanie jest takie, jak chcesz napisac gre na klasyka to pisz tylko na klasyka... w koncu kazdy na sprzecie XXI wieku uruchomi sobie toto na jakims uae bez problemu, jakby nie mial klasyka, to dzisiaj nie problem.
moje zdanie jest takie, jak chcesz napisac gre na klasyka to pisz tylko na klasyka... w koncu kazdy na sprzecie XXI wieku uruchomi sobie toto na jakims uae bez problemu, jakby nie mial klasyka, to dzisiaj nie problem.
23.05.2012 08:14
[#28]
Re: Studio do tworzenia gier w formie biblioteki
Pomiędzy jakimi systemami operacyjnymi to miałoby być przenoszone? Między amigowymi (AmigaOS3, AmigaOS4, MorphOS, AROS) czy też nieamigowymi?
Robienie takiego prostego silniczka (nawet tylko 2D) to jest moim zdaniem zajęcie na min. rok. A i to bez testów i ze strasznymi bugami. No i po roku oczywiście zawsze dochodzi się do wniosku, że to wszystko trzeba przepisać. :) Nie wiem czy gra jest warta świeczki. Takich prostych silniczków 2D do prostych gier jest cała masa (chociaż nie wiem czy na klasyka). Nigdy tego nie używałem, bo to zawsze są ograniczenia. Poza tym używając silnika czuję się bardziej jak użytkownik aplikacji z tekstowym interfejsem użytkownika niż programista. Zupełnie nie sprawia mi to radochy. A próbowałem...
Robienie takiego prostego silniczka (nawet tylko 2D) to jest moim zdaniem zajęcie na min. rok. A i to bez testów i ze strasznymi bugami. No i po roku oczywiście zawsze dochodzi się do wniosku, że to wszystko trzeba przepisać. :) Nie wiem czy gra jest warta świeczki. Takich prostych silniczków 2D do prostych gier jest cała masa (chociaż nie wiem czy na klasyka). Nigdy tego nie używałem, bo to zawsze są ograniczenia. Poza tym używając silnika czuję się bardziej jak użytkownik aplikacji z tekstowym interfejsem użytkownika niż programista. Zupełnie nie sprawia mi to radochy. A próbowałem...
23.05.2012 08:44
[#30]
Re: Studio do tworzenia gier w formie biblioteki
Też kiedyś myślałem, że udostępnię światu ten mój śmietnik (wolę taką nazwę niż "silnik 3D"), który robię od lat. Jednak obleciał gdy sobie zdałem sprawę z tego, że potem musiałbym to wszystko udokumentować, dokończyć elementy, których nie skończyłem, bo nie były mi potrzebne. No i potem weź rozwiązuj zgłoszone przez ludzi problemy, pomagaj, wyjaśniaj, tłumacz. Musiałbym odłożyć wszystko co robię żeby utrzymywać przy życiu tę swoją parodię silnika w wersji dla ludzkości. Poza tym i tak 99% ludzi wolałaby wybrać jakiś bardziej uznany silniczek niż uczyć się jakiegoś dziwadła, które cholera wie jak długo będzie utrzymywane i nigdy nie dogoni uznanych (darmowych) silników. Jak robię dla siebie to mogę sobie pozwolić na pewne uproszczenia, mało uniwersalne rzeczy, odłożenie pewnych elementów na przyszłość, skupienie się na czymś innym (czego wymaga aktualnie klepana gra). Stworzenie wersji dla ludzi jest dla mnie niewykonalne, bo już teraz nie mam zupełnie czasu na to co tam ciągnę nocami kosztem snu, reputacji, w konflikcie ze światem zewnętrznym. :)
Ostatnia aktualizacja: 23.05.2012 08:46:16 przez MDW
Ostatnia aktualizacja: 23.05.2012 08:46:16 przez MDW